| name | interview-me |
| description | 提取用户真正想要的，而非他们认为自己应该想要的。通过一次一个问题的访谈实现，直到对底层意图达到约 95% 的置信度。当需求不具体时使用（"给我建个 X"但没有说明"为谁"或"为什么是现在"），当用户显式调用时使用（"interview me"、"grill me"、"are we sure?"、"stress-test my thinking"），或当你发现自己在任何计划、规格或代码存在之前就开始静默地填补模糊需求时使用。 |
访谈我
概述
人们要求的和他们真正想要的是不同的事情。他们要求"一个仪表盘"，因为那是人们通常要求的，而不是因为仪表盘解决了他们的问题。他们说"让它更快"却没有给出要达到的目标数字。
发现这个差距最便宜的时刻是在任何计划、规格或代码存在之前。一旦你开始构建，切换成本是真实的，用户会将错误的东西合理化为"足够好"的东西。不匹配就被锁定了。
此技能在产生任何成本之前弥合这个差距。其他定义阶段的技能假设你已经大致知道你想要什么：idea-refine 从某个想法生成变体，spec-driven-development 将需求写下来，doubt-driven-development 在你起草计划之后压力测试它。Interview-me 是所有那些之前的部分，在这里你一次问一个问题，附带你的最佳猜测，直到你可以在用户说出来之前预测他们会说什么。
何时使用
在以下情况下应用此技能：
- 需求至少缺少以下之一：谁是用户，他们为什么想要它，成功是什么样子，绑定约束是什么
- 请求是约定俗成的而非具体的（"给我建个 X"、"让它更快"），并且你在不猜测的情况下无法解开这个约定
- 你想从你没有揭示的假设开始
- 当两个合理的价值观处于张力中时（简单性 vs. 灵活性、成本 vs. 速度），用户没有说他们正在优化哪个值
- 用户显式调用："interview me"、"grill me"、"before we start, are we sure?"、"stress-test my thinking"
何时不使用：
- 需求是明确且自包含的（"重命名这个变量"、"修复这个拼写错误"）
- 用户明确要求速度优先于验证
- 纯信息请求（"X 如何工作？"、"这段代码做什么？"）
- 机械操作（重命名、格式化、文件移动）
- 你已经拥有 >= 95% 的置信度；在假设你没有之前重新阅读下面的停止条件
加载约束
此技能需要一个实时的、有响应的用户。不要在非交互式上下文中调用，例如 CI 流水线、计划运行、/loop 或自主循环。如果你在那些上下文中且需求不具体，将其标记为用户的一个阻塞点，而非猜测。
流程
步骤 1：假设，带一个置信度数字
在问任何问题之前，用一句话写下你当前对用户想要什么的最佳解读，加上一个诚实的置信度数字（0-100%）：
假设：你想要一种在站会中回答"我们做得怎么样？"的方式，而"仪表盘"是你想到的约定俗成的答案。
置信度：~30%——缺少：它是为谁的，"指标"在上下文中意味着什么，以及成功是什么样子
数字迫使诚实。如果你写下的数字很高，但实际上无法预测用户对你接下来要问的三个问题的反应，那这个数字就是错的。从你能捍卫的置信度水平开始。
当置信度低于约 70% 时，在同一行附加一个简短的原因——什么仍然未解决或缺失。这告诉用户访谈具体需要揭示什么，并防止数字成为一个模糊的信号。
步骤 2：一次一个问题，每个问题附带一个猜测
格式：
Q: <一个专注的问题>
猜测：<你对答案的假设，以及产生该假设的推理>
等待用户反应后再问下一个问题。
为什么一次一个，而非一批：
- 如果你将假设埋在一个列表中，用户无法对你的假设做出反应
- 批次鼓励略读和表面答案
- 第三个问题通常取决于第一个问题的答案；一次性全问锁定了错误的框架
- 用户仔细思考的能量是有限的；一次一个问题地花费它
为什么附带一个猜测：
- 用户对一个错误的猜测的反应比从零生成一个答案更快
- 它让你承诺一个你可以被证明是错误的假设，这让你保持诚实
- 它揭示了你的假设，这正是访谈旨在暴露的东西
这里的风险是一个礼貌的用户同意你的猜测以示友好。通过表现出可见地愿意被证明是错的来缓解，并且偶尔朝你期望用户反对的方向猜测。
步骤 3：倾听"想要 vs. 应该想要"
最危险的答案是这样的一种：用户说的是深思熟虑的答案听起来像什么，而非他们真正想要什么。注意：
- 没有具体细节的模式匹配最佳实践式谈话（"我想让它可扩展"、"干净的架构"）
- 遵从约定的回答（"大多数应用的做法"、"标准方法"）
- 像"我可能应该……"、"我想我应该……"、"好的工程实践说……"这样的短语
- 作为目标的流行词——当"现代"、"可扩展"、"健壮"是答案而非具体结果时
当你听到这些时，要问的问题是：
"如果你不需要向任何人证明这个，你真正想要什么？"
这个问题通常比前五个问题做更多的工作。
步骤 4：用用户自己的话重述意图
当你的置信度很高时，写回你现在认为用户想要什么。保持紧凑（5-8 行），尽可能使用他们的语言，并以用户可以逐行确认或纠正的结构组织：
以下是我现在认为你想要的：
- 结果： <一行>
- 用户： <一行——谁受益>
- 为什么是现在：<一行——什么发生了变化>
- 成功： <一行——我们如何知道它有效>
- 约束： <一行——绑定的限制>
- 范围之外： <一行——我们明确不做什么>
是 / 否 / 改进？
包含"范围之外"是不可谈判的。一半的错位是关于什么没有在构建的沉默分歧。
步骤 5：确认——明确的"是"，而非"你觉得怎样就怎样"
门槛是一个明确的"是"。以下不是是：
- "你觉得怎样最好就怎样。" → 用户是在委派，这意味着他们也没有 95% 的置信度。用两个具体选项框定为选择来重新询问。
- "听起来不错。" → 模糊。问："有什么你想改进的吗？"沉默不是确认。
- "当然，我们开始吧。" → 通常是一个礼貌的退出，而非认可。同样的跟进。
- 沉默接着"好，我们开始吧。" → 用户放弃了访谈，而非收敛。停下来问你是否遗漏了什么。
如果他们纠正你，将纠正折叠进去并重新陈述。循环直到你得到一个明确的"是"。
95% 置信度停止条件
当你能对以下问题回答"是"时，你就完成了：
我能预测用户对接下来我要问的三个问题的反应吗？
如果是，你们有共享的理解。停止访谈并产出重述。如果否，你还没有完成；问下一个问题。
这是一个可检查的测试，而非一种感觉。它还有一个底线：如果你已经进行了几轮仍然无法预测，那是关于需求本身的信息，而非继续磨下去的理由。停下来告诉用户："我已经问了 X 个问题，我仍然无法预测你的反应。一些基础性的东西缺失了。想退后一步吗？"
输出
此技能的输出是一个经过确认的意图声明：来自步骤 4 的重述，加上来自步骤 5 的明确"是"。那就是交付物。规格、计划和任务列表是下游的；它们消费此技能产出的意图。
如果用户希望意图持久化（多会话项目、交接给另一个协作者），提议将其保存到 docs/intent/[topic].md。仅在用户确认后才保存。
示例
一个简短的之前和之后。
没有 interview-me：
用户： 为我建一个我们指标的仪表盘
智能体：<开始提议图表库和布局>
智能体假设了：为谁、什么指标、"为我们团队"意味着什么、成功是什么样子。这些都没有被陈述。每个假设都是用户后来可以说"那不是我的意思"的地方。
有了 interview-me：
用户：为我建一个我们指标的仪表盘
智能体：
假设：你想要一种在站会中回答"我们做得怎么样？"的方式，而"仪表盘"因为这是约定俗成的答案而浮现在脑海中。
置信度：~30%——缺少：为谁、什么"指标"以及成功是什么样子
Q: 当你说"我们做得怎么样？"时，谁在问——你自己、站会中的工程团队，还是向上的链条（例如，你的经理、高管、董事会）？
猜测：站会中的工程团队，因为"我们"通常是以这种方式范围的，而站会正是这个问题被问的地方。如果是为高管，指标和框架会有很大变化。
用户：实际上是为我。我一直搞不清楚哪些实验在运行以及它们的早期信号是什么样子。
智能体：
更新解读：根本不是团队仪表盘。它是一个个人实验追踪器。置信度：~60%——仍然缺少："早期信号"意味着什么以及完成是什么样子。
Q: 这个缺口是你不知道哪些实验存在，还是你不能在一个地方看到它们的结果？
猜测：第二个。你在某个地方有实验列表，但它们的结果分布在五个不同的工具中，你厌倦了手动协调它们。
用户：实际上是第一个。我真的没有列表。它们分散在不同的文档中。
智能体：<继续>
两个问题后，智能体发现实际需求不是"仪表盘"。而是"一个列表"。不同的产物，不同的范围，不同的工作量。那个仪表盘会是错误的。
与其他技能的交互
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 验证框架事实。它们不竞争。
常见合理化借口
| 合理化借口 | 现实 |
|---|
| "需求够清楚了" | 如果你现在不能用一句话写出用户期望的结果，需求就不清楚。在做决定之前运行步骤 1。 |
| "问太多问题浪费他们的时间" | 4-6 个针对性问题浪费的时间很小。构建错误的东西浪费的时间是巨大的，而且是用户在承受这个代价。 |
| "我在构建时就能搞清楚" | 代码存在之后的切换成本是现在的 10 倍。在实现过程中发现即是返工。 |
| "他们说'你觉得怎样就怎样'，所以我应该直接决定" | "你觉得怎样就怎样"是委派，而非决定。用两个具体选项作为选择重新询问。 |
| "我应该给他们几个选项来选择" | 当用户知道自己想要什么并且在权衡之间选择时，选项有效。他们还不知道自己想要什么。列出选项是扩大搜索；提问是缩小它。 |
| "如果我附上我的猜测，我是在引导他们" | 引导正是重点。反应比从零生成更快。风险是谄媚，不是引导；通过表现出可见地愿意被证明是错的来缓解。 |
| "我们已经谈得够多了，我理解" | 测试它：你能预测他们对接下来三个问题的反应吗？如果不能，你还不理解。 |
| "用户说了'是'，我们完成了" | 如果"是"是在模糊的重述或开放式的"听起来不错"之后，那个"是"是空洞的。具体地重述并重新确认。 |
红旗警告
- 一条消息中包含三个或更多问题：那是批处理，而非访谈
- 一个问题没有附带你的假设：那是在调查，而非承诺
- 接受"你觉得怎样最好就怎样"作为最终答案
- 在用户显式确认你的重述之前就产出规格、计划或任务列表
- 问题被框定为"最佳实践是什么？"而非"你真正想要什么？"
- 用户给出了一个姿态信号答案（"可扩展"、"干净"、"现代"），而你在没有探究这是否是他们真正想要的情况下接受了它
- 三轮或更多轮而你的置信度没有可见的上升：你在问错误的问题，退后一步并重新框定
- 置信度数字低于约 70% 而没有附带原因：如果用户不知道缺失什么，他们无法帮助弥合差距
- 在用户确认之前保存意图文档（该文档本身暗示了用户没有给予的"是"）
- 在重述中跳过"范围之外"行（关于非目标的沉默分歧是一半的错位）
验证
应用 interview-me 后：
