Chachamaru127/claude-code-harness

TL;DR

Claude Code Harness 是一个针对 Claude Code 的插件化工作流框架，通过强制实施 Spec→Plan→Work→Review→Release 的契约驱动循环，解决 AI 编程中常见的上下文漂移、测试缺失和审查滞后问题。它值得关注的核心在于将 AI 的“自由发挥”约束在可验证的文档契约内，并引入独立的 Review 阶段。

它解决什么问题

原生 Claude Code 等 Agent 工具虽然代码生成能力强，但存在明显的工程化缺陷：计划仅存在于聊天上下文中，测试被视为可选项，代码审查往往在提交后才发生，且发布证据容易因记忆重置而丢失。随着 AI 辅助编程从“玩具”走向“生产”，开发者需要一种可重复、可审计的交付路径。该项目在 2025 年底出现，正值 AI Agent 从单轮对话向多阶段复杂工作流演进的关键节点，旨在填补“生成代码”与“交付可用软件”之间的工程鸿沟。

核心做法

Harness 的核心架构围绕 5 个动词技能（plan, work, review, sync, release）构建，强制将工作流标准化： 1. 契约驱动：通过 /harness-plan 生成 spec.md 和 Plans.md 作为唯一事实来源（Source of Truth），明确范围、验收标准和未知项。非平凡计划需经过多视角验证（安全、产品契合度等）。 2. 隔离执行：/harness-work 仅在批准的计划切片内执行，强制 TDD 和验证，未观察到的数据标记为 unknown 而非幻觉填充。 3. 独立审查：/harness-review 将审查与实现分离，重大发现直接阻断完成，确保质量门禁。 4. 证据打包：/harness-release 仅打包经过验证的证据用于 PR 或发布，确保可追溯性。底层使用 Go 编写的原生护栏引擎（Guardrail Engine），不依赖 Node.js，保证执行效率。

作者

项目由 Chachamaru127 维护。README 未提供作者的详细背景或过往项目履历，仅 Acknowledgments 中提及受 AI Masao 的层级技能设计和 Beagle 的测试防篡改模式启发。从项目结构看，作者具备较强的工程化思维，注重边界定义和迁移兼容性，但具体身份尚不明确。

社区反应

项目自 2025 年 12 月创建以来，迅速获得 2,109 Stars 和 216 Forks，显示出较高的关注度。Open Issues 仅 8 个，表明核心功能相对稳定或社区反馈渠道集中。主语言为 Shell（用于命令封装），但核心引擎为 Go，这种混合架构在插件生态中较为少见。由于项目较新，尚未形成大规模的第三方扩展或深度讨论，但 Star 增长速度暗示其在 Claude Code 用户群体中具有潜在的高采用率。

怎么上手

依赖：Claude Code v2.1+，项目仓库写权限，可选 harness-mem 用于跨会话记忆。硬件：无特殊要求，依赖云端 LLM 推理能力。 最小复现步骤： 1. 在 Claude Code 中运行： bash /plugin marketplace add Chachamaru127/claude-code-harness /plugin install claude-code-harness@claude-code-harness-marketplace /harness-setup 2. 执行 /harness-plan 并输入一个小任务（如 Improve the README onboarding flow）。 3. 审查生成的 spec.md 和 Plans.md，批准或修正。 4. 执行 /harness-work 1.1.1 实现具体任务。 5. 运行 /harness-review 获取独立审查结果。

争议与局限

工具锁定风险：目前主要支持 Claude Code，对 Codex、OpenCode 的支持标记为 internal-compatible 或 candidate，存在厂商锁定风险（推断：作者可能优先深耕 Claude 生态）。
流程刚性：强制 Spec→Plan→Work 循环可能对小任务（如简单 typo 修复）造成过度工程化，尽管 README 提到轻量任务可跳过，但默认行为可能增加认知负担（推断）。
审查质量依赖：/harness-review 的有效性高度依赖 LLM 的审查能力，若 LLM 无法识别深层架构问题，独立审查可能流于形式（合理推断）。
迁移成本：现有用户需运行 bin/harness doctor --migration-report 清理旧缓存和冲突，可能增加初始采用门槛。