Tvs Deep Interview

SKILL.md

---
name: tvs-deep-interview
description: 深度需求访谈 Skill。通过苏格拉底式单问题追问、拓扑确认、歧义评分和显式审批闸门，把模糊想法整理成可验证规格。适用于用户说深度访谈、先问我、帮我梳理、不要假设、避免做错方向，或需求复杂到直接实现容易返工的场景。必须优先使用当前 Agent 工具自己的提问、选择、确认能力。
---

# 深度需求访谈

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

核心原则：

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

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

3. 用户确认后锁定拓扑：
   - 进行中：本轮要继续澄清的组件。
   - 已暂缓：用户明确暂缓的组件。
   - 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 拓扑确认。
- [ ] 每轮只问一个问题。
- [ ] 每轮都说明最弱组件/维度和提问原因。
- [ ] 棕地问题先收集代码证据，再向用户确认。
- [ ] 每轮都显示歧义评分。
- [ ] 多组件需求已轮换覆盖。
- [ ] 挑战模式按轮次使用，且每种最多一次。
- [ ] 规格包含目标、约束、非目标、验收标准、拓扑、关键实体和待确认问题。
- [ ] 规格为待审批状态。
- [ ] 未经用户明确批准，没有执行实现。