本页要完成什么
这一页用一个具体的 TODO API v2 项目,演示如何把跨模块需求变成可并行、可检查、可暂停、可恢复的交付流程。项目当前已经支持创建和列出待办,本次增加:GET /todos的分页、completed和tag筛选;PATCH /todos/{id}对title、tag、completed做部分更新;- 保留已有响应字段、认证方式和错误格式;
- 通过单元测试、接口测试、lint、类型检查和构建。
具体命令和 Codex 界面会随版本变化。遇到差异时,以本机
codex --help、对应子命令的 --help 和官方文档为准。
01 开工检查:确认工作区和基线
先进入仓库根目录,确认路径、分支、HEAD、已有修改和工具版本。不要把别人的未提交修改当成自己的基线,也不要用git reset --hard 清理不明来源的修改。
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:数据层实现
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。不能靠两个目录“看起来一样”判断依赖已满足,先核对提交哈希。07 子代理:并行探索和独立审查
Codex 不会自动拆分,必须明说“派几个代理、各做什么、是否等待全部、返回什么摘要”。子代理最适合只读、可独立的工作:扫描不同模块、分别做正确性和兼容性审查、运行互不冲突的检查。不适合多个代理同时改同一类型、生成同一迁移或处理强顺序依赖。 阶段 4 审查提示词:git status 不应多出未授权修改。
如需自定义只读代理,可放在项目 .codex/agents/:
08 冲突处理:文件、契约和资源分开看
文件冲突
契约冲突
如果一方按数组写路由、另一方按对象写测试,这是决策冲突,不是普通文本冲突。回到契约负责人,决定响应形状和兼容方案后,再同步改代码和测试。资源冲突
共享测试数据库、端口或锁文件时,优先使用独立临时资源;不能隔离就串行。禁止为了“解决占用”杀别人的进程、删除锁文件、重置数据库或读取主工作区.env。涉及外部资源重新请求审批。
09 Worktree 的边界和常见错误
检查独立性:.env、缓存和 node_modules 不会因 Handoff 自动搬运。缺依赖时只能运行项目已有 setup 脚本,不要复制真实密钥或连接生产:
10 审批和集成验收
按影响分档:
所有 Worktree 完成后,在专用集成区执行:
- D1-D7 每项都有文件、命令、退出码或测试名称作为证据;
git diff --check通过,diff 只含批准文件;- 分页、筛选、部分更新和旧行为都被测试;
- 错误状态、响应体和状态码符合契约;
- 没有
.env、令牌、日志、缓存、意外锁文件或生成目录; - 没有未解决审查意见;
- 回滚到基线、阶段提交或补丁的路径清楚。
11 回滚、恢复和阶段性交付
阶段记录应包含:- 未提交 Worktree:保存
git status、git diff --stat和补丁;确认目录没有他人修改后按文件恢复或废弃临时 Worktree。 - 已提交未合并分支:保留提交哈希,不合并失败阶段;需要修复时创建新提交,不能改写共享历史。
- 已进入共享分支或外部系统:使用新的反向修复提交;数据库使用项目已有回退迁移、备份恢复或补偿迁移,Git 回滚不能撤销已经写入的数据。
12 最终交付提示词和速查
小结
可靠的 TODO API 协作不是让更多代理同时工作,而是让每个代理拥有明确边界,让每个阶段都能被证明、暂停和恢复:计划模式负责暴露未知事项;契约负责统一实现和测试;只读子代理负责并行探索与审查;Worktree 负责隔离并行写入;审批负责拦住联网、数据库、删除、提交和发布;集成阶段负责最小解决冲突;阶段提交和补丁负责恢复。 迁移到其他项目时,只替换 API 契约、文件路径和验证命令,仍然遵循“先读后写、先契约后实现、先隔离后并行、先证据后交付”。 参考资料:参考/codex/34-capstone.md、参考/codex/14-workflows.md、参考/codex/21-subagents.md、参考/codex/25-worktrees.md。