Codex/Claude 脚踏车要蹬冒烟了
内容提要
作者分享使用 Claude Fable 与 Codex 5.6 的体验：额度定期重置，攒着不用就是损失，应尽快消耗。建议分工协作，Fable 负责顶层设计与创意，Codex 负责稳定执行，两者互相 Review。实用技巧包括对抗性 Review、规格驱动设计、明确验收标准、上下文管理与 Sub-agent 调度。作者借此一人维护 Pigsty 大型项目，认为个人生产力被极大释放。
延伸解读
额度重置下的使用策略
文章指出，Claude 和 Codex 的额度会定期重置，攒着不用就会过期作废。作者以自身经历说明，若将额度留到重置前未用完，相当于损失了潜在价值。因此建议在额度重置周期内尽快消耗，避免浪费。这一策略基于订阅制下额度不可累积的特性，提醒用户调整使用节奏。
模型分工与协作流程
作者根据体验认为，Claude Fable 擅长顶层设计与创意，Codex 5.6 则稳定可靠、适合执行。建议的工作流是：Fable 负责总体设计，Codex 进行具体实现，然后两者互相 Review 以收敛质量。这种分工能发挥各自长处，尤其适合需要创意与执行并重的项目。
实用技巧与上下文管理
文章分享了几个关键技巧：对抗性 Review 通过两个 AI 互相挑错提高可靠性；规格驱动设计强调先写文档再生成代码；验证闭环要求明确验收标准；上下文管理则建议用 Sub-agent 处理杂活，主 Agent 专注调度。这些方法旨在控制复杂度，提升 AI 协作效率。
个人生产力释放与团队局限
作者以一人维护 Pigsty 大型项目为例，说明借助 Claude 和 Codex 可极大释放个人生产力，甚至有余力开展副业。但他也指出，这种模式依赖零沟通成本，难以直接外推到需要大量对齐的团队环境。个人或一人公司更能受益于当前 AI 工具的红利。
Q&A
为什么说 Claude 和 Codex 的额度攒着不用就是损失？
因为额度会定期重置，攒着不用到期就会清零，相当于白白损失了本可以消耗的额度价值。作者举例说，一周的 Claude 额度如果用满，能榨出三五百万 token 的输出，账面价值约 2000 多美元，折合人民币一万块钱上下，省着用结果被重置清零，就相当于损失了八千多块。
Claude Fable 和 Codex 5.6 各自适合做什么？
Fable 想象力狂野、天马行空、极有创意，适合做顶层设计和出总体 Design；Codex 是稳定可靠的执行者，量大管饱，适合照着设计做具体实现。两者可以轮流 Review 收敛质量。
对抗性 Review 是什么？为什么有用？
对抗性 Review 也叫 Oracle 模式，就是找两个 AI 互相对抗、互相审查。能达成共识的部分通常更可靠，有分歧的部分通过反复讨论协商也能收敛出共识。这种共识状态比一个 AI 自己审自己更靠谱。
什么是规格驱动设计（Spec-Driven Design）？
规格驱动设计是指中型复杂度以上的项目，先写文档、写设计规格，把 Spec 打磨讨论到满意为止，再照着规格去生成代码，而不是一股脑上去就干。小活可以赌一把，但复杂特性和工程如果直接干，质量控制就是一场灾难。
如何管理 AI 的上下文以避免超出限制？
主要办法有两个：一是先规划再执行，规划阶段的思考压缩成一份凝练的 SPEC 文件，执行阶段开新会话读 SPEC，省下规划过程的上下文；二是让 Sub-agent 干杂活，主 Agent 只负责调度、收拢结果、派发新任务，具体脏活累活交给 Sub-agent，Sub-agent 只吐回摘要，从而极大节约主 Agent 的上下文。
作者用 Claude 和 Codex 维护 Pigsty 项目的体验如何？
作者一个人维护 Pigsty 这个巨型 PostgreSQL 发行版，涉及几万个 RPM 包、无数组件在 16 个 Linux 平台上协调集成测试。借助 Claude 和 Codex，他还能时间有余，可以搞副业甚至接盘 MinIO。他认为个人生产力被极大释放，但这种模式可能无法直接外推到团队，因为一人干活没有沟通成本，而大公司沟通对齐是最大摩擦。
