深度需求访谈#

深度需求访谈用于把模糊想法整理成清晰、可验证、可执行的规格。

核心原则：

text

AI 可以构建很多东西，真正困难的是弄清楚到底该构建什么。

本 Skill 采用“深度访谈 -> 规格结晶 -> 待审批 -> 显式批准后执行”的闸门流程。访谈阶段只澄清需求和生成规格，不能直接修改代码、提交、推送、部署或委派实现。

适用与不适用#

当出现以下情况时使用：

• 用户只有一个模糊想法，需要先被访谈。
• 用户说“深度访谈”“问我问题”“先帮我梳理”“不要假设”。
• 用户希望避免“这不是我要的”式返工。
• 任务足够复杂，直接编码会把时间浪费在范围探索上。
• 用户希望在执行前获得清晰规格、验收标准和风险提示。

不适用场景：

• 用户已经给出文件路径、函数名、明确验收标准和执行意图。
• 用户只是要一个单点小修或明确改动。
• 用户只想头脑风暴多个方案，此时应走计划/架构分析，而不是访谈闸门。
• 用户已有 PRD 或计划文件，并明确要求执行它。

如果用户说“别问了，直接做”，但需求仍然模糊，应停止访谈并输出“待审批规格草案/风险说明”，不能直接变更代码。

提问工具适配#

必须优先使用当前 Agent 环境提供的原生提问工具。不要为了统一格式而放弃工具能力，也不要伪装自己使用了不存在的工具。

适配顺序：

1. 当前环境有结构化提问/确认工具时，优先调用该工具。
   • Cursor：优先使用 AskQuestion 收集单选、多选、确认类回答；开放文本问题可用普通聊天提问。
   • Claude Code 类工具：如果有 AskUserQuestion、计划确认、审批按钮或原生交互工具，优先使用这些能力。
   • Cline / Roo / Continue / 其他 IDE Agent：如果提供选择框、确认框、表单或审批面板，优先使用。
2. 当前环境没有结构化提问工具，但支持对话时，用“文本提问协议”。
3. 当前环境只支持终端或非交互输入时，也使用文本提问协议，并明确回复格式。

结构化工具使用规则：

• 每轮只能提出一个真正的问题。
• 选项必须与当前上下文相关，并允许“其他/补充”路径。
• 确认类问题必须提供“确认 / 调整 / 暂缓”这类选择。
• 如果工具不支持自由文本，问题正文里说明用户可在聊天里补充。

文本提问协议：

text

DEEP-INTERVIEW QUESTION
轮次：Round {n}
目标组件：{component}
本轮瞄准：{weakest_dimension}
为什么现在问这个：{one_sentence_reason}
当前歧义：{ambiguity_percent}%

问题：
{one_question}

回复格式：
{单选 / 多选 / 文本 / 确认 的明确说明}

核心规则#

• 一次只问一个关键问题，禁止批量提问。
• 每轮必须瞄准最弱清晰度维度。
• 问题要暴露假设，而不是收集功能清单。
• 棕地项目必须先读代码/搜索证据，再问用户确认；不要问代码已经能回答的问题。
• 每轮回答后都要重新评分，并透明展示分数。
• 多组件需求必须逐组件评分和轮换提问，不能因为一个组件清楚就忽略兄弟组件。
• 上下文过大时，先压缩成提示安全摘要，再进入评分、提问和规格生成。
• 歧义低于阈值且用户明确批准前，不得进入执行。
• 允许用户提前退出，但必须说明剩余歧义和返工风险。

初始化#

1. 解析用户初始想法。
2. 判断类型：
   • 绿地：新产品、新功能或没有明显现有代码依赖。
   • 棕地：要修改、扩展或接入现有项目。
3. 棕地项目先收集事实：
   • 当前工具能搜索/读取代码时，先查看目录、相关文件、配置、相似实现。
   • Cursor 可用时，优先用 rg、 ReadFile、 SemanticSearch 或 explore 子 Agent。
   • 其他 Agent 工具按自身能力使用搜索、文件读取、代码索引、MCP 或 IDE 上下文。
   • 没有代码访问能力时，明确说明限制并请用户提供片段。
4. 如果初始上下文很长，先生成提示安全摘要，保留目标、约束、已知决定、不确定点、文件/符号引用和明确非目标。
5. 设置默认阈值：
   • 标准模式：歧义 ≤ 20% 才可进入规格完成态。
   • 快速模式：歧义 ≤ 30%。
   • 深度模式：歧义 ≤ 10%。

启动时向用户说明：

text

开始深度需求访谈。我会一次只问一个问题，通过歧义评分判断需求是否足够清晰。
在歧义低于阈值并获得你明确批准前，我不会执行实现。

你的初始想法：{summary}
项目类型：绿地 / 棕地
当前歧义：100%

Round 0：拓扑确认#

Round 0 在任何歧义评分前执行一次。目标是锁定用户需求的“形状”，避免后续访谈只围绕描述最多的部分钻深，而漏掉其他独立结果。

1. 从初始想法和棕地证据中枚举顶层组件：
   • 顶层组件可以是独立成功/失败的工作流、界面、集成、能力或交付物。
   • 优先 1 到 6 个。超过 6 个时合并同类项并说明原因。
   • 不要把字段、按钮、实现步骤当成顶层组件，除非用户明确把它们作为独立结果。
2. 用当前工具的提问能力询问用户确认：

text

Round 0 | 拓扑确认 | 暂不评分

我把这个需求理解为 {N} 个顶层组件：
1. {component}: {one_sentence_description}
2. ...

这个拓扑对吗？需要新增、删除、合并、拆分或暂缓哪个组件吗？

1. 用户确认后锁定拓扑：
   • 进行中：本轮要继续澄清的组件。
   • 已暂缓：用户明确暂缓的组件。
   • evidence：初始提示词或代码证据来源。

访谈循环#

重复执行，直到歧义低于阈值，或用户选择提前退出。

生成下一问#

构造问题时使用：

• 初始想法或提示安全摘要。
• 已锁定拓扑。
• 过往 Q&A 的精简摘要。
• 每个进行中组件的当前分数和缺口。
• 棕地代码证据，必须压缩为路径、符号、模式，不要倾倒大段源码。
• 已使用的挑战模式。

提问策略：

• 找出“进行中组件 + 清晰度维度”中最低分的一项。
• 多个组件同样薄弱时轮换组件，避免一直追问同一组件。
• 先用一句话说明为什么这项是当前瓶颈。
• 问题必须针对该组件和该维度。
• 如果核心名词在变化，优先问本体问题：“这个东西到底是什么？”

问题类型参考：

维度问法示例目标清晰度到底要发生什么“当你说管理任务时，用户第一步具体做什么？”约束清晰度边界是什么“这必须离线可用，还是默认联网？”成功标准如何证明完成“如果我给你看成品，什么结果会让你说这就是我要的？”上下文清晰度如何接入现有系统“我看到现有鉴权在 src/auth/，这次要扩展它还是刻意另建一套？”本体稳定性核心概念是什么“你前面提到工作流、收件箱、计划器，哪个才是核心实体？”

提问#

使用当前环境自己的提问工具。呈现内容必须包含：

text

Round {n} | 组件：{target_component} | 瞄准：{weakest_dimension} | 歧义：{ambiguity}%

为什么问这个：{reason}

{one_question}

歧义评分#

用户回答后，对每个进行中组件分别评分，再汇总整体歧义。

维度分数：0.0 到 1.0。

• 目标清晰度：目标能否一句话说清，关键实体和动作是否稳定。
• 约束清晰度：边界、非目标、限制、依赖是否清楚。
• 成功标准清晰度：能否写出可验证的验收条件。
• 上下文清晰度：仅棕地项目使用，是否理解现有系统到足以安全修改。

计算公式：

text

绿地歧义 = 1 - (目标 * 0.40 + 约束 * 0.30 + 成功标准 * 0.30)
棕地歧义 = 1 - (目标 * 0.35 + 约束 * 0.25 + 成功标准 * 0.25 + 上下文 * 0.15)

评分输出必须包含：

• 每个维度的分数、理由和缺口。
• 当前最弱组件。
• 当前最弱维度。
• 下一轮为何应该瞄准它。
• 如果多组件并行，说明轮换逻辑。

本体稳定性#

每轮提取关键实体：

• name：实体名。
• type：核心领域 / 支撑对象 / 外部系统 / 视图或容器。
• fields：已明确的关键属性。
• relationships：实体关系。

从第二轮开始比较上一轮：

• stable：名称和概念都稳定。
• changed：名称变化但类型和字段高度重合，视为同一概念重命名。
• new：新出现实体。
• removed：消失实体。
• stability_ratio = (stable + changed) / 当前实体总数。

如果核心实体持续变化，应优先进入本体式提问，不要继续追功能细节。

进度报告#

每轮回答后向用户报告：

text

Round {n} 完成

清晰度：
- 目标：{score}，缺口：{gap}
- 约束：{score}，缺口：{gap}
- 成功标准：{score}，缺口：{gap}
- 上下文：{score}，缺口：{gap}

当前歧义：{ambiguity}%
拓扑：当前瞄准 {component}；进行中 {count}；已暂缓 {count}
本体：{entity_count} 个实体；稳定率 {stability_ratio}
下一轮目标：{component} / {dimension}，原因：{reason}

软限制#

• 第 3 轮后，如果用户说“够了”“就这样”，允许提前退出，但必须展示剩余歧义和风险。
• 第 10 轮给软提醒：继续访谈、生成当前规格，还是暂缓。
• 第 20 轮硬上限：停止继续追问，生成当前清晰度规格并标记风险。
• 若连续 3 轮歧义变化小于 5%，进入本体模式重新确认核心概念。

挑战模式#

挑战模式是提问视角切换，不是另起实现 Agent。

• Round 4+：反方模式。挑战核心假设，例如“如果这个约束不存在，会怎样？”
• Round 6+：简化模式。追问最小可用版本，例如“保留价值所需的最小版本是什么？”
• Round 8+ 且歧义仍高于 30%：本体模式。追问“这到底是什么？哪个实体是核心？”

每个模式只使用一次，使用后回到正常苏格拉底式提问。

规格结晶#

当歧义低于阈值，或用户选择提前退出/达到硬上限时，生成规格。

不要直接实现。规格状态必须是“待审批”。

规格结构：

markdown

# 深度访谈规格：{title}

## 元信息
- 轮次：{round_count}
- 项目类型：绿地 / 棕地
- 最终歧义：{ambiguity}%
- 阈值：{threshold}%
- 状态：通过阈值 / 提前退出 / 达到轮次上限

## 清晰度拆解
| 维度 | 分数 | 权重 | 加权 |
|---|---:|---:|---:|
| 目标 | {score} | {weight} | {weighted} |
| 约束 | {score} | {weight} | {weighted} |
| 成功标准 | {score} | {weight} | {weighted} |
| 上下文 | {score} | {weight} | {weighted} |

## 拓扑
| 组件 | 状态 | 描述 | 覆盖/暂缓说明 |
|---|---|---|---|
| {component} | 进行中/已暂缓 | {description} | {coverage_or_deferral} |

## 目标
{覆盖所有进行中组件的清晰目标陈述}

## 约束
- {constraint}

## 非目标
- {non_goal}

## 验收标准
- [ ] {testable_criterion}

## 已暴露并解决的假设
| 假设 | 如何追问 | 结论 |
|---|---|---|
| {assumption} | {challenge} | {resolution} |

## 技术/项目上下文
{棕地项目写代码证据；绿地项目写技术选择和约束}

## 关键实体
| 实体 | 类型 | 字段 | 关系 |
|---|---|---|---|
| {entity} | {type} | {fields} | {relationships} |

## 本体收敛
说明实体如何在各轮中稳定下来。

## 待确认问题
- {open_question}

## 访谈记录
折叠或摘要列出每轮 Q/A、歧义和关键决定。

如果当前工具允许写文件，并且项目允许保存规划文档，可以写入合适的规格路径；否则直接在对话中输出规格。不要把规格写到随机业务目录。

执行桥接#

规格完成后，必须询问用户下一步。优先使用当前工具的原生确认/选择能力。

可选项：

1. 继续完善规格。
2. 进入计划/架构评审。
3. 明确批准执行。
4. 暂停，保留规格。

在用户明确选择执行前，禁止：

• 修改源码。
• 运行会改变项目状态的命令。
• 提交、推送、发 PR。
• 调用执行型 Agent 或实现型 Skill。

如果用户批准执行，把规格作为上下文交给当前工具合适的执行流程。不要由深度访谈 Skill 自己直接实现。

好例子#

瞄准最弱维度：

text

分数：目标 0.9，约束 0.4，成功标准 0.7
下一问瞄准约束，因为它是最低分：
“你说要支持移动端，这指响应式 Web、PWA，还是原生 App？是否有必须支持的设备或系统版本？”

先读代码再问：

text

我看到现有鉴权集中在 `src/auth/`，使用 JWT 中间件。这个新能力应该扩展现有鉴权路径，还是需要刻意独立出来？

反方模式：

text

你提到必须支撑 1 万并发。假设第一版只需要 100 并发，架构会完全不同吗？这个数字是测量结果还是预设假设？

坏例子#

批量提问：

text

目标用户是谁？技术栈是什么？鉴权怎么做？部署在哪？

为什么坏：四个问题一起问，会得到浅答案，无法准确评分。

问代码已经能回答的问题：

text

你的项目用什么数据库？

为什么坏：如果当前工具能读代码，应先自己查证。

高歧义直接执行：

text

歧义还有 45%，但已经问了 5 轮，开始写代码吧。

为什么坏：歧义闸门就是为了防止这种返工。

完成检查清单#

• 已完成 Round 0 拓扑确认。
• 每轮只问一个问题。
• 每轮都说明最弱组件/维度和提问原因。
• 棕地问题先收集代码证据，再向用户确认。
• 每轮都显示歧义评分。
• 多组件需求已轮换覆盖。
• 挑战模式按轮次使用，且每种最多一次。
• 规格包含目标、约束、非目标、验收标准、拓扑、关键实体和待确认问题。
• 规格为待审批状态。
• 未经用户明确批准，没有执行实现。