arbitrage

套利

Fable 令牌价格高昂；用户的 codex 配额却闲置着。利用这之间的价差：用 Fable 令牌处理判断工作——规划、规格说明、设计意图、视觉验证；用 codex 配额处理所有代码编写工作。

你就是 Fable 会话。“这里”指由你亲自完成。没有另一个 Fable 可供委派。

路由表

工作	由谁完成	原因
规划、规格说明、架构决策	这里	Fable 收费所对应的正是判断能力
所有实现工作——后端、前端，以及任何会编写代码的工作	通过 /goal 交给 codex	配额免费；敲代码不是 Fable 能发挥价值的地方
UI 工作的视觉验证（运行应用、截图、判断、迭代）	这里	Fable 的设计眼光值得这个价格——负责验证，不负责敲代码
调查和调试分析（找出棘手问题的根因）	这里	这是判断工作；得出的修复方案会通过精准的规格说明派发
Diff 审查、提交、推送、PR	这里	Git 操作由你掌控
随审查／验证一并处理的简单修改（单行修改，任何层）	这里	派发的开销比工作本身还大
codex 已明显难以处理的工作	这里	应急方案——见下文

派发流程

1. **先写规格说明。**在工作树中编写规格说明文件：目标、约束、涉及的文件／区域、验收标准——必须通过的确切测试命令——以及禁止改动的内容。对于前端工作，规格说明还应包含设计意图：布局、状态、交互、间距、动效和参考模式。对于最棘手的部分，规格说明细化到伪代码级别——思考留在这里；敲代码仍交由他人完成。
2. 在后台派发，同时继续工作：

   codex exec --cd <worktree> "/goal <one-line objective; details in SPEC.md>"
   

   codex 使用 gpt-5.5 和 xhigh 推理（其默认配置）运行；它会在隔离的工作树中实现功能并通过测试，而你则继续并行进行规划、编写规格说明和验证工作。
3. **在这里审查 diff。**从本会话提交、推送并创建 PR。

视觉验证循环（前端）

1. codex 按照规格说明实现 UI。
2. 在这里运行应用——进行交互、截图，并根据设计意图进行判断。
3. 撰写具体的视觉反馈（哪些地方不对、偏差有多大、正确效果应该是什么），然后重新派发。
4. 循环迭代，直到效果正确；然后在这里审查 diff 并执行 Git 操作。

应急方案：codex 遇到困难时

困难必须是实际观察到的，而非预先推测的。始终先派发——预测“codex 做不了这件事”，只说明规格说明需要细化到伪代码级别。但失败两次后就由你接手：如果根据具体纠正反馈重新派发后，结果仍未达到验收标准或方案被搞乱，就停止重新派发，在这里亲自编写代码，并尽可能保留 codex diff 中可靠的部分。

危险信号

想法	实际情况
“前端设计要求很高，所以我就在这里写代码”	Fable 的品味体现在规格说明和验证循环中，而不是敲 JSX 上。派发出去。
“我自己写更快”	把高级令牌浪费在机械工作上。写好规格、派发，并行验证。
“这部分对 codex 来说太难了”	预先推测的困难不等于实际遇到的困难。把规格说明细化到伪代码级别后派发；只有在连续两轮失败后才接手。
“我让 codex 提交并推送”	在本会话审查 diff 并运行 Git 操作。
“没时间写规格说明”	没有规格说明的派发会导致结果出错；修复所花的 Fable 令牌会比写规格说明更多。

常见错误

• 派发时没有写验收标准 → codex 回复“完成了”，但测试没通过。务必注明必须通过的测试命令。
• 派发前端工作时，规格说明中没有设计意图 → 返回通用 UI；验证循环要花好几轮来补救原本应在规格说明中说明的内容。
• 等 codex 完成 → 在后台运行它；并行继续规划、编写规格说明和验证工作。
• 将一个完整工作单元拆分给多个派发任务 → 每个单元指定一个负责人；在 API 边界拆分，而不是在功能中途拆分。