摘要：最近，一篇名为《How we made our AI code reviewer stop being so noisy》的博客引发了热议。
“我们用 AI 来做代码审查，结果它比我老板还话多。”——这句话可能是很多开发者的真实写照。
最近，一篇名为《How we made our AI code reviewer stop being so noisy》的博客引发了热议。
作者是一位创业公司的创始人，Paul Sangle-Ferriere，这家公司致力于打造一个 AI原生的 GitHub。
这篇文章里讲述了他们团队如何优化一个 AI Agent，让它在 PR 审查中少说废话。虽然有一些观点和做法值得借鉴。
但是评论区却热闹非凡、甚至“翻车”：“例子选得烂”、“信心值是编的”、“这不就是 Copilot 的烂尾问题吗？”
各位不妨一看，相信大家会有自己的判断。
AI 代码审查 Agent 听起来很美：自动识别 bug、反模式、重复代码，协助团队更快更稳地交付代码。可现实往往是——你以为它在帮你，结果只是在“刷存在感”。
我们是 cubic 的团队，一个致力于打造“AI 原生 GitHub”的产品。我们上线过一个 AI 代码审查 Agent，主打 PR 初审。上线第一天，开发者的反馈就很直接：
“太吵了！”
是的，它“滔滔不绝、不厌其烦”地指出每一处无关痛痒的地方，甚至重复 Linter 已经提示的内容，还夹杂着一些离谱的误报——一场“信息污染”风暴。我们意识到：如果不能让它闭嘴，就别指望开发者信它。
经过三次架构重构、数十次 offline 调试，我们最终把误报率降低了 51%。这不仅让 Agent 变“安静”了，更变“聪明”了。以下是我们踩过的坑、学到的招。
我们最初的架构非常符合“直觉”：
复制
[diff]↓ [一大段 prompt（带上下文）]↓ [输出所有建议]1.2.3.4.5.看上去不错，优雅且简单，但在真实环境下却迅速玩崩了：
误报一堆：代码样式风格问题被当成 bug；已修复的 bug 被反复提示；Linter 的建议被复制粘贴。没人信它：一半建议不靠谱，剩下一半也没人看了。改 prompt 毫无用：你就算在 prompt 里写明“请忽略小问题”，它依然我行我素。我们试过加长上下文、调模型 temperature、换 sampling 策略……都没明显改善。
没办法，是时候彻底反思了。
经过数轮试验，我们终于打造出一套效果稳定、实际可用的新架构，成功让误报率降低了 51%，并已部署至生产环境。以下是其中的三个关键策略：
后来，我们要求 AI 在输出任何建议前，必须先明确写出它的“推理逻辑”：
复制
{ "reasoning": "`cfg` can be nil on line 42; dereferenced without check on line 47", "finding": "Possible nil‑pointer dereference", "confidence": 0.81}1.2.3.4.5.这个结构让我们获得了三重收益：
可追踪性大幅提升：开发者能 debug 模型行为，快速看出判断逻辑哪里出了问题，从而精准调整模型行为。强制 AI 结构化思考：AI 只有先说出“为什么”，AI 才能提出“该怎么做”，有效减少了随意下结论的情况。为未来问题排查打基础：很多后续的问题都可以通过推理日志溯源解决。一句话：强制思考比调模型参数更有效。
我们原本给 Agent 配了很多工具：LSP、静态分析器、测试框架……结果发现：
90% 有效建议都来自极少数几个工具，其他的反而制造噪音。
精简版 LSP（Language Server Protocol）基础终端环境（供 Agent 动手查）结果？精简后的工具链让 AI 更聚焦于识别真正的问题，准确率显著提升，出错更少了。
“忽略 .test.ts 中的未使用变量的提示”“跳过 init.py 的导入检查”“不要 lint markdown 文件”但最终发现这条路完全走不通。规则又多又乱，AI 记不住，也执行不好。
Planner Agent：识别变化点、规划检查顺序安全 Agent：检测注入、认证问题重复代码 Agent：识别 copy-paste编辑 Agent：修正拼写与文档一致性每个 Agent 都有明确边界和上下文，专精于一个细分任务，误报自然减少了，运行效率也没拉垮。虽然多个 Agent 会带来 token 重叠问题， token 消耗有所增加，但我们用缓存策略有效平衡了开销。
误报减少 51%PR 评论数减少一半（不再刷屏）团队审查体验明显改善，信任度回升，Merge 效率提高更重要的是，开发者反馈整体满意度提升明显，不再视 AI 为“吵闹的小孩”，而是靠谱的“初审助手”。他们更愿意依赖 AI 完成初审，大大加快了交付速度。
总结下来，核心经验就三句话：
① 显式推理，提升可解释性：要求 AI 在提出建议前先解释“为什么”，既提升准确率，也便于后期调试。
② 工具越少越好，定期评估工具链，把实际使用频率低于 10% 的工具砍掉，保持轻量高效。
③ 任务专精化用多个微型 Agent 分别处理单一任务，能显著提升上下文利用效率与判断准确度。
AI 的“喧哗期”正在过去，接下来拼的是实用性和信任感。如果你也在做 Agent，不妨试试让它“先别说话，先想一想”。
本来是一片分享代码审查Agent优化心得的博客，但评论区的大佬真的是卧虎藏龙。一眼就看出上述三条建议的不妥之处。可以说每条建议都被反驳得有理有据。
小编整理了下，主要有以下观点。
复制
"confidence": 0.811.表面上看，这很专业，仿佛 AI 做了充分思考，还为自己的判断打了个分。但评论区一针见血指出：
“你知道这个 confidence 值是完全胡编的吗？”
一位网友指出，事实上，LLM 并不具备“自我置信评估”的能力。它生成的每个字段，只是按提示模仿结构在编内容。一个 0.81 或 0.92，看上去专业，其实没有统计意义，也没有任何实际校验机制。
正如一位评论者讽刺地说：
“要不干脆加一个字段叫 confidence_in_confidence_rating？”
更有人表示，他们测试时让模型两次对同样输入做 reasoning trace，居然得到了两种语义接近但表述不同的输出。换句话说，不是它骗你，而是它根本没想清楚自己在说什么。
也就是说，你让大模型输出前先思考“为什么”，但回答这个“为什么”的置信度完全是站不住脚的。这个基础崩塌了，理论上也没有什么真实价值。
这种结构的优点是模块清晰、上下文更聚焦，确实在短期内提升了准确率。
但不少开发者质疑：
换句话说，我们其实希望模型能够 end-to-end 理解并完成复杂任务，而不是我们人类先做切分，它再一个个跑。
有人评论得很直白：
“这让我感觉像是在喂模型吃饭，而不是它自己动手做饭。”
关于上述这一点，小编觉得开发者有点“杠精了”。不过需要注意的是，拆分细分任务的 Agent 的做法目前还存在非共识，此前我们也报道过类似的观点。比如 Cusor、Devin 等工具，其实都是在巨大的系统提示词中做了不少的优化工作。
PR 描述几乎从不准确地总结改动90% 的评论都错或无关，常因为缺上下文真正有用的评论不到 10%
这种体验在很多网友那里得到了共鸣。更多人指出，代码审查本质上需要“部落知识”“业务上下文”“历史约定”——这些正是 LLM 最难补足的部分。
甚至有人提出一个更靠谱的方向：
“与其让 AI 编造判断，不如让它推荐历史上类似的 PR 或 Issue 给人类 reviewer 提供参考。”
这类“语义搜索 + 辅助记忆”型的 Agent，其实才更符合当前 LLM 的能力边界。
Cubic 的文章用几个看上去不错的数据展示成果：
评论数量减半错误率降低 51%审查效率提升但很快就有人指出盲点：
“这些数据是跟以前那个更吵的 Agent 对比的，不是和‘没有 Agent’的对比。”
如果你运行着一个不靠谱的机器人，然后说“我把它降低一半了”，这并不意味着它现在值得信任。更严谨的对比，应该是：
开着它 vs 关掉它AI 审查 vs 人工审查AI + 人 vs 只靠人小编看来，这篇博文非常有代表性。
首先，本身代码审查 Agent 在圈内属于一个有争议的方向，大模型的代码编写能力很强，但是让其做代码审核，目前还有很大的争议。
其次，如何做一个做复杂任务的 Agent？目前业内的做法也没有完成共识。是做依托 LLM 做一个大而复杂的长上下文的系统提示词，还是像本篇文章一样拆分成多个“微型 Agent”，两种做法似乎也泾渭分明。
不过，唯一的共识是，现在的 Agent 还远不够成熟。就如同昨天 Gartner 报道：目前绝大多数 Agentic AI 项目仍处于早期试验或概念验证阶段，基本是市场炒作驱动，且常常应用不当。
一位Gartner的高级分析师 Verma 甚至毫不留情的表示：大多数（现在的） Agentic AI 项目商业价值或投资回报率有限。
当然，这并不完全是创业者团队的问题。根本原因还是在大模型上。
Verma解释，因为现有的 AI 模型上不具备足够成熟度与自主能力，无法长时间内自主完成复杂的业务目标，或执行细致、复杂的指令。
所以，话说回我们今天的案例。我们当然理解 AI 工程的不易，尤其是在代码审查这种对准确性要求极高的场景里。
Cubic 做出的努力值得尊敬，它让我们看到一种探索路径。不过这篇博客的评论区更提醒我们：
别迷信结构化字段和术语包装（confidence 不是 magic）别低估人类上下文理解的力量（tribal knowledge 不是可prompt的）别轻信自我对比数据（51% 误判率的下降有可能只是自嗨）最后，不知道各位看官是否在用 AI 做代码审查，不妨在评论区分享你的体验—— 它真的帮你省了时间，还是只是多了一个话痨同事？
https://news.ycombinator.com/item?id=44386887
来源：51CTO一点号