---
name: deep-interview
description: 苏格拉底式深度访谈，用数学化的模糊度评分来澄清需求。适用于模糊的想法、不确定的需求、需要暴露隐藏假设的场景。触发词："deep interview"、"深度访谈"、"需求澄清"、"帮我理清思路"、"不知道要做什么"。
---

# 这个 skill 的定位

本 skill 的核心目标是**在写代码之前**，通过苏格拉底式提问帮助用户澄清模糊的需求和想法。

**核心原则**：
- AI 能构建任何东西，难的是知道要构建什么
- 宁可花时间澄清需求，也不要返工
- 用数学化的模糊度评分，确保真正理解了需求

---

## 什么时候用我

当你的需求涉及以下场景时，请**加载此 skill**：

| 场景 | 触发关键词 | 示例 |
|------|-----------|------|
| 模糊的想法 | "我有个想法"、"想做xxx" | "我想做一个任务管理应用" |
| 不确定的需求 | "不太确定"、"可能需要" | "需要一个API，但不确定具体功能" |
| 需要暴露假设 | "不要假设"、"确保理解" | "别假设，问清楚再开始" |
| 避免返工 | "不想做错"、"先理清" | "帮我理清思路，避免做错" |
| 复杂到不能直接动手 | 复杂任务、多模块 | "重构整个认证系统" |

---

## 什么时候不要用我

| 场景 | 原因 | 替代方案 |
|------|------|---------|
| 明确的文件/函数修改 | 需求清晰，直接执行 | 直接开始实现 |
| 快速小改动 | 单一明确任务 | 直接执行 |
| 用户说"直接做" | 尊重用户意愿 | 直接执行 |
| 已有详细规格文档 | 需求已清晰 | 基于文档执行 |

---

## 核心机制：模糊度评分

### 评分维度

通过迭代提问，对每个维度进行评分（0.0 - 1.0）：

| 维度 | 权重（新项目） | 权重（现有项目） | 评分标准 |
|------|--------------|----------------|---------|
| **目标清晰度** (Goal Clarity) | 40% | 35% | 能否一句话说清目标？ |
| **约束清晰度** (Constraint Clarity) | 30% | 25% | 边界、限制、非目标是否明确？ |
| **成功标准** (Success Criteria) | 30% | 25% | 能否写出可测试的验收标准？ |
| **上下文清晰度** (Context Clarity) | N/A | 15% | 是否理解现有系统？ |

### 模糊度计算

```
新项目: ambiguity = 1 - (目标×0.40 + 约束×0.30 + 成功标准×0.30)
现有项目: ambiguity = 1 - (目标×0.35 + 约束×0.25 + 成功标准×0.25 + 上下文×0.15)
```

**目标**：模糊度 ≤ 20% 才进入执行阶段

---

## 处理流程

### Phase 1: 初始化

1. **解析用户的想法** 从输入中提取初始需求
2. **判断项目类型**：
   - 检查当前目录是否有源代码、配置文件、git 历史
   - 有源代码 + 用户提到修改/扩展 → **现有项目 (Brownfield)**
   - 否则 → **新项目 (Greenfield)**
3. **对于现有项目**：使用 `explore` agent 探索相关代码区域
4. **宣布访谈开始**：

```
> 开始深度访谈。我会通过针对性提问来彻底理解你的想法。
> 每次回答后，我会展示你的清晰度评分。
> 当模糊度降到 20% 以下时，我们就可以开始执行了。
>
> **你的想法**: "{初始想法}"
> **项目类型**: {新项目|现有项目}
> **当前模糊度**: 100%（还没开始）
```

### Phase 2: 访谈循环

重复直到 `模糊度 ≤ 20%` 或用户选择提前退出：

#### Step 2a: 生成下一个问题

**问题目标策略**：
- 找出**评分最低**的维度
- 针对该维度生成问题
- 问题应该**暴露假设**，而不是收集功能列表

**各维度问题风格**：

| 维度 | 问题风格 | 示例 |
|------|---------|------|
| 目标清晰度 | "具体来说，当...时会发生什么？" | "你说'管理任务'，用户第一个具体操作是什么？" |
| 约束清晰度 | "边界在哪里？" | "这个需要离线工作吗？还是假设有网络？" |
| 成功标准 | "怎么知道它工作了？" | "如果我给你看完成的产品，什么会让你说'对，就是这个'？" |
| 上下文清晰度 | "这怎么融入现有系统？" | "现有认证用的是 JWT，我们应该扩展它还是新建一个流程？" |

#### Step 2b: 提出问题

每次只问**一个问题**，不要批量提问。格式：

```
Round {n} | 针对: {最弱维度} | 模糊度: {score}%

{问题}

选项：
1. {选项A}
2. {选项B}
3. 其他（自由输入）
```

使用 `question` 工具让用户选择。

#### Step 2c: 评分

收到用户回答后，对每个维度评分：

```
评分提示词（使用高质量模型，temperature 0.1）：

根据以下访谈记录，对每个维度评分（0.0-1.0）：

原始想法: {idea}

访谈记录:
{所有轮次的Q&A}

评分维度：
1. 目标清晰度 (0.0-1.0): 主要目标是否明确？能否一句话说清且无歧义？
2. 约束清晰度 (0.0-1.0): 边界、限制、非目标是否清晰？
3. 成功标准清晰度 (0.0-1.0): 能否写出测试来验证成功？验收标准是否具体？
4. 上下文清晰度 (0.0-1.0) [仅现有项目]: 是否充分理解现有系统以便安全修改？

对每个维度提供：
- score: float (0.0-1.0)
- justification: 一句话解释评分
- gap: 还有什么不清楚（如果 score < 0.9）

以 JSON 格式回复。
```

#### Step 2d: 展示进度

```
Round {n} 完成。

| 维度 | 评分 | 权重 | 加权分 | 差距 |
|------|------|------|--------|------|
| 目标 | {s} | {w} | {s*w} | {gap 或 "清晰"} |
| 约束 | {s} | {w} | {s*w} | {gap 或 "清晰"} |
| 成功标准 | {s} | {w} | {s*w} | {gap 或 "清晰"} |
| 上下文（现有项目）| {s} | {w} | {s*w} | {gap 或 "清晰"} |
| **模糊度** | | | **{score}%** | |

{score <= 20% ? "清晰度达标！可以开始执行。" : "下一问题针对: {最弱维度}"}
```

### Phase 3: 挑战模式

在特定轮次，转换提问视角：

| 模式 | 激活时机 | 目的 | 示例问题 |
|------|---------|------|---------|
| **反驳者** (Contrarian) | Round 4+ | 挑战核心假设 | "如果相反的情况是真的呢？这个约束真的存在吗？" |
| **简化者** (Simplifier) | Round 6+ | 去除不必要复杂度 | "最简单的可用版本是什么？哪些约束其实是假设？" |
| **本质论者** (Ontologist) | Round 8+ (模糊度>30%) | 重新定义问题本质 | "这到底是什么？用一句话向同事描述会怎么说？" |

每种模式只使用一次，然后恢复正常苏格拉底式提问。

### Phase 4: 结晶规格

当模糊度 ≤ 20%（或用户选择提前退出）：

1. **生成规格文档**
2. **输出到聊天**（不需要写文件）

规格结构：

```markdown
# 需求规格: {标题}

## 元信息
- 访谈轮次: {count}
- 最终模糊度: {score}%
- 项目类型: 新项目 | 现有项目
- 状态: {通过 | 提前退出}

## 清晰度分解
| 维度 | 评分 | 权重 | 加权分 |
|------|------|------|--------|
| 目标清晰度 | {s} | {w} | {s*w} |
| 约束清晰度 | {s} | {w} | {s*w} |
| 成功标准 | {s} | {w} | {s*w} |
| **总清晰度** | | | **{total}** |
| **模糊度** | | | **{1-total}** |

## 目标
{从访谈中得出的清晰目标陈述}

## 约束
- {约束 1}
- {约束 2}
- ...

## 非目标
- {明确排除的范围 1}
- {明确排除的范围 2}

## 验收标准
- [ ] {可测试的标准 1}
- [ ] {可测试的标准 2}
- [ ] {可测试的标准 3}
- ...

## 暴露的假设
| 假设 | 挑战 | 决定 |
|------|------|------|
| {假设} | {如何被质疑} | {最终决定} |

## 技术上下文
{现有项目: 相关代码发现}
{新项目: 技术选择和约束}

## 核心实体
| 实体 | 字段 | 关系 |
|------|------|------|
| {实体} | {字段1, 字段2} | {关联到...} |

## 访谈记录
<details>
<summary>完整Q&A ({n} 轮)</summary>

### Round 1
**Q:** {问题}
**A:** {回答}
**模糊度:** {score}%

...
</details>
```

### Phase 5: 执行选择

规格生成后，询问用户如何继续：

```
你的需求规格已准备好（模糊度: {score}%）。你想如何继续？

1. **开始实现** - 基于规格直接开始编码
2. **先做技术设计** - 先输出技术设计方案，再实现
3. **继续澄清** - 继续访谈以进一步降低模糊度（当前: {score}%）
4. **保存规格** - 将规格保存到文件，稍后再处理
```

---

## 规则

### 必须做 (MUST)

- [ ] 每次只问一个问题，绝不批量提问
- [ ] 针对评分最低的维度提问
- [ ] 在问用户之前，先用 `explore` agent 探索代码库
- [ ] 每次回答后都展示模糊度评分
- [ ] 模糊度 ≤ 20% 才建议进入执行
- [ ] 允许提前退出但要展示风险

### 绝不能做 (MUST NOT)

- [ ] 一次问多个问题
- [ ] 问代码库中已有的信息（应该先探索）
- [ ] 模糊度还很高时就进入执行
- [ ] 猜测答案而不是询问用户

---

## 软限制

- **Round 3+**: 允许用户说"够了"、"开始吧"、"直接做"来提前退出
- **Round 10**: 软警告："已经10轮了，当前模糊度: {score}%。继续还是用当前清晰度开始？"
- **Round 20**: 硬上限："达到最大访谈轮数。用当前清晰度继续（{score}%）。"

---

## 示例

### 好的示例

**针对最弱维度**：
```
评分: 目标=0.9, 约束=0.4, 成功标准=0.7
下一问题针对约束（最低 0.4）:

"你提到这个需要'在移动端工作'。这意味着原生App、
响应式网页、还是PWA？需要支持哪些具体的设备或系统版本？"
```

**先探索再问**：
```
[启动 explore agent: "查找认证实现"]
[收到: "认证在 src/auth/ 使用 JWT 和 passport.js"]

问题: "我看到项目使用 JWT 认证和 passport.js 在 src/auth/。
对于这个新功能，我们应该扩展现有认证中间件还是
创建一个单独的认证流程？"
```

**挑战模式**：
```
Round 5 | 反驳者模式 | 模糊度: 42%

你说这需要支持10,000并发用户。如果只需要处理100个呢？
架构会有根本变化吗，还是这个10K数字只是一个假设
而不是实测的需求？
```

### 坏的示例

**批量提问**：
```
"目标用户是谁？用什么技术栈？认证怎么处理？
还有，部署目标是什么？"
```
→ 错误：四个问题同时问，导致浅层回答

**问代码库已有的信息**：
```
"你的项目用什么数据库？"
```
→ 错误：应该先用 explore agent 查找

**模糊度高时继续执行**：
```
"模糊度45%但已经5轮了，开始做吧。"
```
→ 错误：45%意味着近一半需求不清晰

---

## 模糊度解读

| 范围 | 含义 | 行动 |
|------|------|------|
| 0-10% | 水晶般清晰 | 立即执行 |
| 10-20% | 足够清晰 | 执行（默认阈值）|
| 20-40% | 有一些差距 | 继续访谈 |
| 40-60% | 显著差距 | 聚焦最弱维度 |
| 60-80% | 非常不清晰 | 可能需要重构问题（本质论者模式）|
| 80-100% | 几乎一无所知 | 早期阶段，继续 |

---

## 与其他 skill 的配合

- **澄清需求后** → 可以调用 `nop-orm-modeler` 生成 ORM 模型
- **澄清需求后** → 可以调用 `nop-codegen-master` 生成项目脚手架
- **技术设计** → 可以在澄清后做详细的技术设计

---

## 工具使用

- 使用 `question` 工具进行用户问答
- 使用 `task(subagent_type="explore")` 探索现有代码库
- 使用高质量模型进行模糊度评分（保持一致性）