1.告别 AI 编码“随机漂移”:Claude Code Harness 如何给你的编程戴上纪律的紧箍咒

用 AI 写代码越来越像开盲盒？计划丢失、测试被跳、审查滞后、上线凭感觉——Harness 用一套“计划→工作→审查→发布”的闭环，把 AI 助手拉回工程正轨。

你为什么需要读这篇文章？

你是否经历过这样的场景：让 Claude 或 Copilot 帮你重构一个模块，它立刻开始改代码，但改着改着就忘了原来的需求，测试没写、审查也省了，最后提交时你只能靠记忆来确认“应该没问题吧”。这不是你的错——大型语言模型本质上是概率生成器，在没有明确约束时，它们会“漂移”。

Claude Code Harness（下称 Harness）就是针对这个问题设计的：它不改变 AI 的能力，而是改变你与 AI 协作的流程。无论你是资深开发者还是刚接触编程的小白，都能通过它获得可重复、可审查、可发布的工程产出。

Harness 是什么？

官方口号：Plan. Work. Review. Ship. （规划、执行、审查、发布）

它是一个用于 Claude Code（也兼容 Codex、OpenCode、Cursor 等）的工作流纪律框架。把它想象成一个“工程管家”，它：

把模糊的对话式编程变成结构化的五步操作（5 个动词技能）；
强制你在 AI 动手前先确认计划，执行后独立审查，发布前检查证据；
规定“未知的东西就标成未知”，不允许 AI 胡编数据；
全程留下可追溯的文档和验证记录，让每一次提交都有据可查。

它本身是一个 Claude Code 插件，安装只需 30 秒，学习曲线几乎为零。

它能解决哪些实际问题？

传统 AI 编码痛点	Harness 的解决方式
需求记在聊天里，一刷新就忘了	自动生成 `spec.md`（规格说明）和 `Plans.md`（计划），持久化在代码仓库中
AI 为了“完成任务”而跳过测试	任务若要求 TDD，必须在实施时写测试并通过，否则无法继续
修改代码和审查代码是同一个人（同一个 AI）	`/harness-review` 独立执行审查，重大发现会阻塞完成
发布时缺少证据，全靠记忆打包	`/harness-release` 检查 CHANGELOG、标签、验证记录，只打包经验证的内容
不确定 AI 有没有偷偷“编造”依赖或数据	未知信息显式标为 `unknown`，阻止 AI 凭空创造

从安装到第一次发布：手把手操作指南

前置要求

拥有 **Claude Code v2.1+**（推荐）或其他兼容工具（Codex CLI、OpenCode 等，详见下文）。
一个本地的项目仓库，并有写入权限。
无需 Node.js，Harness 的守护引擎是 Go 原生编译的。

第 0 步：安装（30 秒）

在 Claude Code 的对话中依次输入：

/plugin marketplace add Chachamaru127/claude-code-harness
/plugin install claude-code-harness@claude-code-harness-marketplace
/harness-setup

/harness-setup 会自动创建项目级的指导文件、命令入口和钩子，将仓库调整为“Harness 就绪”状态。

第 1 步：规划（Plan）——把你的意图变成书面合约

想象你要“改进 README 的引导流程”。不要直接让 AI 改，而是输入：

/harness-plan Improve the README onboarding flow

Harness 会分析你的话，草拟出：

spec.md：目标、范围、验收标准、未知项。
Plans.md：可执行的任务清单，每个任务都有编号（如 1.1.1）。

这时你的工作不是写计划，而是审核并纠正 AI 的草稿。如果生成的合约有问题，直接回复修改意见；没问题则批准。

小白友好解释：就像你请装修队装修，他们先给你看设计图和施工方案，你点头了他们才动工。Harness 就是强迫 AI 先画图。

第 2 步：实施（Work）——只做批准过的事

计划通过后，可以逐步执行任务。比如只做第一个子任务：

/harness-work 1.1.1

Harness 会精确实施该任务，如果任务要求 TDD（测试驱动开发），它必须写测试并通过，否则会报错。执行过程中所有产出（代码、测试结果）都会记录。

如果想一口气跑完整个计划，可以使用：

/harness-work all

但官方建议仅在计划清晰且仓库基线已知时使用。

第 3 步：独立审查（Review）——把“警察”和“小偷”分开

实施完成后，不要让同一个 AI 审查自己写的代码。输入：

/harness-review

这会触发一个独立的审查流程，它会基于计划和验收标准检查代码。重大发现会被标记为阻塞项，直到你或 AI 修掉它们才能进入下一步。

第 4 步：发布/打包（Release）——只交付有证据的东西

当你对结果满意后，执行：

/harness-release

它会检查发布就绪状态：标签是否正确、CHANGELOG 是否更新、验证证据是否齐全。最终帮你生成一个“证据包”，直接用于 PR 或正式发布。

工作流全景图

阶段	产出物	门禁
调研	证据 + 未知项清单	禁止将未观测到的数据提升为断言
计划	`spec.md` + `Plans.md`	用户批准或纠正 AI 生成的合约
实施	代码 + 测试	若任务要求 TDD 则必须执行
审查	独立审查意见	重大问题阻塞完成
打包	证据包	满足发布预检条件
发布	标签/发布产物	仅发布路径通过检查才执行

不止 Claude Code：多工具兼容矩阵

Harness 设计上不绑定单一工具，但承诺的支持程度不同：

工具	支持等级	安装方式
Claude Code	✅ 完全支持	插件市场一键安装 + `/harness-setup`
Codex CLI	🟡 内部兼容	`scripts/setup-codex.sh --user`
OpenCode	🟡 内部兼容	`scripts/setup-opencode.sh`
Cursor	🟡 内部兼容	`scripts/setup-cursor.sh` （真实目录本地安装）
Codex App	🔶 候选	仅烟雾测试，不共享 CLI 证明
GitHub Copilot CLI	🔶 候选	仅手动配置研究
Antigravity CLI	❌ 未来/不支持	本阶段无最终用户安装路径

“内部兼容”意味着提供了适配脚本，但作者并未声称运行时行为完全对等。每个工具的边界都极其严谨。

进阶玩法：你不是一个人在战斗

当你熟悉基本流程后，可以尝试这些高级功能：

Breezing（团队模式）：将大任务拆分为 Planner（规划者）、Critic（批评者）、Worker（工作者）三种角色，模拟多人协作。
Codex 作为第二审查员：通过 scripts/codex-companion.sh 让 Codex 给出结构化审查意见，形成交叉验证。
跨会话记忆：搭配可选组件 harness-mem，让 Harness 记住项目背景，避免每次都要重新交代上下文。

旧项目迁移指南

如果你已有复杂的 Claude Code 插件环境或手动配置，不要直接覆盖。先运行：

bin/harness doctor --migration-report

这个命令会罗列出旧的插件缓存、重复技能、符号链接等，不删除任何数据，让你安全地评估影响后再清理。

谁最适合用它？

个人开发者：希望规范自己的 AI 编码习惯，让产出能自信地放进正式项目。
开源维护者：想为贡献者提供一致的 AI 辅助流程，降低 review 成本。
技术团队：需要将 AI 编码纳入 CI/CD 和质量管理体系，确保代码可追溯、可审计。
编程初学者：通过结构化工作流学习“正确的开发顺序”，避免养成跳过测试、不做计划的坏习惯。

结语：把纪律还给工程

AI 编码工具的魔力在于速度，但速度失控就是灾难。Claude Code Harness 没有给 AI 添加魔法，它只是把软件工程中多年验证的最佳实践——计划驱动、测试先行、审查独立、发布有据——强行植入到你和 AI 的对话里。

它或许会让你觉得“多了一步”，但这一步正是专业与业余的分界线。下一次当你的 AI 助手又想直接改代码时，试试对它说：/harness-plan。

项目地址：https://github.com/Chachamaru127/claude-code-harness
遵循 MIT 协议，欢迎提 Issue 和 PR。