From 075d99ba66c76d01d15789d3abe391f96715d13e Mon Sep 17 00:00:00 2001 From: wehub-skill-sync Date: Mon, 13 Jul 2026 21:36:05 +0800 Subject: [PATCH] chore: import zh skill interview-me --- README.wehub.md | 9 ++ SKILL.md | 225 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 234 insertions(+) create mode 100644 README.wehub.md create mode 100644 SKILL.md diff --git a/README.wehub.md b/README.wehub.md new file mode 100644 index 0000000..3b7161d --- /dev/null +++ b/README.wehub.md @@ -0,0 +1,9 @@ +# WeHub 来源说明 + +- Skill 名称：`interview-me` +- 中文类目：模糊 brief 结构化澄清 +- 上游仓库：`addyosmani__agent-skills` +- 上游路径：`skills/interview-me/SKILL.md` +- 上游链接：https://github.com/addyosmani/agent-skills/blob/HEAD/skills/interview-me/SKILL.md +- 本仓库为 WeHub 中文 Skill 汉化包，基于 skill 市场筛选 Top200 清单整理 +- 原作者、版权和许可证信息以上游仓库为准 diff --git a/SKILL.md b/SKILL.md new file mode 100644 index 0000000..bb39269 --- /dev/null +++ b/SKILL.md @@ -0,0 +1,225 @@ +--- +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`）的交接都基于已确认的意图，而不是最初那个不明确的需求