interview-me

采访我

概述

人们要求的和他们实际想要的是两回事。他们要求“一个仪表盘”，因为那是人们通常会要求的，而不是因为仪表盘能解决他们的问题。他们说“让它更快”，却没有一个具体的数字目标。

发现这个差距成本最低的时机是在任何计划、规格或代码存在之前。一旦你开始构建，切换成本就变得真实，用户会将错误的东西合理化成一个“足够好”的东西。这种不匹配就被锁定了。

这个技能在造成任何成本之前就消除了这个差距。其他定义阶段的技能假设你已经大致知道你想要什么：idea-refine 从一个想法生成变体，spec-driven-development 将需求写下来，doubt-driven-development 在你起草计划后对其进行压力测试。而 interview-me 是所有这些之前的部分，你一次问一个问题，并附上你的最佳猜测，直到你能在用户说出之前预测他们将要说什么。

何时使用

在以下情况下应用此技能：

• 需求缺少以下至少一项：谁是用户，为什么他们想要，成功是什么样子，以及约束条件是什么
• 请求是常规性的而非具体的（如“给我建个X”、“让它更快”），而且你无法在不猜测的情况下解析这个常规
• 你倾向于从你尚未浮出水面的假设开始
• 当两个合理的价值存在冲突时（简单性与灵活性，成本与速度），用户没有说明他们优化的是哪个价值
• 用户明确要求：“采访我”、“拷问我”、“在我们开始之前，我们确定吗？”、“压力测试我的想法”

何时不使用：

• 需求明确且自包含（如“重命名这个变量”、“修复这个拼写错误”）
• 用户明确要求速度优先于验证
• 纯粹的信息请求（如“X如何工作？”、“这段代码是做什么的？”）
• 机械操作（重命名、格式化、移动文件）
• 你已经拥有≥95%的置信度；在假设你没有之前，重新阅读下面的停止条件

加载约束

这个技能需要一个活跃、响应的用户。不要在非交互式环境中调用，如CI流水线、定时任务、/loop 或自主循环。如果你处于这些环境中且需求不明确，请将其标记为用户的阻碍，而不是猜测。

流程

步骤1：假设，并附上置信度数字

在问任何问题之前，用一句话写下你当前对用户想要什么的最佳解读，加上一个诚实的置信度数字（0–100%）：

假设：你想要一种在站会上回答“我们做得怎么样？”的方式，而“仪表盘”是你想到的常规答案。
置信度：~30% — 缺少：给谁用，“指标”在上下文中是什么意思，以及成功是什么样子

这个数字迫使你诚实。如果你写了一个很高的数字，但实际上无法预测用户对你接下来要问的三个问题的反应，那么这个数字就是错的。从你能捍卫的置信水平开始。

当置信度低于约70%时，在同一行附上一个简短的原因——还有什么未解决或缺失。这告诉用户访谈需要揭示什么，并防止数字成为一个模糊的信号。

步骤2：一次问一个问题，每个问题附上猜测

格式：

问：<一个聚焦的问题>
猜：<你对答案的假设，以及产生这个假设的推理>

等待用户回应后再问下一个问题。

为什么一次一个，而不是批量：

• 如果你把假设埋在一个列表里，用户无法对你的假设做出反应
• 批量提问鼓励略读和表面回答
• 第三个问题通常取决于第一个问题的答案；一次性问完会锁定错误的框架
• 用户认真思考的精力是有限的；一次一个问题地花费它

为什么附上猜测：

• 用户对错误猜测的反应比从头生成答案更快
• 它让你承诺一个你可以明显出错的假设，这让你保持诚实
• 它浮出水面了你的假设，而这正是访谈要暴露的

这里的风险是礼貌的用户为了讨好而同意你的猜测。通过表现出你愿意犯错来缓解，并偶尔朝你预期用户会反驳的方向猜测。

步骤3：倾听“想要 vs. 应该想要”

最危险的答案是那些用户说出一个深思熟虑的答案听起来的样子，而不是他们实际想要的东西。注意：

• 匹配最佳实践话语的答案（如“我想要它可扩展”、“干净架构”）但没有具体内容
• 遵循惯例的答案（如“大多数应用的做法”、“标准方法”）
• 像“我可能应该……”、“我想我应该……”、“好的工程实践说……”这样的短语
• 作为目标的流行词——当“现代”、“可扩展”、“健壮”是答案而不是具体结果时

当你听到这些时，要问的问题是：

“如果你不需要向任何人证明这一点，你实际想要什么？”

这一个问题通常比前五个问题更有效。

步骤4：用用户自己的话重述意图

当你的置信度很高时，写下你现在认为用户想要什么。保持简洁（5–8行），尽可能使用他们的语言，并结构化以便用户可以逐行确认或纠正：

这是我现在认为你想要的：

- 结果：      <一行>
- 用户：      <一行 — 谁受益>
- 为什么现在：<一行 — 什么变了>
- 成功：      <一行 — 我们如何知道它有效>
- 约束：      <一行 — 限制条件>
- 范围外：    <一行 — 我们明确不做什么>

是 / 否 / 完善？

包含“范围外”是不可协商的。一半的不一致是对不构建什么的无言分歧。

步骤5：确认——明确的“是”，而不是“你觉得怎样都行”

门槛是一个明确的“是”。以下不是“是”：

• “你觉得怎样最好就怎样。” → 用户在授权，这意味着他们也没有95%的置信度。重新提问，提供两个具体选项作为选择。
• “听起来不错。” → 模棱两可。问：“有什么需要完善的吗？”沉默不是确认。
• “好的，开始吧。” → 通常是礼貌的退出，而不是认可。同样的后续问题。
• 沉默后跟着“好吧，开始吧。” → 用户已经放弃了访谈，而不是达成一致。停下来问你是否遗漏了什么。

如果他们纠正你，将纠正内容纳入并重述。循环直到你得到一个明确的“是”。

95%置信度停止条件

当你对以下问题能回答“是”时，你就完成了：

我能预测用户对我接下来要问的三个问题的反应吗？

如果能，你们就有了共同理解。停止访谈并产生重述。如果不能，你还没完成；问下一个问题。

这是一个可检查的测试，而不是一种感觉。它也有一个底线：如果你已经进行了几轮仍然无法预测，这说明了关于需求的信息，而不是继续磨下去的理由。停下来告诉用户：“我已经问了X个问题，仍然无法预测你的反应。有些基础性的东西缺失了。想退一步吗？”

输出

这个技能的输出是一个确认的意图陈述：步骤4的重述，加上步骤5的明确“是”。这就是交付物。规格、计划和任务列表是下游的；它们消耗这个技能产生的意图。

如果用户希望意图持久化（多会话项目、交接给其他协作者），提供将其保存到 docs/intent/[topic].md。只有在用户确认时才保存。

示例

一个简短的前后对比。

没有 interview-me：

用户：给我建一个我们指标的仪表盘
智能体：<开始提议图表库和布局>

智能体假设了：给谁用、什么指标、“给我们团队”是什么意思、成功是什么样子。这些都没有说明。每个假设都是用户以后可以说“这不是我的意思”的地方。

使用 interview-me：

用户：给我建一个我们指标的仪表盘

智能体：
假设：你想要一种在站会上回答“我们做得怎么样？”的方式，而“仪表盘”是你想到的常规答案。
置信度：~30% — 缺少：给谁用，“指标”是什么，以及成功是什么样子

问：    当你说“我们做得怎么样？”时，谁在问——只有你，工程团队在站会上，还是向上汇报（比如你的经理、高管、董事会）？
猜：    工程团队在站会上，因为“我们”通常这样限定范围，而且站会上经常问这个问题。如果是给高管，指标和框架会变化很大。

用户：实际上是给我自己。我经常搞不清哪些实验在运行以及它们的早期信号是什么样子。

智能体：
更新解读：根本不是团队仪表盘。是个人的实验追踪器。置信度：~60% — 仍然缺少：“早期信号”是什么意思以及完成是什么样子。

问：    差距是你不知道哪些实验存在，还是你不能在一个地方看到它们的结果？
猜：    第二个。你在某个地方有一个实验列表，但它们的结果分布在五个不同的工具中，手动核对是你厌倦的。

用户：实际上是第一个。我根本没有一个列表。它们分散在不同的文档中。

智能体：<继续>

两个问题之后，智能体发现实际需求不是“一个仪表盘”，而是“一个列表”。不同的工件，不同的范围，不同的工作。仪表盘会是错的。

与其他技能的交互

• 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）的交接都是基于确认的意图，而不是原始的不明确需求