深度解读：OMH —— 基于 Harness 理念的轻量化编程工作流

背景

随着 AI 编程助手（如 Codex、OpenCode 等）的普及，开发者面临着订阅成本高昂、Token 消耗过快以及代码质量不稳定等痛点。传统的“Vibe Coding”（氛围编程）往往缺乏严谨的工程结构，导致上下文污染、返工率高，进而加剧了 Token 的浪费。

在此背景下，社区开发者推出了一款名为 OMH (Oh My Harness) 的开源工作流。该工作流基于 Harness 理念设计，旨在通过解耦编程的不同阶段，合理利用不同平台（如 Web 端与本地客户端）的资源特性，实现轻量级、低成本且高质量的代码开发。OMH 目前主要支持 Codex 和 OpenCode，并鼓励社区通过 PR 进行扩展。

核心内容

OMH 的核心逻辑在于将编程过程分解为四个明确的阶段，并通过特定的 Skill（技能/指令）来规范 Agent 的行为，从而优化资源分配。

1. 架构与 Skill 设计

OMH 仅包含四个核心 Skill，分为“核心”与“辅助”两类：

• 核心 Skill: harness 定义了标准的开发循环：

  1. 收集信息 (只读)：获取任务相关上下文。
  2. 制定 Plan (计划可写)：生成清晰、单一目标的开发计划。
  3. 实现 Plan (代码可写)：根据 Plan 编写代码。
  4. 审查实现 (只读)：检查代码是否符合 Plan 和需求。
  5. 反馈调整：根据审查结果回到前序阶段进行修正。

• 辅助 Skill

  • TDD Skill：源自 mattpocock 的修改版，提供测试驱动开发策略。
  • Debug & Review Skills：源自 superpowers 的 systematic-debugging 和 receiving-code-review 的适配版本，提供系统化的调试能力和接受代码审查的机制。

2. 开发理念与实践

OMH 的诞生基于以下开发哲学：

• Plan 的明确性与单一性： 借鉴 GitHub PR（Pull Request）的开发模式，每个 Plan 应清晰明确，最佳策略是“一次 Plan 只做一件事”。虽然可以将多个小任务打包，但子任务必须界限分明。
• 分支开发 (Worktrees)： 放弃在主分支直接修改，转而使用分支进行开发。这不仅保护了主分支的稳定性，还支持清晰的并发开发（如不同模块独立分支），并便于回退。
• 上下文纯净度 (Context Purity)：
  • 知彼：任务开始前，由主 Agent 收集信息，子 Agent 补充，确保上下文的最纯净状态，避免信息过载导致的“坑”。
  • 知己：开发者需明确 Agent 的能力边界、协作方式及潜在陷阱。
• 多 Agent 的合理使用： 反对无意义的多 Agent 讨论（可能导致“三个臭皮匠”效应，即结果更混乱）。多 Agent 仅应用于特定场景，如分工审查（一个查 Bug，一个查静默失败）或并行信息搜集。
• 测试驱动反馈： 利用 Agent 的 React 特性，构建自我反馈的测试工具（如 E2E 测试），使 Agent 能自动发现并修复问题。
• 模型分层策略：
  • 计划阶段：需要强大的模型进行逻辑推演。
  • 实现阶段：次旗舰模型即可，注重效率。
  • 审查阶段：需要偏好审查的模型，而非单纯擅长写代码的旗舰模型。

3. 成本优化策略：解耦与资源复用

这是 OMH 最具价值的部分，旨在最大化利用订阅权益（以 ChatGPT Plus 为例）：

• 痛点分析：

  1. Plan 阶段消耗大：Web 端对话导致上下文变长，Token 消耗剧增。
  2. 返工消耗：缺乏 Harness 规范导致代码质量差，引发返工。
  3. Review 冷启动：本地 Review 需重新加载上下文，造成额外花费。
  4. 实现阶段：在清晰 Plan 下，实现阶段的 Token 消耗是必要且可控的。

• 优化方案：只读操作移出 Codex

  • 阶段 1 & 2 (收集与 Plan)： 利用 Web 端（如 GPT Web、Claude Web、Grok）慷慨的免费/高额度模型（如 GPT 5.5 Web 端），通过 GitHub 连接器读取私有仓库代码。生成 PR 和详细的 Plan。注意：不建议 Web 端直接修改代码（因无法 Patch，只能重写，质量低），仅用于分析和生成 Plan。
  • 阶段 3 (实现)： 在本地 Codex/OpenCode 中，使用 $harness 接手 PR 任务。拉取分支，读取 Plan，进行信息确认后开始编码。此时可选用次旗舰模型（如 GPT 5.4，其额度通常是 5.5 的两倍；或 GPT 5.3 Codex、DS 模型）以降低成本。
  • 阶段 4 (审查)： 利用云端 Codex Review 功能。Codex Review 由 GPT 5.3 Codex 驱动，拥有独立的额度池（每周 3000 次调用，5 小时限制），不与本地 Codex 额度共享。本地 Agent 只需等待云端审查结果（通常 10 分钟内），无需消耗本地 Token。

关键要点

• 工作流核心：OMH 通过 harness Skill 强制实施“收集-计划-实现-审查”的闭环，确保开发过程可控。
• 资源解耦：将“只读/分析”任务（Plan 阶段）移至 Web 端，将“代码修改”任务（实现阶段）移至本地，将“代码审查”任务移至云端 Review 服务，实现各平台优势最大化。
• 模型选型策略：
  • Plan 阶段：使用 Web 端高额度模型（如 GPT 5.5 Web）。
  • 实现阶段：使用本地次旗舰模型（如 GPT 5.4 或更便宜的模型）。
  • 审查阶段：使用云端 Codex Review（独立额度，不占本地配额）。
• 开发规范：
  • 坚持 PR 式开发，每个 PR 对应清晰单一的目标。
  • 使用分支（Worktrees）进行开发，避免污染主分支。
  • 优先收集纯净上下文，避免多 Agent 无效讨论。
• 技术实现：
  • 初始化命令：npx @doraemon-hug-u/oh-my-harness。
  • 支持平台：目前支持 Codex 和 OpenCode，架构设计允许扩展至其他平台。
  • 依赖 Skill：整合了 mattpocock 的 TDD 和 superpowers 的 Debug/Review 技能。

意义与影响

OMH 工作流为 AI 辅助编程提供了一套可落地的工程化解决方案。它不仅仅是一个工具，更是一种**“AI 原生软件工程”**的实践范式：

1. 降低经济门槛：通过精细化的 Token 管理和订阅权益复用，使得个人开发者或小型团队能够以更低的成本使用高级 AI 编程能力，让“订阅物尽其用”。
2. 提升代码质量：通过强制的 Harness 循环和明确的 Plan 机制，减少了 AI 生成代码的随机性和幻觉，提高了代码与需求的对齐度。
3. 推动社区协作：作为开源项目，OMH 鼓励社区贡献 PR 和 Skill 适配，有助于形成标准化的 AI 开发工作流最佳实践。
4. 启发后续工具设计：其“解耦阶段”和“