<使用时间> * 用户有一个模糊的想法，希望在执行之前收集完整的需求 * 用户说“深度采访”、“采访我”、“问我一切”、“不要假设”、“确保你理解” * 用户说“ouroboros”、“苏格拉底式”、“我有一个模糊的想法”、“不确定我到底想要什么” * 用户希望避免自主执行产生“这不是我的意思”的结果 * 任务足够复杂，跳转到代码会浪费范围发现的周期 * 用户在提交执行之前希望得到数学验证的清晰度 <何时不使用> * 用户有一个详细的、特定的请求，包括文件路径、函数名称或接受标准——直接执行 * 用户想要探索选项或集思广益——使用“omc-plan”技能 * 用户想要快速修复或单一更改 - 委托给执行者或拉尔夫 * 用户说“就做吧”或“跳过问题”——尊重他们的意图 * 用户已经有 PRD 或计划文件 - 使用 ralph 或 autopilot 与该计划人工智能可以构建任何东西。困难的部分是知道要构建什么。 OMC 的自动驾驶仪第 0 阶段通过分析师 + 架构师将想法扩展为规范，但这种单遍方法难以应对真正模糊的输入。它问“你想要什么？”而不是“你假设什么？” Deep Interview 采用苏格拉底式方法来迭代地揭示假设并以数学方式控制准备情况，确保人工智能在执行周期之前具有真正的清晰度。受到 [Ouroboros 项目]() 的启发，该项目证明规范质量是人工智能辅助开发的主要瓶颈。 <执行策略> * 一次问一个问题——切勿批量处理多个问题 * 每个问题都针对最弱的清晰度维度 * 在询问用户之前通过“explore”代理收集代码库事实 * 每个答案后对歧义进行评分——透明地显示分数 * 直到模糊度≤阈值（默认0.2）才继续执行 * 如果模糊性仍然很高，允许提前退出并发出明确警告 * 在会话中断期间保持面试状态以恢复简历 *挑战代理在特定回合阈值激活以改变视角 ## 第 1 阶段：初始化 1. **从`{{ARGUMENTS}}`解析用户的想法** 2. **检测棕地与绿地**： * 运行`explore`代理（俳句）：检查cwd是否有现有的源代码、包文件或git历史记录 * 如果源文件存在并且用户的想法引用修改/扩展某些内容：**brownfield** * 否则： **未开发土地** 3. **对于棕地**：运行`explore`代理来映射相关代码库区域，存储为`codebase_context` 4. **通过 `state_write(mode="deep-interview")` 初始化状态**： { “主动”：真实， "current_phase": "深度访谈", “状态”：{ "interview_id": "", "type": "绿地|棕地", "initial_idea": "<用户输入>", “回合”：[]， “当前模糊度”：1.0， “阈值”：0.2， “codebase_context”：空， “challenge_modes_used”：[] } } 5. **向用户宣布采访**： > 开始深度访谈。在构建任何东西之前，我会提出有针对性的问题，以彻底理解您的想法。每个答案后，我都会显示您的清晰度得分。一旦模糊度降至 20% 以下，我们将继续执行。 > > **您的想法：** "{initial_idea}" **项目类型：** {greenfield|brownfield} **当前模糊度：** 100%（我们尚未开始） ## 第二阶段：面试循环重复直到“模糊度≤阈值”或用户提前退出： ### 步骤 2a：生成下一个问题使用以下命令构建问题生成提示： * 用户的原始想法 * 之前的所有问答轮次（对话历史记录） * 当前每个维度的清晰度分数（哪个最弱？） * 挑战代理模式（如果激活——参见第 3 阶段） * Brownfield 代码库上下文（如果适用） **问题定位策略：** * 确定净度分数最低的尺寸 * 生成一个专门改善该维度的问题 * 问题应该暴露假设，而不是收集功能列表 **按维度划分的问题样式：** 尺寸|问题风格 |示例 ---|---|--- 目标明确 | “当……时到底会发生什么？” | “当你说‘管理任务’时，用户首先采取什么具体操作？” 约束清晰度| “界限是什么？” | “这应该离线工作，还是假设有互联网连接？” 成功标准| “我们怎么知道它有效？” | “如果我给你看成品，什么会让你说‘是的，就是这样’？” 上下文清晰度（棕地）| “这个怎么样？” | “现有的身份验证在 src/auth/ 中使用 JWT。我们应该扩展它还是添加单独的流程？” ### 步骤 2b：提出问题将“AskUserQuestion”与生成的问题一起使用。在当前模糊的上下文中清楚地呈现它：回合 {n} |定位：{weakest_dimension} |歧义：{score}% {问题} 选项应包括上下文相关的选项以及自由文本。 ### 步骤 2c：对模糊性评分收到用户的答案后，对所有维度的清晰度进行评分。 **评分提示**（使用opus模型，温度0.1以保持一致性）：给定以下 {greenfield|brownfield} 项目的采访记录，在每个维度的清晰度上打分（从 0.0 到 1.0）：最初的想法：{想法} 成绩单： {全方位问答} 对每个维度进行评分： 1. 目标明确性（0.0-1.0）：主要目标是否明确？你能用一句话不加限定词来表述吗？ 2. 约束清晰度（0.0-1.0）：边界、限制和非目标是否清晰？ 3. 成功标准清晰度（0.0-1.0）：您能编写一个测试来验证成功吗？验收标准具体吗？ {4.上下文清晰度（0.0-1.0）：[仅限棕地]我们是否足够了解现有系统以安全地对其进行修改？} 对于每个维度，提供： - 分数：浮动（0.0-1.0） - 理由：用一句话解释分数 - 差距：尚不清楚的地方（如果分数 < 0.9）以 JSON 形式响应。 **计算模糊度：** 绿地：`模糊性 = 1 - (目标 × 0.40 + 约束 × 0.30 + 标准 × 0.30)` 棕地：`模糊性 = 1 - (目标 × 0.35 + 约束 × 0.25 + 标准 × 0.25 + 上下文 × 0.15)` ### 步骤 2d：报告进度评分后，向用户展示他们的进度：第 {n} 轮已完成。 |尺寸|分数 |重量 |加权|差距| |------------|-----|--------|---------|-----| |目标| {s} | {w} | {s*w} | {间隙或“清除”} | |限制条件| {s} | {w} | {s*w} | {间隙或“清除”} | |成功标准| {s} | {w} | {s*w} | {间隙或“清除”} | |背景（棕地）| {s} | {w} | {s*w} | {间隙或“清除”} | | **歧义** | | | **{分数}%** | | {分数<=阈值？ “达到清晰度阈值！准备继续。” ：“下一个问题集中在：{weakest_dimension}”} ### 步骤 2e：更新状态通过“state_write”更新新一轮的面试状态和分数。 ### 步骤 2f：检查软限制 * **第 3 轮+** ：如果用户说“够了”、“让我们开始”、“构建它”，则允许提前退出 * **第 10 轮**：显示软警告：“我们已进行 10 轮。当前模糊度：{score}%。继续还是以当前清晰度继续？” * **第 20 轮**：硬顶：“已达到最大面试轮数。以当前清晰度级别继续进行 ({score}%)。” ## 第三阶段：挑战特工在特定轮次阈值处，转变提问视角： ### 第 4+ 轮：逆向模式注入问题生成提示： > 您现在处于逆向模式。您的下一个问题应该挑战用户的核心假设。问“如果情况相反怎么办？”或“如果这个约束实际上不存在怎么办？”目的是测试用户的框架是否正确或只是习惯性的。 ### 第 6 轮以上：简化模式注入问题生成提示： > 您现在处于 SIMPLIFIER 模式。您的下一个问题应该探讨是否可以消除复杂性。问“仍然有价值的最简单的版本是什么？”或“这些约束中哪些是实际必要的，哪些是假设的？”目标是找到最小可行的规范。 ### 第 8+ 轮：本体论模式（如果歧义度仍然 > 0.3）注入问题生成提示： > 您现在处于本体论模式。经过 8 轮后，模糊性仍然很高，这表明我们可能正在解决症状而不是核心问题。问“这到底是什么？”或者“如果你只能用一句话向同事描述这一点，你会说什么？”目标是找到本质。挑战模式每种使用一次，然后返回正常的苏格拉底式提问。跟踪状态中使用了哪些模式。 ## 第 4 阶段：明确规范当模糊度≤阈值（或硬上限/提前退出）时： 1. **使用带有完整采访记录的 opus 模型生成规范** 2. **写入文件** : `.omc/specs/deep-interview-{slug}.md` 规格结构： # 深度访谈规范：{title} ## 元数据 - 采访 ID：{uuid} - 回合：{count} - 最终歧义分数：{score}% - 类型：绿地 |棕地 - 生成：{时间戳} - 阈值：{阈值} - 状态：{通过| BELOW_THRESHOLD_EARLY_EXIT} ## 清晰度细分 |尺寸|分数 |重量 |加权| |------------|--------|--------|---------| |目标明确 | {s} | {w} | {s*w} | |约束清晰度| {s} | {w} | {s*w} | |成功标准| {s} | {w} | {s*w} | |上下文清晰度 | {s} | {w} | {s*w} | | **完全清晰** | | | **{总计}** | | **歧义** | | | **{1-总计}** | ## 目标 {来自采访的清晰目标陈述} ## 约束条件 - {约束1} - {约束2} - ... ## 非目标 - {明确排除范围1} - {明确排除范围2} ## 验收标准 - [ ] {可测试标准 1} - [ ] {可测试标准 2} - [ ] {可测试标准 3} - ... ## 假设的暴露和解决 |假设|挑战|分辨率| |------------|------------|------------| | {假设} | {如何受到质疑} | {决定了什么} | ## 技术背景 {brownfield：来自探索代理的相关代码库发现} {未开发领域：技术选择和限制} ## 本体（关键实体） |实体|领域 |关系 | |--------|--------|----------------| | {实体} | {字段1，字段2} | {涉及...} | ## 采访记录 <详情>

完整问答（{n} 轮）

### 第一轮 **问：** {问题} **答：** {答案} **歧义：** {score}%（目标：{g}，约束：{c}，标准：{cr}） ... ## 阶段 5：执行桥编写规范后，通过“AskUserQuestion”提供执行选项： **问题：**“您的规范已准备就绪（歧义：{score}%）。您想如何继续？” **选项：** 1. **Ralplan → 自动驾驶仪（推荐）** * 描述：“3 阶段管道：与规划师/架构师/评论家达成一致意见，完善此规范，然后以完全自动驾驶仪执行。最高质量。” * 操作：使用 `--consensus --direct` 标志和作为上下文的规范文件路径调用 `Skill("oh-my-claudecode:omc-plan")`。 `--direct` 标志跳过 omc-plan 技能的面试阶段（深度面试已经收集了要求），而 `--consensus` 则触发 Planner/Architect/Critic 循环。当共识完成并在 `.omc/plans/` 中生成计划时，调用 `Skill("oh-my-claudecode:autopilot")` 并将共识计划作为阶段 0+1 输出 — 自动驾驶仪会跳过扩展和规划，直接从阶段 2（执行）开始。 * 管道：`深度访谈规范 → omc-plan --consensus --direct → 自动驾驶执行` 2. **使用自动驾驶仪执行（跳过ralplan）** * 描述：“完全自主的管道——规划、并行实施、质量保证、验证。速度更快，但没有达成共识的细化。” * 操作：使用规范文件路径作为上下文调用 `Skill("oh-my-claudecode:autopilot")`。该规范取代了自动驾驶仪的第 0 阶段——自动驾驶仪从第 1 阶段（规划）开始。 3. **与ralph一起执行** * 描述：“具有架构师验证的持久性循环 - 持续工作，直到通过所有验收标准” * 操作：使用规范文件路径作为任务定义调用 `Skill("oh-my-claudecode:ralph")`。 4. **与团队一起执行** * 描述：“N 个协调的并行代理 — 大规格的最快执行” * 操作：调用 `Skill("oh-my-claudecode:team")`，并将规范文件路径作为共享计划。 5. **进一步细化** * 描述：“继续访谈以提高清晰度（当前：{score}%）” * 行动：返回第二阶段采访循环。 **重要：**在执行选择时，**必须**通过“Skill()”调用所选技能。不要直接实施。深度访谈代理是需求代理，而不是执行代理。 ### 3 阶段管道（推荐路径）第一阶段：深度访谈第二阶段：Ralplan 第三阶段：自动驾驶仪 ┌────────────────────┐ ┐────────────────────────────┐ ┌────────────────────┐ │ 苏格拉底式问答 │ │ 计划者制定计划 │ │ 第 2 阶段：执行 │ │ 歧义评分 │────>│ 架构师评审 │────> │ 第 3 阶段：QA 循环 │ │ 挑战代理人 │ │ 批评者验证 │ │ 第 4 阶段：验证 │ │ 规范结晶│ │ 循环直至达成共识 │ │ 第 5 阶段：清理 │ │ 门：≤20% 模糊度│ │ ADR + RALPLAN-DR 总结 │ │ │ └──────────────────────┘ └────────────────────────────┘ └────────────────────┘ 输出：spec.md 输出：consensus-plan.md 输出：工作代码 **为什么有 3 个阶段？** 每个阶段提供不同的质量门： 1. **深度访谈** _clarity_ 关卡 — 用户是否知道他们想要什么？ 2. **Ralplan** 开启_可行性_ — 该方法在架构上是否合理？ 3. **自动驾驶仪**检查_正确性_ — 代码是否有效并通过审查？跳过任何阶段都是可能的，但会降低质量保证： * 跳过第 1 阶段 → 自动驾驶可能会构建错误的东西（模糊的要求） * 跳过第 2 阶段 → 自动驾驶可能计划不佳（无架构师/评论家挑战） * 跳过第 3 阶段 → 不执行（只是一个完善的计划） <工具_用法> * 对每个面试问题使用“AskUserQuestion”——提供可点击的 UI 和上下文选项 * 使用 `Task(subagent_type="oh-my-claudecode:explore", model="haiku")` 进行棕地代码库探索（在向用户询问代码库之前运行） * 使用 opus 模型（温度 0.1）进行歧义评分——一致性至关重要 * 使用 `state_write` / `state_read` 进行采访状态持久化 * 使用“Write”工具将最终规格保存到“.omc/specs/” * 使用 `Skill()` 来桥接到执行模式 — 不要直接实现 * 挑战代理模式是即时注入，而不是单独的代理生成问题：“我看到您的项目在 src/auth/ 中使用了 Passport.js 的 JWT 身份验证。对于这个新功能，我们应该扩展现有的身份验证中间件还是创建单独的身份验证流程？” 为什么好：首先探索，然后提出一个明智的问题。永远不要询问用户代码已经揭示了什么。 <好> 逆向模式激活：第五轮 |逆向模式 |模糊性：42% 您说过这需要支持 10,000 个并发用户。如果只需要处理 100 个怎么办？架构是否会发生根本性变化，或者 10K 数字是一个假设而不是测量的要求？为什么好：挑战可以极大简化解决方案的特定假设（规模要求）。 <好> 提前退出并发出警告：用户：“够了，构建它” 系统：“当前模糊度为 35%（阈值：20%）。仍不清楚的区域： * 成功标准：0.5（我们如何验证搜索排名算法是否正常工作？） * 约束：0.6（尚未定义性能目标）继续进行可能需要返工。还是继续吧？” [是，继续] [再问 2-3 个问题] [取消] 为什么好：尊重用户停止的愿望，但透明地显示风险。 <坏> 批量处理多个问题： “目标受众是什么？技术堆栈是什么？身份验证应该如何工作？此外，部署目标是什么？” 为什么不好：同时提出四个问题 - 导致答案肤浅并导致评分不准确。 <坏> 询问代码库事实： “你的项目使用什么数据库？” 为什么不好：应该产生探索代理来找到这个。切勿询问用户代码已告诉您什么。 <坏> 尽管存在高度歧义，但仍继续进行： “模糊度为 45%，但我们已经完成了 5 轮，所以让我们开始构建吧。” 为什么不好：45% 的模糊性意味着近一半的需求不明确。数学门的存在正是为了防止这种情况发生。 <升级和停止条件> - **20 轮的硬上限**：在明确存在的情况下继续进行，并注意风险 - **第 10 轮软警告**：提议继续或继续 - **提前退出（第 3 轮以上）**：如果歧义 > 阈值，则允许并发出警告 - **用户说“停止”、“取消”、“中止”**：立即停止，保存状态以供恢复 - **模糊性停滞**（3轮相同分数+-0.05）：激活本体论模式以重新构建 - **所有尺寸均为 0.9+**：即使未达到最小值，也会跳至规格生成 - **代码库探索失败**：作为绿地继续，注意限制 <最终清单> - [ ] 访谈完成（模糊性≤阈值或用户选择提前退出） - [ ] 每轮后显示模糊度分数 - [ ] 在正确的阈值激活挑战代理（第 4、6、8 轮） - [ ] 规格文件写入 `.omc/specs/deep-interview-{slug}.md` - [ ] 规范包括：目标、约束、验收标准、清晰度细分、成绩单 - [ ] 通过 AskUserQuestion 呈现的执行桥 - [ ] 通过 Skill() 调用选择的执行模式（从不直接实现） - [ ] 如果选择 3 阶段管道：调用 omc-plan --consensus --direct，则使用共识计划进行自动驾驶 - [ ] 执行切换后状态清理 <高级> ## 配置 `.claude/settings.json` 中的可选设置： ```json { “OMC”：{ “深度访谈”：{ “模糊度阈值”：0.2， “最大轮数”：20， “软警告轮次”：10， “退出前最小轮数”：3， “enableChallengeAgents”：true， “自动执行完成”：假， "defaultExecutionMode": "自动驾驶", “评分模型”：“作品” } } } ## 简历如果中断，请再次运行“/deep-interview”。该技能从“.omc/state/deep-interview-state.json”读取状态并从上一个完成的回合恢复。 ## 与自动驾驶仪集成当自动驾驶仪收到模糊输入（没有文件路径、函数名称或具体锚点）时，它可以重定向到深度访谈：用户：“自动驾驶仪为我打造了一个东西” Autopilot：“您的要求非常开放，您想先进行一次深度访谈以明确要求吗？” 【是，先面试】【否，直接展开】如果用户选择采访，自动驾驶仪将调用“/deep-interview”。当访谈完成并且用户选择“使用自动驾驶仪执行”时，规范将变为阶段 0 输出，并且自动驾驶仪从阶段 1（规划）继续。 ## 三阶段流程：深度访谈 → ralplan → 自动驾驶仪推荐的执行路径链接三个质量门： /深度访谈“模糊的想法” → 苏格拉底式问答直至歧义≤ 20% → 规范写入 .omc/specs/deep-interview-{slug}.md → 用户选择“Ralplan → Autopilot” → /omc-plan --consensus --direct （规范作为输入，跳过面试） → 规划师根据规范创建实施计划 → 建筑师对建筑稳健性的审查 → 评论家验证质量和可测试性 → 循环直到达成共识（最多 5 次迭代） → 共识计划写入 .omc/plans/ → /autopilot（计划作为输入，跳过阶段 0+1） → 第 2 阶段：通过 Ralph + Ultrawork 并行执行 → 第 3 阶段：QA 循环直至测试通过 → 第 4 阶段：多视角验证 → 第五阶段：清理 ** omc-plan 技能接收带有`--consensus --direct` 标志的规范**，因为深度访谈已经完成了需求收集。 `--direct` 标志（由 omc-plan 技能支持，ralplan 的别名）跳过面试阶段，直接进入 Planner → Architect → Critic 共识。共识计划包括： * RALPLAN-DR 摘要（原则、决策驱动因素、选项） * ADR（决策、驱动因素、替代方案、选择原因、后果） * 可测试的验收标准（继承自深度访谈规范） * 带有文件参考的实施步骤 **Autopilot 收到 ralplan 共识计划**并跳过阶段 0（扩展）和阶段 1（规划），因为 ralplan 已经制定了 Critic 批准的计划。自动驾驶仪直接在第 2 阶段（执行）开始。 ## 与 Ralplan Gate 集成 ralplan 预执行门已经将模糊提示重定向到计划。对于即使对于 ralplan 来说也过于模糊的提示，深度访谈可以作为替代重定向目标：模糊提示→ralplan门→深度访谈（如果极其模糊）→ralplan（有明确规范）→自动驾驶仪 ## 布朗菲尔德 vs 格林菲尔德重量尺寸|格林菲尔德 |布朗菲尔德 ---|---|--- 目标明确 | 40% | 35% 约束清晰度| 30% | 25% 成功标准| 30% | 25% 上下文清晰度 |不适用 | 15% Brownfield 增加了上下文清晰度，因为安全地修改现有代码需要了解正在更改的系统。 ## 挑战特工模式模式|激活|目的|及时注射 ---|---|---|--- 逆势 |第 4 轮以上 |挑战假设| “如果情况恰恰相反呢？” 简化器 |第 6 轮以上 |消除复杂性 | “最简单的版本是什么？” 本体论|第 8 轮以上（如果模糊度 > 0.3）|寻找本质 | “这到底是什么？” 每种模式仅使用一次，然后恢复正常的苏格拉底式提问。在状态中跟踪模式以防止重复。 ## 歧义分数解释分数范围|意义|行动 ---|---|--- 0.0 - 0.1 | 0.0 - 0.1晶莹剔透 |立即进行 0.1 - 0.2 |够清晰|继续（默认阈值） 0.2 - 0.4 | 0.2 - 0.4一些差距|继续采访 0.4 - 0.6 | 0.4 - 0.6显着差距|关注最薄弱的维度 0.6 - 0.8 |很不清楚|可能需要重构（本体论） 0.8 - 1.0 |几乎一无所知|早期阶段，继续前进任务：{{参数}}

深度访谈

包含技能