OmX Deep-interview Phase 1 验证解析四个压力轴如何在不破坏 OMX 不变式的前提下强化苏格拉底式提问【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex导读本文围绕 OmXOh My codeX中deep-interview技能在 Phase 1 提问强化questioning-strengthening pass后的手动 transcript 式验证展开逐场景复现一个绿色地 CLI 需求、一个棕色地 auth 改动、一个模糊工作流请求三类真实输入下的完整提问流程并逐一核对问题数量压力、深度压力、假设探测、追问压力这四个验证轴是否达标。读完本文你将掌握 deep-interview 技能验证契约的判定方法、三类场景下的预期对话走向以及这些契约在 skills/deep-interview/SKILL.md 与 src/config/deep-interview.ts 等源码中的落地证据可直接用于复现该验证或编写同类技能契约。一、为什么需要一次transcript 式验证deep-interview本质上是指令面instruction surface而非编译型运行时它不执行任何计算逻辑而是通过 skills/deep-interview/SKILL.md 中约 540 行的指令契约约束模型在规划与实现之前完成意图优先的苏格拉底式澄清循环。正因为没有可运行的二进制确定性契约测试deterministic contract tests无法完全证明提问是否真的更有压力——它只能证明文档中写了某些规则。因此 docs/qa/deep-interview-phase-1-validation.md 采用了一条互补的验证路径手工构造代表性 prompt走完整条预期提问流程再逐轴判定压力是否到位。这条验证通道与确定性测试各司其职确定性测试锁定契约文本存在性例如 src/hooks/tests/deep-interview-contract.test.ts 断言 SKILL.md 必须包含Greenfield:ambiguity 公式、Decision Boundaries、Contrarian/Simplifier/Ontologist挑战模式、answers[]主契约、.omx/interviews/与.omx/specs/ 产物路径等文本要素transcript 式验证证明对话行为确实变强即便公式与关键词都在仍可能出现问满 5 轮但全是泛泛之问的假性达标这正是本次 Phase 1 强化要杜绝的。二、验证焦点四个压力轴与五条保留不变式验证围绕四个必须被加大的压力轴展开它们同时也是后续每个场景的 PASS 判据问题数量压力question count pressure——不得在澄清充分前过早结晶crystallize深度压力depth pressure——追问必须触及底层假设与根因而非停留在功能表层假设探测assumption probing——用户回答中未经证实的假设要被直接挑战追问压力follow-up pressure——每个答案都必须被收紧为下一个更窄、更聚焦的问题而不是提前总结收尾。同时复检以下被保留的 OMX 不变式歧义门槛ambiguity gating仍存在于技能契约中readiness gates 仍强制要求显式的Non-goals与Decision Boundaries上下文快照 / transcript / spec 三类产物仍然存在.omx/context/、.omx/interviews/、.omx/specs/执行交接契约仍然存在$ralplan、$autopilot、$ralph、$team、Refine further棕色地确认brownfield confirmation仍必须引用已发现的证据。三、场景一绿色地 CLIgreenfieldPromptI want to build a task management CLI.Phase 1 预期流程强化后Round 1Assistant 询问用户为什么需要这个 CLI以及当前工作流中的哪个失败点触发了这个需求Round 2用户回答我总是在多个仓库间忘记临时任务Assistant顺着同一条缝追问是什么假设让 CLI 比日历/提醒流程更好Round 3用户回答我需要仓库本地上下文和快速记录Assistant 追问第一版应该显式排除哪些内容Round 4用户回答不要同步、不要多用户、不要 GUIAssistant 追问如果快速记录与严格任务结构冲突哪个取舍不可接受。PASS 判据问题数量压力PASS—— 第 4 轮之前没有结晶深度压力PASS—— 第 2 轮冲击的是底层假设而非仅仅列举功能假设探测PASS—— CLI 优于提醒这一假设被立即挑战追问压力PASS—— 第二个问题停留在新出现的线索上而不是提前总结。这个场景完整演示了 SKILL.md 中intent-first的阶段优先级Stage 1 先澄清 Intent/Outcome/Scope/Non-goals/Decision Boundaries再进入可行性以及stay on the same thread原则——四轮全部围绕意图-假设-边界一条线收紧而非为了覆盖面轮换维度。四、场景二棕色地 auth 改动brownfieldPromptI need to change auth in this brownfield app.Phase 1 预期流程强化后PreflightAssistant先收集代码库证据Round 1Assistant 提出一个基于证据的确认问题例如I found token-refresh handling insrc/auth/session.ts. Should this change follow that pattern or replace it?Round 2用户回答替换它因为刷新循环掩盖了真正的失败Assistant 追问什么证据表明这个循环是根因而不是症状Round 3用户回答刷新重试掩盖了上游 401 抖动Assistant 追问如果修复需要同时触及中间件与会话存储OMX 可以在不确认的情况下自行决定哪些决策边界Round 4用户回答所有权边界Assistant 追问哪些 auth 行为必须显式排除在范围之外。PASS 判据问题数量压力PASS—— 初始棕色地确认之后访谈仍在继续施压深度压力PASS—— 第 2 轮强制要求根因证据而非接受替换这一主张假设探测PASS—— 未经支持的棕色地主张被直接挑战追问压力PASS—— 每个答案都会生成一个更窄的下一个问题然后才继续棕色地不变式PASS—— 提问始终基于证据而非抽象空谈。这里的evidence-backed confirmation是深访契约的核心特征之一且被强制执行——skills/deep-interview/SKILL.md 的 Execution Policy 明确要求Gather codebase facts viaexplorebefore asking user about internals并对棕色地优先采用I found X in Y. Should this change follow that pattern?形式的确认问句同时要求[from-code][auto-confirmed]只允许自动确认描述性事实任何蕴含应该怎么做/跟随哪个模式/接受哪个取舍的决策性问题都必须以[from-user]路由回用户。五、场景三模糊工作流请求ambiguousPromptImprove onboarding for first-time contributors.Phase 1 预期流程强化后Round 1Assistant 询问是什么具体的贡献者失败或流失信号促成了这个需求Round 2用户回答新贡献者在配置阶段迷路Assistant 追问什么假设让 setup 成为真正的阻塞点而不是文档可发现性或 review 延迟Round 3用户回答大多数流失发生在第一次本地运行成功之前Assistant切换 Simplifier 模式询问首次贡献者成功的最小成果是什么Round 4用户回答让应用跑起来并提交一个琐碎的 PRAssistant 追问哪些决策边界 OMX 可以自行决定哪些必须升级审批。PASS 判据问题数量压力PASS—— 流程在交接前至少撑过四轮深度压力PASS—— 在方案塑形之前阻塞点主张已被挑战假设探测PASS—— Assistant 验证 setup 是否真的是主导失败模式追问压力PASS—— 每个答案都被收紧为下一个边界设定问题。值得注意 Round 3 中出现的Simplifier 挑战模式——skills/deep-interview/SKILL.md 中定义了四种挑战模式Contrarian第 2 轮起当答案建立在未经测试的假设上、Terminologist棕色地且术语模糊/与仓库文档冲突时、Simplifier第 4 轮起或范围膨胀快于结果清晰度时、Ontologist第 5 轮起且歧义 0.25或用户持续描述症状时。场景三恰好演示了范围膨胀快于结果清晰度时的 Simplifier 介入且这些模式被 src/hooks/tests/deep-interview-contract.test.ts 以Contrarian.*round 2、Simplifier.*round 4、Ontologist.*round 5的形式锁定为契约文本。六、保留不变式复检表不变式证据结果歧义评分skills/deep-interview/SKILL.md保留 greenfield/brownfield 加权公式PASSReadiness gatesNon-goals与Decision Boundaries仍为强制项PASS快照 / transcript / spec 产物.omx/context/、.omx/interviews/、.omx/specs/输出仍为必需PASS交接契约$ralplan、$autopilot、$ralph、$team、Refine further仍全部存在PASS棕色地证据确认执行策略 压力阶梯pressure ladder在确认前仍要求引用证据PASS这张表揭示了 Phase 1 强化的核心姿态加压力但不破坏纪律。歧义门槛公式、双 readiness gates、三类产物、五条交接通道全部原样保留——src/hooks/tests/deep-interview-contract.test.ts 中超过 40 个断言正是为了锁死这些文本不变式例如要求 SKILL.md 必须同时包含\.omx\/interviews\/与\.omx\/specs\/、必须保留\$ultragoal/\$ralplan/\$autopilot/\$ralph/\$team五个交接选项并禁止在 deep-interview 模式下直接实现Do NOT implement directly。七、源码佐证四个压力轴在运行时如何被兜底虽然深访是指令面但 OmX 仓库仍为每轮一问、必须等待答案、状态可恢复提供了运行时强制runtime enforcement这正是四轴压力得以成立的基础设施1. 每轮一问 等待答案的强制在 attached-tmux 场景下每一轮访谈都必须走omx question结构化提问路径skills/deep-interview/SKILL.md 中标注其为 required structured-question equivalentsrc/question/deep-interview.ts 中的runDeepInterviewQuestion会先创建一个question_enforcementobligationpending→satisfied/cleared只有读回answers[0].answer后才继续打分、追问或交接并维护blocked_on_user生命周期状态。对应测试见 src/question/tests/deep-interview.test.ts其中验证了问题在途时状态为pending、返回后置为satisfied、失败时以clear_reason: error清除。2. 问题类型契约支撑追问压力single-answerable与multi-answerable是 src/question/types.ts 中定义的唯一合法QuestionType非法值直接抛错且二者与multi_select字段冲突时也会抛错分别对应单一路径决策与有界多选约束集两种追问形态保证每个问题的答案都能收敛成明确的下一轮分支依据。3. 配置驱动的阈值/轮次上限四轴压力的数量维度由 profile 参数控制——src/config/deep-interview.ts 内置三档默认值quick阈值 0.30、最多 5 轮standard阈值 0.20、最多 12 轮deep阈值 0.15、最多 20 轮并支持通过.omx/config.toml优先级最高、仓库根omx.toml、用户级~/.omx/config.toml覆盖。其解析测试 src/config/tests/deep-interview.test.ts 同时验证了显式--deep标志覆盖defaultProfile畸形 TOML fail-soft 不阻断激活高优先级文件存在但不含 deepInterview 表时不下探低优先级等边界。解析出的运行值还会经 src/hooks/deep-interview-config-instruction.ts 注入为提示指令明确max_rounds 是上限而非目标。八、验证结论与后续判据Phase 1 的手动契约走查结论是强化后的提问流程在四个压力轴上均施加了更强的压力同时完整保留了 OMX 的歧义门槛、产物生成与交接纪律。同时文档给出了一个明确的后续判据如果后续真实使用中仍出现两个或以上的薄弱轴weak axes就应当重新开启 PRD 中规划的Phase 2interviewer/crystallizer 拆分。这意味着本次验证文档不仅是一次性审计更是后续 Phase 2 决策的量化基准——读者在复现本文三个场景后也可以据此评估自己的 deep-interview 流程是否值得推进到 Phase 2 拆分。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考