需要把项目构想固化成版本化 PRD 文档时…

通过一次一个问题的结构化访谈，按固定 8 段模板产出或扩展 docs/PRD.md，把项目立项正式化。

适用场景

解决思路

1. 必要时先探索仓库以理解既有上下文（CLAUDE.md、ADR、业务术语表、相邻代码）；在 PRD 中复用项目词汇，并遵守已定的架构决策；如果答案能在仓库里找到，就去探索而不是提问。
2. 如果 docs/PRD.md 已存在，先读它，与收到的 brief 交叉比对，只就差异部分提问；遇到矛盾要当面指出：『你之前定了 X，brief 暗示 Y，我们保留哪个？』。既没有 PRD 也没有 brief 时，第一个问题就是『你想立项什么？』。
3. 一次只问一个问题，并给出有理由的推荐。遵循依赖顺序：问题 → 目标用户 → 方案 → 成功标准 → 范围外。用户故事和实现决策横向浮现。切换前先问：『补充说明里还有什么吗：风险、依赖、假设？』。
4. 当每个段落都能无空缺地撰写时，用一句话说明，并按模板在对话中写出完整 PRD。用户故事此时根据其他回答综合而成，并提交确认。
5. 用户逐段确认或修正。收到修正时，只重新贴出被改动的那一段。全部确认后，写入 docs/PRD.md（必要时创建 docs/ 目录），并确认『✓ 已写入 docs/PRD.md』。
6. 按模板撰写各段：问题——用户所经历的状况：挫败感、背景、『为什么是现在』；用第三人称散文，不用『我』。
7. 方案——从用户视角描述产品方向：产品让他能做什么，而不是怎么构建。
8. 目标用户——画像 + 使用场景，精确到能想象出一个真实的人。
9. 用户故事——编号的详尽列表，格式为『作为 <角色>，我想要 <功能>，以便 <收益>』；覆盖主要交互、空状态、错误、替代路径、边界情况。
10. 成功标准——可直接验证的标准：可观察事件（点击、产出文件、收到邮件）或客观度量（时长、数量、阈值）。不要用内在行为判断（『理解 X』『识别 Y』）。
11. 范围外——明确拒绝做的事。要详尽，这正是防止过度工程的东西。
12. 实现决策——用户可见的产品行为（数字限制、空状态、显示格式、UX 选择、形态、错误）。不要内部技术细节（算法、公式、环境变量、库名、技术类别）。心理测试：如果用户在使用中观察不到差别，就排除。
13. 补充说明——兜底项：风险、外部依赖、假设、参考、未来事项。保持简短；没有就写『无特别说明。』。
14. 遵守规则：词汇用用户的，逐字照用。
15. PRD 中不出现具体技术名、不留空缺、不写文件路径、不写代码片段。
16. 用户故事必须编号：US-1、US-2……

适用边界 · 注意事项

• 只想做技术方案或架构设计时（应走下游的 /planifie 类流程），而不是产品立项。
• 项目已有明确 brief 且无需版本化文档时，直接实现即可。
• 需要记录内部技术细节（算法、库、环境变量）时，这些不属于 PRD 范围。