（整理自完整版 commands/plan.md 实测文本与 /plan 公开 Gist，非本次新实测；/plan 不在 Lite 免费版、只在完整版。）
接到一个“感觉要干好几天”的需求，最容易踩的坑不是写不出来，而是直接开写、写到一半才发现理解错了、返工三次。/plan 只做一件事：先拆再干——把需求拆成可执行的任务清单，每步有验收标准、依赖关系和风险点，拆完再动手。
5 步：
- 先澄清范围。先用 3 句话以内复述你理解的需求；列出 3 个以内必须确认的歧义点，标
[待确认]，不要替用户脑补拍板。需求里有不确定的地方，先把“未知项”列出来，而不是边写边猜。 - 再拆任务。拆成 3–8 个任务，每个任务必须包含：编号与标题（如 T2）、做什么（一句话）+ 验收标准（可验证、可演示，如“pytest 通过 5 个新增用例”）、依赖（依赖哪个任务先完成）、预计涉及的文件。没有验收标准的任务不算拆完。
- 单独标风险。单独列“风险与未知项”，每个风险给一句话缓解建议。风险不写进清单，执行时就会在最不方便的时候冒出来。
- 给出执行顺序。给出建议执行顺序，说明哪两个任务可以并行。顺序不是“按编号从头做到尾”，并行项要 explicitly 标出来。
- 收尾提问。最后问一句“按这个顺序从 T1 开始吗？有没有要调整的？”非交互环境（无人值守执行、无法等用户确认）时不等确认，默认按建议顺序从 T1 开始，并在输出开头标注
[清单未确认-已继续]。
输出长什么样（取自 plan.md 的格式）：需求理解（3 句话复述 + [待确认] 项）、任务清单（- [ ] T1 xxx — 做什么；验收：xxx；依赖：无；涉及文件：xxx）、风险与未知项、建议顺序（T1 → T2、T3 并行 → T4）。
什么时候不要用：需求本身只有一两行代码能搞定——直接写，别拆；需求完全没想清楚、连目标用户都说不清——先聊清楚再 /plan，否则拆出来的是幻觉清单；已经在执行中的任务中途改方向——先停下来重新 /plan，不要在旧清单上硬拧。
示例要点（取自 plan.md 的输入输出示例）：输入是 /plan 给 orders.py 加一个 CSV 导出函数，支持按日期过滤；拆为 T1 写导出函数（验收：导出 CSV 列齐全）、T2 日期过滤参数（验收：边界日期用例通过）、T3 补单测（验收：pytest 全绿）、T4 更新 README 用法；风险：大文件内存占用 → 缓解：流式写入。
免费先试：Lite 免费版含 /review、/commit、/test 三条命令，双兼容 Claude Code 与 Codex CLI，见 Lite 仓。
完整版含 /plan 在内的 10 条命令，早鸟 ¥9.90（限前 100 份）／正式 ¥19.90，付款后 12 小时内私信交付，7 天无理由退款。国内账号风控提示：优先用 Codex。
链接（文末三链接）：
