需求不明确时用逐问访谈提取用户真实意图…

当用户提出含糊的“做个 X”或需要压力测试想法时，用一次一问、每问附猜测的访谈，在写计划、spec 或代码前确认真实意图。

适用场景

解决思路

1. 在问任何问题前，先用一句话写下对用户想要什么的最佳假设，并给出 0–100% 的诚实置信度。格式：HYPOTHESIS: ... 与 CONFIDENCE: ~30% — missing: ...。
2. 置信度必须可辩护：如果你无法预测用户对接下来三个问题的反应，就不要写高置信度；从你能辩护的置信度开始。
3. 当置信度低于约 70% 时，在同一行附上简短原因，说明仍未解决或缺失什么；让用户知道访谈需要揭示什么，避免数字变成模糊信号。
4. 一次只问一个问题，每个问题都附上你的猜测。格式：Q: <一个聚焦问题> 与 GUESS: <你对该答案的假设及推理>。
5. 问完一个问题后等待用户反应，再问下一个；不要把问题批量发出。
6. 不要批量提问：用户无法对埋在列表里的假设作出反应；批量会鼓励略读和表面回答；第三个问题常依赖第一个答案；用户认真思考的精力有限，应一次花一个。
7. 附上猜测：用户对错误猜测的反应比从零生成答案更快；猜测迫使你承担一个可被明显证伪的假设，保持诚实；暴露你的假设，而这正是访谈要揭示的。
8. 缓解礼貌用户为了迎合而同意猜测的风险：明显表现出愿意犯错，并偶尔故意猜一个你预期用户会反对的方向。
9. 倾听“想要”与“应该想要”的区别：警惕像最佳实践话术但没有具体内容的回答，如 I want it to be scalable、clean architecture。
10. 警惕诉诸惯例的回答，如 the way most apps do it、the standard approach。
11. 警惕 I should probably…、I think I'm supposed to…、good engineering practice says… 等措辞。
12. 警惕把 buzzword 当目标：当 modern、scalable、robust 就是答案而不是具体结果时。
13. 听到上述回答时，问：If you didn't have to justify this to anyone, what would you actually want? 这个问题常比前五个问题更有效。
14. 当置信度高时，回写你认为用户想要的内容，保持紧凑，5–8 行，尽量使用用户的语言，并结构化让用户逐行确认或纠正。
15. 回写格式包含：Outcome 一行；User 一行，说明谁受益；Why now 一行，说明什么变化了；Success 一行，说明如何知道成功；Constraint 一行，说明约束限制；Out of scope 一行，说明明确不做什么；最后问 Yes / no / refine?。
16. 必须包含 Out of scope：一半的错位来自对“不构建什么”的沉默分歧。
17. 确认门槛是明确的 yes。以下不是 yes：Whatever you think is best. 表示用户在授权，说明他们也没有 95% 把握；应重新以两个具体选项作为选择来问。
18. Sounds good. 不明确；追问：Anything you'd refine? 沉默不是确认。
19. Sure, let's go. 常是礼貌退出而非认可；同样追问。
20. 沉默随后 okay let's start. 表示用户放弃访谈而非收敛；停下来问是否漏掉了什么。
21. 如果用户纠正你，把纠正纳入并重新陈述；循环直到获得明确 yes。
22. 当用户用明确 yes 确认意图陈述后：交付已确认的 Statement of Intent。
23. 然后提供下游路径：提出保存到 docs/intent/[topic].md、用 spec-driven-development 起草 spec、或 spec 后进入任务规划。
24. 然后立即结束本轮：不要在本轮调用工具或开始下游工作；把控制权交还用户选择下一步。
25. 停止条件：当你能回答“我能预测用户对接下来三个问题的反应吗？”为 yes 时，就停止访谈并产出 restate。如果不能，继续问下一个问题。
26. 这是一个可检查的测试，不是凭感觉；它也有下限：如果已问多轮仍无法预测，这是关于需求本身的信息，不是继续硬磨的理由。停下来告诉用户：I've asked X questions and I still can't predict your reactions. Something foundational is missing. Want to step back?
27. 技能输出是“已确认的意图陈述”：Step 4 的 restate 加 Step 5 的明确 yes。Specs、plans、任务列表都是下游，消费该意图。
28. 如果用户希望意图持久化，例如多 session 项目或交接给协作者，提出保存到 docs/intent/[topic].md；只有用户确认后才保存。
29. 与下游技能交互：若确认意图是“我想要 X 但不知道怎么定范围”，交给 idea-refine 基于已明确意图生成变体。
30. 若确认意图具体，例如 I want X for Y users with Z success criteria，交给 spec-driven-development 写下来。
31. planning-and-task-breakdown 在本技能下游两跳，即 spec 之后。
32. doubt-driven-development 在时间线另一端：interview-me 是决策前意图提取，doubt-driven 是决策后产物审查；两者都发现偏差，但时刻不同。
33. source-driven-development 正交：interview-me 澄清用户想要什么，SDD 验证框架事实；二者不竞争。
34. 常见合理化与应对：The ask is clear enough——如果你现在不能用一句话写出用户期望的结果，它就不清楚；先运行 Step 1 再判断。
35. 常见合理化与应对：Asking too many questions wastes their time——4–6 个针对性问题浪费的时间很小；构建错误东西浪费巨大，且由用户承担。
36. 常见合理化与应对：I'll figure it out as I build——代码存在后的切换成本是现在的 10 倍；实现中才发现是返工。
37. 常见合理化与应对：They said 'whatever you think,' so I should just decide——whatever you think 是授权不是决定；用两个具体选项重新问。
38. 常见合理化与应对：I should give them several options to pick from——选项适用于用户知道想要什么并在权衡间选择时；他们还不知道想要什么。列选项扩大搜索，提问缩小搜索。
39. 常见合理化与应对：If I attach my guess, I'm leading them——引导正是重点；反应比从零生成快。风险是谄媚，不是引导；通过明显愿意犯错来缓解。
40. 常见合理化与应对：We've talked enough, I get it——测试：你能预测他们对接下来三个问题的反应吗？不能就还没懂。
41. 常见合理化与应对：The user said yes, we're done——如果 yes 跟在模糊 restate 或开放式 sounds good 之后，yes 是空洞的；具体 restate 并重新确认。
42. 红旗：单条消息中三个或更多问题等于批量，不是访谈。
43. 红旗：问题没有附上你的假设等于调查，不是承诺。
44. 红旗：接受 whatever you think is best 作为终止答案。
45. 红旗：在用户明确确认你的 restate 之前产出 spec、plan 或任务列表。
46. 红旗：意图确认后立即调用工具或开始下游工作，而不是结束本轮。
47. 红旗：问题框架是 what would be best practice? 而不是 what do you actually want?。
48. 红旗：用户给出 sophistication-signaling 答案，如 scalable、clean、modern，而你未探查这是否是他们真正想要的。
49. 红旗：三轮或更多轮后置信度没有明显上升，说明你在问错问题，退一步重新框定。
50. 红旗：置信度低于约 70% 但没有附原因：用户不知道缺什么就无法帮助缩小差距。
51. 红旗：用户确认前保存 intent doc，因为文档本身暗示一个用户没给的 yes。
52. 红旗：restate 中跳过 Out of scope 行，因为对非目标的沉默分歧是一半的错位。
53. 验证：应用后检查第一轮是否陈述了假设与置信度。
54. 验证：每个低于约 70% 的置信度都附一行原因。
55. 验证：问题是否一次一个，每个附猜测。
56. 验证：用户给出 sophistication 或 convention 信号答案时，是否至少运行一次“没有 justifying 限制时你实际想要什么”的探查。
57. 验证：是否回写给用户一个具体的 restate，包含 Outcome、User、Why now、Success、Constraint、Out of scope。
58. 验证：用户是否用明确 yes 确认 restate，而不是 whatever you think、sounds good 或沉默。
59. 验证：停止点是否能预测接下来三个问题的反应。
60. 验证：收到明确确认后是否立即结束本轮，不调用工具或开始下游工作。
61. 验证：任何交给下游技能的 handoff 是否基于已确认意图，而不是原始不明确需求。

适用边界 · 注意事项

• 非交互环境：CI pipelines、定时任务、/loop、autonomous-loop 等没有实时响应用户的场景；若需求不明确，应标记为阻塞而不是猜测。
• 需求无歧义且自包含，如重命名这个变量、修复这个 typo；纯信息请求，如 X 如何工作、这段代码做什么；机械操作，如重命名、格式化、移动文件。
• 用户明确要求速度优先于验证，或你已经有 ≥95% 把握；先重读停止条件再假设没有。