編輯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

“我們用 AI 來做代碼審查，結果它比我老板還話多。”——這句話可能是很多開發者的真實寫照。

最近，一篇名為《How we made our AI code reviewer stop being so noisy》的博客引發了熱議。

作者是一位創業公司的創始人，Paul Sangle-Ferriere，這家公司致力于打造一個 AI原生的 Github。

這篇文章里講述了他們團隊如何優化一個 AI Agent，讓它在 PR 審查中少說廢話。雖然有一些觀點和做法值得借鑒。

但是評論區卻熱鬧非凡、甚至“翻車”：“例子選得爛”、“信心值是編的”、“這不就是 Copilot 的爛尾問題嗎？”

各位不妨一看，相信大家會有自己的判斷。

一、太吵了，Agent 這么愛刷存在感

AI 代碼審查 Agent 聽起來很美：自動識別 bug、反模式、重復代碼，協助團隊更快更穩地交付代碼。可現實往往是——你以為它在幫你，結果只是在“刷存在感”。

我們是 cubic 的團隊，一個致力于打造“AI 原生 GitHub”的產品。我們上線過一個 AI 代碼審查 Agent，主打 PR 初審。上線第一天，開發者的反饋就很直接：

“太吵了！”

是的，它“滔滔不絕、不厭其煩”地指出每一處無關痛癢的地方，甚至重復 Linter 已經提示的內容，還夾雜著一些離譜的誤報——一場“信息污染”風暴。我們意識到：如果不能讓它閉嘴，就別指望開發者信它。

圖片

經過三次架構重構、數十次 offline 調試，我們最終把誤報率降低了 51%。這不僅讓 Agent 變“安靜”了，更變“聰明”了。以下是我們踩過的坑、學到的招。

二、別再幻想萬能 Agent：第一版完全崩了

我們最初的架構非常符合“直覺”：

復制

[diff]
↓  
[一大段 prompt（帶上下文）]
↓  
[輸出所有建議]

看上去不錯，優雅且簡單，但在真實環境下卻迅速玩崩了：

• 誤報一堆：代碼樣式風格問題被當成 bug；已修復的 bug 被反復提示；Linter 的建議被復制粘貼。
• 沒人信它：一半建議不靠譜，剩下一半也沒人看了。
• 改 prompt 毫無用：你就算在 prompt 里寫明“請忽略小問題”，它依然我行我素。

我們試過加長上下文、調模型 temperature、換 sampling 策略……都沒明顯改善。

沒辦法，是時候徹底反思了。

三、怎么讓 AI “閉嘴”：我們用的 3 個奏效方法

經過數輪試驗，我們終于打造出一套效果穩定、實際可用的新架構，成功讓誤報率降低了 51%，并已部署至生產環境。以下是其中的三個關鍵策略：

1.顯式推理：先講邏輯再輸出結論

后來，我們要求 AI 在輸出任何建議前，必須先明確寫出它的“推理邏輯”：

復制

{
  "reasoning": "`cfg` can be nil on line 42; dereferenced without check on line 47",
  "finding": "Possible nil?pointer dereference",
  "confidence": 0.81
}

這個結構讓我們獲得了三重收益：

• 可追蹤性大幅提升：開發者能 debug 模型行為，快速看出判斷邏輯哪里出了問題，從而精準調整模型行為。
• 強制 AI 結構化思考：AI 只有先說出“為什么”，AI 才能提出“該怎么做”，有效減少了隨意下結論的情況。
• 為未來問題排查打基礎：很多后續的問題都可以通過推理日志溯源解決。

一句話：強制思考比調模型參數更有效。

2.精簡工具鏈：從“大雜燴”到“剛剛好”

我們原本給 Agent 配了很多工具：LSP、靜態分析器、測試框架……結果發現：

90% 有效建議都來自極少數幾個工具，其他的反而制造噪音。

于是我們砍掉了大部分依賴，只留下兩個：

• 精簡版 LSP（Language Server Protocol）
• 基礎終端環境（供 Agent 動手查）

結果？精簡后的工具鏈讓 AI 更聚焦于識別真正的問題，準確率顯著提升，出錯更少了。

3.一個萬能大 prompt > 多個專精微型 Agent

我們一開始采用的戰斗方法是：瘋狂往大 prompt 里塞規則：

• “忽略 .test.ts 中的未使用變量的提示”
• “跳過 init.py 的導入檢查”
• “不要 lint markdown 文件”

但最終發現這條路完全走不通。規則又多又亂，AI 記不住，也執行不好。

我們換了策略：一個 Agent 專注一件事，比如：

• Planner Agent：識別變化點、規劃檢查順序
• 安全 Agent：檢測注入、認證問題
• 重復代碼 Agent：識別 copy-paste
• 編輯 Agent：修正拼寫與文檔一致性

每個 Agent 都有明確邊界和上下文，專精于一個細分任務，誤報自然減少了，運行效率也沒拉垮。雖然多個 Agent 會帶來 token 重疊問題， token 消耗有所增加，但我們用緩存策略有效平衡了開銷。

四、實際效果：總算不廢話連篇了

過去六周，我們把優化后的 Agent 投入真實項目中，覆蓋開源與私有倉庫，數據如下：

• 誤報減少 51%
• PR 評論數減少一半（不再刷屏）
• 團隊審查體驗明顯改善，信任度回升，Merge 效率提高

更重要的是，開發者反饋整體滿意度提升明顯，不再視 AI 為“吵鬧的小孩”，而是靠譜的“初審助手”。他們更愿意依賴 AI 完成初審，大大加快了交付速度。

總結下來，核心經驗就三句話：

① 顯式推理，提升可解釋性：要求 AI 在提出建議前先解釋“為什么”，既提升準確率，也便于后期調試。

② 工具越少越好，定期評估工具鏈，把實際使用頻率低于 10% 的工具砍掉，保持輕量高效。

③ 任務專精化用多個微型 Agent 分別處理單一任務，能顯著提升上下文利用效率與判斷準確度。

AI 的“喧嘩期”正在過去，接下來拼的是實用性和信任感。如果你也在做 Agent，不妨試試讓它“先別說話，先想一想”。

評論區集體翻車：微型Agent真的好嗎？對比方式存疑

本來是一片分享代碼審查Agent優化心得的博客，但評論區的大佬真的是臥虎藏龍。一眼就看出上述三條建議的不妥之處。可以說每條建議都被反駁得有理有據。

小編整理了下，主要有以下觀點。

1. 模型思考的“信心值”是不靠譜的、甚至可能是胡編的

在那段結構化輸出示例中，Cubic 給出了這樣的字段：

復制

"confidence": 0.81

表面上看，這很專業，仿佛 AI 做了充分思考，還為自己的判斷打了個分。但評論區一針見血指出：

“你知道這個 confidence 值是完全胡編的嗎？”

圖片

一位網友指出，事實上，LLM 并不具備“自我置信評估”的能力。它生成的每個字段，只是按提示模仿結構在編內容。一個 0.81 或 0.92，看上去專業，其實沒有統計意義，也沒有任何實際校驗機制。

正如一位評論者諷刺地說：

“要不干脆加一個字段叫 confidence_in_confidence_rating？”

更有人表示，他們測試時讓模型兩次對同樣輸入做 reasoning trace，居然得到了兩種語義接近但表述不同的輸出。換句話說，不是它騙你，而是它根本沒想清楚自己在說什么。

也就是說，你讓大模型輸出前先思考“為什么”，但回答這個“為什么”的置信度完全是站不住腳的。這個基礎崩塌了，理論上也沒有什么真實價值。

2. 微代理架構：有效，但是否必要？

Cubic 把原本一個大 prompt 的“全能 agent”，拆分成多個“微代理”：

• Planner：先判斷需要檢查什么
• Security Agent：查安全漏洞
• Duplication Agent：查復制粘貼
• Editorial Agent：檢查文檔和拼寫

這種結構的優點是模塊清晰、上下文更聚焦，確實在短期內提升了準確率。

但不少開發者質疑：

“這不就是在用人為任務拆分，彌補模型本身無法有效規劃的問題嗎？”

換句話說，我們其實希望模型能夠 end-to-end 理解并完成復雜任務，而不是我們人類先做切分，它再一個個跑。

有人評論得很直白：

“這讓我感覺像是在喂模型吃飯，而不是它自己動手做飯。”

關于上述這一點，小編覺得開發者有點“杠精了”。不過需要注意的是，拆分細分任務的 Agent 的做法目前還存在非共識，此前我們也報道過類似的觀點。比如 Cusor、Devin 等工具，其實都是在巨大的系統提示詞中做了不少的優化工作。

圖片

圖片

3. AI審查工具的真實體驗：能用，但不太值得

評論區，有一位親歷者總結自己試用多個 AI 審查工具后的感受：

• PR 描述幾乎從不準確地總結改動
• 90% 的評論都錯或無關，常因為缺上下文
• 真正有用的評論不到 10%

這種體驗在很多網友那里得到了共鳴。更多人指出，代碼審查本質上需要“部落知識”“業務上下文”“歷史約定”——這些正是 LLM 最難補足的部分。

甚至有人提出一個更靠譜的方向：

“與其讓 AI 編造判斷，不如讓它推薦歷史上類似的 PR 或 Issue 給人類 reviewer 提供參考。”

這類“語義搜索 + 輔助記憶”型的 Agent，其實才更符合當前 LLM 的能力邊界。

4. 降噪 = 提升？小心被對照組誤導

Cubic 的文章用幾個看上去不錯的數據展示成果：

• 評論數量減半
• 錯誤率降低 51%
• 審查效率提升

但很快就有人指出盲點：

“這些數據是跟以前那個更吵的 Agent 對比的，不是和‘沒有 Agent’的對比。”

圖片

如果你運行著一個不靠譜的機器人，然后說“我把它降低一半了”，這并不意味著它現在值得信任。更嚴謹的對比，應該是：

• 開著它 vs 關掉它
• AI 審查 vs 人工審查
• AI + 人 vs 只靠人

否則，這些數據看似是勝利，其實可能是“自我感動”。

寫在最后：Agent仍處于概念驗證期

小編看來，這篇博文非常有代表性。

首先，本身代碼審查 Agent 在圈內屬于一個有爭議的方向，大模型的代碼編寫能力很強，但是讓其做代碼審核，目前還有很大的爭議。

其次，如何做一個做復雜任務的 Agent？目前業內的做法也沒有完成共識。是做依托 LLM 做一個大而復雜的長上下文的系統提示詞，還是像本篇文章一樣拆分成多個“微型 Agent”，兩種做法似乎也涇渭分明。

不過，唯一的共識是，現在的 Agent 還遠不夠成熟。就如同昨天 Gartner 報道：目前絕大多數 Agentic AI 項目仍處于早期試驗或概念驗證階段，基本是市場炒作驅動，且常常應用不當。

一位Gartner的高級分析師 Verma 甚至毫不留情的表示：大多數（現在的） Agentic AI 項目商業價值或投資回報率有限。

當然，這并不完全是創業者團隊的問題。根本原因還是在大模型上。

Verma解釋，因為現有的 AI 模型上不具備足夠成熟度與自主能力，無法長時間內自主完成復雜的業務目標，或執行細致、復雜的指令。

所以，話說回我們今天的案例。我們當然理解 AI 工程的不易，尤其是在代碼審查這種對準確性要求極高的場景里。

Cubic 做出的努力值得尊敬，它讓我們看到一種探索路徑。不過這篇博客的評論區更提醒我們：

• 別迷信結構化字段和術語包裝（confidence 不是 magic）
• 別低估人類上下文理解的力量（tribal knowledge 不是可prompt的）
• 別輕信自我對比數據（51% 誤判率的下降有可能只是自嗨）

最后，不知道各位看官是否在用 AI 做代碼審查，不妨在評論區分享你的體驗—— 它真的幫你省了時間，還是只是多了一個話癆同事？

參考鏈接：

??https://www.cubic.??dev/blog/learnings-from-building-ai-agents

??https://news.ycombinator.com/item?id=44386887??

本文轉載自??51CTO技術棧??，作者：云昭