Usage

Codex使用技巧

摘录自公众号《老冯云数》

• 对抗性 Review（Adversarial Review）

现在也有人管这叫 “Oracle 模式”，说白了就是管理学里的制衡术：找两个 AI 互相对抗。能达成共识的部分，通常更为可靠；有分歧的部分，通过反复讨论协商，最终也能收敛出共识。这种共识状态，比一个 AI 埋头苦干、自己审自己，要靠谱得多。

• 先规划再干活，即"规格驱动设计"（Spec-Driven Design）

中型复杂度以上的项目，先写文档、写设计规格，把 Spec 打磨讨论到你满意为止，再照着规格去生成代码——而不是像抽卡摇骰子一样一股脑上去就干。小活可以赌一把，复杂特性和工程要还这么玩，质量控制就是一场灾难。Spec-Driven Design 就是解这个问题的。

• 验证闭环

派任务的关键，是给出清楚的验收标准。比如让它构建一个 RPM 包，验收标准就两条：第一，构建出来的包在我的标准容器和虚拟机环境里装得上、跑得通，加载不 crash、不 core dump；第二，按官方文档列出的主要功能点设计测试用例，全部跑通不报错。有了清楚的验收标准，事情就好办了：这类任务可以用 GOAL-driven 的方式发起——目标明确，它自己就会不断迭代，直到把问题干掉。

• 上下文管理，重中之重

你得对一个活的复杂度心里有数：它能不能在一个 session 的上下文里跑完？跑不完，就要靠拆解来控制复杂度。办法主要两个：先规划再执行。规划阶段的思考被压缩成一份凝练的 SPEC 文件；执行阶段直接开新会话读 SPEC，规划过程的上下文就全省下来了。

• 让 Sub-agent 干杂活

比如要在很多个 Linux 平台上构建包，主 Agent 只管调度、收拢结果、派发新任务，具体平台上的构建交给 Sub-agent。Sub-agent 的上下文被脏活累活填满，最后只吐回一句摘要——成没成、挂在哪。主 Agent 的上下文因此得到极大节约，就能撑着调度更久、更复杂的工作。

• 利用最后一条消息

Codex 在周额度打满的最后时刻，可以拉起一个巨无霸任务，这个任务会无视配额，直到完成为止。比如趁着周额度还剩 2%，给它派个大任务接着跑。