interview-me

访谈我（Interview Me）

概览

人们开口要的东西和他们真正想要的东西，是两回事。他们要“一个 dashboard”，是因为那是人们会去要的东西，而不是因为 dashboard 能解决他们的问题。他们说“再快一点”，却没有一个要达到的数字。

发现这个落差最便宜的时刻，是在任何 plan、spec 或代码存在之前。一旦你开始构建，切换成本就是真实的，用户会把错误的东西合理化成“够用的”东西。错配就此被锁死。

这个 skill 在落差造成任何代价之前把它合上。Define 阶段的其他 skill 都假定你已经大致知道要什么：idea-refine 从一个想法生成变体，spec-driven-development 把需求写下来，doubt-driven-development 在你起草完一个计划之后对它做压力测试。Interview-me 是所有这些之前的那一步：你一次问一个问题、每个问题附上你的最佳猜测，直到能在用户开口之前预测到他会说什么。

何时使用

在以下情况应用这个 skill：

• 这个请求至少缺一项：谁是用户、为什么想要它、成功长什么样、那个有约束力的限制条件是什么
• 请求是惯例式的而非具体的（"build me X"、"make it faster"），而你不动脑筋就无法拆解这个惯例
• 你蠢蠢欲动，想用没有摆到台面上的假设直接开工
• 当两个都合理的价值取向相互冲突时（简单 vs. 灵活、成本 vs. 速度），用户还没说他在优化哪一个
• 用户明确发出邀请："interview me"、"grill me"、"before we start, are we sure?"、"stress-test my thinking"

何时不要使用：

• 请求明确且自包含（"rename this variable"、"fix this typo"）
• 用户已明确要求速度优先于验证
• 纯信息类请求（"how does X work?"、"what does this code do?"）
• 机械操作（重命名、格式化、移动文件）
• 你已经有 ≥95% 的置信度；重读下面的停止条件，再假定你没有

加载约束

这个 skill 需要一个在线、会回应的用户。不要在非交互上下文中调用，比如 CI pipeline、定时运行、/loop 或自主循环。如果你在其中之一里且请求信息不全，把这个事实标记为用户的 blocker，而不是靠猜。

流程

Step 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% 时，在同一行追加一句简短的理由——还有什么悬而未决或缺失。这准确地告诉用户访谈需要浮现什么，也防止这个数字变成一个含糊的信号。

Step 2: 一次问一个问题，每个都附上猜测

格式：

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

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

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

• 如果把猜测埋进一个列表，用户就没法对你的猜测做出回应
• 成批发问鼓励扫读和浮于表面的回答
• 第三个问题往往取决于第一个问题的答案；一口气全问出来会锁死错误的框架
• 用户认真思考的精力有限；一次一个问题地花掉它

为什么附上猜测：

• 用户纠正一个错误猜测，比从零生成一个答案快得多
• 它逼你给出一个会 visibly 出错的假设，这让你保持诚实
• 它浮现的是你的假设，而这正是访谈要暴露的东西

这里的风险是一个礼貌的用户为了配合而附和你的猜测。缓解方式：表现出你愿意出错，并且偶尔往你预期用户会反驳的方向猜。