一个 todo-cli 从 0 到提交：/plan→/test→/review→/commit 真实走了一遍，修掉 4 个问题

整理自完整版工作流包 D4 演示项目的过程记录（2026-10-01），非新实测；演示原文如实记下了 command 不好用的地方，本文照实转述，不做广告式改写。

前面 14 篇分别讲了 10 条命令、三套 CLAUDE.md 模板和一张速查表。本篇换个写法：不讲单条命令，讲一次从 0 到提交的完整走法——一个 Python 命令行待办工具 todo-cli，约 140 行，add/list/done/remove 四个子命令，数据存本地 JSON。

第一步：/plan 先拆，不直接写

输入只有一个任务描述：用本包工作流从 0 写一个 todo-cli 小项目，全流程走 /plan→/test→/review→/commit，附过程记录。

/plan 输出 5 个任务 T1→T5：实现→测试→评审→过程记录→提交，每个任务含验收标准、依赖、风险。T1 的验收标准“四个子命令手工跑通”在后面真用上了——拆出来的清单可以直接执行，这就是 /plan 在这里的价值：不是写得好看，是后面每一步都有验收口径可对照。

第二步：写实现，手工跑通先抓 1 个 bug

手写 todo.py（argparse + JSON 持久化）。按 T1 验收手工跑四个子命令时，程序启动即崩：action="true" 应为 action="store_true"，ValueError: unknown action。修完后 add/list/done/remove 全通，done 99 正确 exit 1 并 stderr 报错。

这一点值得单拎出来：手工跑通不是走过场，它就是第一道测试。没有这一步，这个启动崩溃会留到后面。

第三步：/test 先列清单，再写用例

输入 /test demo/todo-cli/todo.py。输出分两段：先列 12 条用例清单（正常 6 / 边界 3 / 异常 3），再写 tests/test_todo.py。非交互环境按规则标 [清单未确认-已继续] 直接动手，没有卡住等确认——这是 D2 修的 fallback 在演示里生效。

首轮 11 passed / 1 failed：test_add_删除后 id 不复用 失败。按 /test 规则先判定是测试错还是代码 bug：代码实现是 max+1，删除最大 id 后新 id 会复用，是测试期望写错（误以为 max+1 永不复用）。处理方式是不迁就测试改代码（max+1 是合理语义），而是修正 docstring 如实说明语义，并把测试改成“删除非最大 id 后 id 递增”的真实契约。最终 12 passed。

这个判定顺序是 /test 最有用的地方：失败先分清是谁错，再决定改代码还是改测试。

第四步：/review 只说能动手改的真问题

输入 /review demo/todo-cli/todo.py。结论“需修改后合并”；[必须改] 0 条；[建议改] 2 条；[可忽略] 2 条，没有凑数。

• 建议 1：add "" 空标题可写入 → 加 strip + 判空 exit 1。
• 建议 2：load_todos 不校验条目形状，手改数据文件会 KeyError traceback，与函数“内容损坏返回空列表”的契约不符 → 加形状过滤。

2 条全部修掉，各补 1 个回归用例，最终 14 passed。评价一句：review 没纠结风格（引号、空行），只说能动手改的真问题；“上限 10 条”的规则本轮没触发（代码小）。

第五步：/commit 只生成信息，不自动提交

读 git diff --cached 后生成 conventional commits 信息，人工确认后真实执行 git commit。本轮 diff 只有 demo/todo-cli 新增文件，无混入无关改动，无需拆分。

本轮修掉的真实问题，共 4 个

1. argparse action="true" 启动崩溃（T1 手工测试发现）
2. 测试期望误写 max+1 永不复用（/test 首轮失败，判定为测试错，修正期望 + 文档）
3. 空标题待办可写入（/review 建议改）
4. 形状错误的数据条目导致 KeyError（/review 建议改）

command 不好用的地方，照实记录

1. /plan 的“收尾提问”（按这个顺序从 T1 开始吗）在自主执行/非交互场景是多余动作——期望它像 /test 那样有非交互 fallback（无人值守时默认按清单继续并标注），目前没有，已记为 command 迭代项。
2. /test 的“清单给用户过一眼”在演示里靠 [清单未确认-已继续] 绕过，合理；但如果是严格交互流程，清单太长时用户根本不会细看——这是流程设计问题，不是本轮要修的。
3. /commit 永远不自动提交是对的，但本轮“用户 + 执行者”是同一人，确认环节是自己跟自己确认——演示场景下的形式感，真实团队场景下这道门有价值。

一句话总结

/plan 定验收口径，手工跑通抓启动 bug，/test 用“先判定谁错”避免改错方向，/review 只给可落地的修改，/commit 只生成信息不代劳提交。五步走完，一个 140 行的小工具从 0 到提交，测试从 12 passed 到 14 passed，修掉 4 个真实问题。

完整版工作流包（含本文用到的 /plan、/test、/review、/commit 等 10 条命令、三套 CLAUDE.md 模板与速查表）在爱发电上架中：早鸟 ¥9.90（限前 100 份），正式 ¥19.90。免费 Lite 版（3 条命令）见 GitHub：

• Lite 版仓库：https://github.com/alapha888/cn-ai-coding-workflow-lite
• 爱发电商品页：https://afdian.com/item/8c9c0932bd7711f19eb852540025c377