在 Codex 中实现新功能或重构前，用…

当用户调用 /plan-interview 并希望在非平凡实现前先明确需求、范围、风险与成功标准时使用。

适用场景

解决思路

1. 在实现前运行结构化需求访谈，先收集明确需求而不是做假设。
2. 检查可用工具中是否有 `AskUserQuestion`；若有，优先用它以 2-3 个问题为一组进行主题批次访谈，形成结构化提问。
3. 若没有 `AskUserQuestion`，例如 GitHub Copilot 或其他不支持它的提供方，直接在聊天中提出同样的问题，并暂停等待用户回复后再继续。
4. 在继续前覆盖全部四个问题域：技术约束、范围边界、风险容忍度、成功标准。
5. 技术约束：询问性能要求、兼容性需求、需要遵循的既有模式、以及对不熟悉代码库的架构理解。
6. 范围边界：询问明确不在范围内的内容、MVP 与完整愿景、对其他工作的依赖。
7. 风险容忍度：询问可接受的取舍，例如速度 vs 质量、技术债容忍度、是否接受破坏性变更。
8. 成功标准：询问如何知道完成、什么定义“正确工作”、测试/验证要求。
9. 根据任务动态生成问题，不使用固定模板。
10. 将相关问题分组为主题批次。
11. 每批 2-3 个问题，不要超过。
12. 持续访谈直到获得可操作的明确性，即能描述具体实现步骤。
13. 在离开访谈阶段前，对任务分类并选择规划深度：简单/琐碎任务，例如小 bug 修复、孤立改动，用最小计划，最多 1 轮精炼。
14. 中等任务，例如已知区域的特性工作，用标准计划，通常 1-2 轮精炼。
15. 复杂/高风险任务，例如多文件、新架构、不熟悉代码库、迁移、认证、并发，用深度计划，迭代精炼直到改进趋于平缓。
16. 如果用户有明确偏好，允许其覆盖深度选择，例如 `fast` vs `deep`。
17. 遇到矛盾需求时，给出带理由的建议并请用户确认。
18. 用户改变需求方向时，以新方向重新开始访谈。
19. 会话中断时，询问用户是继续之前进度还是重新开始。
20. 避免反模式：不要问同一问题的变体。
21. 避免反模式：不要在未询问的情况下做重大假设。
22. 避免反模式：不要为简单任务过度设计计划。
23. 访谈完成后，探索代码库，理解与任务相关的既有模式、将受影响的文件、集成点、潜在风险。
24. 对复杂或不熟悉的项目，在深度规划前做简短上下文刷新：如存在且相关，重新阅读 `AGENTS.md` 和 `README.md`。
25. 在精炼计划前，识别当前架构边界和约定。
26. 如果会话中断或上下文漂移，在下一次精炼轮次前再次刷新 `AGENTS.md`、`README.md`、架构边界和约定。
27. 将计划写入 `docs/plans/plan-NNN-<slug>.md`，其中 NNN 为顺序编号。
28. 使用“草稿 -> 精炼”工作流；在仍在发现实质性改进时停留在计划空间；对于非琐碎工作，规划 token 通常比实现 token 便宜得多。
29. 先创建草稿：根据访谈 + 探索结果创建草稿计划。
30. 在请求批准前运行迭代精炼轮次，深度基于任务复杂度。
31. 将精炼后的计划呈现给用户审查。
32. 在用户审查前运行 1..N 轮精炼，取决于复杂度。每轮强制以“新鲜视角”开始：在修改任何内容前重新阅读访谈答案、约束、成功标准和当前草稿计划。
33. 每轮检查矛盾、遗漏的边缘情况、集成风险和含糊的实现步骤。
34. 每轮在明显有助于用户时改进架构、排序和可靠性。
35. 每轮加强测试和验证计划，适用时包含单元测试 + 集成/e2e，以及有用的诊断/日志。
36. 每轮验证功能保留：不要过度简化；不要移除已约定的功能/功能，除非用户明确批准缩减范围。
37. 每轮记录简短总结：改了什么以及为什么。
38. 满足以下任一条件时停止迭代：连续两轮没有产生实质性改进；变更只是措辞/风格且不影响执行质量；任务简单且计划已可操作；用户要求停止并继续。
39. 如果用户提供多个竞争计划，将它们与当前计划诚实比较。
40. 多计划综合时，提取最佳想法、取舍和风险缓解措施。
41. 多计划综合时，合并为单一权威计划，并保留已约定范围。
42. 当用户要求修订输出时，优先展示对现有计划的 git-diff 风格变更。
43. 迭代精炼循环和多计划综合的可复用提示模板位于 `references/iterative-plan-refinement-prompts.md`。
44. 每个计划必须包含 `## Success Criteria`，内容为来自访谈的清晰完成定义。
45. 每个计划必须包含 `## Risk Assessment`，内容为可能出错的地方 + 缓解措施。
46. 每个计划必须包含 `## Affected Files/Areas`，内容为将触及的代码库部分。
47. 每个计划必须包含 `## Test Strategy`，内容为适用时的单元测试、集成测试和 e2e 测试/脚本；包含关键场景、失败模式、fixtures/mocks。
48. 每个计划必须包含 `## Validation and Diagnostics`，内容为实现后如何验证功能；在有助于调试时，包含测试/脚本中详细日志/诊断的预期。
49. 每个计划必须包含 `## Open Questions`，列出实现期间要解决的不确定性，用 `- [ ] Question 1 - [Blocks implementation / Can proceed]` 格式。
50. 每个计划必须包含 `## Implementation Checklist`，用 `- [ ] Step 1`、`- [ ] Step 2` 等列出步骤。
51. 可选元素：仅在相关时包含 `Rejected Alternatives`，且仅用于重大架构决策。
52. 可选元素：仅在存在多个有效方法时包含 `Decision Tree`。
53. 可选元素：在有助于理解时包含 ASCII 或 Mermaid 视觉图。
54. 约束：不要写时间估算——描述需要做什么，而不是需要多久。
55. 约束：不要设长度限制——计划应匹配任务复杂度。
56. 约束：不要静默缩减范围——不要为了让计划“更干净”而丢弃已约定功能。
57. 约束：不要过度迭代简单工作——使用上述规划深度校准。
58. 约束：除必需元素外，结构可自由形式。
59. 用户批准计划后：立即自动开始实现，无需“proceed”确认。
60. 用检查清单项填充 `TodoWrite`。
61. 在自然断点，即重大决策处，将进度与计划比较。
62. 快速模式：如果用户想要快速规划，使用“草稿 + 精炼”：执行以任务为中心的代码库搜索。
63. 快速模式：生成草稿计划。
64. 快速模式：运行简略访谈以精炼。
65. 快速模式：只运行一次“新鲜视角”精炼轮次，保留功能、收紧步骤、添加测试/验证覆盖。
66. 恢复支持：如果 `docs/plans/` 中存在部分计划，用 `AskUserQuestion` 询问：“I found an existing partial plan. Would you like to:”，选项包括 `Continue the interview`、`Resume plan drafting/refinement`、`Review current plan and finalize`、`Start fresh with a new plan`。
67. 如果恢复精炼，先总结当前计划状态和最近的精炼变更，然后继续新鲜视角精炼循环。

适用边界 · 注意事项

• 纯研究/探索任务。
• 简单 bug 修复。
• 用户只想要标准规划而不需要访谈过程。