出品方 | 快手研發效能委員會 x 研發效能中心
概 況
在快手全面推進「AI 研發典範升級」的進程中，如何將個人使用 AI 帶來的效率提升，轉化為組織整體的交付效能，是必須攻克的核心命題。智能程式碼審查系統正是破解這一命題的關鍵環節——它作用於個人開發完成之後、團隊交付合併之前，通過品質過濾和知識沉澱，讓 AI 能力從「私人助理」升級為「團隊協作者」。
在傳統研發流程中，Code Review（程式碼審查）往往面臨人工覆核成本高、標準不統一、評審深度難下沉的結構性痛點。本文總結了快手智能程式碼審查系統從「純 LLM 啟發式」到「知識引擎 + 規則確定性」，再到「Agentic 自主決策」的三代架構演進。
針對 AI 幻覺這一核心頑疾，快手技術團隊通過構建 Context 引擎與沉澱 1,100+ 條確定性規則，輔以三層過濾與 BadCase 反例庫，將評審採納率從 7.9% 躍升至 54%，並將 MR 評審時長 80 分位顯著縮短 9.9%；通過「知識工程」提升大模型準確性，讓智能評審真正落地為可信賴的生產力工具，也為 AI 時代如何實現「個人提效→組織提效」的傳導提供了可複用的實踐樣本。
背 景
1.1 效率與品質的博弈：傳統 CR 模式的固有痛點
在快手高速迭代的業務場景下，程式碼變更的規模與日俱增，傳統的人工程式碼審查模式逐漸不堪重負，其固有的三大痛點日益凸顯：
• 效率低下，響應看「緣分」
當程式碼變更量級較大時，人工 CR 的成本顯著增加。評審週期被拉長，響應時效完全取決於 Reviewer 的忙閒程度，一個核心倉庫的 MR 排隊等待 48 小時已是常態，嚴重影響了業務交付的整體速度。
• 基礎錯誤，防不勝防
人類的認知注意力是有限的。評審者在面對複雜邏輯時，往往會潛意識地忽略那些看似簡單的基礎錯誤。例如，if((a || b) && c) 在刪除條件 b 時誤改為 if(a || c)，或出現 a.setId(a.getId()) 這樣的明顯賦值錯誤。然而，數據表明，這類「基礎失誤」在程式碼變更引發的線上故障中占有相當高的比例。
• 效果不穩，知識難傳承
評審品質的高度依賴於評審者的經驗和認知負荷。資深工程師的寶貴經驗和隱性知識難以系統化沉澱為團隊共識，而初級開發者則因經驗不足容易遺漏深層缺陷。這種不穩定性導致程式碼品質時好時壞，增加了生產環境的風險，並阻礙了團隊內部知識的有效傳承。
1.2 AI 的引入與新挑戰：如何破除「信任危機」
面對傳統 CR 的困境，智能化被視為必然出路。然而，在初期引入大模型進行程式碼審查時，我們遭遇了典型的 AI 信任危機，主要表現為如下幾方面：
• 「幻覺」問題
AI 基於片面程式碼片段進行推斷，容易產生大量不準確或錯誤的誤報，降低了評審結果的可靠性。
• 低價值建議
AI 生成的評論中包含大量通用性、無實質價值的建議，如「建議優化」、「可以考慮」等，導致開發者疲勞，降低了採納意願。
• Context 缺失
僅分析 Git Diff 片段，無法理解程式碼在系統中的完整作用。
• 知識不可控
大模型的「黑盒」特性使得評審標準的沉澱和傳承變得困難，難以形成統一的團隊規範。
這些問題導致 AI 評審評論品質較低，開發者普遍產生抵觸情緒，採納率長期徘徊在 10% 以下，嚴重影響了智能 CR 工具的推廣和應用。
效 果
快手智能 CR 取得的效果如下：
• 評論品質穩步提升
評論採納率持續提升，從智能 CR1.0 階段的不足 10% 穩步上升，現階段已穩定在 50%+。
• 助力評審效率提升
2025 年全年相對於 2024 年，快手 MR 評審時長 80 分位下降 9.9%，從 7.07 小時下降到 6.37 小時。特別是從 2025 年 6 月開始，評審時長呈現明顯下降趨勢，時間線與智能 CR 在公司層面大範圍推廣落地時間高度吻合。
• 覆蓋規模與深度
智能 CR 在快手完成公司級落地，MR 覆蓋達 74%，支援 Java、C/C++、JS/TS、GO 等主流語言，沉澱 1,100+ 條 CR 規則。
實踐 1：核心技術實現從啟發式到確定性和自主性融合的演進
在智能 CR 系統的建設過程中，快手始終秉持一個核心理念：工具不僅要「可用」，更要成為開發者「可信賴」的智能夥伴。整個智能 CR 系統經歷了三個關鍵演進階段：從最初的「純 LLM 啟發式評審」到「知識引擎驅動的確定性評審」，再到最新的「Agentic 自主決策評審」，每一次演進都是對前一階段核心問題的系統性解決，持續推動系統向更高可信度和實用性邁進。最終構建了一套高可信的智能 CR 框架，實現了從基礎功能到高可信評審能力的跨越。
3.1 智能 CR1.0：純 LLM 啟發式評審探索期
為解決人工 CR 的痛點，快手在 2024 年 Q2 開始引入 LLM 建設智能 CR 的探索，整體設計採用「粗篩 + 精評 + 過濾」的三步串聯流水線。
3.1.1 核心流程
• 步驟 1：CR 必要性判斷
輸入：MR Diff 片段
輸出：布林值（true/false）
目的：過濾無需評審的 MR，降低成本
• 步驟 2：Review 生成
基於模糊任務描述，LLM 進行啟發式評審
檢查項：語法 / 邏輯錯誤、效能問題、安全漏洞、可讀性、命名規範等
關鍵字檢測：XSS 相關 API（dangerouslySetInnerHTML、v-html、innerHTML 等）、base64 編碼字串
• 步驟 3：評論過濾
基於規則刪除低價值評論：註解 / 版權建議、未定義物件問題、CSS 問題、無效行號等
3.1.2 核心問題
• Context 嚴重不足
僅提供 MR Diff 片段，缺少完整方法體和跨檔案依賴
模型無法理解程式碼在系統中的完整作用，誤判率高
• 知識體系缺失，召回穩定性差
無規則庫支撐，完全依賴模型「黑盒」能力
團隊知識無法沉澱和傳承
評審標準不統一，品質波動大
• 任務定義過於寬泛
給模型的指令缺乏 Know-how，過於依賴模型自主理解
檢查項描述模糊（如「效能問題」、「安全問題」）
缺少具體場景和範例，模型難以準確把握評審重點
• 優化手段有限
對於 BadCase 缺乏可操作的優化路徑
無法系統性改進評審品質
3.1.3 階段總結
• 數據表現：評論採納率 7.9%，評論品質差、誤報多、無價值建議泛濫
• 技術驗證：證明了 AI 程式碼審查的技術可行性，暴露了純 LLM 驅動模式的根本性缺陷
• 演進方向：構建工程化的 Context 構造機制，建立領域知識體系（規則庫、最佳實踐），設計多層次品質保障機制
3.2 智能 CR2.0：知識引擎驅動的三階段確定性評審
針對智能 CR1.0 階段的 Context 不足、知識缺失、品質不穩定和調優成本高的痛點，我們在深入分析問題後，摒棄了「純 LLM 驅動」的思路，結合領域知識和工程鏈路，構建了「Context 工程 + 規則驅動評審 + 評論價值評估和 BadCase 攔截保障」的確定性評審框架，通過規則提供高確定性的知識，為 LLM 劃定評審範圍和重點，再結合 LLM 強大的程式碼理解與邏輯推理能力，兩者的互補與融合確保評審結果的準確性和可解釋性，實現了從基礎功能到高可信評審能力的跨越。
3.2.1 Context 智能構造引擎
為解決「Context 缺失導致誤判」的痛點，我們構建了多層次的 Context 理解能力，旨在全面、準確地理解程式碼變更的「全貌」。從原始 Git Diff 到富 Context Prompt 的生成，包含以下關鍵能力：
• 語言智能識別：自動識別 Java、JS/TS、Go 等 10+ 種程式語言，適配差異化分析策略
• 方法體擴展：突破 Git Diff 片段限制，從 diff 行擴展到完整方法體，避免斷章取義
• AST 深度解析：通過抽象語法樹理解程式碼結構語義和控制流
• 跨檔案依賴推斷：識別介面、方法之間的調用關係，評估變更的潛在影響範圍。
• Diff 智能切分：將大型變更集拆分為邏輯獨立的評審單元，突破 token 視窗限制，提升評審聚焦度
• PRD 需求關聯：通過關聯需求文件（PRD），進一步豐富 Context 資訊，確保評審建議與業務目標對齊
3.2.2 Map-Reduce 長 Context 處理
智能 CR 推進落地過程中，出現了因為大 MR 或大規則集導致模型注意力不集中引起漏召甚至超出模型 Context 視窗的問題，我們採用類似於 Map-Reduce 的分散式處理邏輯，將長 Context 問題分解為拆分→處理→合併三個階段。
• 階段 1：Map 階段（拆分）
將大型 Diff 按照邏輯獨立性進行智能切分
檔案層分組：按修改檔案進行初步分組
功能塊識別：利用 AST 分析，識別相關的函數、類、模組等邏輯單元
依賴關係分析：分析不同塊之間的依賴關係，確保切分不破壞邏輯完整性
大小均衡：確保每個分割後的 Diff 大小在 LLM 可處理範圍內
• 階段 2：Process 階段（處理）
對每個拆分單元進行 Context 融合和評論生成，規則引擎與 LLM 聯合工作
• 階段 3：Reduce 階段（合併）
通過分類、相似度計算、聚類合併和優先級排序，將多個單元的評論整合為高品質輸出
3.2.3 價值評估過濾體系：從「廢話」到「金句」
為了從海量評論中篩選出真正有價值的「金句」，快手建立了三層價值評估過濾體系。
• 第一層：基礎噪聲過濾
通用廢話模式識別：自動過濾「建議優化」、「可以考慮」等無實質內容評論
重複建議合併：相似評論智能聚合，避免資訊過載
明顯誤判攔截：修改建議與原始程式碼一致等
• 第二層：準確性校驗，確保每條評論都具備充分的證據和合理性
證據充分性評估：評論必須有具體且合理的程式碼位置和問題描述
規則匹配度驗證：檢查評論是否基於有效規則觸發
Context 一致性：確保建議在當前程式碼 Context 中合理
• 第三層：價值密度評估，聚焦真正重要的問題
問題嚴重性分級：基於規則等級和 Context 證據，將問題分為 P0（阻塞）、P1（嚴重）、P2（主要）等不同級別
影響面和開發者友好度評估：優先呈現高優先級的建議；根據變更大小動態調整單次評審輸出的評論數量限制，避免評審疲勞；盡可能為每條評論提供具體的修改建議或範例程式碼
3.2.4 RAG 增強的 BadCase 智能攔截
引入價值評估過濾體系後，透出的評論品質有明顯提升，但日常分析 BadCase 過程中，識別到依然有部分誤判評論透出，針對 AI「幻覺」問題，我們建立了主動防禦機制，LLM 評估當前評論是否與歷史 BadCase 屬於同類誤判，分析誤判的根本原因：Context 誤解、規則過嚴、場景不適等，動態調整評審策略，避免重複出現同類幻覺誤判的情況。
• 歷史 BadCase 向量庫構建
構建已驗證誤判案例的 BadCase 向量資料庫
收集使用者反饋的所有誤判案例
人工驗證並標註誤判類型和原因
提取 BadCase 的語義特徵
使用多維度 Embedding 建立語義索引
對 BadCase 的問題描述、程式碼 Context、評論內容進行向量化
建立高維語義空間索引
支援快速相似度檢索
• 實時 BadCase 檢測流程
實時相似性檢索
每條生成評論都進行 BadCase 匹配檢查
計算評論與歷史 BadCase 的向量相似度
識別潛在的同類誤判
LLM 自檢
當相似度超過閾值時，觸發 LLM 自檢
LLM 評估當前評論是否與歷史 BadCase 屬於同類誤判
判斷是否存在相同的錯誤模式
根因分析
分析誤判的根本原因
Context 理解錯誤：缺少關鍵 Context 導致誤判
規則應用過嚴：規則在特定場景下不適用
場景識別失敗：未能正確識別程式碼使用場景
記錄分析結果，用於後續優化
• 策略動態調整
根據根因分析結果調整評審策略
對同類場景應用修正後的評審邏輯
避免重複出現同類幻覺誤判
3.2.5 階段總結
通過系統性引入 Context 工程、規則知識體系和多層品質保障機制，CR2.0 架構從根本上解決了 CR1.0 的核心問題，將智能 CR 從「能用」提升到「好用」，實現了評論採納率從 7.9% 到 54% 的跨越式增長，重建了開發者信任。
3.3 智能 CR3.0：Agentic 自主決策評審
智能 CR2.0 雖已顯著提升評審效果（綜合採納率達 54%），但在實際應用中暴露出三個層次的局限，制約了系統向更高層次演進。
(1) Context 獲取靈活性有限
Context 的獲取採用工程化預定義策略，缺乏運行時自適應能力。這導致兩個極端問題：一方面容易出現「過度獲取」，將大量無關程式碼納入 Context，造成 token 浪費並干擾模型注意力；另一方面又可能「獲取不足」，對於需要深度分析的複雜場景，預定義策略無法動態擴展 Context 範圍，限制了分析深度。
(2) 深度缺陷識別能力邊界
對於跨服務依賴分析、長調用鏈路追蹤、架構級風險識別等複雜場景，預定義流程難以完全覆蓋。系統缺乏自主探索能力，無法根據問題特徵動態調整分析策略，導致在處理大規模重構、架構變更等複雜場景時存在明顯短板。
(3) 創造性評審缺失
規則驅動模式雖能保證確定性和穩定性，但在創造性方面存在不足。系統難以產生讓開發者「眼前一亮」的洞察性建議，評審深度主要停留在程式碼層面，缺乏對架構設計、業務意圖的深層理解。
為此，我們繼續推進系統向 Agentic 模式演進，核心思想是「該快則快、該深則深」，構建「自主規劃 + 雙路並行 + Agentic 智能體」的確定性和創造性融合框架。
• 對於標準場景：保持 CR2.0 高效穩定的確定性流程
• 對於複雜場景：引入 Agentic 自主決策能力，實現從被動檢查到主動協作的本質轉變
3.3.1 Metadata 驅動的 Agentic 基座
為了降低團隊 AI 場景 Agentic 建設成本，我們建設了一套以 Metadata 驅動的聲明式可擴展 AI Agent 基座，旨在通過統一的底層能力和聲明式擴展機制，支援快速構建領域特定的 AI Agent 應用。
• 應用層：通過注入業務規則、聲明式配置工具和提示詞，即可實現完整的 Agent 功能。
• Agentic 基座層（核心）：提供五大核心能力——AgentExecutor（聲明式執行引擎）、Tool Orchestration（工具調用編排）、Skills Manager（動態技能管理）、History Manager（歷史管理）、Context Manager（Context 管理）。所有能力均通過 METADATA 動態驅動引擎實現，支援運行時動態加載和組裝。
• 聲明式擴展層：通過 MCP 協定、Skills、Tools、System Prompt 四種擴展機制，支援熱插拔式能力註冊。基於 FunctionDeclaration 和 AgentDefinition 的聲明式設計，使得擴展開發和集成變得簡單高效。
• 基礎設施層：提供沙箱隔離、本地操作、無狀態化等基礎能力，保障 Agent 的安全性、可靠性和可擴展性。
3.3.2 Planning 智能規劃層
Planning 層作為 MR 級別的全域路由決策器，負責分析變更特徵並智能決策評審路徑。
• 分析維度
變更複雜度量化
程式碼變更規模：修改檔案數、程式碼行數、變更密集度
影響範圍識別：跨檔案 / 模組依賴、核心介面變更
邏輯複雜度：圈複雜度、嵌套層級、分支數量
• 規則特徵識別
規則類型分類：標準通用規則 vs 需深度理解的特殊規則
Context 需求評估：預定義 Context 是否充分、是否需動態擴展
執行複雜度預估：計算成本、多輪推理需求、外部工具依賴
• 路由策略
CR2.0 版本三階段架構：簡單 MR + 標準規則 → 高效、穩定、成本低
Agentic 鏈路：複雜 MR + 特殊規則 → 深度分析、靈活應對
3.3.3 雙路並行架構
• 路徑一：CR2.0 確定性鏈路
沿用 CR2.0 成熟架構，適用於標準評審場景。處理流程為：預定義 Context 構造 → 規則匹配與 LLM 推理 → 三層價值過濾 → BadCase 攔截。
• 核心優勢
高吞吐：預定義流程，平均處理時間<1 分鐘
高穩定：基於成熟架構，品質基線有保障
低成本：Token 消耗可控
• 路徑二：Agentic 自主決策鏈路
CR3.0 核心創新，適用於複雜 / 深度分析場景。
• 核心優勢
自主 Context 獲取：採用 ReAct 思考 - 行動循環機制，實現 Context 自主規劃獲取，確保有充分的依據支撐評論產出。
• Agentic 評論生成：基於充分的 Context 資訊，Agentic 評論生成具備三大深度能力：
深度邏輯推理：完整系統理解、潛在影響分析、架構層面洞察
跨邊界分析：調用鏈追蹤、跨服務一致性檢查、系統級風險識別
業務意圖理解：需求對齊檢查、業務邏輯驗證、使用者體驗評估
3.3.4 Agentic 評論評估智能體
CR3.0 將評論評估環節升級為 Agentic 智能體，實現從規則評估到智能評估的跨越。
技術實現：
• 深度語義理解：評論價值深度理解、開發者需求洞察、Context 敏感判斷
• 動態品質標準：場景自適應、團隊規範適配、價值密度優化
• BadCase 攔截：保留 CR2.0 的 RAG 向量庫機制，雙重保障（Agentic 智能評估 + BadCase 向量庫攔截）
3.3.5 階段總結
智能 CR3.0 階段，採用雙鏈路模式驅動，對於標準場景，保持 CR2.0 的高效穩定，預定義流程，成本可控，對於複雜場景，提供深度分析能力，自主獲取 Context，發現系統級、架構級問題。既有確定性保障，又有創造性突破，「該快則快、該深則深」。
實踐 2：知識自進化 越用越智能的知識底座
4.1 研發知識自進化：將隱性經驗轉化為可執行的評審規則
傳統程式碼審查高度依賴工程師的個人經驗，這些「隱性知識」難以規模化傳承。我們通過系統化方法，構建了四層規則體系，將團隊智慧轉化為可複用的評審能力。通過業務場景驅動的程式碼審查，將隱性知識顯性化，構建了四重維度的規則來源體系：
• 故障回溯規則：分析近兩年公司線上問題的根因，提煉預防性檢查規則（如空指標防護、資源洩漏檢查）。
• 避坑指南與最佳實踐標準化：將團隊在實踐中積累的典型「坑點」、編碼規範、效能優化等經驗固化沉澱為規則。將「事後救火」的經驗轉化為「事前預防」的檢查規則。涵蓋效能優化（如資料庫查詢、快取使用、並發控制）、安全防護（如輸入驗證、權限校驗）等關鍵維度。
• 歷史評審知識挖掘：利用 AI 輔助分析歷史人工評審評論，識別資深工程師的評審關注點和判斷邏輯，提取高頻問題模式，挖掘「潛規則」：團隊約定俗成但未文件化的品質標準。
• 業務定制規則：支援各業務團隊根據自身特性配置專屬檢查項，實現垂直場景的精細化管理。
通過這一體系，快手將碎片化的評審經驗系統化，形成了覆蓋程式碼品質、效能、安全、可維護性、最佳實踐多個維度的規則庫，累計規則數超過 1,200 條。這顯著提升了團隊的整體程式碼品質與穩定性。
4.2 實現自進化：構建資料驅動的持續改進閉環
快手智能 CR 系统能夠不斷提升並長期保持高採納率的關鍵在於其資料驅動的自進化閉環。這一機制確保了系统能夠根據實際反饋不斷學習和優化，實現「越用越準、越用越智能」。
• 反饋智能收集：開發者對每條評論的採納、拒絕、修改等行為都被自動記錄，作為系統學習的寶貴資料。
• 根因深度分析：每週分析 BadCase，找出系統薄弱環節，並對其進行迭代改進。
• 漸進式優化：小步快跑，每次優化都經過嚴格 A/B 測試驗證，確保每次迭代穩健有效。
• 知識持續沉澱：將驗證有效的模式固化為新規則，不斷豐富和更新團隊的知識庫，形成規則本身的自進化。
實踐 3：產品與營運策略 從精準試點到規模化落地
解決的問題：
• 如何讓開發者無感接 入，降低使用門檻
• 如何適配不同團隊、倉庫的差異化需求
• 如何從試點到規模化推廣，建立使用者信任
• 如何從「增量把關」延伸到「全鏈路品質護航」
5.1 無縫的研發體驗：「滑滑梯」式集成
工具的價值在於使用，我們致力於將智能 CR 無縫集成到開發者日常工作中，做到「潤物細無聲」。
• 場景集成：
在開發者創建或更新 MR 時自動觸發全量或增量評審。
通過 IDE 外掛，將評審能力左移到編碼階段，實現即時反饋。
支援基於分支合併方向、MR 標籤等資訊的自定義觸發策略。
• 評審規則適配：
支援團隊和倉庫維度的規則自定義，滿足不同業務的差異化需求。
針對大倉、多團隊協作倉庫和多技術棧倉庫存在細粒度評審規範的訴求，我們建立了基於倉庫路徑、程式碼檔案開發語言、MR 發起人等。
5.2 循序漸進的推進策略
快手智能 CR 在落地過程中，採用漸進式推廣方式，從精準試點開始，通過迭代優化建立信任，利用口碑效應擴大影響，最終實現全面規模化覆蓋。
• 精準試點：選擇對新技術接受度高的團隊作為試點，集中資源打造成功案例，為後續推廣奠定基礎。
• 迭代優化：基於試點團隊的反饋持續優化產品功能和體驗，建立使用者對產品的信任和依賴。
• 口碑推廣：利用成功標杆的示範效應，吸引其他團隊主動接 入，形成自發的推廣動力。
• 全面規模化：根據不同團隊的特點制定差異化策略，最終實現全公司範圍內的全面覆蓋。
最終通過以上策略，在快手內部實現 74% 的 MR 智能 CR 覆蓋。
5.3 開放共建生態：能力邊界拓展
為拓展智能評審能力的邊界，我們與各業務團隊深度協作，共同打造了覆蓋既有資產治理、業務邏輯和安全專項的三大共建能力，推動智能 CR 從「增量把關」走向「全鏈路品質護航」。
5.3.1 共建能力 1：倉庫級智能掃描——既有程式碼「深度體檢」
• 背景：
既有程式碼引發線上問題佔比高：2024 以來年業務部門程式碼問題導致的線上問題中，其中有 32% 是源自既有程式碼問題。
既有問題發現成本高：既有問題發現成本高、治理推進難，成為業務穩定性的潛在隱患。
為此，我們與生活服務部門共建倉庫級智能掃描能力，旨在以較低成本實現系統性隱患挖掘與閉環修復。
• 建設內容：
全量程式碼分析：利用 AI 對指定程式碼倉庫進行深度掃描，快速識別編碼缺陷、效能瓶頸及線上隱患。
問題分級與分發：對發現的問題進行嚴重程度分級，生成掃描報告，並分配至相應負責人，推動問題追蹤與修復閉環。
• 效果與挑戰：
在試點業務倉庫中，掃描準確率 75%，掃描問題範例。
掃描
業務截圖
說明：提示使用者可上傳 10M 大小的檔案，但使用者在上傳的時候，才發現上傳限制是 2M。嚴重影響使用者使用。
5.3.2 共建能力 2：業務邏輯評審 -- 從「程式碼正確」到「業務正確」
• 背景：通用智能 CR 難以判斷程式碼是否與業務需求一致，無法識別業務類缺陷，因此我們與商業化團隊共建業務邏輯智能評審，旨在實現從「程式碼審查」到「業務邏輯校對」的跨越。
• 建設內容：
需求文件解析：自動關聯程式碼變更與對應的需求文件（PRD），利用 AI 提取關鍵功能點，並將其轉化為結構化 Context。
需求 - 程式碼比對：以標準化的需求描述為基準，由智能評審任務比照程式碼實現，識別業務邏輯層面的不一致、缺失或錯誤。
場景化提示：針對識別出的偏差，生成具體、可操作的業務邏輯建議，輔助開發者確認實現與需求對齊。
• 效果與挑戰：該能力已在部分業務中試點，初步驗證了技術路徑的可行性。當前核心挑戰在於對非標準化需求文件的深度理解與功能拆解，未來將重點優化需求理解能力，強化與業務場景的結合。
評論範例：
5.3.3 共建安全 CR：將安全左移至開發早期
• 背景：為貫徹「安全左移」理念，快手與安全團隊合作，將專業安全檢測能力集成至 Code Review 階段，力求在程式碼入庫前早期發現並修復安全漏洞。
• 建設內容：
安全檢測 Agent 集成：接 入安全團隊提供的專業檢測能力，以 Agent 形式融入到智能評審流程，識別注入、洩漏、越權等常見安全問題。
評審建議融合：將檢測出的安全漏洞以程式碼審查評論的形式直接呈現給開發者，提供修復建議與依據。
• 效果與挑戰：試點期間，系統已幫助開發者識別並確認有效安全漏洞約 200 個。當前採納率約 25%，反映出在漏洞檢測準確性方面仍有優化空間。後續將持續協同，聚焦提升精準率與開發者接受度。
評論範例：
展 望
快手智能 CR 的目標不止於發現程式碼層面的問題，未來還將致力於如下方向工作：
• 能力拓展：實現跨程式碼倉庫的長鏈路缺陷識別，理解需求變更引發的跨服務、跨倉庫的所有程式碼改動，識別潛在的鏈路級風險。
• 自動修復：對於高置信度的問題，提供「一鍵修復」能力，將開發者從重複的修復工作中解放出來。
最終，快手希望將智能 CR 打造為一名「架構顧問」，能夠在需求設計和編碼階段就提供前瞻性的架構建議和風險預警，進一步提升研發效能和系統品質。