我不需要几百个 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 接着干，而不是从旧对话里重新拼凑上下文。

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

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

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

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

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

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