interview-me

采访我

概述

人们提出的需求和他们实际想要的东西并不相同。他们会说要一个“仪表板”，因为大家通常都会这么提，而不是因为仪表板能解决他们的问题。他们会说“让它更快”，却不给出具体的目标数字。

找出这种差距，成本最低的时机是在任何计划、规格说明或代码出现之前。一旦开始构建，切换成本就是真实存在的，而用户会为错误的方向找理由，把它说成“够用了”。不合适的方案就此定型。

这项技能能在产生任何代价之前弥合差距。其他 Define 阶段的技能都假设你大致知道自己想要什么：idea-refine 根据一个想法生成不同方案，spec-driven-development 把需求写下来，doubt-driven-development 则在你起草计划后对其进行压力测试。Interview-me 是这一切之前的环节：一次问一个问题，并附上你最好的猜测，直到你能在用户开口之前预测他们会怎么回答。

何时使用

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

• 需求至少缺少以下内容之一：用户是谁、他们为什么想要它、成功是什么样子，以及具有约束力的限制条件是什么
• 请求比较笼统，而非具体（“帮我构建 X”“让它更快”），你无法在不猜测的情况下拆解其中的惯例说法
• 你正打算基于尚未明确说出的假设开始行动
• 当两个合理的价值取向存在冲突（简单性与灵活性、成本与速度）时，用户尚未说明自己要优先优化哪一项
• 用户明确提出：“采访我”“盘问我”“开始之前，确定我们想清楚了吗？”“对我的想法进行压力测试”

何时不要使用：

• 需求明确且完整（“重命名这个变量”“修复这个拼写错误”）
• 用户明确要求优先考虑速度，而不是验证
• 纯信息请求（“X 是如何工作的？”“这段代码做什么？”）
• 机械操作（重命名、格式化、移动文件）
• 你已经有 ≥95% 的把握；在认定自己没有把握之前，请重新阅读下方的停止条件

加载限制

此技能需要一个实时且能及时响应的用户。**请勿在 CI 流水线、定时运行、/loop 或 autonomous-loop 等非交互式环境中调用。**如果你处于这类环境，而需求说明不充分，请将其标记为用户需要解决的阻塞项，而不是自行猜测。

流程

步骤 1：提出假设，并给出信心分数

提问之前，用一句话写下你目前对用户需求的最佳判断，并给出诚实的信心分数（0–100%）：

HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like

这个数字能迫使你保持诚实。如果你写了一个很高的数字，却无法真正预测自己接下来要问的三个问题会得到什么反应，那这个数字就不对。请从你能合理辩护的信心水平开始。

当信心低于约 70% 时，请在同一行附上简短的原因——还有什么尚未解决或缺失。这能准确地告诉用户访谈需要弄清什么，也能避免这个数字沦为空泛的信号。

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

格式：

Q: <one focused question>
GUESS: <your hypothesis for the answer, with the reasoning that produced it>

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

为什么一次只问一个，而不是一批问题：

• 如果把假设埋在列表里，用户就无法对其作出回应
• 一批问题会让人草草浏览，给出表面化的回答
• 第三个问题往往取决于第一个问题的答案；一次全问出来，就会把错误的框架固定下来
• 用户认真思考的精力有限；一次只问一个问题，才能把这份精力用在刀刃上

为什么要附上猜测：

• 面对一个错误的猜测，用户通常比从零开始生成答案反应更快
• 这会让你明确提出一个可能被证明错误的假设，从而促使你保持诚实
• 这会暴露你的假设，而这正是访谈要揭示的内容

这里的风险是，礼貌的用户可能为了顺着你而赞同你的猜测。应对方法是明确表示你愿意出错，并偶尔朝你预计用户会反驳的方向提出猜测。

第 3 步：倾听“想要”与“应该想要”之间的区别

最危险的回答，是用户说出深思熟虑的答案听起来应该是什么样，而不是他们实际想要什么。注意以下情况：

• 回答只是套用最佳实践的话术（“我希望它可扩展”“清晰的架构”），却没有具体细节
• 回答遵循惯例（“大多数应用的做法”“标准方法”）
• 使用“我可能应该……”“我想我应该……”“良好的工程实践要求……”之类的说法
• 把流行词当作目标——回答的是“现代”“可扩展”“稳健”，而不是具体结果

听到这些说法时，可以问：

“如果你不需要向任何人解释这个选择，你实际上会想要什么？”

单单这个问题，往往比前面五个问题更有用。

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

当你有把握时，把你现在认为用户想要的内容写出来。简明扼要（5–8 行），尽可能使用用户的措辞，并按行组织，让用户可以逐行确认或纠正：

Here's what I now think you want:

- Outcome:      <one line>
- User:         <one line — who benefits>
- Why now:      <one line — what changed>
- Success:      <one line — how we know it worked>
- Constraint:   <one line — the binding limit>
- Out of scope: <one line — what we're explicitly not doing>

Yes / no / refine?

必须包含“范围之外”的内容。这一点不容商榷。很多误解都源于双方默默地对不要构建的内容持有不同看法。

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

确认的标准是明确说“是”。以下都不算“是”：

• “你觉得怎样最好就怎样。”→ 用户是在把决定权交给你，这意味着他们也没有 95% 的把握。用两个具体选项让用户选择，然后重新提问。
• “听起来不错。”→ 含义不明确。问：“你觉得有什么需要调整的吗？”沉默不等于确认。
• “好，那就开始吧。”→ 往往只是礼貌地结束对话，而非认可。继续追问。
• 沉默后说“好，那就开始吧。”→ 用户是放弃了访谈，而不是达成了共识。停下来问是否有什么遗漏。

如果用户纠正了你，就吸收这些更正并重新陈述。持续循环，直到获得明确的“是”。

第 6 步：终止轮次与停止规则（重要）

当用户明确说“是”，确认意图陈述后：

1. 交付已确认的意图陈述。
2. 提供后续选项（可以提议将其保存到 docs/intent/[topic].md，使用 spec-driven-development 起草规格，或在规格完成后进入任务规划）。
3. **立即结束本轮。**本轮中不要调用工具，也不要开始后续工作。将控制权交还给用户，由他们选择下一步。

95% 把握度停止规则

当你能对以下问题回答“是”时，就可以结束：

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

如果可以，说明双方已经达成共识。停止访谈并给出重述。如果不可以，就还没结束；继续问下一个问题。

这是一个可验证的标准，不是凭感觉判断。它也有一个底线：如果经过几轮交流后你仍然无法预测，这说明用户的需求存在问题，而不是继续反复追问的理由。停下来告诉用户：“我已经问了 X 个问题，但仍然无法预测你的反应。某些基础信息还不清楚。要不要退一步重新梳理？”

输出

这项技能的输出是已确认的意图陈述：第 4 步的重述，以及第 5 步的明确“是”。这就是交付内容。规格、计划和任务列表属于后续工作；它们会基于这项技能产出的意图继续推进。

如果用户希望保留意图（用于多轮会话的项目，或交接给其他协作者），可以提议将其保存到 docs/intent/[topic].md。只有在用户确认后才保存。

示例

简短对比。

不使用 interview-me：

User:  build me a dashboard for our metrics
Agent: <starts proposing chart libraries and layouts>

Agent 自行假设了目标用户、指标、“面向我们的团队”的含义，以及成功的标准。这些内容都没有明确说明。每一项假设都可能导致用户之后说“我不是这个意思”。

使用 interview-me：

User: build me a dashboard for our metrics

Agent:
HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" came to mind because that's the conventional answer.
CONFIDENCE: ~30% — missing: who it's for, what "metrics" are, and what success looks like

Q:     When you say "how are we doing?", who's asking — you alone, the engineering team in standup, or up the chain (e.g., your manager, an exec, a board)?
GUESS: engineering team in standup, because "we" usually scopes that way and standups are where this question gets asked. If it's for execs the metrics and the framing change a lot.

User: It's actually for me. I keep losing track of which experiments are running and what their early signal looks like.

Agent:
Updated read: not a team dashboard at all. It's a personal experiment tracker. Confidence: ~60% — still missing: what "early signal" means and what done looks like.

Q:     Is the gap that you don't know which experiments exist, or that you can't see their results in one place?
GUESS: the second one. You have a list of experiments somewhere, but their results live in five different tools, and reconciling them by hand is what you're tired of.

User: First one actually. I literally don't have a list. They're spread across different docs.

Agent: <continues>

只问了两个问题，Agent 就发现，用户实际想要的不是“仪表盘”，而是“列表”。交付物不同、范围不同、工作也不同。如果做成仪表盘，结果就会错。

与其他技能的交互

• idea-refine：下游。如果确认后的意图是“我想做 X，但不知道如何界定范围”，则移交给 idea-refine，根据现在已明确的意图生成不同方案。
• spec-driven-development：下游。如果确认后的意图很具体（“我想为 Y 用户做 X，并以 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% 的置信度数值都附有一行理由（说明仍有哪些问题尚未解决或信息缺失）
• 每次只问一个问题，并附上 Agent 的猜测
• 当用户给出彰显专业或强调惯例的回答时，至少进行了一次“如果不必为此找理由，你实际上想要什么？”的探问
• 向用户写明了具体的复述（目标／用户／为何是现在／成功标准／约束／范围之外）
• 用户明确回答“是”以确认复述（而非“随便你觉得”“听起来不错”或保持沉默）
• 到达停止点时，Agent 能够预测用户对接下来三个问题的反应
• 收到明确确认后，立即停止本轮，不调用工具或开始后续工作
• 移交给下游技能（idea-refine、spec-driven-development）时，依据已确认的意图来说明，而非依据最初未充分明确的请求