Back to Details

interview-me

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Interview Me

Interview Me

Overview

概述

What people ask for and what they actually want are different things. They ask for "a dashboard" because that's what one asks for, not because a dashboard solves their problem. They say "make it faster" without a number to hit.
The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in.
This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: 
idea-refine
generates variations from an idea, 
spec-driven-development
writes the requirements down, 
doubt-driven-development
stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.
人们所要求的内容，和他们真正想要的往往并非同一回事。他们说“做一个仪表盘”，只是因为这是常规请求，而非因为仪表盘能解决他们的问题。他们说“让它更快”，却没有给出具体的性能指标。
在制定任何计划、规范或编写代码之前，是发现这种需求偏差的最佳时机，成本最低。一旦开始开发，切换成本就会变得很高，用户会将错误的方案合理化，认为“足够好”，最终导致需求与实现的偏差被固化下来。
本技能能在产生成本之前填补这一偏差。其他定义阶段的技能默认你已大致明确需求：
idea-refine
基于现有想法生成变体，
spec-driven-development
撰写需求文档，
doubt-driven-development
在你草拟计划后对其进行严谨验证。而Interview-me是所有这些步骤之前的环节：你逐个提出问题，并附上自己的最佳猜测，直到你能提前预判用户的回答。

When to Use

适用场景

Apply this skill when:
  • The ask is missing at least one of: who the user is, why they want it, what success looks like, what the binding constraint is
  • The request is conventional rather than specific ("build me X", "make it faster") and you can't unpack the convention without guessing
  • You're tempted to start with assumptions you haven't surfaced
  • The user hasn't said which value they're optimizing for when two reasonable ones are in tension (simplicity vs. flexibility, cost vs. speed)
  • The user explicitly invokes: "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking"
When NOT to use:
  • The ask is unambiguous and self-contained ("rename this variable", "fix this typo")
  • The user has explicitly asked for speed over verification
  • Pure information requests ("how does X work?", "what does this code do?")
  • Mechanical operations (renames, formats, file moves)
  • You already have ≥95% confidence; re-read the stop condition below before assuming you don't
在以下情况下使用本技能：
  • 请求缺少至少一项关键信息：用户是谁、为何需要该功能、成功的标准是什么、核心约束条件是什么
  • 请求过于常规而非具体（比如“帮我做X”“让它更快”），你无法在不猜测的前提下拆解常规表述背后的真实需求
  • 你忍不住基于未明确的假设开始工作
  • 当两种合理的价值取向存在冲突时（比如简洁性vs灵活性、成本vs速度），用户未说明他们优先优化哪一项
  • 用户明确发起请求：“访谈我”“追问我”“开始之前，我们确定吗？”“验证我的想法是否严谨”
不适用场景：
  • 请求清晰明确且独立完整（比如“重命名这个变量”“修正这个拼写错误”）
  • 用户明确要求优先速度而非验证
  • 纯信息查询请求（比如“X是如何工作的？”“这段代码的作用是什么？”）
  • 机械操作（重命名、格式化、文件移动）
  • 你已拥有≥95%的置信度；在假设自己不满足条件前，请重新阅读下方的停止条件

Loading Constraints

加载约束

This skill needs a live, responsive user. Do not invoke in non-interactive contexts like CI pipelines, scheduled runs, 
/loop
, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing.
本技能需要一个实时响应的用户。请勿在非交互式场景中调用，比如CI流水线、定时任务、
/loop
或自动循环。如果处于此类场景且需求描述不明确，请将其标记为障碍告知用户，而非自行猜测。

The Process

流程

Step 1: Hypothesize, with a confidence number

步骤1：提出假设并给出置信度

Before asking anything, write down your current best read of what the user wants in one sentence, plus an honest confidence number (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%
The number forces honesty. If you wrote down a high number but can't actually predict the user's reactions to the next three questions you'd ask, the number is wrong. Start at the confidence level you can defend.
在提问之前，用一句话写下你当前对用户需求的最佳判断，并给出真实的置信度数值（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%
数值能迫使你保持诚实。如果你写了一个高置信度数值，但实际上无法预判用户对接下来三个问题的反应，那这个数值就是错误的。从你能辩护的置信度开始。

Step 2: Ask one question at a time, each with a guess attached

步骤2：逐个提问，每个问题附上你的猜测

Format:
Q: <one focused question>
GUESS: <your hypothesis for the answer, with the reasoning that produced it>
Wait for the user to react before asking the next question.
Why one at a time, not a batch:
  • The user can't react to your hypotheses if you bury them in a list
  • Batches encourage skim-reading and surface answers
  • The third question often depends on the answer to the first; asking them all at once locks in the wrong framing
  • The user's energy for thinking carefully is finite; spend it one question at a time
Why attach a guess:
  • The user reacts faster to a wrong guess than they generate an answer from scratch
  • It commits you to a hypothesis you can be visibly wrong about, which keeps you honest
  • It surfaces your assumptions, which is what the interview is meant to expose
The risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
格式：
Q: <一个聚焦的问题>
GUESS: <你对答案的假设及推理过程>
等待用户回复后再提出下一个问题。
为何逐个提问而非批量提问：
  • 如果将假设隐藏在列表中，用户无法针对你的假设做出反应
  • 批量提问会导致用户略读并给出表面化的答案
  • 第三个问题往往取决于第一个问题的答案；一次性提出所有问题会锁定错误的框架
  • 用户认真思考的精力是有限的；应将精力集中在逐个问题上
为何附上猜测：
  • 用户对错误猜测的反应速度，比从头生成答案更快
  • 这能让你坚守一个可被证伪的假设，保持诚实
  • 这能暴露你的假设，而这正是访谈的目的所在
这里的风险是用户为了迎合你而礼貌地同意你的猜测。可以通过明确表现出愿意接受错误，以及偶尔猜测用户可能会反驳的方向来缓解这一风险。

Step 3: Listen for "want vs. should want"

步骤3：区分“想要”与“应该想要”

The most dangerous answers are the ones where the user says what a thoughtful answer sounds like rather than what they actually want. Watch for:
  • Answers that pattern-match best-practice talk ("I want it to be scalable", "clean architecture") without specifics
  • Answers that defer to convention ("the way most apps do it", "the standard approach")
  • Phrases like "I should probably…", "I think I'm supposed to…", "good engineering practice says…"
  • Buzzwords as goals — when "modern", "scalable", "robust" are the answer instead of a specific outcome
When you hear these, the question to ask is:
"If you didn't have to justify this to anyone, what would you actually want?"
That single question often does more work than the previous five.
最危险的回答是用户说出的是听起来合理的答案，而非他们真正想要的内容。请注意以下信号：
  • 答案符合最佳实践话术（比如“我想要它可扩展”“清晰的架构”）但没有具体细节
  • 答案遵循常规做法（比如“大多数应用的做法”“标准方案”）
  • 出现类似“我可能应该……”“我觉得我应该……”“良好的工程实践要求……”的表述
  • 将流行语作为目标——比如用“现代化”“可扩展”“健壮”作为答案，而非具体的结果
当听到这些表述时，你应该问：
“如果不需要向任何人证明，你真正想要的是什么？”
这个问题的作用往往超过之前的五个问题。

Step 4: Restate intent in the user's own words

步骤4：用用户的语言重述意图

When your confidence is high, write back what you now think the user wants. Keep it tight (5–8 lines), use their language where possible, and structure it so the user can confirm or correct line by line:
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?
Including "Out of scope" is non-negotiable. Half of misalignment is silent disagreement about what is not being built.
当你的置信度足够高时，写下你当前对用户需求的理解。保持简洁（5-8行），尽可能使用用户的语言，并结构化内容以便用户可以逐行确认或修正：
以下是我理解的你的需求：

- 目标结果：      <一行描述>
- 用户群体：         <一行描述——谁会从中受益>
- 当下需求原因：      <一行描述——发生了什么变化>
- 成功标准：      <一行描述——如何判断成功>
- 约束条件：   <一行描述——核心限制>
- 范围外内容： <一行描述——明确不做的事情>

是/否/需要调整？
必须包含“范围外内容”部分。一半的需求偏差都来自于对“不做什么”的隐性分歧。

Step 5: Confirm — explicit yes, not "whatever you think"

步骤5：确认——明确的“是”，而非“你看着办”

The gate is an explicit "yes." The following are not yes:
  • "Whatever you think is best." → The user is delegating, which means they don't have 95% confidence either. Re-ask with two concrete options framed as a choice.
  • "Sounds good." → Ambiguous. Ask: "Anything you'd refine?" Silence isn't confirmation.
  • "Sure, let's go." → Often a polite exit, not an endorsement. Same follow-up.
  • Silence followed by "okay let's start." → The user has given up on the interview, not converged. Stop and ask whether you've missed something.
If they correct you, fold the correction in and restate. Loop until you get an explicit yes.
必须得到明确的“是”才算完成。以下表述不等同于“是”：
  • “你看着办就好。” → 用户是在委托决策，这意味着他们自己也没有95%的置信度。重新提出两个具体选项供用户选择。
  • “听起来不错。” → 表述模糊。追问：“有需要调整的地方吗？”沉默不代表确认。
  • “当然，开始吧。” → 通常是礼貌性的结束，而非认可。同样需要跟进追问。
  • 沉默后说“好的，开始吧。” → 用户已经放弃访谈，而非达成共识。停止并询问是否遗漏了什么。
如果用户修正了你的理解，将修正内容纳入并重述。循环直到得到明确的“是”。

The 95% Confidence Stop

95%置信度停止条件

You're done when you can answer yes to this:
Can I predict the user's reaction to the next three questions I would ask?
If yes, you have shared understanding. Stop interviewing and produce the restate. If no, you're not done; ask the next question.
This is a checkable test, not a vibe. It also has a floor: if you've gone several rounds and still can't predict, that's information about the ask, not a reason to keep grinding. Stop and tell the user: "I've asked X questions and I still can't predict your reactions. Something foundational is missing. Want to step back?"
当你能对以下问题回答“是”时，访谈即可结束：
我能预判用户对接下来三个问题的反应吗？
如果能，说明你们已达成共识。停止访谈并给出重述内容。如果不能，说明还未完成；继续提出下一个问题。
这是一个可验证的测试，而非主观感受。同时还有一个下限：如果你已经进行了多轮提问仍无法预判用户的反应，这说明需求本身存在根本性缺失，而非需要继续追问的理由。停止并告知用户：“我已经问了X个问题，但仍无法预判你的反应。存在一些根本性的信息缺失。要不要退一步重新梳理？”

Output

输出

The output of this skill is a confirmed statement of intent: the restate from Step 4, with an explicit yes from Step 5. That's the deliverable. Specs, plans, and task lists are downstream; they consume the intent this skill produces.
If the user wants the intent to persist (a multi-session project, a handoff to another collaborator), offer to save it to 
docs/intent/[topic].md
. Only save if they confirm.
本技能的输出是一份已确认的意图声明：即步骤4中的重述内容，加上步骤5中用户明确的“是”。这就是交付成果。规范、计划和任务列表都是后续环节，它们依赖本技能生成的意图。
如果用户希望意图声明持久保存（比如跨会话项目、交接给其他合作者），可以提议将其保存到
docs/intent/[topic].md
。仅在用户确认后保存。

Example

示例

A short before-and-after.
Without 
interview-me
:
User:  build me a dashboard for our metrics
Agent: <starts proposing chart libraries and layouts>
The agent has assumed: who it's for, what metrics, what "for our team" means, what success looks like. None of these are stated. Every assumption is a place the user can later say "that's not what I meant."
With 
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%

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%.

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>
Two questions in, the agent has discovered the actual ask isn't "a dashboard." It's "a list." Different artifact, different scope, different work. The dashboard would have been wrong.
一个简短的前后对比。
未使用
interview-me
：
用户:  帮我做一个指标仪表盘
Agent: <开始提议图表库和布局>
Agent已经做出了诸多假设：受众是谁、包含哪些指标、“我们团队”的具体含义、成功的标准是什么。这些假设均未被明确说明。每一个假设都可能导致后续用户说“这不是我想要的”。
使用
interview-me
：
用户: 帮我做一个指标仪表盘

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%

Q:     当你说“我们做得怎么样？”时，是谁在问——只是你自己、站会上的工程团队，还是上级（比如你的经理、高管、董事会）？
GUESS: 站会上的工程团队，因为“我们”通常指这个范围，而且这个问题常在站会上被问到。如果是给高管看的，指标和呈现方式会有很大不同。

用户: 其实是给我自己用的。我总是记不清哪些实验在运行，以及它们的早期信号是什么样的。

Agent:
更新后的理解：这根本不是团队仪表盘，而是个人实验追踪工具。置信度：~60%。

Q:     你的痛点是不知道有哪些实验存在，还是无法在一个地方查看实验结果？
GUESS: 第二个。你有实验列表，但结果分散在五个不同的工具中，手动整合让你感到疲惫。

用户: 其实是第一个。我根本没有列表，实验信息分散在不同的文档里。

Agent: <继续访谈>
仅两个问题，Agent就发现用户的真实需求不是“仪表盘”，而是“列表”。这是完全不同的产物、范围和工作量。如果直接做仪表盘就错了。

Interaction with Other Skills

与其他技能的交互

  • idea-refine
    : downstream. If the confirmed intent is "I want X but I don't know how to scope it," hand off to 
    idea-refine
    to generate variations against the now-explicit intent.
  • spec-driven-development
    : downstream. If the confirmed intent is concrete ("I want X for Y users with Z success criteria"), hand off to 
    spec-driven-development
    to write it down.
  • planning-and-task-breakdown
    : two hops downstream of this skill (after the spec).
  • doubt-driven-development
    : opposite end of the timeline. Interview-me is pre-decision intent extraction; doubt-driven is post-decision artifact review. Both catch divergence, but at different moments.
  • source-driven-development
    : orthogonal. Interview-me clarifies what the user wants; SDD verifies framework facts. They don't compete.
  • 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-development是决策后的成果审查。两者都能发现偏差，但处于不同阶段。
  • source-driven-development
    ：正交技能。Interview-me明确用户需求；SDD验证框架事实。两者互不冲突。

Common Rationalizations

常见合理化借口

RationalizationReality
"The ask is clear enough"If you can't write the user's desired outcome in one sentence right now, the ask isn't clear. Run Step 1 before deciding.
"Asking too many questions wastes their time"Time wasted by 4–6 targeted questions is small. Time wasted by building the wrong thing is enormous, and the user is the one bearing that cost.
"I'll figure it out as I build"Switching costs after code exists are 10x what they are now. Discovery during implementation is rework.
"They said 'whatever you think,' so I should just decide""Whatever you think" is delegation, not decision. Re-ask with two concrete options as a choice.
"I should give them several options to pick from"Options work when the user knows what they want and is choosing between trade-offs. They don't know what they want yet. Listing options widens the search; asking narrows it.
"If I attach my guess, I'm leading them"Leading is the point. Reacting is faster than generating from scratch. The risk is sycophancy, not leading; mitigate by being visibly willing to be wrong.
"We've talked enough, I get it"Test it: can you predict their reaction to the next three questions? If not, you don't get it yet.
"The user said yes, we're done"If the yes followed a vague restate or an open-ended "sounds good," the yes is hollow. Restate concretely and re-confirm.
合理化借口实际情况
“需求已经足够明确了”如果你现在无法用一句话写出用户的期望结果，说明需求并不明确。在做决定前先执行步骤1。
“问太多问题会浪费用户时间”4-6个针对性问题花费的时间很少。而开发错误产品浪费的时间是巨大的，且最终由用户承担成本。
“我会在开发过程中弄清楚”代码编写完成后的切换成本是现在的10倍。开发过程中的需求发现本质上是返工。
“用户说‘你看着办’，所以我应该直接做决定”“你看着办”是委托决策，而非明确决定。重新提出两个具体选项供用户选择。
“我应该给他们几个选项来挑选”当用户知道自己想要什么，只是在权衡取舍时，选项才有用。但用户现在还不知道自己想要什么。列出选项会扩大搜索范围；提问则会缩小范围。
“如果附上我的猜测，会引导用户”引导正是目的所在。用户对猜测的反应比从头生成答案更快。风险在于迎合而非引导；可以通过明确表现出愿意接受错误来缓解。
“我们已经谈得够多了，我理解了”测试一下：你能预判用户对接下来三个问题的反应吗？如果不能，说明你还没理解。
“用户说‘是’了，我们完成了”如果“是”是在模糊的重述或开放式的“听起来不错”之后给出的，这个“是”是空洞的。重新用具体内容重述并再次确认。

Red Flags

警示信号

  • Three or more questions in a single message: that's batching, not interviewing
  • A question without your hypothesis attached: that's surveying, not committing
  • Accepting "whatever you think is best" as a terminal answer
  • Producing a spec, plan, or task list before the user has explicitly confirmed your restate
  • Questions framed as "what would be best practice?" instead of "what do you actually want?"
  • The user gives a sophistication-signaling answer ("scalable", "clean", "modern") and you accept it without probing whether it's what they actually want
  • Three or more rounds without your confidence visibly rising: you're asking the wrong questions, step back and reframe
  • Saving the intent doc before the user has confirmed (the doc itself implies a yes the user didn't give)
  • Skipping the "Out of scope" line in the restate (silent disagreement about non-goals is half of misalignment)
  • 单条消息中包含三个或更多问题：这是批量提问，而非访谈
  • 问题未附上你的假设：这是调查，而非明确立场
  • 将“你看着办就好”作为最终答案
  • 在用户明确确认你的重述内容之前，就生成规范、计划或任务列表
  • 问题的框架是“最佳实践是什么？”而非“你真正想要的是什么？”
  • 用户给出一个彰显专业性的答案（比如“可扩展”“清晰”“现代化”），你未进一步探究这是否是他们真正想要的
  • 三轮或更多提问后，你的置信度没有明显提升：你问错了问题，退一步重新梳理框架
  • 在用户确认之前就保存意图文档（文档本身暗示了用户未给出的“是”）
  • 在重述内容中省略“范围外内容”部分（对非目标的隐性分歧是一半需求偏差的来源）

Verification

验证

After applying interview-me:
  • An explicit hypothesis with a confidence number was stated in the first turn
  • Questions were asked one at a time, each with the agent's guess attached
  • At least one "what would you actually want if you didn't have to justify it?" probe ran when the user gave a sophistication-signaling or convention-signaling answer
  • A concrete restate (Outcome / User / Why now / Success / Constraint / Out of scope) was written back to the user
  • The user confirmed the restate with an explicit yes (not "whatever you think," not "sounds good," not silence)
  • At the stop point, the agent could predict reactions to the next three questions it would ask
  • Any handoff to a downstream skill (
    idea-refine
    , 
    spec-driven-development
    ) was framed in terms of the confirmed intent, not the original underspecified ask
应用Interview-me后，请检查：
  • 在第一轮交互中明确提出了带有置信度数值的假设
  • 逐个提问，每个问题都附上了Agent的猜测
  • 当用户给出彰显专业性或遵循常规的答案时，至少进行了一次“如果不需要向任何人证明，你真正想要的是什么？”的追问
  • 向用户返回了具体的重述内容（目标结果/用户群体/当下需求原因/成功标准/约束条件/范围外内容）
  • 用户用明确的“是”确认了重述内容（而非“你看着办”“听起来不错”或沉默）
  • 在停止点，Agent能预判对接下来三个问题的用户反应
  • 任何向下游技能（
    idea-refine
    、
    spec-driven-development
    ）的交接，都是基于已确认的意图，而非最初不明确的请求