用途
Interview Me 是一个访谈技能，用于在形成计划、规格或代码之前，把用户真正想要的东西弄清楚。它针对的问题是：人们提出的要求和他们真正想要的结果往往是两回事。比如有人要“一个仪表盘”，只是因为仪表盘是常见的表达方式，而不是因为仪表盘能解决他的问题；有人说“做得更快”，却没有给出要达到的数字。在任何计划、规格或代码存在之前，发现这种差距的代价最低。一旦开始构建，切换成本就会真实存在，用户也会把并不合适的东西合理化成一个“够用”的东西，错配就此固定下来。
该技能定位于 Define 阶段的最前端。idea-refine 从想法生成变体、spec-driven-development 把需求写下来、doubt-driven-development 在草稿完成后对计划做压力测试，它们都假设你大致知道自己想要什么；Interview Me 是这些之前的一步。
主要能力
- 先假设，再提问：提问前先写下一句对用户意图的最佳理解，以及一个诚实的置信度数字（0–100%）。置信度低于约 70% 时，在同一行附上简短原因，说明还有什么未解决或缺失。置信度是主观估计，不是校准过的概率，也不是双方已达成共识的证据。
- 一次一问，附带猜测：格式为“Q: 一个聚焦的问题”“GUESS: 对答案的假设及其推理”，等用户反应后再问下一题。逐题提问是因为批量提问会埋没假设、诱导粗读和表面回答，且第三题往往依赖第一题的答案。附上猜测是因为用户对错误猜测的反应比从零生成答案更快，也能暴露假设。需要注意：礼貌的用户可能为了附和你而同意猜测，因此要表现出愿意被纠正，并在可能产生锚定效应时提供中性的问题或备选，绝不能故意歪曲自己的判断来激起反应。
- 识别“想要”与“应该想要”：警惕缺少具体内容的“最佳实践”式回答（可扩展、整洁架构）、对惯例的顺从（“大多数应用都这样做”）、带“我应该……”“我想我大概应该……”等措辞的回答，以及把“现代”“可扩展”“健壮”等热词当作目标。遇到这些情况，追问：“如果不需要向任何人解释，你真正想要什么？”
- 用自己的话复述意图：置信度高时，用 5–8 行复述意图，尽量使用用户的措辞，方便逐条确认或纠正，包含 Outcome、User、Why now、Success、Constraint、Out of scope 六项。其中 Out of scope（明确不做什么）不可省略，因为错配有一半来自对非目标的沉默分歧。
- 确认复述：接受“听起来不错”“行，开始吧”等明确的上下文同意；“你觉得怎么好就怎么来”在常规选择上可作为授权，应说明所选假设并在范围内推进；只有在仍有实质性歧义或必要授权缺失时才追问。沉默不算同意。
- 95% 置信度停止条件：判断标准是自己能否预判用户对接下来三个问题的反应。能，就停止访谈并输出复述；不能，就继续问。这是主观的停止启发式，用户确认和足够的任务信息比读心更重要。它也有下限：若已多轮仍无法预判，说明需求本身有问题，应停下来告诉用户“我已问了 X 个问题，仍无法预判你的反应，有些根本性的东西缺失，要不要退一步？”。
使用方式
该技能需要一位实时响应的用户，不能用于 CI 流水线、定时运行、/loop 或自主循环等非交互环境；若处于这类环境且需求不明确，应把它标记为阻塞项交给用户，而不是猜测。
流程分五步：第一步写下假设与置信度；第二步一次一问并附带猜测；第三步识别“想要”与“应该想要”的差别；第四步用用户的话复述意图；第五步让用户确认复述。最终交付物是一份经用户明确确认的意图陈述。若用户希望意图持久保存（多会话项目或交接给协作者），可提议保存到 docs/intent/[topic].md，仅在用户确认后保存。
适用场景
- 需求至少缺少以下一项：用户是谁、为什么想要、成功是什么样、约束条件是什么。
- 请求是常规而非具体的（“给我做个 X”“让它更快”），不猜测就无法拆解。
- 你忍不住从尚未说明的假设开始。
- 两种合理价值存在取舍（简单 vs 灵活、成本 vs 速度），用户没说自己在优化哪一个。
- 用户明确说“访谈我”“拷问我”“开始前先确认一下”“压力测试我的想法”。
不适用：需求明确且自足（重命名变量、修错别字）、用户明确要求速度优先于验证、纯信息请求、机械操作，或已有至少 95% 的把握。
与其他技能的关系
idea-refine 与 spec-driven-development 位于下游：确认的意图若模糊，交给 idea-refine 生成变体；若具体，交给 spec-driven-development 写下来。planning-and-task-breakdown 在规格之后，是更下游两步。doubt-driven-development 处在时间线的另一端：Interview Me 是决策前的意图提取，doubt-driven 是决策后的产物审查。source-driven-development 是正交的，前者澄清用户想要什么，后者核实框架事实，二者不冲突。
限制
仅为指导性方法，不能替代项目自身的 linter、类型检查器、格式化工具或测试套件。缺少必要输入、权限或范围边界时应停下询问。资料未提供该技能的价格、收费方式、安装命令或具体平台要求。