| 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: 初始化
- 解析用户的想法 从输入中提取初始需求
- 判断项目类型：
- 检查当前目录是否有源代码、配置文件、git 历史
- 有源代码 + 用户提到修改/扩展 → 现有项目 (Brownfield)
- 否则 → 新项目 (Greenfield)
- 对于现有项目：使用
explore agent 探索相关代码区域
- 宣布访谈开始：
> 开始深度访谈。我会通过针对性提问来彻底理解你的想法。
> 每次回答后，我会展示你的清晰度评分。
> 当模糊度降到 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%（或用户选择提前退出）：
- 生成规格文档
- 输出到聊天（不需要写文件）
规格结构：
# 需求规格: {标题}
## 元信息
- 访谈轮次: {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)
绝不能做 (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") 探索现有代码库
- 使用高质量模型进行模糊度评分（保持一致性）
