教程概述
$deep-interview 是 oh-my-codex 的意图澄清技能，通过苏格拉底式追问帮助你将模糊需求转化为明确的技术目标。
你将学到
- ✅ $deep-interview 的工作原理
- ✅ 苏格拉底式追问的流程
- ✅ explore 预探索功能
- ✅ 意图澄清的核心原则
- ✅ 与 $plan 的衔接方法
触发方式标识
trigger_mode: "显式命令（$deep-interview）"
codex_native_alternative: "手动澄清对话"
superpowers_equivalent: "brainstorming 技能"
when_to_use_omx: "需求模糊、目标不明确时使用"
when_to_skip_omx: "需求清晰、可直接执行时"
为什么需要 $deep-interview？
模糊需求的代价
flowchart TD
A[模糊需求] --> B[开始实现]
B --> C[中途发现理解偏差]
C --> D[大量返工]
D --> E[交付延期]
E --> F[质量下降]
style A fill:#ffcccc
style C fill:#ffcccc
style D fill:#ffcccc
意图澄清的优势
flowchart TD
A[模糊需求] --> B[$deep-interview]
B --> C[明确目标]
C --> D[精准实现]
D --> E[一次到位]
E --> F[高质量交付]
style B fill:#e1f5ff
style C fill:#e1f5ff
$deep-interview 是什么？
$deep-interview 是 oh-my-codex 提供的意图澄清工作流，通过结构化的苏格拉底式追问，帮助你：
- 揭示隐含假设 - 挖掘需求背后的真实意图
- 明确边界范围 - 确定功能的包含与不包含
- 识别依赖关系 - 理清前置条件和外部依赖
- 量化验收标准 - 定义"完成"的具体指标
工作流程
flowchart LR
A[用户提出需求] --> B{是否清晰?}
B -->|否| C[$deep-interview]
C --> D[追问关键问题]
D --> E[补充缺失信息]
E --> F[明确目标]
F --> G[$plan 生成计划]
B -->|是| G
style C fill:#e3f2fd
style F fill:#e8f5e9
苏格拉底式追问流程
核心提问框架
$deep-interview 使用以下六个维度进行追问：
| 维度 | 核心问题 | 目的 |
|---|---|---|
| What | “这个功能具体是什么？” | 明确功能定义 |
| Why | “为什么需要这个功能？” | 理解业务价值 |
| Who | “谁会使用这个功能？” | 确定目标用户 |
| When | “什么时候需要完成？” | 明确时间约束 |
| Where | “这个功能部署在哪里？” | 确定运行环境 |
| How | “如何验证功能正确？” | 定义验收标准 |
追问示例
原始需求：“帮我优化网站性能”
$deep-interview 过程：
AI: "优化网站性能"这个目标比较宽泛。让我们澄清一下：
1. 你指的是前端性能（加载速度）还是后端性能（响应时间）？
→ 用户：前端性能，首屏加载太慢
2. 当前的首屏加载时间是多少？目标时间是多少？
→ 用户：现在 5 秒，希望优化到 2 秒以内
3. 主要是什么类型的网站？静态页面还是动态应用？
→ 用户：Next.js 电商网站
4. 目标用户的网络环境如何？需要支持低速网络吗？
→ 用户：主要是国内用户，需要支持 3G 网络
5. 你愿意接受哪些优化手段？代码分割、图片优化、CDN？
→ 用户：都可以，优先考虑成本效益最高的
澄清后的目标：
- 优化 Next.js 电商网站首屏加载时间从 5s 到 2s
- 支持 3G 网络环境
- 优先实施代码分割和图片优化
explore 预探索功能
在 $deep-interview 之前，可以使用 explore 命令对代码库进行预探索：
$explore "分析当前项目的性能瓶颈"
explore 会：
- 只读分析代码库
- 识别潜在问题区域
- 生成探索报告到
.omx/explore/
explore + deep-interview 组合
flowchart TD
A[模糊需求] --> B[$explore 预探索]
B --> C[生成探索报告]
C --> D[$deep-interview]
D --> E[基于事实的澄清]
E --> F[明确技术目标]
style B fill:#e3f2fd
style D fill:#e3f2fd
完整实战案例
场景：开发用户反馈系统
原始需求：
"帮我加个用户反馈功能"
步骤 1：运行 $deep-interview
$deep-interview "用户反馈功能"
AI 追问过程：
让我们澄清这个需求的细节：
Q1: 反馈表单需要收集哪些信息？
A: 用户姓名、邮箱、反馈类型、详细描述
Q2: 反馈类型有哪些选项？
A: Bug 报告、功能建议、使用问题、其他
Q3: 反馈提交后如何处理？
A: 发送到管理员邮箱，并存入数据库
Q4: 用户是否需要看到反馈状态？
A: 不需要，这是内部系统
Q5: 有文件上传需求吗？
A: 需要支持截图上传，最大 5MB
Q6: 需要防 spam 机制吗？
A: 需要，加验证码
Q7: 技术栈是什么？
A: Next.js + Prisma + PostgreSQL
澄清后的完整需求：
# 用户反馈系统需求
## 功能范围
- 反馈表单：姓名、邮箱、反馈类型、详细描述
- 反馈类型：Bug报告、功能建议、使用问题、其他
- 文件上传：截图，最大 5MB
- 防 spam：验证码验证
## 数据处理
- 存储：PostgreSQL 数据库
- 通知：发送邮件给管理员
- 状态：无需用户可见的状态跟踪
## 技术栈
- 前端：Next.js
- ORM：Prisma
- 数据库：PostgreSQL
- 文件存储：本地或云存储
步骤 2：衔接 $plan
$plan "实现用户反馈系统"
基于澄清后的需求，$plan 可以生成精准的 PRD。
核心原则
DO（推荐做法）
✅ 回答具体问题，补充上下文
✅ 提供可量化的指标
✅ 明确边界（哪些不做）
✅ 分享业务背景
✅ 承认不确定性
DON’T（避免做法）
❌ 用"你懂的"省略关键信息
❌ 给出无法验证的目标
❌ 隐瞒技术约束
❌ 假设 AI 知道你的业务背景
与 $plan 的衔接
flowchart LR
A[模糊需求] --> B[$deep-interview]
B --> C[明确需求文档]
C --> D[$plan 规划]
D --> E[生成 PRD]
E --> F[开始实现]
style B fill:#e3f2fd
style D fill:#e8f5e9
最佳实践：
- 复杂任务：必用 $deep-interview
- 简单任务：可直接 $plan
- 不确定时：先用 $deep-interview 澄清
反模式与常见错误
反模式 1：跳过澄清直接实现
❌ 错误：
用户："优化性能"
AI：直接开始改代码
✅ 正确：
用户："优化性能"
AI："让我们用 $deep-interview 澄清一下..."
反模式 2：回答过于笼统
❌ 错误回答：
Q: "目标用户是谁？"
A: "所有人"
✅ 正确回答：
Q: "目标用户是谁？"
A: "25-35 岁的电商卖家，主要用 Chrome 浏览器"
反模式 3：忽视验收标准
❌ 不完整的需求：
"实现用户注册"
✅ 完整的需求：
"实现用户注册，包含：
- 邮箱验证
- 密码强度检查（8位以上）
- 注册成功率 > 95%"
vs 原生 Codex
| 特性 | 原生 Codex | $deep-interview |
|---|---|---|
| 澄清方式 | 渐进式对话 | 结构化追问 |
| 信息收集 | 被动等待 | 主动挖掘 |
| 输出格式 | 自由文本 | 结构化需求文档 |
| 与后续衔接 | 需手动整理 | 直接衔接 $plan |
| 可追溯性 | 对话历史 | 生成需求文档 |
vs Superpowers
| 特性 | Superpowers brainstorming | $deep-interview |
|---|---|---|
| 触发方式 | 自动触发 | 显式命令 |
| 提问风格 | 引导式设计 | 苏格拉底式追问 |
| 输出物 | PRD 草案 | 需求澄清文档 |
| 使用时机 | 设计阶段 | 任何模糊需求 |
快速参考
命令速查
# 意图澄清
$deep-interview "你的模糊需求"
# 预探索
$explore "分析代码库"
# 澄清后规划
$plan "明确后的需求"
适用场景检查清单
- 需求包含"优化"、“改进"等模糊词汇
- 缺少具体数字指标
- 边界不明确
- 涉及多个系统/模块
- 用户角色不清晰
小结
$deep-interview 帮助你在动手之前确保需求清晰，是 oh-my-codex 工作流的第一道关卡。
核心要点：
- 模糊需求必用 $deep-interview
- 诚实回答追问，补充上下文
- 澄清后直接衔接 $plan
- 探索 + 澄清 + 规划 = 高质量交付
上一篇：教程 1：安装配置与快速入门