deep-interview

star 688

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

entropy-cloud By entropy-cloud schedule Updated 3/5/2026

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") 探索现有代码库
  • 使用高质量模型进行模糊度评分(保持一致性)
Install via CLI
npx skills add https://github.com/entropy-cloud/nop-entropy --skill deep-interview
Repository Details
star Stars 688
call_split Forks 100
navigation Branch main
article Path SKILL.md
More from Creator
entropy-cloud
entropy-cloud Explore all skills →