我的Harness Engineering实践

所谓Harness Engineering，是通过强制性的工程约束和标准化的输入输出，将 AI 的不可预测性，收敛为确定性的交付。

下面是运行了多年的企业级全栈项目

[图示或嵌入内容已省略]

下面是运行了多年的企业级全栈项目，是一个Monorepo（前端后端代码都放在一个项目里），采用Spring Boot + React + PostgreSQL，部署在 Kubernetes 上，通过 Helm charts 管理多环境配置，Jenkins pipeline 做 CI/CD。

提示

这套东西就基本上规范了开发者的开发流程，而这套规范，换到Agent生成，就成了Harness Engineering的一部分。总体架构大概是这样

[图示已省略]

Spring Boot MVC 分层

说实话，我个人并不喜欢Spring Boot 这套东西，很啰嗦，每次加点小feature，就搞个几千行的代码变更。

[图示已省略]

这里只是加了一个很小的feature

但Spring Boot 能在企业应用中风靡这么久，有它的道理。Spring Boot的规范性强，约定和分层让 50 人的团队写出结构一致的代码。使用spring boot开发的软件架构如下，代码应该怎么放，挺清晰的。

[图示已省略]

这个分层结构对 AI agent 来说，本身就构成了一套 harness 约束。

当然，这套约束对AI有强制效果吗？我只能说，有效果，但AI非要瞎写时，我也管不住。那么，怎么才能把这套指导，变成强制约束呢？我们团队设置了几层约束：

强制规范约束

提示

项目配置了多层静态分析，确保：

Spotless（自动格式化）确保每行代码风格统一
Checkstyle（编码规范）约束类成员声明顺序、禁止 magic number
SpotBugs（缺陷检测）在编译期捕获常见 bug 模式
JaCoCo（覆盖率）设定 90% 行覆盖率硬门槛
ESLint + Prettier（前端）保持 React/TypeScript 代码一致性

当 AI 生成的代码过不了 lint、过不了覆盖率检查，它会被迫修正。这些质量检测系统构成了 harness 的第一道防线。

[图示已省略]

（注：以上这套分析用到的一些工具，例如JaCoCo，虽然是分析java用的，但过程可以借鉴，例如你用python，就用pytest-cov）

Pre-commit 约束

提示

在项目文件夹的 /github/hooks下面，放了三个代码：

pre-commit-lint.sh：运行lint检查
pre-commit-test.sh ：运行单元测试
commit-msg.sh：检查提交信息符合规范，必须带branch名称作为前缀，以方便review

[图示已省略]

可以看到，我们这套代码规范还是挺严格的。这形成了一个反馈闭环：AI 写代码 → 提交 → hooks 拦截 → AI 修复 → 再提交。整个过程不需要人介入，但质量被牢牢把控。

CI/CD约束

我可以在AutoJenkins文件里定义buildFlow，这样每次我提交代码，就会触发build。

        buildFlow            : [
                PULL_REQUEST: ['Build', 'Compile', 'Unit Test', 'Scan', 'scanAtSource','Sonar', 'Quality Gate'],
                QA          : ['Build', 'Compile', 'Unit Test'],
                RELEASE     : ['Build', 'Compile', 'Unit Test'],
        ],

可以看到，在不同的开发阶段，可以采用不同标准的质量管理方法啊，例如PR时由于要并入Agent的代码，需要更多步骤检查，而并入后，在其他阶段，只需要跑Unit Test就够了。

将工作流编进skills里进行约束

当然，CI/CD+软件工程规范并非Harness Engineering的全部，但也80%了。Harness Engineering的最终目的，是人搭好脚手架后，Agent能够在尽量少人工干预的情况下，尽可能多且好的完成工作。剩下的20%，可以通过最近很火的skills来实现。

我定义了几个skills，它们定义了：

本地开发环境怎么起（Docker Compose → 数据库 → Backend → Frontend 的启动顺序）

Git 工作流是什么（rebase 策略、冲突解决方式、分支命名）

PR 要满足什么质量才能合并

CI/CD 的 delta build 机制（只构建有变更的子项目）

当然，这些流程能不能构成约束？其实是可以的，例如本地环境怎么起这一块，它不follow我的流程，它就起不来。

达到的效果

通过这套Harness Engineering的方案，团队实现了「一劳永逸」的Vibe Coding体验，目前我们日常是这样的：

每周plan会议，讨论这周要实现的东西

在每个ticket里，描述我们要实现的feature

在Cursor里，通过skils，读取ticket里的内容，然后开始自动开发

开发完成，本地会跑lint，JaCoCo，checkstyle，单元测试等。

开发者在这一步介入，通过skills让代码在本地跑一下，看看feature实现得是否符合预期。

本地review一下，没问题，通过skills，自动创建branch（branch名字和ticket名字一样以方便管理），提交，创建PR

通知团队成员一起review。虽然多数时候大家给的评论都是「LGTM」，但我认为，还是很有必要review的，虽然AI写的代码你不一定每一行都看，但你得大概有个印象，这是mental alignment的一部分。

总结

可以看到，我们做Harness Engineering，有三层约束：

第一层：架构级约束（Architecture as Harness），例如 Spring Boot MVC。
第二层：质量级约束（Quality as Harness），例如Spotless, Checkstyle, JaCoCo等，让 Agent生成的代码质量在编译器和测试报告中进化。
第三层：流程级约束（Workflow as Harness）。整合 Git Hooks 和 Jenkins CI/CD，实现反馈闭环（Feedback Loop），让AI 不只是写代码，它必须自己通过你设定的重重关卡。

没有Harness Engineering，技术债就会膨胀。以前我们设定软件工程规范，其实是需要取一个平衡值的，既不能没有规范导致技术债膨胀，也不能规范太多导致大家开发效率太低。而Agentic coding年代，可以再严格点，反正是Agent来写，随便压榨！