需求澄清访谈 · interview-me

二次开发：本技能改编自 addyosmani/agent-skills 的 interview-me（MIT © 2025 Addy Osmani），在保留其核心方法论基础上，升级为「提示词 + 可执行 CLI」双形态。署名见本目录 NOTICE.md 与仓库 THIRD_PARTY_NOTICES.md。

这个技能做什么

用户嘴上要的东西，和他真正要解决的问题，往往不是一回事。他说"做个数据看板"，只是因为"做个看板"是一个张口就来的说法，并不代表看板真能解决他的问题；他说"再优化一下"，却没有一个要达到的数字。

发现这个落差最便宜的时刻，是在任何方案、文档、代码动手之前。 一旦开工，返工成本是此刻的十倍，而用户会把做错的东西自我说服成"也能凑合用"——偏差就这样被锁死了。

本技能在成本为零的时刻，把"一句话委托"收敛成一份可逐条确认的需求说明：先写下你对需求的假设并诚实标注置信度，然后一次只问一个问题、每个问题都附上你的猜测答案，警惕"最佳实践"式的套话并追问"如果不用向任何人解释，你真正想要什么"，最后用固定 6 行结构把意图复述出来，拿到明确的"是"才算收敛。

典型适用场景（中文职场高频）：

• 产品需求梳理：老板一句"做个 XX 功能"，先把为谁、解决什么、成功标准问清楚再排期；
• 活动立项："办个用户活动"之前，先对齐目标人群、为什么现在办、成败怎么衡量；
• 跨部门任务交接：接兄弟部门甩来的需求，先把隐含假设摆到台面上再动手；
• 客户需求访谈：客户说"要个方案"，用带猜测答案的问题清单一次问清；
• 汇报前对齐：向上汇报前，把领导那句模糊指示复述成可确认的 6 行需求。

输入要求

• 必填：用户对需求的原始模糊描述（CLI 输入文件应包含的内容）——哪怕只是一句话转述，例如"领导说做个东西""客户要个方案""老板让我优化一下"。
• 可选：背景与已知信息（谁提的、手上已有什么、时间压力、试过什么）；--focus 指定重点澄清方向（如"重点帮我搞清楚成功标准和预算"）。
• 不要：替用户把没说的背景补全成事实。信息不足处一律标注"（待确认）"，猜测必须显式声明"这是猜测，请确认或修正"。

输出结构（模板见 scripts/templates/interview-me.template.md）

一份单轮收敛的需求澄清报告（CLI 无法真对话，故把访谈设计成"问题清单 + 猜测答案"，供用户逐条确认／修改），自上而下：

1. 需求原文与初步假设：先复述用户原话；再写下当前最佳理解（一两句话），每条假设后附诚实的置信度百分比；置信度低于 ~70% 时，同行写一句"还缺什么"。
2. 访谈问题清单（3–8 问）：按重要性排序，最重要排最前；一问一意图，绝不复合提问；每问格式为：
   • Q{n}：<一个聚焦的问题>
     • 猜测答案：<你的假设答案 + 得出它的理由>
     • （这是猜测，请确认或修正） 对"最佳实践／通用做法／应该会更 scalable"这类套话，必须补一道"如果不用向任何人解释，你真正想要什么"的追问。
3. 6 行需求复述：固定六行、不可省略，每行末尾带"（待确认）"标记——
   • Outcome（要达成什么结果）
   • User（谁受益／谁是使用者）
   • Why now（为什么是现在、什么变了）
   • Success（怎么算做成了，最好带可检验的标准）
   • Constraint（最硬的一条约束）
   • Out of scope（明确不做什么）——不可省略，一半的分歧来自"悄悄对不做什么有不同意见"
4. 待确认事项汇总与下一步：汇总上面所有（待确认）项；建议用户按 6 行复述逐条给出明确的"是／改／否"，确认后再进入设计或排期。

工作流程

1. 先假设、带数字（第 1 步）：开口问之前，先用一句话写下"我猜你要的是……"，再诚实给一个 0–100% 的置信度；给不出高置信度就别写高——你若答不出"接下来三个问题用户会怎么反应"，数字就是假的。低于 ~70% 必须附一行理由（还缺什么）。
2. 一次一问、附猜测答案（第 2 步）：每个问题只打一个意图，后面紧跟 GUESS（猜测答案 + 理由）。为什么不打包问：用户没法对着一长串清单逐题反应；第三题往往依赖第一题的答案，打包问会锁死错误框架；用户认真思考的精力有限，一次花在一道题上。为什么附猜测：人对"错误猜测"的反应，比对"从零想答案"快得多；也把你自己的假设暴露出来接受检验。
3. 警惕"想要 vs 应该想要"（第 3 步）：最危险的回答是"听起来很对"的那种——"要可扩展""干净架构""按行业通用做法"。听到这类，追问一句："如果这件事你不用向任何人解释、不用显得专业，你真正想要的是什么？" 这一句往往顶前面五句。
4. 6 行复述（第 4 步）：置信度上来后，用用户的语言把意图写成固定 6 行，结构到能逐行点头或逐行改。
5. 要明确的"是"（第 5 步）："你看着办吧""听起来不错""行吧那就开始"都不算确认——那是用户在放弃访谈，不是收敛。遇到就把复述改得更具体、二选一地再问一轮。
6. 收敛即停：当你能预测"接下来三个问题用户会怎么回答"，就停访谈、产出复述；CLI 单轮形态下，即以"问题清单 + 猜测 + 6 行待确认复述"作为交付，把球交回给用户逐条确认。

质量规则（必须遵守）

• 忠于原文：只基于用户给出的描述做推断，绝不编造用户没说的背景、人名、数据、预算；
• 猜测必须挂牌：所有猜测答案显式标注"（这是猜测，请确认／修正）"，不许把假设写成事实；
• 一问一意图：禁止复合问句（"说明一下排期和预算"必须拆成两问）；
• 数字要诚实：置信度百分比必须敢写低的；低于 ~70% 必须同行附"还缺什么"；
• 套话必追问：出现"最佳实践／可扩展／通用做法／应该"类答案，必须补"不向任何人解释你真正想要什么"一问；
• 6 行不省略：Outcome / User / Why now / Success / Constraint / Out of scope 六行缺一不可，Out of scope 尤其不许省；
• 信息不足标（待确认）：用户没说、也猜不准的地方，一律标"（待确认）"，不要填一个看似合理的默认值糊弄过去；
• 最重要排最前：问题按重要性降序排列，3–8 问，不堆长清单。

边界与异常处理

• 需求已经明确自足（"改个变量名""修个错别字"）→ 不需要本技能，直接做即可；
• 用户明确要求"别问了直接做"→ 尊重速度优先，但把关键假设一次性列出来让他过目；
• 信息实在太少（只有一句话、零背景）→ 照出假设与问题清单，把置信度压到 ~20–30%，并在报告开头说明"输入信息极少，以下假设均待确认"；
• 用户连续几轮后置信度仍不上升 → 说明问错了方向，退一步重构框架，不要硬问到底；
• 纯信息查询（"X 怎么用""这段代码干嘛的"）→ 不适用本技能；
• 涉外场景保留英文专有名词，问题正文用中文。

与脚本配合

• 批量 / 命令行场景：scripts/draft_interview_me.py（纯标准库，一条命令跑通）；输入为用户对需求的模糊描述文本（可附背景），输出为上述四节结构的需求澄清报告 Markdown。
• 可选 --focus：指定本次重点澄清方向（如"重点确认成功标准与预算约束"）。
• 自定义模板：复制 scripts/templates/interview-me.template.md 修改后使用。