两个月用掉 130 亿 Token 后 我总结出 3 个 Codex 开发 Skill

过去两个月，我在 Codex 里累计消耗了 13B Token。单次峰值 1.1B，最长任务 12 小时 26 分。最直接的感受不是模型越来越会写，而是旧的开发组织方式开始失效：Agent 的实现速度已经快到人无法继续把逐行阅读当成唯一控制方式。

13B 不是成绩单。它只说明我足够长时间、足够高强度地撞过 Agent 开发的边界。最终沉淀下来的不是更多 Prompt，而是三个开发 Skill：SuperDev、SuperGoal 和 SuperReview。

这不是说人可以退出开发，也不是说生成代码不需要审查。变化发生在控制面：我们不再试图亲手控制每个 token，而是更早地定义系统应该长什么样，哪些边界不能越过，什么结果才算完成，以及 Agent 必须拿出什么证据。

控制面为什么必须上移

过去，一个开发者可以靠熟悉所有模块来维持系统一致性。Agent 把实现速度放大后，代码规模和变化频率也一起被放大。如果控制方式仍停留在 diff 的每一行，人的注意力会先成为瓶颈。

更可扩展的方式，是在实现前把四件事说清楚：

这四件事不是替代代码，而是给代码建立坐标系。Agent 可以自由选择局部实现，只要它没有偏离目标架构，也能通过约定好的验收。

SuperDev：开发前先把架构聊清楚

SuperDev 解决的是最靠前的问题：不要一收到需求就开始改文件。先让人和 Agent 对齐当前实现、目标逻辑和变化边界，再进入实现。

我选择 Mermaid，不是因为文字没有用，而是因为大段 AI 说明很容易制造一种“好像解释清楚了”的错觉。图会强迫系统把模块、输入、输出和依赖关系摆在同一个空间里。缺失的节点、错误的方向和不合理的中心化，通常一眼就能看出来。

Current Architecture
        ↓ identify the gap
Target Architecture
        ↓ execution evidence
PLAN.md: status / risks / verification

所以“两份文档，三件事情”是一个很轻的契约：当前架构、目标架构、已经发生的工作。它们让人不必阅读 Agent 的全部思考过程，也能知道系统在哪里、要去哪里、现在走到了哪一步。

SuperGoal：把目标架构拆成可并行的工作

架构清楚以后，SuperGoal 让 Codex 的主 Agent 把目标状态翻译成可验收的 Goal Contract，再寻找互相独立的工作切片。只要写入范围不冲突、依赖关系允许，就尽量交给多个 subagent 并行完成。

这里的目标不是 spawn 得越多越好，而是尽可能安全地并行。两个 subagent 同时修改同一组核心文件，往往只会制造冲突和重复上下文。真正适合并行的是只读探索、独立模块、互不相交的实现，以及独立验证。

主 Agent 也不能退化成消息转发器。它负责目标、范围、依赖、整合和最终验收。subagent 只拥有一个有边界的子目标，完成后返回证据，而不是重新定义项目方向。

SuperReview：主 Agent 判断，subagent 原子修复

SuperReview 使用同一套分工，但把重点放在代码审查。主 Agent 先冻结 PR 或 working tree 的准确边界，亲自读完整 diff 和必要的上下文，确认哪些问题真的可复现、应该修、优先级是什么。

finding 确认后，每一个互相独立的问题都可以交给一个 repair subagent。它只允许处理一个 finding，并返回最小补丁和验证结果。如果多个问题会写同一个模块，就顺序修，不为并行而并行。

循环会继续，直到审查范围内没有未解决的 actionable finding。这里不能承诺“软件从此没有 bug”，那是不诚实的。能承诺的是：每个已发现问题都有状态，每个修复都经过重新验证，最终结论对应的是一个明确、完整的变更集合。

为什么是瞄准环、构建体和扫描框

我一开始也考虑过用三个球。但球只有尺寸差异，表达不了三种职责。最后我让三个 Skill 拥有不同的工程形态。

这三个装置表示责任，不是死板的时间顺序。新项目通常从 SuperDev 的架构讨论开始，再由 SuperGoal 组织执行；SuperReview 发现结构性问题时，也会把工作重新送回 SuperDev。它们最终形成的是一个闭环。

人、主 Agent 和 subagent 的新分工

这不是让开发者少负责，而是让责任落在更有杠杆的位置。我们仍然会看关键代码，但不再幻想靠阅读全部生成代码来维持控制。真正稳定的系统，依靠的是清楚的架构、有限的权限、可观察的状态和不能被语言绕过的验收。