編輯 | 云昭
出品 | 51CTO技術(shù)棧（微信號：blog51cto）
“我們用 AI 來做代碼審查，結(jié)果它比我老板還話多?！薄@句話可能是很多開發(fā)者的真實寫照。
最近，一篇名為《How we made our AI code reviewer stop being so noisy》的博客引發(fā)了熱議。
作者是一位創(chuàng)業(yè)公司的創(chuàng)始人，Paul Sangle-Ferriere，這家公司致力于打造一個 AI原生的 Github。
這篇文章里講述了他們團隊如何優(yōu)化一個 AI Agent，讓它在 PR 審查中少說廢話。雖然有一些觀點和做法值得借鑒。
但是評論區(qū)卻熱鬧非凡、甚至“翻車”：“例子選得爛”、“信心值是編的”、“這不就是 Copilot 的爛尾問題嗎？”
各位不妨一看，相信大家會有自己的判斷。
一、太吵了，Agent 這么愛刷存在感
AI 代碼審查 Agent 聽起來很美：自動識別 bug、反模式、重復(fù)代碼，協(xié)助團隊更快更穩(wěn)地交付代碼。可現(xiàn)實往往是——你以為它在幫你，結(jié)果只是在“刷存在感”。
我們是 cubic 的團隊，一個致力于打造“AI 原生 GitHub”的產(chǎn)品。我們上線過一個 AI 代碼審查 Agent，主打 PR 初審。上線第一天，開發(fā)者的反饋就很直接：
“太吵了！”
是的，它“滔滔不絕、不厭其煩”地指出每一處無關(guān)痛癢的地方，甚至重復(fù) Linter 已經(jīng)提示的內(nèi)容，還夾雜著一些離譜的誤報——一場“信息污染”風(fēng)暴。我們意識到：如果不能讓它閉嘴，就別指望開發(fā)者信它。
圖片
經(jīng)過三次架構(gòu)重構(gòu)、數(shù)十次 offline 調(diào)試，我們最終把誤報率降低了 51%。這不僅讓 Agent 變“安靜”了，更變“聰明”了。以下是我們踩過的坑、學(xué)到的招。
二、別再幻想萬能 Agent：第一版完全崩了
我們最初的架構(gòu)非常符合“直覺”：
[diff]
↓
[一大段 prompt（帶上下文）]
↓
[輸出所有建議]看上去不錯，優(yōu)雅且簡單，但在真實環(huán)境下卻迅速玩崩了：
- 誤報一堆：代碼樣式風(fēng)格問題被當成 bug；已修復(fù)的 bug 被反復(fù)提示；Linter 的建議被復(fù)制粘貼。
- 沒人信它：一半建議不靠譜，剩下一半也沒人看了。
- 改 prompt 毫無用：你就算在 prompt 里寫明“請忽略小問題”，它依然我行我素。
我們試過加長上下文、調(diào)模型 temperature、換 sampling 策略……都沒明顯改善。
沒辦法，是時候徹底反思了。
三、怎么讓 AI “閉嘴”：我們用的 3 個奏效方法
經(jīng)過數(shù)輪試驗，我們終于打造出一套效果穩(wěn)定、實際可用的新架構(gòu)，成功讓誤報率降低了 51%，并已部署至生產(chǎn)環(huán)境。以下是其中的三個關(guān)鍵策略：
1.顯式推理：先講邏輯再輸出結(jié)論
后來，我們要求 AI 在輸出任何建議前，必須先明確寫出它的“推理邏輯”：
{
"reasoning": "`cfg` can be nil on line 42; dereferenced without check on line 47",
"finding": "Possible nil?pointer dereference",
"confidence": 0.81
}這個結(jié)構(gòu)讓我們獲得了三重收益：
- 可追蹤性大幅提升：開發(fā)者能 debug 模型行為，快速看出判斷邏輯哪里出了問題，從而精準調(diào)整模型行為。
- 強制 AI 結(jié)構(gòu)化思考：AI 只有先說出“為什么”，AI 才能提出“該怎么做”，有效減少了隨意下結(jié)論的情況。
- 為未來問題排查打基礎(chǔ)：很多后續(xù)的問題都可以通過推理日志溯源解決。
一句話：強制思考比調(diào)模型參數(shù)更有效。
2.精簡工具鏈：從“大雜燴”到“剛剛好”
我們原本給 Agent 配了很多工具：LSP、靜態(tài)分析器、測試框架……結(jié)果發(fā)現(xiàn)：
90% 有效建議都來自極少數(shù)幾個工具，其他的反而制造噪音。
于是我們砍掉了大部分依賴，只留下兩個：
- 精簡版 LSP（Language Server Protocol）
- 基礎(chǔ)終端環(huán)境（供 Agent 動手查）
結(jié)果？精簡后的工具鏈讓 AI 更聚焦于識別真正的問題，準確率顯著提升，出錯更少了。
3.一個萬能大 prompt > 多個專精微型 Agent
我們一開始采用的戰(zhàn)斗方法是：瘋狂往大 prompt 里塞規(guī)則：
- “忽略 .test.ts 中的未使用變量的提示”
- “跳過 init.py 的導(dǎo)入檢查”
- “不要 lint markdown 文件”
但最終發(fā)現(xiàn)這條路完全走不通。規(guī)則又多又亂，AI 記不住，也執(zhí)行不好。
我們換了策略：一個 Agent 專注一件事，比如：
- Planner Agent：識別變化點、規(guī)劃檢查順序
- 安全 Agent：檢測注入、認證問題
- 重復(fù)代碼 Agent：識別 copy-paste
- 編輯 Agent：修正拼寫與文檔一致性
每個 Agent 都有明確邊界和上下文，專精于一個細分任務(wù)，誤報自然減少了，運行效率也沒拉垮。雖然多個 Agent 會帶來 token 重疊問題， token 消耗有所增加，但我們用緩存策略有效平衡了開銷。
四、實際效果：總算不廢話連篇了
過去六周，我們把優(yōu)化后的 Agent 投入真實項目中，覆蓋開源與私有倉庫，數(shù)據(jù)如下：
- 誤報減少 51%
- PR 評論數(shù)減少一半（不再刷屏）
- 團隊審查體驗明顯改善，信任度回升，Merge 效率提高
更重要的是，開發(fā)者反饋整體滿意度提升明顯，不再視 AI 為“吵鬧的小孩”，而是靠譜的“初審助手”。他們更愿意依賴 AI 完成初審，大大加快了交付速度。
總結(jié)下來，核心經(jīng)驗就三句話：
① 顯式推理，提升可解釋性：要求 AI 在提出建議前先解釋“為什么”，既提升準確率，也便于后期調(diào)試。
② 工具越少越好，定期評估工具鏈，把實際使用頻率低于 10% 的工具砍掉，保持輕量高效。
③ 任務(wù)專精化用多個微型 Agent 分別處理單一任務(wù)，能顯著提升上下文利用效率與判斷準確度。
AI 的“喧嘩期”正在過去，接下來拼的是實用性和信任感。如果你也在做 Agent，不妨試試讓它“先別說話，先想一想”。
評論區(qū)集體翻車：微型Agent真的好嗎？對比方式存疑
本來是一片分享代碼審查Agent優(yōu)化心得的博客，但評論區(qū)的大佬真的是臥虎藏龍。一眼就看出上述三條建議的不妥之處?？梢哉f每條建議都被反駁得有理有據(jù)。
小編整理了下，主要有以下觀點。
1. 模型思考的“信心值”是不靠譜的、甚至可能是胡編的
在那段結(jié)構(gòu)化輸出示例中，Cubic 給出了這樣的字段：
"confidence": 0.81表面上看，這很專業(yè)，仿佛 AI 做了充分思考，還為自己的判斷打了個分。但評論區(qū)一針見血指出：
“你知道這個 confidence 值是完全胡編的嗎？”
圖片
一位網(wǎng)友指出，事實上，LLM 并不具備“自我置信評估”的能力。它生成的每個字段，只是按提示模仿結(jié)構(gòu)在編內(nèi)容。一個 0.81 或 0.92，看上去專業(yè)，其實沒有統(tǒng)計意義，也沒有任何實際校驗機制。
正如一位評論者諷刺地說：
“要不干脆加一個字段叫 confidence_in_confidence_rating？”
更有人表示，他們測試時讓模型兩次對同樣輸入做 reasoning trace，居然得到了兩種語義接近但表述不同的輸出。換句話說，不是它騙你，而是它根本沒想清楚自己在說什么。
也就是說，你讓大模型輸出前先思考“為什么”，但回答這個“為什么”的置信度完全是站不住腳的。這個基礎(chǔ)崩塌了，理論上也沒有什么真實價值。
2. 微代理架構(gòu)：有效，但是否必要？
Cubic 把原本一個大 prompt 的“全能 agent”，拆分成多個“微代理”：
- Planner：先判斷需要檢查什么
- Security Agent：查安全漏洞
- Duplication Agent：查復(fù)制粘貼
- Editorial Agent：檢查文檔和拼寫
這種結(jié)構(gòu)的優(yōu)點是模塊清晰、上下文更聚焦，確實在短期內(nèi)提升了準確率。
但不少開發(fā)者質(zhì)疑：
“這不就是在用人為任務(wù)拆分，彌補模型本身無法有效規(guī)劃的問題嗎？”
換句話說，我們其實希望模型能夠 end-to-end 理解并完成復(fù)雜任務(wù)，而不是我們?nèi)祟愊茸銮蟹郑僖粋€個跑。
有人評論得很直白：
“這讓我感覺像是在喂模型吃飯，而不是它自己動手做飯?！?/p>
關(guān)于上述這一點，小編覺得開發(fā)者有點“杠精了”。不過需要注意的是，拆分細分任務(wù)的 Agent 的做法目前還存在非共識，此前我們也報道過類似的觀點。比如 Cusor、Devin 等工具，其實都是在巨大的系統(tǒng)提示詞中做了不少的優(yōu)化工作。
圖片
圖片
3. AI審查工具的真實體驗：能用，但不太值得
評論區(qū)，有一位親歷者總結(jié)自己試用多個 AI 審查工具后的感受：
- PR 描述幾乎從不準確地總結(jié)改動
- 90% 的評論都錯或無關(guān)，常因為缺上下文
- 真正有用的評論不到 10%
這種體驗在很多網(wǎng)友那里得到了共鳴。更多人指出，代碼審查本質(zhì)上需要“部落知識”“業(yè)務(wù)上下文”“歷史約定”——這些正是 LLM 最難補足的部分。
甚至有人提出一個更靠譜的方向：
“與其讓 AI 編造判斷，不如讓它推薦歷史上類似的 PR 或 Issue 給人類 reviewer 提供參考?！?/p>
這類“語義搜索 + 輔助記憶”型的 Agent，其實才更符合當前 LLM 的能力邊界。
4. 降噪 = 提升？小心被對照組誤導(dǎo)
Cubic 的文章用幾個看上去不錯的數(shù)據(jù)展示成果：
- 評論數(shù)量減半
- 錯誤率降低 51%
- 審查效率提升
但很快就有人指出盲點：
“這些數(shù)據(jù)是跟以前那個更吵的 Agent 對比的，不是和‘沒有 Agent’的對比?！?/p>
圖片
如果你運行著一個不靠譜的機器人，然后說“我把它降低一半了”，這并不意味著它現(xiàn)在值得信任。更嚴謹?shù)膶Ρ?，?yīng)該是：
- 開著它 vs 關(guān)掉它
- AI 審查 vs 人工審查
- AI + 人 vs 只靠人
否則，這些數(shù)據(jù)看似是勝利，其實可能是“自我感動”。
寫在最后：Agent仍處于概念驗證期
小編看來，這篇博文非常有代表性。
首先，本身代碼審查 Agent 在圈內(nèi)屬于一個有爭議的方向，大模型的代碼編寫能力很強，但是讓其做代碼審核，目前還有很大的爭議。
其次，如何做一個做復(fù)雜任務(wù)的 Agent？目前業(yè)內(nèi)的做法也沒有完成共識。是做依托 LLM 做一個大而復(fù)雜的長上下文的系統(tǒng)提示詞，還是像本篇文章一樣拆分成多個“微型 Agent”，兩種做法似乎也涇渭分明。
不過，唯一的共識是，現(xiàn)在的 Agent 還遠不夠成熟。就如同昨天 Gartner 報道：目前絕大多數(shù) Agentic AI 項目仍處于早期試驗或概念驗證階段，基本是市場炒作驅(qū)動，且常常應(yīng)用不當。
一位Gartner的高級分析師 Verma 甚至毫不留情的表示：大多數(shù)（現(xiàn)在的） Agentic AI 項目商業(yè)價值或投資回報率有限。
當然，這并不完全是創(chuàng)業(yè)者團隊的問題。根本原因還是在大模型上。
Verma解釋，因為現(xiàn)有的 AI 模型上不具備足夠成熟度與自主能力，無法長時間內(nèi)自主完成復(fù)雜的業(yè)務(wù)目標，或執(zhí)行細致、復(fù)雜的指令。
所以，話說回我們今天的案例。我們當然理解 AI 工程的不易，尤其是在代碼審查這種對準確性要求極高的場景里。
Cubic 做出的努力值得尊敬，它讓我們看到一種探索路徑。不過這篇博客的評論區(qū)更提醒我們：
- 別迷信結(jié)構(gòu)化字段和術(shù)語包裝（confidence 不是 magic）
- 別低估人類上下文理解的力量（tribal knowledge 不是可prompt的）
- 別輕信自我對比數(shù)據(jù)（51% 誤判率的下降有可能只是自嗨）
最后，不知道各位看官是否在用 AI 做代碼審查，不妨在評論區(qū)分享你的體驗—— 它真的幫你省了時間，還是只是多了一個話癆同事？
參考鏈接：
https://www.cubic.dev/blog/learnings-from-building-ai-agents
