Skip to main content

本页要完成什么

这一页用一个具体的 TODO API v2 项目,演示如何把跨模块需求变成可并行、可检查、可暂停、可恢复的交付流程。项目当前已经支持创建和列出待办,本次增加:
  • GET /todos 的分页、completed 和 tag 筛选;
  • PATCH /todos/{id} 对 title、tag、completed 做部分更新;
  • 保留已有响应字段、认证方式和错误格式;
  • 通过单元测试、接口测试、lint、类型检查和构建。
不在本次范围内:更换数据库、修改前端、重做认证、连接生产服务、删除历史迁移、无审批提交或发布。你可以把 TypeScript、Node.js 和下列路径换成实际项目的技术栈,但流程和边界应保持一致:
完成定义: 具体命令和 Codex 界面会随版本变化。遇到差异时,以本机 codex --help、对应子命令的 --help 和官方文档为准。

01 开工检查:确认工作区和基线

先进入仓库根目录,确认路径、分支、HEAD、已有修改和工具版本。不要把别人的未提交修改当成自己的基线,也不要用 git reset --hard 清理不明来源的修改。
给主代理的第一条提示词:
预期不是“可以开始”,而是可核对的事实:
验收:代理没有产生 diff,git status 与开始时一致。如果它误改了文件,先保存并查看 git diff,不要将检查和实现混在一起。

02 计划模式:把不确定性暴露出来

在 CLI 或 App 中进入计划模式;不同版本可能使用按钮或 /plan。计划的目标是明确契约、依赖、并行机会和审批点,不是生成一篇漂亮长文。
合格的任务图应类似: 要求代理把“改一下接口”“优化数据库”改写成明确决定。例如:page_size 上限是多少?空 tag 是不筛选还是筛选空标签?旧客户端收到数组还是对象?如果这些问题没有答案,计划必须标记 BLOCKED,而不是让实现代理自行猜测。 计划审查提示词:
预期输出:阶段 1 read、阶段 2 write、数据库迁移 external、commit/push/release irreversible。验收:契约和任务依赖由人确认,未批准动作没有执行。

03 任务拆分:按结果和依赖分工

拆分不是按文件数量平均分配,而是让每项任务有一个主要结果、明确输入、有限文件范围和独立验证。建议采用四条工作流。

A:只读探索

预期:证据索引,而不是修复建议。验收:每条结论都能回到文件或测试。

B:API 契约

预期至少覆盖默认分页、超限、非数字、非法布尔值、空标签、无结果、空标题和旧客户端。验收:主代理、实现代理和测试代理使用同一份已批准契约。

C:数据层实现

预期:稳定排序、明确分页边界、部分更新不覆盖未传字段,且 diff 不越界。

D:路由和接口测试

04 阶段 0 和阶段 1:基线与契约交付

阶段 0 先记录基线,不要顺手修历史失败:
提示词:
预期记录:base=8f31c2a、npm test=PASS,或列出已有失败。验收:没有新 diff。回滚:无需回滚;只清理项目明确允许的缓存。 阶段 1 执行只读探索、契约讨论和任务图审批。交付物:
验收:歧义全部得到决定,或明确标记 BLOCKED。回滚:废弃错误的契约草稿,保留已批准版本;不要让代理以旧契约继续实现。

05 阶段 2:Worktree 中实现数据层

多个线程的上下文隔离不等于文件系统隔离。并行写入必须使用不同 Worktree,或严格串行使用同一工作区。推荐: 在 App 中新线程选择 Worktree、选择起始分支,再发任务;Worktree 默认可能是 detached HEAD,需要提交时先创建分支。CLI 是否具备同样界面能力以本机版本为准,不要假设有通用 --worktree 参数。 启动提示词:
审批提示词:
预期:
验收提示词:
回滚:先保存 git diff > phase-2.patch,确认目录没有他人改动后按文件恢复,或废弃整个临时 Worktree。不要用 git restore . 覆盖无关修改。

06 阶段 3:路由、服务和接口测试

阶段 2 通过后,才能基于它的提交创建或更新路由 Worktree。不能靠两个目录“看起来一样”判断依赖已满足,先核对提交哈希。
预期:接口测试覆盖分页、筛选、部分更新、非法输入、无结果、未知 ID 和旧请求;测试命令和退出码明确。验收:代码路径、测试和 diff 三者都与契约一致。 若失败:保留阶段 2 有效提交,不合并阶段 3;若根因是契约,回到阶段 1 重新审批,不在路由里偷偷同时支持矛盾的两种契约。

07 子代理:并行探索和独立审查

Codex 不会自动拆分,必须明说“派几个代理、各做什么、是否等待全部、返回什么摘要”。子代理最适合只读、可独立的工作:扫描不同模块、分别做正确性和兼容性审查、运行互不冲突的检查。不适合多个代理同时改同一类型、生成同一迁移或处理强顺序依赖。 阶段 4 审查提示词:
预期:
审查验收:阻塞项必须修复并有回归测试;应修项要修复或由负责人批准延期;建议项不自动扩大范围。审查代理没有写文件,git status 不应多出未授权修改。 如需自定义只读代理,可放在项目 .codex/agents/:
多个结果矛盾时,要求双方引用证据,用最小复现测试验证,仍不能判定则人工决定;不要用代理投票代替事实。

08 冲突处理:文件、契约和资源分开看

文件冲突

处理顺序:保存双方提交和 diff;对照契约;在集成 Worktree 做最小合并;运行受影响测试和完整测试。

契约冲突

如果一方按数组写路由、另一方按对象写测试,这是决策冲突,不是普通文本冲突。回到契约负责人,决定响应形状和兼容方案后,再同步改代码和测试。

资源冲突

共享测试数据库、端口或锁文件时,优先使用独立临时资源;不能隔离就串行。禁止为了“解决占用”杀别人的进程、删除锁文件、重置数据库或读取主工作区 .env。涉及外部资源重新请求审批。

09 Worktree 的边界和常见错误

检查独立性:
同一分支不能同时在两个 Worktree 检出。遇到:
先找出占用目录,确认哪个线程继续使用;另建分支,或用 App 的 Handoff 转移线程。不要强行删除锁或目录。Worktree 中的 .env、缓存和 node_modules 不会因 Handoff 自动搬运。缺依赖时只能运行项目已有 setup 脚本,不要复制真实密钥或连接生产:
清理有改动的 Worktree 前先记录提交、补丁和状态;没有有效改动的临时 Worktree 才能在确认无人使用后清理。长期环境使用永久 Worktree,避免误删重要工作。

10 审批和集成验收

按影响分档: 所有 Worktree 完成后,在专用集成区执行:
集成提示词:
获批后:
最终验收:
  • D1-D7 每项都有文件、命令、退出码或测试名称作为证据;
  • git diff --check 通过,diff 只含批准文件;
  • 分页、筛选、部分更新和旧行为都被测试;
  • 错误状态、响应体和状态码符合契约;
  • 没有 .env、令牌、日志、缓存、意外锁文件或生成目录;
  • 没有未解决审查意见;
  • 回滚到基线、阶段提交或补丁的路径清楚。
最终验收提示词:

11 回滚、恢复和阶段性交付

阶段记录应包含:
失败分三类:
  1. 未提交 Worktree:保存 git status、git diff --stat 和补丁;确认目录没有他人修改后按文件恢复或废弃临时 Worktree。
  2. 已提交未合并分支:保留提交哈希,不合并失败阶段;需要修复时创建新提交,不能改写共享历史。
  3. 已进入共享分支或外部系统:使用新的反向修复提交;数据库使用项目已有回退迁移、备份恢复或补偿迁移,Git 回滚不能撤销已经写入的数据。
测试失败也要分类:断言失败是代码或契约问题;缺依赖是 setup 问题;端口占用是资源冲突;网络超时不是循环重试理由;权限拒绝应检查审批,不要扩大权限。 阶段交付表:

12 最终交付提示词和速查

人工查看:
本地提交也要单独批准:
全流程速查:
每条实现提示词都应写出:背景目标、文件范围、不可变契约、允许/禁止动作、验证命令、停止条件、预期输出、验收证据和回滚点。每次并行前都确认任务独立、写入目录隔离、分支不重复检出、资源可隔离、主代理保留最终决策权。

小结

可靠的 TODO API 协作不是让更多代理同时工作,而是让每个代理拥有明确边界,让每个阶段都能被证明、暂停和恢复:计划模式负责暴露未知事项;契约负责统一实现和测试;只读子代理负责并行探索与审查;Worktree 负责隔离并行写入;审批负责拦住联网、数据库、删除、提交和发布;集成阶段负责最小解决冲突;阶段提交和补丁负责恢复。 迁移到其他项目时,只替换 API 契约、文件路径和验证命令,仍然遵循“先读后写、先契约后实现、先隔离后并行、先证据后交付”。 参考资料:参考/codex/34-capstone.md、参考/codex/14-workflows.md、参考/codex/21-subagents.md、参考/codex/25-worktrees.md。