OmX Prometheus Strict 工作流 Dogfood 验证实录：意图分类、提问编排与 6 项清单的实战拆解

OmX Prometheus Strict 工作流 Dogfood 验证实录意图分类、提问编排与 6 项清单的实战拆解【免费下载链接】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仓库中的 Dogfood 验证证据文档docs/recipes/prometheus-strict/dogfood-2026-05-22.md为主体完整拆解一个名为 Prometheus Strict 的实验性规划工作流在三个典型场景trivial / simple / architecture下的 dry-run 行为从意图分类、研究 fan-out、omx question多轮提问到 6 项检查清单6-item checklist与 Oracle 计划输出的完整链路。读完本文你将掌握这套把可吸收的模糊点按引用吸收、把会影响 CRITICAL 轴的问题抛给用户的提问编排策略并了解当前仓库中该技能已被替换为$plan的生命周期管理机制见 sunset-stub.ts。说明本文涉及的 Prometheus Strict 是一个实验性概念。仓库文档 prometheus-inspired-deliberation.md 明确标注其为非规范的 recipenon-canonical不是 OMX 的 active skill且当前代码库中$prometheus-strict及相关 prompt 已被下线见后文技能生命周期一节。本文按证据文档的原始记录如实呈现其设计并给出仓库当前状态的对照。一、Dogfood 验证的整体设计三场景 × 三档意图Dogfood自用验证的核心目标是用真实形态的 prompt 检验一个工作流在不同复杂度下的行为是否符合设计预期。证据文档用三个场景覆盖了意图复杂度的三个档位场景意图Roundsomx question 调用次数每轮问题数Absorbed 计数Fan-outAtrivial00N/A30Bsimple11121 exploreCarchitecture223, 261 explore 1 researcher三档意图的设计逻辑非常清晰trivial场景 A单行文档改动明确目标文本与文件——完全不需要提问与外部研究直接产出计划simple场景 B13 个文件的单元测试新增涉及命名函数与路径——需要 1 次 explore 确认测试布局仅 1 个关键问题architecture场景 C跨系统的 auth 会话迁移cookie → JWT含回滚与消费方影响——需要 explore researcher 双路 fan-out、两轮共 5 个问题。三个场景共同验证了工作流的一个核心不变量提问数量与意图复杂度正相关且每一轮omx question都会把问题收敛到会改变 CRITICAL 决策轴的少数几个问题上。二、场景 A — Trivial零提问直接产出计划Prompt 原文$prometheus-strict fix typo managment → management in README.md line 42Agent 执行的 dry-run 记录意图分类trivial——原因是这是带明确目标文本与文件的单行 typo/文档修复Fan-out被research_fan_out的 trivial 规则跳过0 explore, 0 researcher轮次0omx question调用次数0每轮问题数N/AAbsorbed-with-citation 计数3。这条路径揭示了工作流的第一条关键设计并非所有任务都需要提问。当任务的目标、边界与验收标准在 prompt 中已经显式给出时提问只会增加延迟此时吸收absorb比抛出surface更优。这也是 src/question/policy.ts 中evaluateQuestionPolicy这类策略评估存在的意义——先评估该不该问再决定问什么。6 项检查清单最终状态ItemStateBasisobjectiveYES / USER_ANSWEREDtypo replacement named in promptscope INOUTYES / USER_ANSWEREDINREADME.md line 42; OUT all other filesacceptanceYES / INFERRED_FROM_SPECtarget string becomesmanagement, nomanagmentat linetest strategyYES / ABSORBED_WITH_CITATIONAgent-QA only for doc typo; no automated test neededhandoff targetYES / INFERRED_FROM_SPECdirect executor, not$teamno outstanding CRITICALYES / ABSORBED_WITH_CITATIONno Plan-A/Plan-B divergence across 5 axes清单里值得注意的两种达成方式USER_ANSWERED——来自用户 prompt 中显式给出的信息typo 目标、文件范围INFERRED_FROM_SPEC——从任务规格可推断的结论验收就是字符串变成managementABSORBED_WITH_CITATION——按既定规则吸收、并附带引用依据的默认结论文档 typo 只需 Agent-QA无需自动化测试。Oracle 计划输出ReadREADME.mdaround line 42.Replacemanagmentwithmanagementonly at the requested location.Verify withgrep -n managment\|management README.md.Stop condition: requested typo is corrected and no unrelated files changed.这里展示了Oracle 计划的形态面向执行器的、可直接照做的有序步骤 明确的停止条件。即便在零提问场景计划也包含只改指定位置、不改无关文件的边界约束与 grep 验证步骤避免执行器过度发散。三、场景 B — Simple一次 explore、一个问题Prompt 原文$prometheus-strict add a unit test for the foo() function in src/utils/foo.tsAgent 执行的 dry-run 记录意图分类simple——因为这是对命名函数/路径的 13 文件测试新增Fan-out需要1 explore确认现有测试运行器/位置0 researcher没有指名外部依赖轮次1omx question调用次数1每轮问题数1Absorbed:surfaced 比例2:1吸收 2 个模糊点、抛出 1 个问题。omx question批次Q1: Forfoo()insrc/utils/foo.ts, should the first unit test cover only the documented happy path, or include the primary error/edge branch too?Option 1: Happy path only — minimal regression test for current behavior.Option 2: Happy edge — broader test if edge behavior is part of acceptance.这个单一问题被判定为值得问是因为测试覆盖范围的选取直接决定验收标准见下方清单 acceptance 行。而其余两个模糊点则被按规则吸收Defaults AppliedABSORBED_WITH_CITATIONexplore 之后沿用仓库现有的 Node 测试运行器/布局不询问框架选择ABSORBED_WITH_CITATION文件缺失或确切的同目录测试路径由执行器按仓库约定解析不阻塞用户。第二条尤其体现了最小打扰原则执行器能够从仓库约定自行推导的信息不进入用户提问队列。6 项检查清单最终状态ItemStateBasisobjectiveYES / USER_ANSWEREDunit test forfoo()namedscope INOUTYES / USER_ANSWEREDIN test forsrc/utils/foo.ts; OUT implementation changes unless needed to expose functionacceptanceYES / USER_ANSWEREDselected test coverage option determines acceptancetest strategyYES / INFERRED_FROM_SPECunit test onlyhandoff targetYES / INFERRED_FROM_SPECdirect executorno outstanding CRITICALYES / ABSORBED_WITH_CITATIONremaining gaps do not alter 5 CRITICAL axes注意 scope OUT 的表述除非需要暴露函数否则不做实现改动——把实现改动的范围显式排除防止测试任务演变成重构任务。Oracle 计划输出Explore existing test layout andfoo()export shape.Add the selected unit test near existing utility tests.Run the focused test command and build if required.四、场景 C — Architecture双路 fan-out 与两轮提问Prompt 原文$prometheus-strict design the auth session migration from cookie-based to JWT, including rollback path and consumer impact analysisAgent 执行的 dry-run 记录意图分类architecture——因为任务指名了跨系统的 auth/会话迁移、回滚与消费方影响Fan-out触发1 explore摸清当前模块边界 1 researcher研究 JWT 迁移/会话模式轮次2omx question调用次数2每轮问题数3然后2Absorbed-with-citation 总数6Absorbed:surfaced 比例6:5——吸收的模糊点数量超过抛出的 CRITICAL 问题数量而每一个被抛出的问题都会改变某个 CRITICAL 决策轴。Round 1omx question批次3 个问题Q1 scope boundaryJWT 最初与 cookie 会话共存还是在切换时直接替换 cookie 会话Q2 rollback contract回滚是否允许使新签发的 JWT 失效还是回滚期间 JWT 必须保持有效Q3 consumer impact哪些消费方必须在第一天就兼容迁移仅 Web、API 客户端还是两者都要Round 2omx question批次2 个问题Q4 acceptance什么能证明迁移成功仅 auth 对等测试、分阶段金丝雀指标还是两者都要Q5 handoff target执行应该是单个$ultragoalstory还是拆分为$team的多条 laneauth 核心 / 消费方 / QADefaults Applied6 条默认吸收ABSORBED_WITH_CITATIONtoken 签名算法默认采用现有安全框架的推荐合规有额外要求时再回头调整ABSORBED_WITH_CITATION测试策略默认对迁移关键的 auth 路径采用 TDDABSORBED_WITH_CITATION会话 TTL 保持当前 cookie TTL除非产品显式变更ABSORBED_WITH_CITATION文档更新作为执行器验收证据的一部分不作为独立的用户问题ABSORBED_WITH_CITATION特性开关命名遵循仓库现有约定执行器验证路径ABSORBED_WITH_CITATION监控阈值默认采用当前 auth 错误预算除非产品给出更严格的 SLO。这 6 条是吸收策略的典型示范凡是能从仓库约定、安全框架默认值或既有产品决策推导出的结论一律带引用吸收把宝贵的提问轮次留给真正只有用户能回答的决策点。6 项检查清单最终状态ItemStateBasisobjectiveYES / USER_ANSWEREDdesign auth session migration cookie → JWTscope INOUTYES / USER_ANSWEREDcoexist/replace and consumer scope answeredacceptanceYES / USER_ANSWEREDselected migration evidence answeredtest strategyYES / ABSORBED_WITH_CITATIONTDD migration safety defaulthandoff targetYES / USER_ANSWERED$ultragoalvs$teamansweredno outstanding CRITICALYES / ABSORBED_WITH_CITATIONall remaining gaps absorbed or carried as non-blocking risks与场景 A/B 相比架构场景的清单状态明显向USER_ANSWERED倾斜——因为 scope、acceptance、handoff 这三个轴都真正依赖用户决策。Oracle 最终计划输出Map current cookie session issue/validate/refresh/logout boundaries.Define JWT claims, signing/rotation, and compatibility layer.Implement migration behind a reversible feature flag.Add parity tests for cookie and JWT session validation, refresh, logout, and expiry.Stage rollout by consumer group and monitor auth failure rate.Rollback by disabling JWT issuance, preserving validation for already-issued JWTs if selected in Round 1/2 answers.注意第 6 步按 Round 1/2 的选择保留对已签发 JWT 的校验——计划输出与问答结果严格联动用户对 Q2回滚契约的选择直接决定回滚步骤的行为体现了提问服务于计划、计划消化提问的闭环。五、机制拆解意图分类、Fan-out 与 Absorbed/Surfaced 的权衡三个场景背后是一套统一的编排机制可以从证据文档与仓库源码中相互印证1. 意图分类Intent classification工作流首先把任务归入trivial / simple / architecture或中间档位。分类依据是任务涉及的文件数、是否跨系统、是否指名外部依赖、是否有显式目标与边界。场景 A 因单行 typo 显式目标文本/文件归为 trivial场景 C 因跨系统迁移 回滚 消费方影响归为 architecture。2. 研究 Fan-outresearch_fan_outfan-out 是要不要派研究员/探索器的规则集trivial0 explore, 0 researchersimple1 explore确认测试运行器/位置0 researcherarchitecture1 explore模块边界1 researcherJWT 迁移/会话模式。这与仓库中的关键词路由机制一脉相承keyword-detector.ts 中prometheus(?:-strict)?被归入协调工作流主体coordinated workflow subject与autopilot、deep-interview、ralplan、ultragoal、team等并列说明这类工作流共享同一套关键词检测与路由基础。3. 轮次Rounds与omx question轮次是提问-回答的迭代次数从 trivial 的 0 轮到 architecture 的 2 轮。omx question是实际提问的执行面其仓库实现位于 src/question/client.ts 的runOmxQuestion含defaultOmxQuestionProcessRunner与OmxQuestionError错误类型并配套策略评估src/question/policy.ts 的evaluateQuestionPolicy——决定某批问题是否应该问、问多少事件记录src/question/events.ts 的buildQuestionEvent与appendQuestionEvent——每次提问/回答都落盘为可审计的事件记录渲染与注入src/question/renderer.ts 负责把问题渲染到终端/面板并把答案回注injectQuestionAnswersToPane。从这些源码可以推断omx question并不是一次性的交互调用而是带策略、带审计、带渲染生命周期的完整子系统——这正是多轮问答场景 C 的 3→2 问题能在两次调用间保持状态连续性的基础。4. Absorbed:surfaced 比例这是工作流最核心的权衡指标场景 B2:1——吸收 2 个、抛出 1 个场景 C6:5——吸收 6 个、抛出 5 个且每个被抛出的问题都改变一个 CRITICAL 轴。设计意图可以概括为能用引用/仓库约定/既有决策吸收的模糊点绝不打扰用户只有那些真正改变 CRITICAL 决策轴的问题才值得占用一轮问答。这与 prompts/verifier.md、prompts/planner.md 等角色提示所强调的基于证据而非假设的纪律一致。六、6 项检查清单6-item checklist解析每个场景在产出计划前都要过一遍 6 项检查清单任何一项未满足都不能进入执行Item含义常见达成方式objective目标是否明确USER_ANSWEREDprompt 显式给出scope INOUT边界内/外是否清楚USER_ANSWERED范围显式、INFERRED_FROM_SPECacceptance验收标准是否可判INFERRED_FROM_SPEC、USER_ANSWERED由所选选项决定test strategy测试策略是否确定ABSORBED_WITH_CITATION如 TDD 默认、Agent-QAhandoff target交接目标direct executor /$ultragoal/$teamINFERRED_FROM_SPEC、USER_ANSWEREDno outstanding CRITICAL是否无未决 CRITICAL 项ABSORBED_WITH_CITATION剩余差距不影响 5 个 CRITICAL 轴三个场景中no outstanding CRITICAL 全部以ABSORBED_WITH_CITATION达成——但含义有细微差别trivial 场景是5 个轴上不存在 Plan-A/Plan-B 分歧架构场景则是剩余差距要么被吸收、要么作为非阻塞风险记录。也就是说清单的达成不是消灭所有不确定性而是确认剩余不确定性不会改变 CRITICAL 决策轴。七、当前仓库状态技能生命周期与$plan迁移这是阅读本证据文档时必须了解的重要背景文档记录的是 2026-05-22 的 dry-run 验证而当前代码库中该技能已进入下线sunset状态。sunset-stub.ts 中注册了prometheus-strict、prometheus-strict-metis、prometheus-strict-momus、prometheus-strict-oracle四个条目统一提示Skill$prometheus-stricthas been removed. Use$planfor planning instead.该文件的头注释说明它是已移除技能/提示的统一 sunset-stub 解析器是后续移除行为的单一事实来源Single SSOT新增移除只需在此登记关键词/hook 面就会自动输出干净的removed, use X错误skill-catalog-hygiene.test.ts 将prometheus-strict列入 removed 列表做卫生检查防止目录中出现残留配套的 prometheus-inspired-deliberation.md 则保留了该概念的精神遗产它把 Prometheus 式的严格规划收敛为围绕 canonical 路径$deep-interview - $ralplan - $ultragoal的手动清单建议并明确三条边界——不调用$prometheus-strict、不新增 Metis/Momus/Oracle 的 prompt 型原生 agent、不建立独立的 Prometheus 产物约定。从源码结构看这体现了 OMX 对实验性工作流的标准处置方式先在证据文档中做 dogfood 验证、验证其价值再决定是收编进 canonical 技能路径、还是下线并由统一 stub 引导用户迁移到$plan。这套验证 → 决策 → 统一下线的生命周期管理比单纯删除技能更能保护用户不被死链接和两跳死胡同困扰文件注释中明确批评了此前$ultrawork → $ralph这类两跳死胡同问题。八、可复用的经验与落地建议抛开$prometheus-strict已下线的事实这份证据文档本身是一份高质量的提问编排与计划收敛设计样例其经验可以迁移到任何 LLM 驱动的任务编排系统按复杂度分档处理trivial 不提问、simple 少量提问、architecture 多轮提问——提问成本必须与任务复杂度匹配显式 Fan-out 规则明确什么任务需要 explore、什么任务需要 researcher避免研究资源浪费带引用的吸收ABSORBED_WITH_CITATION默认值必须有来源仓库约定、安全框架、既有决策而不是无依据的猜测只问会改变 CRITICAL 轴的问题用 6 项清单在计划前做最后把关把剩余不确定性显式标记为非阻塞风险计划与问答闭环用户对回滚契约、验收方式的选择必须能回溯到最终计划的具体步骤如场景 C 第 6 步实验性功能的优雅下线即使方案验证后被替换也通过统一 stubsunset-stub.ts给出removed, use X的明确指引并用测试skill-catalog-hygiene.test.ts保证不残留。如果你想在自己的项目中复现这套验证方法推荐路径是先以本仓库的 prometheus-inspired-deliberation.md 为概念蓝本把意图分类、fan-out 规则、6 项清单落到自己的规划提示词中再用真实任务做三档 dogfood 验证trivial/simple/architecture用Absorbed:surfaced 比例和每轮是否改变 CRITICAL 轴作为量化指标判断这套编排是否值得进入正式技能路径。相关仓库资源索引证据文档本体docs/recipes/prometheus-strict/dogfood-2026-05-22.md概念 recipe 与边界说明docs/recipes/prometheus-inspired-deliberation.md已移除技能统一解析器src/hooks/sunset-stub.ts关键词路由协调工作流主体含prometheus(?:-strict)?src/hooks/keyword-detector.ts技能目录卫生测试removed 列表src/hooks/tests/skill-catalog-hygiene.test.tsomx question客户端实现src/question/client.ts提问策略评估src/question/policy.ts提问事件审计src/question/events.ts提问渲染与答案回注src/question/renderer.ts【免费下载链接】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），仅供参考