我不需要几百个 Codex agent：我要的是能看懂、能审查的改动

Tue, 15 Sep 2026 08:00:00 +0800

把活交给 Codex，最舒服的永远是刚开头那几分钟。你丢给它一个需求，它刷刷刷地改文件、跑命令，你坐在旁边看着，感觉自己一个人就顶了一支团队。

可一旦这个「活」开始变大，另一种焦虑就会冒出来：它到底改了什么？为什么这么改？测试到底跑过没有？

Rafael Pierre 是 Lighthouse AI 的工程师，长期做架构、逆向和实验。他给出的判断和主流的「堆 agent」叙事正好相反：我不需要几百个 Codex agent，我需要的是能看懂、能审查的改动。

把历史留在 GitHub

一个人写项目的时候，开 issue、提 PR 看起来像多余的行政手续。没有同事在等你的解释，你自己也知道想做什么。

但几周后回来看，你会想理解一个实现背后的约束，而不是去翻当初那段几十万 token 的对话。一条 commit message 能解释一个决定，但只有 issue 和 PR 才能完整保留这个决定是怎么演化出来的：原始需求是什么、考虑过哪些方案、review 时提了什么反馈、后来又改了哪些。

这份历史，在你需要回头改实现、或者追查一个 bug 是怎么溜进去的时候，会格外有用。它也让 agent 之间切换变得更顺滑：你可以把 issue 和 PR 直接丢给 Claude Code、Copilot、Hermes 接着干，而不是从旧对话里重新拼凑上下文。

给 Codex 一个能验收的需求

也许不算秘密了，但 agentic engineering 的成功率，跟你描述工作的方式直接挂钩。

一个「改进 onboarding」这样的标题，够提醒你自己有个想法，却给 Codex 留下了太多推断空间。它可能为了消歧，对整个仓库做一次全面分析，烧掉一大笔 token；也可能干脆瞎猜，然后惨败。最糟的是两种错一起犯。

作者的办法是把话说全：问题是什么、为什么必须解决、现在表现如何、期望的行为是什么、有哪些约束、结果该怎么验证。Codex 再把这些整理成一个 GitHub issue，对照 backlog 补上合适的 label 和优先级。

他举了一个自己项目的例子：一个聊天前端，突发的事件流偶尔会把健康的响应掐断。这里的需求不止「修好报错」，还包含三条验收标准：正常突发要能完整跑完、卡住的客户端要有受控清理、队列必须保持有界。这些标准给了 Codex 一个具体的靶子，也给了你自己一把衡量实现的尺子。

把仓库规则写进 AGENTS.md

源码本身不会可靠地告诉你：一个新的后端服务该放在哪、哪些模块必须保持独立、一个改动 ready 之前要过哪些检查。

作者把这些写进 AGENTS.md，覆盖两部分：项目的架构，以及贡献它的流程。于是 prompt 可以聚焦在具体的改动上，剩下的让 Codex 自己按规则去 scope 和跟踪成 issue。

12000 次 AI 代码审查的真相：审到第四轮就该收手

Mon, 14 Sep 2026 09:00:00 +0800

想象一下你的日常：你让 Codex 写了一段代码，然后让另一个 AI 帮你审查。它报了几个问题，你让 Codex 去改，改完再送审。第二轮、第三轮、第四轮，你盯着这个循环，脑子里冒出一个问题：这到底什么时候是个头？多审几轮，代码真的在变好吗？

大多数团队根本回答不了这个问题。他们只知道「AI 帮我写、AI 帮我审」，却从没想过审查这件事本身也可以被量化。John Watson 在 2026 年 8 月的一篇文章里，给出了一个罕见的答案。他帮一家叫 Gymwasp 的公司搭了一套「软件工厂」流水线，让 AI 从规划一路干到发布，全程没有一个人类去读代码。六个月之后，他从 372 个 issue、1801 轮对抗性审查、将近 1.2 万条审查结论里，挖出了六个反直觉的发现。

七个审查员，各管一摊

这套工厂的名字叫 The Mandible。它的审查环节同时跑七个独立的审查 agent，每个 agent 跑在自己的模型实例上，互相看不到对方发现了什么。七个「赛道」分别是：测试覆盖率、整洁代码、前端、领域驱动设计、安全、无障碍、可观测性。每个审查员给出三种结论之一：pass（通过）、warn（警告，不阻塞合并）、fail（失败，阻塞发布），一轮的最终结论取七者中最差的那个。

这里藏着一个容易被忽略的细节：每个审查员都拿到一份「赛道外排除清单」，明确告诉它哪些事不该它管。作者说，没有这份清单，你会看到同一个问题被七个审查员重复报七遍。

发现一：六成五一轮就过

数据里最反直觉的一点是，合并就绪来得比想象中快得多。65% 的 issue 在第一轮审查之后就没有任何 fail 赛道了，94.5% 三轮内达标，98.9% 四轮内达标。换句话说，绝大部分价值在第一轮就已经落地。真正拖到第四轮之后的，往往是那些复杂的 PR，它们在 LLM 的非确定性面前，想拿一个「全绿」几乎不可能。

这里要分清两个概念：「合并就绪」（没有 fail）和「全绿」（七条赛道全部 pass）。前者才是决定代码能不能上线的指标，后者更多是心理安慰。

发现二：第四轮之后，多审反而更糟

如果额外的轮次真的在帮忙，「本轮通过的概率」这条曲线应该持续攀升。但数据显示它既不升也不平，而是先减半、再原地踏步。第一、二轮的转化率大约是 25%，从第三轮开始，审查进入了「震荡」而不是「收敛」。

更麻烦的是，有 218 个 fail 出现在之前一直干净的赛道上。原因不难理解：每一次修复都会碰到相邻的代码，从而在新地方触发新的问题。作者说得很直接：第四轮是一个「肘点」，过了这个点，多花一轮审查引入的不确定性，和它想消除的不确定性一样多。

发现三、四：29% 从没拿过全绿，天真的平均值会低估成本 44%

如果只看那些「全绿」的 issue，平均每单要 3.31 轮。但把「带着 warn 上线」的也算进去，诚实的数字是 5.99 轮，差了将近一倍。有 29% 的 issue 从头到尾没拿到过全绿，它们是带着 warn 被发布出去的。

Code Review on Codexer