---
name: interview-me
description: 挖掘用户实际想要什么，而不是他们认为自己应该想要什么。通过一次只问一个问题的方式逐步访谈，直到对底层意图达到约 95% 的把握。适用于：需求表述不明确（例如"帮我做个 X"却没有说明"给谁用"或"为什么现在做"）、用户明确要求（"访谈我"、"拷问我"、"我们确定吗？"、"给我的想法来一次压力测试"）、或你发现自己正在任何计划、规格、代码出现之前就默默填补模糊需求的时候。
---

# 访谈我

## 概述

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

发现这种偏差最经济的时机，是在任何计划、规格或代码出现之前。一旦你开始构建，切换成本就是实实在在的，用户会把错误的东西合理化成一个"足够好"的东西。这种错位就此被固化。

这项技能在付出任何成本之前就消除这种偏差。其他的「定义阶段」技能都假定你大致已经知道自己想要什么：`idea-refine` 从一个想法生成多个变体，`spec-driven-development` 把需求写下来，`doubt-driven-development` 在你起草完计划之后对其进行压力测试。而 interview-me 是所有这些之前的那一步，你一次只问一个问题，附带你的最佳猜测，直到你能够在用户说出答案之前就预测到他们要说什么。

## 何时使用

在以下情况应用此技能：

- 需求缺少以下至少一项：**谁**是用户、他们**为什么**想要、**成功**的标准是什么、关键的**约束**是什么
- 请求是常规性的而非具体的（"帮我做个 X"、"让它更快"），而且你无法在不猜测的情况下拆解这种常规表达
- 你正想基于一些你尚未浮出水面的假设就开始工作
- 用户没有说明，当两个合理的价值之间存在张力时（简单 vs. 灵活、成本 vs. 速度），他们要优化哪一个
- 用户明确要求："访谈我"、"拷问我"、"在我们开始之前，我们确定吗？"、"给我的想法来一次压力测试"

**何时不使用：**

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

## 加载约束

此技能需要一个在线的、能够响应的用户。**不要在非交互式环境中调用**，例如 CI 流水线、定时任务、`/loop` 或自主循环。如果你处于上述环境中且需求表述不明确，应将其标记为阻塞项告知用户，而不是自行猜测。

## 流程

### 第一步：提出假设，附上置信度数字

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

```
假设：你希望在每日站会上回答"我们做得怎么样了？"这个问题，而"仪表盘"是你脑海中浮现的常规答案。
置信度：约 30% —— 缺少：给谁用的、"指标"在上下文中指什么、以及成功的标准是什么
```

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

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

### 第二步：一次只问一个问题，每个问题附带一个猜测

格式：

```
问：<一个聚焦的问题>
猜测：<你对答案的假设，以及得出该假设的推理过程>
```

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

**为什么要一次只问一个，而不是批量问：**

- 如果你把问题埋在一堆列表中，用户就无法对你的假设做出反应
- 批量问题会鼓励用户扫读和给出表面答案
- 第三个问题的答案往往依赖于第一个问题的答案；一次性全部问完，会把错误的框架锁定下来
- 用户用于认真思考的精力是有限的；一次只花在一个问题上

**为什么要附带猜测：**

- 用户对一个错误猜测的反应，比他们从头生成一个答案要快得多
- 它让你对一个假设做出承诺，这个假设是你可以被明确证明是错的，从而保持你的诚实
- 它把你**自己的**假设浮出水面，而这正是访谈想要暴露的东西

这里的风险是礼貌的用户为了表现得配合而同意你的猜测。缓解方法是让自己明显表现出愿意被否定，并偶尔朝你预期用户会反驳的方向去猜。

### 第三步：倾听"想要 vs. 应该想要"

最危险的回答是那些用户说的是"听起来深思熟虑的回答"而不是他们实际想要的。注意以下几点：

- 那些听起来像是"最佳实践"的套话（"我希望它能扩展"、"干净的架构"）却没有具体内容
- 那些遵循惯例的回答（"大多数应用的做法"、"标准方案"）
- 像"我可能应该……"、"我觉得我应该……"、"好的工程实践说……"这样的措辞
- 以流行词作为目标——当"现代化"、"可扩展"、"健壮"是答案，而不是一个具体的结果

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

> *"如果你不需要向任何人证明什么，你实际上想要的是什么？"*

这一个问题往往比前面五个问题加起来还管用。

### 第四步：用用户自己的话重述意图

当你的置信度很高时，把你现在认为用户想要的东西写回去。保持精炼（5–8 行），尽可能使用他们的语言，并使其结构让用户可以逐行确认或修正：

```
以下是现在我理解的你想要的东西：

- 结果：      <一行>
- 用户：      <一行——谁受益>
- 为什么现在：<一行——什么变了>
- 成功标准：  <一行——我们怎么知道它有效>
- 约束条件：  <一行——关键限制>
- 不在范围内：<一行——明确不做的事情>

是 / 否 / 需要细化？
```

包含"不在范围内"这一项是不可省略的。一半的错位都源于对**不**构建什么这件事上的沉默分歧。

### 第五步：确认——明确的"是"，而不是"你决定就好"

关卡是一个明确的"是"。以下情况**不是**"是"：

- "你决定就好。"——用户是在授权，这意味着他们自己也没有 95% 的把握。重新问，给出两个具体的选项让他们做选择。
- "听起来不错。"——模棱两可。问："有什么需要细化的吗？"沉默不是确认。
- "好的，我们开始吧。"——往往是一种礼貌的退出，而不是认可。同样需要跟进。
- 沉默之后接"好吧，开始吧。"——用户已经放弃访谈了，而不是达成了共识。停下来，问你是否遗漏了什么。

如果他们纠正了你，把修正融入进去并重新重述。循环直到你得到一个明确的"是"。

### 95% 置信度停止条件

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

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

如果能，你们就拥有共同的理解。停止访谈并输出重述。如果不能，你还没完成；继续问下一个问题。

这是一个可检验的标准，而不是一种感觉。它还有一个底线：如果你已经过了几轮仍然无法预测，这说明需求本身的信息不足，而不是你该继续硬磨的理由。停下来告诉用户："我已经问了 X 个问题，但仍然无法预测你的反应。缺少一些基础性的东西。想退一步重新审视吗？"

## 输出

此技能的输出是一个**已确认的意图陈述**：第四步中的重述，加上第五步中的明确"是"。这就是交付物。规格、计划和任务清单都是下游工作；它们消费的是此技能产出的意图。

如果用户希望意图能够持久（跨会话的项目、交接给其他协作者），主动提出将其保存到 `docs/intent/[主题].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 验证框架事实。两者不冲突。

## 常见的合理化借口

| 合理化借口 | 实际情况 |
|---|---|
| "需求已经够清楚了" | 如果你现在不能用一句话写出用户想要的结果，那么需求就不清楚。在做决定之前先运行第一步。 |
| "问太多问题是在浪费他们的时间" | 花在 4–6 个针对性问题上的时间很少。花在构建错误的东西上的时间极其巨大，而承受这个成本的是用户。 |
| "我边做边弄清楚" | 代码存在后的切换成本是现在的 10 倍。实施过程中的发现就是返工。 |
| "他们说了'你决定就好'，所以我自己决定就行" | "你决定就好"是授权，不是决定。重新问，给出两个具体选项让他们做选择。 |
| "我应该给他们几个选项让他们挑" | 当用户知道自己想要什么并在权衡取舍时，选项是有用的。他们还不知道自己想要什么。列出选项会扩大搜索范围；提问则会缩小范围。 |
| "如果我附上我的猜测，我就是在引导他们" | 引导就是目的。对猜测做出反应比从头生成答案要快。风险是谄媚附和，而不是引导；缓解方法是让自己明显表现出愿意被否定。 |
| "我们已经谈得够多了，我懂了" | 测试一下：你能预测他们对接下来三个问题的反应吗？如果不能，你还没懂。 |
| "用户说了是，我们完成了" | 如果这个"是"跟在一个模糊的重述或一个开放式的"听起来不错"之后，那这个"是"是空洞的。给出具体的重述并重新确认。 |

## 警示标志

- 一条消息中包含三个或更多问题：这是批量提问，不是访谈
- 一个问题没有附上你的假设：这是在调查，不是在承诺
- 接受"你决定就好"作为最终答案
- 在用户明确确认你的重述之前就产出了规格、计划或任务清单
- 问题被框定为"最佳实践是什么？"而不是"你实际想要什么？"
- 用户给出一个显示"专业水准"的答案（"可扩展"、"干净"、"现代化"），而你接受了，却没有探究这是否是他们真正想要的
- 三个或更多轮次过去，你的置信度没有明显上升：你在问错误的问题，退一步重新调整
- 置信度数字低于约 70% 却没有附带原因：用户如果不知道缺失了什么，就无法帮助你缩小差距
- 在用户确认之前就保存了意图文档（文档本身隐含了一个用户并未给出的"是"）
- 在重述中跳过了"不在范围内"这一项（对非目标的沉默分歧是错位的一半原因）

## 验证

应用 interview-me 后：

- [ ] 在第一轮中明确陈述了一个假设及其置信度数字
- [ ] 每个低于约 70% 的置信度数字都附带了一行原因（什么仍然未解决或缺失）
- [ ] 问题一次只问一个，每个都附带了代理的猜测
- [ ] 当用户给出显示"专业水准"或循规蹈矩的回答时，至少运行了一次"如果你不需要向任何人证明，你实际想要什么？"的探询
- [ ] 向用户写回了一个具体的重述（结果 / 用户 / 为什么现在 / 成功标准 / 约束条件 / 不在范围内）
- [ ] 用户用一个明确的"是"确认了重述（不是"你决定就好"，不是"听起来不错"，不是沉默）
- [ ] 在停止点上，代理能够预测对接下来三个问题的反应
- [ ] 任何向下游技能（`idea-refine`、`spec-driven-development`）的交接都基于已确认的意图，而不是最初那个不明确的需求