用途
Interview Me 是一个需求澄清技能，用于在制定计划、规格或编写代码之前，挖掘用户真正想要的东西，而不是用户以为自己应该要的东西。人们提出的请求和实际想要的东西往往不同：他们说要“一个仪表盘”，只是因为这是习惯性的说法，而不是因为仪表盘能解决他们的问题；他们说“让它更快”，却没有给出要达成的具体数字。
发现这种差距成本最低的时机，是在任何计划、规格或代码存在之前。一旦开始构建，切换成本就会变得真实，用户会把错误的东西合理化成一个“足够好”的东西，错配就此锁定。
其他 Define 阶段的技能都假设你已经大致知道自己想要什么：idea-refine 从一个想法生成变体，spec-driven-development 把需求写下来，doubt-driven-development 在你起草计划后对其进行压力测试。Interview Me 是所有这些之前的部分，它一次问一个问题，并附上自己的最佳猜测，直到你能在用户开口之前预测他们会说什么。
主要能力
- 在提问前先写下对用户意图的假设，并给出 0–100% 的诚实置信度。
- 当置信度低于约 70% 时，在同一行附上简短原因，说明还有什么未解决或缺失。
- 一次只问一个聚焦问题，并附上自己的猜测及推理，等待用户回应后再问下一个。
- 识别“想要 vs. 应该想要”的回答，例如套用最佳实践话术、诉诸惯例、出现“我应该……”“好的工程实践说……”等措辞，或把“现代”“可扩展”“健壮”等流行词当作目标。
- 当听到这类回答时，追问：“如果你不需要向任何人证明什么，你实际想要的是什么？”
- 用用户自己的语言复述意图，结构包括：结果、用户、为什么是现在、成功标准、约束条件、范围之外。
- 要求用户以明确的“是”确认，而不是“你觉得怎样都行”“听起来不错”或沉默。
- 在用户明确确认后，立即停止本轮，不调用工具或开始下游工作。
使用方式
该技能需要一位实时、可回应的用户。不要在非交互式环境中调用，例如 CI 流水线、定时运行、/loop 或自主循环。如果处于这类环境且需求描述不充分，应将其标记为阻塞项交给用户，而不是猜测。
流程分为六步：
- 假设，并附上置信度数字。在提问前，用一句话写下当前对用户想要什么的最佳解读，加上诚实的置信度（0–100%）。
- 一次问一个问题，每个问题附上猜测。格式为 Q: <一个聚焦问题>，GUESS: <你对答案的假设及产生它的推理>。等待用户反应后再问下一个。
- 倾听“想要 vs. 应该想要”。最危险的回答是用户说出一个深思熟虑的答案听起来该有的样子，而不是他们实际想要的。
- 用用户自己的话复述意图。当置信度较高时，写回你认为用户想要的东西，保持简洁（5–8 行），使用他们的语言，并结构化以便逐行确认或纠正。
- 确认——明确的“是”，而不是“你觉得怎样都行”。
- 终止轮次与停止规则（关键）。当用户以明确的“是”确认意图陈述后：交付已确认的意图陈述；提供下游路径（提议保存到 docs/intent/[topic].md、用 spec-driven-development 起草规格，或在规格后进入任务规划）；立即停止本轮，不要调用工具或开始下游工作，把控制权交回用户选择下一步。
95% 置信度停止条件：当你能对以下问题回答“是”时就算完成——我能预测用户对我接下来会问的三个问题的反应吗？如果能，就停止访谈并产出复述。如果不能，就还没完成，继续问下一个问题。这也有一个下限：如果已经问了好几轮仍无法预测，这是关于需求本身的信息，而不是继续硬磨的理由。应停下来告诉用户：“我已经问了 X 个问题，仍然无法预测你的反应。有些根本性的东西缺失了。要不要退一步？”
适用场景
在以下情况应用该技能：
- 请求至少缺少以下之一：用户是谁、为什么想要、成功是什么样、约束条件是什么。
- 请求是惯例性的而非具体的（“给我建个 X”“让它更快”），不猜测就无法拆解这个惯例。
- 你忍不住想从尚未浮现的假设开始。
- 当两个合理的价值取向存在张力（简单 vs. 灵活、成本 vs. 速度）时，用户没有说明在优化哪个价值。
- 用户明确要求：“interview me”“grill me”“开始之前，我们确定吗？”“压力测试我的想法”。
不适用的情况：
- 请求明确且自包含（“重命名这个变量”“修复这个拼写错误”）。
- 用户明确要求速度优先于验证。
- 纯信息请求（“X 是怎么工作的？”“这段代码做什么？”）。
- 机械操作（重命名、格式化、移动文件）。
- 你已经有 ≥95% 的把握；在假设自己没有之前，重读上面的停止条件。
限制
- 需要实时、可回应的用户，不能在非交互式环境使用。
- 输出是已确认的意图陈述，即第 4 步的复述加上第 5 步的明确“是”。规格、计划和任务列表属于下游，它们消费本技能产出的意图。
- 如果用户希望意图持久化（多会话项目、交接给其他协作者），可提议保存到 docs/intent/[topic].md，但仅在用户确认后才保存。
- 常见合理化借口包括：“需求已经够清楚了”“问太多问题浪费他们时间”“我边做边想”“他们说了‘你觉得怎样都行’，所以我该直接决定”“我该给他们几个选项挑”“如果我附上猜测就是在引导他们”“我们聊够了，我懂了”“用户说了是，我们就完成了”。这些都需要按技能中的现实说明处理。
- 危险信号包括：单条消息里问三个或更多问题、问题没有附上假设、接受“你觉得怎样都行”作为最终答案、在用户明确确认复述前产出规格/计划/任务列表、意图确认后立即调用工具或开始下游工作、问题以“什么是最佳实践？”而非“你实际想要什么？”来表述、用户给出炫耀性回答（“可扩展”“干净”“现代”）而不探究是否真是他们想要的、三轮以上置信度没有明显上升、置信度低于约 70% 却没有附原因、在用户确认前保存意图文档、复述中跳过“范围之外”一行。
与其他技能的关系
- idea-refine：下游。如果确认的意图是“我想要 X 但不知道怎么界定范围”，交给 idea-refine 针对现已明确的意图生成变体。
- spec-driven-development：下游。如果确认的意图是具体的（“我想要 X，面向 Y 用户，成功标准是 Z”），交给 spec-driven-development 写下来。
- planning-and-task-breakdown：本技能下游两跳（规格之后）。
- doubt-driven-development：时间线的另一端。Interview Me 是决策前的意图提取；doubt-driven 是决策后的产物审查。两者都捕捉偏差，但时机不同。
- source-driven-development：正交。Interview Me 澄清用户想要什么；SDD 验证框架事实。两者不竞争。