interview-me

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 后：

• 第一个回合中就陈述了一个带有置信度数字的显式假设
• 每个低于约 70% 的置信度数字都附带一行原因（什么仍然未解决或缺失）
• 问题是一次一个提出的，每个都附带了智能体的猜测
• 当用户给出姿态信号或约定信号答案时，至少运行了一次"如果你不需要为此证明，你真正想要什么？"的探究
• 一个具体的重述（结果 / 用户 / 为什么是现在 / 成功 / 约束 / 范围之外）被写回给用户
• 用户以明确的"是"确认了重述（不是"你觉得怎样就怎样"，不是"听起来不错"，不是沉默）
• 在停止点，智能体能够预测对接下来要问的三个问题的反应
• 对下游技能（idea-refine、spec-driven-development）的任何交接都是以确认的意图来框定的，而非原始的模糊需求