oh-my-codex v0.8.8 发布解读：Anti-Slop 工作流落地与按队友分配推理强度

2026-03-08 发布的 oh-my-codex（OMX）v0.8.8 是项目演进中的一个务实节点：它以 5 个非合并提交完成了两项关键能力——把「反 AI 味（anti-slop）」清理工作流固化到 guidance/catalog 全链路，并让 Team 多智能体模式支持按单个队友（teammate）分配推理强度（reasoning effort）。本篇文章以官方发布说明为主体，结合仓库中的 skills/ai-slop-cleaner/SKILL.md、templates/AGENTS.md、src/team/model-contract.ts 等源码证据，为你还原这两个特性的设计意图、落地方式与底层实现，并梳理同批次的 bug 修复与工程细节，帮助你理解如何在日常开发、Ralph 工作流和团队协作中直接使用这些能力。

版本概览

维度	内容
版本号	v0.8.8
发布日期	2026-03-08
提交窗口	main..dev，5 个非合并提交
Diff 快照	main...dev：29 个文件变更，+1,061 / -203 行
提交人	@Yeachan-Heo

本版本完整提交日志（main..dev）：

d6dae26 feat(team): allocate reasoning effort per teammate (#642)
ac675d0 feat: add anti-slop workflow (#634)
a4e6e35 fix(pkg): normalize npm bin path (#638)
4352f30 fix: lock deep-interview auto-approval injection (#637)
274d5e7 fix: reserve worker role for team mode

Highlights 一：Anti-Slop 工作流全面落地

v0.8.8 的「反 AI 味」特性并不是一个孤立的脚本，而是一套贯穿 guidance（提示词引导）与 catalog（技能目录）两个表面的工作流。官方说明将其定义为 anti-slop workflow rollout，具体包含四件事：

1. 在根级与模板级 AGENTS.md 中加入 anti-slop 工作流指引；
2. 引入专门的技能表面 skills/ai-slop-cleaner/SKILL.md；
3. 更新 catalog manifest 与生成的 catalog 输出；
4. 为 anti-slop 工作流契约增加回归测试覆盖。

对应的 PR 为 #634（外部链接按规范不展开，以下均以仓库证据为准）。

工作流契约：从「指令」到「执行协议」

仓库顶层契约 templates/AGENTS.md 的 execution_protocols 一节（Anti-slop workflow 小节）明确定义了它的定位与纪律：

• 清理/重构/去味（deslop）工作沿用同一套轻量工作流 understand -> execute -> verify -> report；
• $ai-slop-cleaner 只是所选执行通道内的有界辅助器（bounded helper），不是与之竞争的顶级工作流；
• 修改代码前先写清理计划；先用回归测试锁定既有行为，再一个异味（smell）一个 pass 地推进；
• 优先删除而非新增，优先复用 + 边界修复而非叠层；
• 未经明确请求不得新增依赖；
• 完成前必须跑 lint、typecheck、tests 与静态分析；
• 保持 writer/reviewer 分离，清理计划与审批分开进行。

在 skills/ai-slop-cleaner/SKILL.md 中，这份契约被细化成一张完整的「任务卡」（Task Card），定义了使用时机、输入、编辑前准备、异味分类学、pass 顺序、证据/输出契约与退出条件。

何时使用与输入

当以下情况出现时使用该技能：

• 工作代码臃肿、嘈杂、重复、过度抽象或明显是 AI 生成；
• 用户直接请求清理/重构/去味；
• 一次 follow-up 留下了重复/死代码、弱边界、缺失测试、fallback 式路径或包装层。

输入是「被请求的特性/文件」与「需要保留的行为」。文件列表作用域是合法的，pass 必须限定在其内。特别地，在 Ralph 工作流中，本技能只运行在 Ralph 修改过的文件上，默认使用标准模式，除非显式另有要求。

编辑前：先锁行为，再列计划

SKILL.md 要求在任何编辑之前完成五步准备：

1. 先用回归测试锁定行为：识别要保留的行为，运行/补充最窄的目标测试，同时覆盖主路径与保留的兼容性/fail-safe fallback 路径；
2. 代码之前先写清理计划：列出作用域与异味，包含 fallback 发现/分类/上报，并先做最安全、信号最强（highest-signal）的修复；
3. 盘点作用域内的 fallback 类代码：临时 hack、临时 workaround、临时 fallback、just bypass、just skip、fail 时 fallback、被吞掉的错误、静默默认值、宽泛兼容 shim、重复的替代执行路径；
4. 逐一分类每个 fallback：
   • Masking fallback slop（掩蔽式 fallback 异味）：隐藏证据、绕过契约、压制校验、吞掉失败、静默默认、添加未测试路径；
   • Grounded compatibility/fail-safe fallback（有依据的兼容/失效保护 fallback）：窄化在外部/版本/fail-safe 边界上、记录理由、保留失败证据、同时测试主路径与 fallback；
5. 优先根因修复、删除、边界修复或显式失败行为。对宽泛/含糊/跨层/架构级发现，调用 $ralplan 做共识裁决；若已在 ralplan、ralph、team 或其他 OMX 工作流内，不要嵌套再拉起一个 $ralplan，而是把发现挂到当前 handoff 上。

异味分类学与 pass 顺序

SKILL.md 给出了七类可操作的异味：

异味类别	典型表现
Fallback 类代码	掩蔽式 fallback、workaround 分支、绕过、被吞错误、静默默认、宽泛 shim、替代路径
重复	重复逻辑、复制粘贴分支、冗余 helper
死代码	未使用/不可达代码、过期 flag、调试残留
多余抽象	透传包装、投机式间接层、单次使用分层
边界违反	隐藏耦合、责任泄漏、错误分层 import/副作用
缺失测试	行为未锁定或边界用例未覆盖
UI/设计味	上下文敏感信号而非绝对禁令；保留有意的品牌、设计系统、可访问性或产品上下文例外

UI/设计味一栏给出了具体的检查信号（来自 SKILL.md 原文，作为判断基准而非绝对标准）：

• 韩文正文 11–12px（一般要求 14px 或更大）；
• 无谓的 box shadow；
• 重复的「eyebrow + 标题 + 描述 + 段落」堆叠与通用 emoji 徽章；
• 默认的 AI 蓝/紫，如 #3B82F6；
• 反射式 3 列或 4 列网格；
• 极端渐变——除非有上下文正当理由。

pass 顺序要求先解决 fallback 代码裁决门（resolution gate），然后一个异味一个异味地处理：

1. Pass 1：死代码删除；
2. Pass 2：重复去除；
3. Pass 3：命名/错误处理清理；
4. Pass 4：测试加固。

每个 pass 之后重跑定向验证，并避免无关重构。优先删除/复用现有工具；除非显式要求，不引入新抽象或新依赖。

证据与输出契约

完成清理后必须输出结构化的 AI SLOP CLEANUP REPORT：

AI SLOP CLEANUP REPORT
Scope: [files/feature]
Behavior Lock: [targeted tests added/run]
Cleanup Plan: [bounded smells/order]
Fallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]
UI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]
Passes Completed: [resolution gate; Passes 1-4]
Quality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)
Changed Files: [path -> simplification]
Remaining Risks: [none or deferred item]

报告需包含：变更文件、简化说明、fallback 分类/上报状态、运行过的测试/诊断/构建检查、相关 UI 发现与延期风险，并保持清理计划与审批的 writer/reviewer 分离。

退出条件

当满足以下条件时停止：请求作用域具备行为锁定证据、每个选中的异味 pass 已完成或带理由显式延期、验证已报告、没有无关文件或临时产物残留。绝不要把未经验证的清理当作完成；遇到真实的架构阻塞点要上报，而不是用掩蔽手段糊过去。

Catalog 与回归覆盖的证据

在仓库中可以看到该技能已进入 catalog 体系：catalog/manifest.json 与 catalog/generated/public-catalog.json 均把 ai-slop-cleaner 标记为 status: "active"、category: "shortcut" 的内置技能（非 core）。回归测试也验证了契约：

• catalog/tests/generator.test.ts 断言生成的 catalog 契约中包含名为 ai-slop-cleaner 且状态为 active 的技能；
• catalog/tests/schema.test.ts 断言 ai-slop-cleaner 是 active 的内置技能。

这与发布说明中「更新 catalog manifests 和生成输出」「增加 anti-slop 工作流契约回归覆盖」完全对应。

Ralph 工作流中的强制集成

Anti-slop 工作流与 Ralph 的集成不是可选项，而是强制收尾 pass。在 src/cli/ralph.ts 中可以看到：

• Ralph 会生成「changed files」清单，并在步骤 7.5 要求只在清单列出的仓库相对路径上、以标准模式运行 oh-my-codex:ai-slop-cleaner；
• 若启用 --no-deslop flag，则跳过强制收尾 pass，并使用上一次成功的 pre-deslop 验证证据（- \--no-deslop` is active for this Ralph run, so skip the mandatory ai-slop-cleaner final pass ...`）；
• 步骤 7.6 要求在 ai-slop-cleaner 之后重跑当前 tests/build/lint 验证；若回归失败，要么回滚清理变更，要么修复后重试再完成。

相关测试（src/cli/tests/ralph.test.ts）断言了指令文本包含 ai-slop-cleaner、skip the mandatory ai-slop-cleaner final pass 与 mandatory final ai-slop-cleaner pass，锁定该集成行为。换句话说：每次 Ralph 交付前，改动过的文件都会过一遍去味收尾，确保不会把「AI 味」沉淀进代码库。

Highlights 二：Team 按队友分配推理强度

v0.8.8 的第二大特性是：团队执行把推理强度决策更深地带入 runtime 与 worker 启动路径，而不是把 worker 配置当作一个无差别的默认值。官方要点如下：

• 扩展 team model-contract 逻辑以支持 teammate 级别的推理强度；
• 更新 runtime、scaling 与 tmux-session 行为以传播这些设置；
• 为 runtime、tmux session 与 model-contract 路径增加回归覆盖；
• 刷新 README 与 team skill 指引以反映新行为。

对应 PR 为 #642。

底层实现：model-contract 中的推理强度解析

核心实现位于 src/team/model-contract.ts。关键常量是 REASONING_KEY = 'model_reasoning_effort'（第 19 行），推理强度通过 Codex 配置键 model_reasoning_effort 注入 worker 启动参数。

normalizeOptionalReasoning()（第 137-144 行）把字符串归一化为合法枚举：low、medium、high、xhigh、max，非法值返回 undefined。extractReasoningEffort()（第 146-150 行）从 model_reasoning_effort="..." 形式的配置覆盖中提取实际强度。

在 ResolvedTeamWorkerLaunchDiagnostics（第 52-62 行）中，reasoningSource 被区分为三种来源：

• explicit：来自显式覆盖（inherited 或 env 中的 reasoning override）；
• role-default：来自角色默认值（preferredReasoning，即 requestedDefaultReasoning）；
• none：未指定。

这对应官方「而不是把 worker 配置当作一个无差别的默认值」的表述：每个 worker 的推理强度现在有可追溯的来源（显式 > 角色默认 > 无）。

从实现细节看（第 160-186 行）：

• 显式覆盖优先级为 inheritedParsed.reasoningOverride ?? envParsed.reasoningOverride；
• reasoningSource 判定：有显式覆盖则 explicit，否则有 preferredReasoning 则 role-default，否则 none。

模型配置侧的按角色推理强度

推理强度的定义与归一化落在 src/config/models.ts：

• PER_AGENT_REASONING_EFFORTS 导出 PerAgentReasoningEffort 类型（第 50 行），是 worker 可用的枚举集合；
• ROOT_REASONING_EFFORTS 导出 RootReasoningEffort（第 53 行）用于主（leader）侧；
• resolvePerAgentReasoningEfforts()（第 201 行起）把每个 agent 类型映射到各自归一化后的推理强度，形成 Record<string, PerAgentReasoningEffort>。

也就是说，从配置文件到运行时，推理强度走的是「agent 角色 -> 解析映射 -> 注入 worker 启动参数」的完整链路。

回归测试：scaling 与 tmux-session 路径

回归覆盖在 src/team/tests/scaling.test.ts 中可以看到具体形态：

• 多个用例把 -c 'model_reasoning_effort="medium"'（及 "low"、"xhigh"）与 --model、bypass flag 组合，验证解析结果（第 1058-1105 行）；
• 一个专门的用例「uses project-scoped CODEX_HOME for scaled worker reasoning and model defaults」（第 1776 行起）验证项目作用域下扩缩容 worker 的推理与模型默认值：它创建临时项目目录，初始化 team state（initTeamState('scale-up-project-reasoning', 'task', 'executor', 1, cwd)）、创建任务、读取 team 配置与 manifest.v2.json，断言 worker 启动脚本包含 model_reasoning_effort="xhigh"，并检查 workers/worker-2/AGENTS.md 的生成内容（第 1892-1896 行）。

这证明 teammate 级推理强度不仅停留在配置解析层，还会穿透到真实的 worker 启动脚本与 worker AGENTS.md，与发布说明「runtime、scaling、tmux-session 行为传播这些设置」吻合。

Team 模型解析的优先级（上下文）

从 templates/AGENTS.md 的 team_model_resolution 一节可知 Team/Swarm worker 模型选择的完整优先级：显式 OMX_TEAM_WORKER_LAUNCH_ARGS > 继承的 leader --model > 低复杂度默认 OMX_DEFAULT_SPARK_MODEL（旧别名 OMX_SPARK_MODEL）；模型 flag 统一归一化为一条 --model <value>，并优先使用 OMX_DEFAULT_FRONTIER_MODEL / OMX_DEFAULT_SPARK_MODEL 而非猜测默认值。推理强度解析（model_reasoning_effort）正是这套 OMX_TEAM_WORKER_LAUNCH_ARGS 解析能力的一部分。

Bug 修复与工程打磨

Deep-interview 自动审批锁加固

发布说明指出：notify-hook 与 keyword-detection 逻辑被收紧，使 deep-interview 自动审批注入保持锁保护并得到更好的测试覆盖（PR #637）。

在 src/hooks/keyword-detector.ts 中可以看到：

• 常量 DEEP_INTERVIEW_INPUT_LOCK_MESSAGE = 'Deep interview is active; auto-approval shortcuts are blocked until the interview finishes.'（第 189 行），语义是：deep-interview 进行中时，自动审批快捷路径被阻塞，直到访谈结束；
• 状态化技能模式列表包含 deep-interview（第 191 行），scope: 'deep-interview-auto-approval' 用于标识该锁的作用域（第 126、488 行）。

回归测试 src/hooks/tests/keyword-detector.test.ts 断言：input_lock.active === true、blocked_inputs 包含 'next i should' 等被阻塞的自动审批输入、message 等于 DEEP_INTERVIEW_INPUT_LOCK_MESSAGE。这验证了「锁保护」行为：访谈进行中，任何试图走自动审批快捷路径的输入都会被拦截。

打包与路由契约修正

发布说明还包含两个较小的契约修正：

1. npm bin 路径归一化（PR #638）：规范发布后的 npm bin 路径，并更新 package-bin 回归覆盖。这与 package.json 中 bin 字段的工程化治理对应；
2. 为 team mode 显式保留 worker 角色（PR #641）：在 prompt-guidance 路由中，worker 只允许在激活的 team/swarm 会话中使用。这一点在 templates/AGENTS.md 的 delegation_rules 中表述得十分明确：

Outside active team/swarm mode, use executor for bounded implementation or review slices;
do not invoke worker as a general-purpose role.
Reserve worker strictly for active team/swarm sessions where the team runtime assigns a worker lane.
worker is a team-runtime surface, not a general-purpose child role.

也就是说，worker 不再是通用子角色，而是 Team runtime 专属的表面；团队模式之外请使用 executor。这与「提交日志第 5 条 fix: reserve worker role for team mode」一一对应。

版本数据的工程解读

• Commit window：5 个非合并提交，2026-03-08 单日完成，说明这是一个小而聚焦的迭代；
• Diff snapshot（main...dev）：29 个文件变更，+1,061 / -203，规模适中，与「1 个 feature（anti-slop）+ 1 个 feature（推理强度）+ 3 个 fix」的工作量相匹配；
• 提交信息均遵循 Conventional Commits 风格（feat(team):、feat:、fix(pkg):、fix:），scoped 提交让变更意图一目了然。

如何验证与使用这些能力

仓库是只读的，以下为查看、安装与配置方式，不涉及修改仓库：

1. 查看 anti-slop 技能：直接阅读 skills/ai-slop-cleaner/SKILL.md 获取完整任务卡；顶层执行契约见 templates/AGENTS.md 的 Anti-slop workflow 小节；catalog 登记见 catalog/manifest.json 与 catalog/generated/public-catalog.json。
2. 在 Ralph 工作流中使用：运行 Ralph 后，步骤 7.5 会自动对 changed files 执行 oh-my-codex:ai-slop-cleaner 标准模式收尾；需要跳过时使用 --no-deslop flag（见 src/cli/ralph.ts）。
3. 配置 teammate 级推理强度：通过 OMX_TEAM_WORKER_LAUNCH_ARGS（或继承 leader 配置）传入 -c 'model_reasoning_effort="low|medium|high|xhigh|max"'，Team runtime 会按 teammate 分别解析并写入 worker 启动脚本与 worker AGENTS.md。
4. 验证安装：执行 omx setup 安装全部组件，omx doctor 校验安装（见 templates/AGENTS.md 的 Setup 一节）。

小结

v0.8.8 的两个核心特性相辅相成：anti-slop 工作流把「清理/去味」从口头倡议变成带异味分类学、pass 顺序、证据契约与 Ralph 强制收尾的可执行协议；按 teammate 分配推理强度则让 Team 模式的资源分配从「一刀切」进化到「按角色、按任务可追溯」。再加上 deep-interview 自动审批锁与 worker 角色保留等契约修正，这一版本体现的是 OMX 在「多智能体质量治理」方向上的持续收紧。若要深入源码，建议从 skills/ai-slop-cleaner/SKILL.md、src/team/model-contract.ts 与 src/config/models.ts 三条线入手，配合 src/team/tests/scaling.test.ts 与 src/hooks/tests/keyword-detector.test.ts 的回归用例交叉印证。