Generate, validate, and modify Nop ORM models from MySQL DDL/SQL or business requirements. Covers entity modeling, relationships, domains, dictionaries, displayName localization, and ORM file organization (Delta mode). Use for database-first or requirements-first ORM development.

2026-02-22688

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)

每次只问一个问题，绝不批量提问
针对评分最低的维度提问
在问用户之前，先用 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") 探索现有代码库
使用高质量模型进行模糊度评分（保持一致性）