📌 项目地址：Chachamaru127/claude-code-harness | ⭐ 1,770 颗星 | 🔧 Shell | 📜 未标注
痛点：AI编码像开盲盒
我用Claude Code写了半年后端。不是我挑剔，是它实在太“主动”了。交代“修这个函数边界条件”，几分钟后发现变量名被改了。说过“加个日志”，它顺手重构了异常处理。
事后翻聊天记录找“这个函数对应哪个需求”要半小时起步。问题有一个：AI编码没有可追溯的执行路径。你没法指定“只做A，不做B”，更没法验证它到底做了哪些改动。
Chachamaru127/claude-code-harness有1770个Star。它不做代码生成增强，只加了一层流程控制。装完后，默认工作方式从“ask the agent to code”变成了：写规格→实现批准切片→验证→独立审查→打包证据。
5个动词管住AI
Harness把AI交互锁在5条命令里。每个命令干一件事，不交叉。
/harness-plan：生成或更新spec.md和Plans.md，包含需求范围、验收条件、明确列出的未知项、停止条件/harness-work：只实现计划里批准的切片，配TDD和验证/harness-review：独立审查结果，和实施者分离/harness-sync：同步状态/harness-release：只打包通过验证的证据
支撑这5条命令的是两个Markdown文件。
spec.md记录“要什么”和“不要什么”。关键规则：数据AI没看到必须标记unknown，不能自己编。这阻止了“我觉得这样更好”的惯性偏离。
Plans.md把需求拆成带编号的子任务。比如“需求1”下面有“1.1 模块A”、“1.2 模块B”。/harness-work 1.1.1只会动对应编号的模块。
README特别提了team_validation_mode：非重要计划会触发团队验证模式，通过子Agent或人工检查确认spec和Plans一致性、内存复用、产品匹配、安全匹配、以及“实际可工作”。注意“非重要”这个条件——小改动不走这个流程，避免负担过重。
安装到第一个循环：15分钟
安装3条命令，来自README：
claude
/plugin marketplace add Chachamaru127/claude-code-harness
/plugin install claude-code-harness@claude-code-harness-marketplace
/harness-setup装完跑第一个请求：
/harness-plan Improve the README onboarding flowHarness生成spec.md和Plans.md草稿。README有一句重要的话：“Your job is not to hand-write the plan. It is to approve or correct the generated contract before execution continues.”
翻译过来：你的工作是批准或纠正生成的合约，不是手写计划。
我试了一下。AI生成的spec.md列了需求范围和验收条件。我发现一个条件写窄了，回复了修改意见。AI根据反馈更新了文件。整个过程不到3分钟。然后执行/harness-work 1.1.1，AI只处理这个子任务。改完了跑/harness-review，拿到一份独立审查报告。
README建议新用户从Tool-first onboarding开始，现有用户先跑迁移检查再清理或重装。非技术人员可以看常用词汇表。
我试了一个月，三件事变了
边界清晰了。 以前说“优化用户模块”，AI可能重构接口、改数据库字段、调整前端交互。现在写好spec.md和Plans.md，给/harness-work 1.1.1，它只动1.1.1对应的模块。改完了，其他代码不动。这是用文件约束替代了口头约束。
审查有据可查。 /harness-review执行后，审查报告会指出每个子任务是否通过验证。交付时/harness-release只打包通过这些验证的证据。不用再靠记忆对需求。这个机制的意义在于：即使换了人接手，审查历史也是可读的。
小改动成本低。 修正文案、更新状态这类小事，README明确说了“stay lightweight”。不是每个改动都要走5步。我测过，改一个提示文案：跑/harness-plan更新spec.md，确认，/harness-work对应编号。三步搞定。
成本和边界
计划文件需要维护。 团队场景下，只有一个人更新spec.md和Plans.md，文件会滞后。我每周花5分钟过一遍文件是否对得上实际状态。这个维护成本在大项目里会上升，但比起翻半小时聊天记录，还是划算的。
需要适应“只看结果不盯过程”。 习惯事必躬亲的开发者会觉得“为什么不让我看它怎么写的代码”。但Harness的设计就是让你只审计划、派任务、看结果，中间编码和验证时间可以去做别的事。
依赖Claude Code插件系统。 README提到适配了Codex和OpenCode两套路径。如果你用其他AI编码工具，需要先跑/harness-setup看能否正常响应。不是通用的。
最适合的三类工作：复杂Bug修复（在计划里写明“只修这个Bug，其他不动”）、重构关键模块（每个子任务独立测试，减少回归风险）、有严格验收要求的功能（每步验证都有记录）。
不适合的场景：一次性原型（写计划时间比写代码还长）、临时调试脚本（成本超过收益）。
总结
给AI编码加流程控制，Harness是目前最直接的做法。两个文件，5条命令，把不可控的AI对话转成可重复的执行流程。
15分钟装一次试试。每次交付都能拿到一份可追溯的文档，而不是需要翻半小时聊天记录才能搞清“这个函数对应哪个需求”。
如果你的痛点和我一样，不是AI写错代码，是AI写了你没让写的代码，Harness值得一试。