deep-interview

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. 输出到聊天（不需要写文件）

规格结构：

# 需求规格: {标题}

## 元信息

- 访谈轮次: {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") 探索现有代码库
• 使用高质量模型进行模糊度评分（保持一致性）