采納率從7.9%到54%：快手智能Code Review的三階進化

出品方 | 快手研發效能委員會 x 研發效能中心

概 況

在快手全面推進“AI 研發范式升級”的進程中，如何將個人使用 AI 帶來的效率提升，轉化為組織整體的交付效能，是必須攻克的核心命題。智能代碼審查系統正是破解這一命題的關鍵環節——它作用于個人開發完成之后、團隊交付合并之前，通過質量過濾和知識沉淀，讓 AI 能力從“私人助理”升級為“團隊協作者”。

在傳統研發流程中，Code Review（代碼評審）往往面臨人工復核成本高、標準不統一、評審深度難下沉的結構性痛點。本文總結了快手智能代碼審查系統從“純 LLM 啟發式”到“知識引擎 + 規則確定性”，再到“Agentic 自主決策”的三代架構演進。

針對 AI 幻覺這一核心頑疾，快手技術團隊通過構建上下文引擎與沉淀 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 生成的評論中包含大量通用性、無實質價值的建議，如“建議優化”、“可以考慮”等，導致開發者疲勞，降低了采納意愿。

• 上下文缺失

僅分析 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 核心問題

• 上下文嚴重不足

• • 僅提供 MR Diff 片段，缺少完整方法體和跨文件依賴

  • 模型無法理解代碼在系統中的完整作用，誤判率高

• 知識體系缺失，召回穩定性差

• • 無規則庫支撐，完全依賴模型"黑盒"能力

  • 團隊知識無法沉淀和傳承

  • 評審標準不統一，質量波動大

• 任務定義過于寬泛

• • 給模型的指令缺乏 Know-how，過于依賴模型自主理解

  • 檢查項描述模糊（如"性能問題"、"安全問題"）

  • 缺少具體場景和示例，模型難以準確把握評審重點

• 優化手段有限

• • 對于 BadCase 缺乏可操作的優化路徑

  • 無法系統性改進評審質量

3.1.3 階段總結

• 數據表現：評論采納率 7.9%，評論質量差、誤報多、無價值建議泛濫

• 技術驗證：證明了 AI 代碼評審的技術可行性，暴露了純 LLM 驅動模式的根本性缺陷

• 演進方向：構建工程化的上下文構造機制，建立領域知識體系（規則庫、最佳實踐），設計多層次質量保障機制

3.2 智能 CR2.0：知識引擎驅動的三階段確定性評審

針對智能 CR1.0 階段的上下文不足、知識缺失、質量不穩定和調優成本高的痛點，我們在深入分析問題后，摒棄了"純 LLM 驅動"的思路，結合領域知識和工程鏈路，構建了"上下文工程 + 規則驅動評審 + 評論價值評估和 BadCase 攔截保障"的確定性評審框架，通過規則提供高確定性的知識，為 LLM 劃定評審范圍和重點，再結合 LLM 強大的代碼理解與邏輯推理能力，兩者的互補與融合確保評審結果的準確性和可解釋性，實現了從基礎功能到高可信評審能力的跨越。

3.2.1 上下文智能構造引擎

為解決"上下文缺失導致誤判"的痛點，我們構建了多層次的上下文理解能力，旨在全面、準確地理解代碼變更的"全貌"。從原始 Git Diff 到富上下文 Prompt 的生成，包含以下關鍵能力：

• 語言智能識別：自動識別 Java、JS/TS、Go 等 10+ 種編程語言，適配差異化分析策略

• 方法體擴展：突破 Git Diff 片段限制，從 diff 行擴展到完整方法體，避免斷章取義

• AST 深度解析：通過抽象語法樹理解代碼結構語義和控制流

• 跨文件依賴推斷：識別接口、方法之間的調用關系，評估變更的潛在影響范圍。

• Diff 智能切分：將大型變更集拆分為邏輯獨立的評審單元，突破 token 窗口限制，提升評審聚焦度

• PRD 需求關聯：通過關聯需求文檔（PRD），進一步豐富上下文信息，確保評審建議與業務目標對齊

3.2.2 Map-Reduce 長上下文處理

智能 CR 推進落地過程中，出現了因為大 MR 或大規則集導致模型注意力不集中引起漏召甚至超出模型上下文窗口的問題，我們采用類似于 Map-Reduce 的分布式處理邏輯，將長上下文問題分解為拆分→處理→合并三個階段。

• 階段 1：Map 階段（拆分）

  將大型 Diff 按照邏輯獨立性進行智能切分

• • 文件級分組：按修改文件進行初步分組

  • 功能塊識別：利用 AST 分析，識別相關的函數、類、模塊等邏輯單元

  • 依賴關系分析：分析不同塊之間的依賴關系，確保切分不破壞邏輯完整性

  • 大小均衡：確保每個分割后的 Diff 大小在 LLM 可處理范圍內

• 階段 2：Process 階段（處理）

  對每個拆分單元進行上下文融合和評論生成，規則引擎與 LLM 聯合工作

• 階段 3：Reduce 階段（合并）

  通過分類、相似度計算、聚類合并和優先級排序，將多個單元的評論整合為高質量輸出

3.2.3 價值評估過濾體系：從“廢話”到“金句”

為了從海量評論中篩選出真正有價值的“金句”，快手建立了三層價值評估過濾體系。

• 第一層：基礎噪聲過濾

• • 通用廢話模式識別：自動過濾“建議優化”、“可以考慮”等無實質內容評論

  • 重復建議合并：相似評論智能聚合，避免信息過載

  • 明顯誤判攔截：修改建議與源代碼一致等

• 第二層：準確性校驗，確保每條評論都具備充分的證據和合理性

• • 證據充分性評估：評論必須有具體且合理的代碼位置和問題描述

  • 規則匹配度驗證：檢查評論是否基于有效規則觸發

  • 上下文一致性：確保建議在當前代碼上下文中合理

• 第三層：價值密度評估，聚焦真正重要的問題

• • 問題嚴重性分級：基于規則等級和上下文證據，將問題分為 P0（阻塞）、P1（嚴重）、P2（主要）等不同級別

  • 影響面和開發者友好度評估：優先呈現高優先級的建議；根據變更大小動態調整單次評審輸出的評論數量限制，避免評審疲勞；盡可能為每條評論提供具體的修改建議或示例代碼

3.2.4 RAG 增強的 BadCase 智能攔截

引入價值評估過濾體系后，透出的評論質量有明顯提升，但日常分析 BadCase 過程中，識別到依然有部分誤判評論透出，針對 AI"幻覺"問題，我們建立了主動防御機制，LLM 評估當前評論是否與歷史 BadCase 屬于同類誤判，分析誤判的根本原因：上下文誤解、規則過嚴、場景不適等，動態調整評審策略，避免重復出現同類幻覺誤判的情況。

• 歷史 BadCase 向量庫構建

• • 構建已驗證誤判案例的 BadCase 向量數據庫

  • 收集用戶反饋的所有誤判案例

  • 人工驗證并標注誤判類型和原因

  • 提取 BadCase 的語義特征

  • 使用多維度 Embedding 建立語義索引

  • 對 BadCase 的問題描述、代碼上下文、評論內容進行向量化

  • 建立高維語義空間索引

  • 支持快速相似度檢索

• 實時 BadCase 檢測流程

• • 實時相似性檢索

  • 每條生成評論都進行 BadCase 匹配檢查

  • 計算評論與歷史 BadCase 的向量相似度

  • 識別潛在的同類誤判

  • LLM 自檢

  • 當相似度超過閾值時，觸發 LLM 自檢

  • LLM 評估當前評論是否與歷史 BadCase 屬于同類誤判

  • 判斷是否存在相同的錯誤模式

  • 根因分析

  • 分析誤判的根本原因

  • 上下文理解錯誤：缺少關鍵上下文導致誤判

  • 規則應用過嚴：規則在特定場景下不適用

  • 場景識別失敗：未能正確識別代碼使用場景

  • 記錄分析結果，用于后續優化

• 策略動態調整

• • 根據根因分析結果調整評審策略

  • 對同類場景應用修正后的評審邏輯

  • 避免重復出現同類幻覺誤判

3.2.5 階段總結

通過系統性引入上下文工程、規則知識體系和多層質量保障機制，CR2.0 架構從根本上解決了 CR1.0 的核心問題，將智能 CR 從"能用"提升到"好用"，實現了評論采納率從 7.9% 到 54% 的跨越式增長，重建了開發者信任。

3.3 智能 CR3.0：Agentic 自主決策評審

智能 CR2.0 雖已顯著提升評審效果（綜合采納率達 54%），但在實際應用中暴露出三個層次的局限，制約了系統向更高層次演進。

(1) 上下文獲取靈活性有限

上下文的獲取采用工程化預定義策略，缺乏運行時自適應能力。這導致兩個極端問題：一方面容易出現"過度獲取"，將大量無關代碼納入上下文，造成 token 浪費并干擾模型注意力；另一方面又可能"獲取不足"，對于需要深度分析的復雜場景，預定義策略無法動態擴展上下文范圍，限制了分析深度。

(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（上下文管理）。所有能力均通過 METADATA 動態驅動引擎實現，支持運行時動態加載和組裝。

• 聲明式擴展層：通過 MCP Protocol、Skills、Tools、System Prompt 四種擴展機制，支持熱插拔式能力注冊。基于 FunctionDeclaration 和 AgentDefinition 的聲明式設計，使得擴展開發和集成變得簡單高效。

• 基礎設施層：提供沙箱隔離、本地操作、無狀態化等基礎能力，保障 Agent 的安全性、可靠性和可擴展性。

3.3.2 Planning 智能規劃層

Planning 層作為 MR 級別的全局路由決策器，負責分析變更特征并智能決策評審路徑。

• 分析維度

• • 變更復雜度量化

  • 代碼變更規模：修改文件數、代碼行數、變更密集度

  • 影響范圍識別：跨文件 / 模塊依賴、核心接口變更

  • 邏輯復雜度：圈復雜度、嵌套層級、分支數量

  • 規則特征識別

  • 規則類型分類：標準通用規則 vs 需深度理解的特殊規則

  • 上下文需求評估：預定義上下文是否充分、是否需動態擴展

  • 執行復雜度預估：計算成本、多輪推理需求、外部工具依賴

• 路由策略

• • CR2.0 版本三階段架構：簡單 MR + 標準規則 → 高效、穩定、成本低

  • Agentic 鏈路：復雜 MR + 特殊規則 → 深度分析、靈活應對

3.3.3 雙路并行架構

路徑一：CR2.0 確定性鏈路

沿用 CR2.0 成熟架構，適用于標準評審場景。處理流程為：預定義上下文構造 → 規則匹配與 LLM 推理 → 三層價值過濾 → BadCase 攔截。

• 核心優勢

• • 高吞吐：預定義流程，平均處理時間<1 分鐘

  • 高穩定：基于成熟架構，質量基線有保障

  • 低成本：Token 消耗可控

路徑二：Agentic 自主決策鏈路

CR3.0 核心創新，適用于復雜 / 深度分析場景。

• 核心優勢

• • 自主上下文獲取：采用 ReAct 思考 - 行動循環機制，實現上下文自主規劃獲取，確保有充足的依據支撐評論產出。

• Agentic 評論生成：基于充分的上下文信息，Agentic 評論生成具備三大深度能力：

• • 深度邏輯推理：完整系統理解、潛在影響分析、架構層面洞察

  • 跨邊界分析：調用鏈追蹤、跨服務一致性檢查、系統級風險識別

  • 業務意圖理解：需求對齊檢查、業務邏輯驗證、用戶體驗評估

3.3.4 Agentic 評論評估智能體

CR3.0 將評論評估環節升級為 Agentic 智能體，實現從規則評估到智能評估的跨越。

技術實現：

• 深度語義理解：評論價值深度理解、開發者需求洞察、上下文敏感判斷

• 動態質量標準：場景自適應、團隊規范適配、價值密度優化

• BadCase 攔截：保留 CR2.0 的 RAG 向量庫機制，雙重保障（Agentic 智能評估 + BadCase 向量庫攔截）

3.3.5 階段總結

智能 CR3.0 階段，采用雙鏈路模式驅動，對于標準場景，保持 CR2.0 的高效穩定，預定義流程，成本可控，對于復雜場景，提供深度分析能力，自主獲取上下文，發現系統級、架構級問題。既有確定性保障，又有創造性突破，"該快則快、該深則深"。

實踐 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 提取關鍵功能點，并將其轉化為結構化上下文。

  • 需求 - 代碼比對：以標準化的需求描述為基準，由智能評審任務比照代碼實現，識別業務邏輯層面的不一致、缺失或錯誤。

  • 場景化提示：針對識別出的偏差，生成具體、可操作的業務邏輯建議，輔助開發者確認實現與需求對齊。

• 效果與挑戰：該能力已在部分業務中試點，初步驗證了技術路徑的可行性。當前核心挑戰在于對非標準化需求文檔的深度理解與功能拆解，未來將重點優化需求理解能力，強化與業務場景的結合。

• 評論示例：

5.3.3 共建安全 CR：將安全左移至開發早期

• 背景：為貫徹“安全左移”理念，快手與安全團隊合作，將專業安全檢測能力集成至 Code Review 階段，力求在代碼入庫前早期發現并修復安全漏洞。

• 建設內容：

• • 安全檢測 Agent 集成：接入安全團隊提供的專業檢測能力，以 Agent 形式融入到智能評審流程，識別注入、泄露、越權等常見安全問題。

  • 評審建議融合：將檢測出的安全漏洞以代碼評審評論的形式直接呈現給開發者，提供修復建議與依據。

• 效果與挑戰：試點期間，系統已幫助開發者識別并確認有效安全漏洞約 200 個。當前采納率約 25%，反映出在漏洞檢測準確性方面仍有優化空間。后續將持續協同，聚焦提升精準率與開發者接受度。

• 評論示例：

展 望

快手智能 CR 的目標不止于發現代碼層面的問題，未來還將致力于如下方向工作：

• 能力拓展：實現跨代碼倉庫的長鏈路缺陷識別，理解需求變更引發的跨服務、跨倉庫的所有代碼改動，識別潛在的鏈路級風險。

• 自動修復：對于高置信度的問題，提供“一鍵修復”能力，將開發者從重復的修復工作中解放出來。

最終，快手希望將智能 CR 打造為一名“架構顧問”，能夠在需求設計和編碼階段就提供前瞻性的架構建議和風險預警，進一步提升研發效能和系統質量。