一个叫 Habitat-Thinking 的团队，把“Harness Engineering”这个概念做成了插件：ai-literacy-superpowers。它要解决的问题很具体：AI 编程助手写的代码能跑、能过测试，但一段时间后架构悄悄走样，命名乱了，约定被绕开了，没人第一时间发现。
这套插件的判断很直接：AI 生成代码不能只靠“生成时相信它”，得靠“生成后持续查它”。核心是一份叫 HARNESS.md 的文档，记录技术栈、架构决定和各项约束的执行状态。配合三层检查循环，验证被嵌进日常的编辑、提交、定期巡检里。
Harness engineering 做了什么：把验证做成常态
/harness-sync 命令能一键跑出一张对照表：文档里声明的约束，和代码实际验证出的结果，哪里对不上，一眼可见。团队不用凭记性去猜哪里出了问题。
具体怎么查，插件设计了三层循环，时机不同，容错也不同。
三层分别对应三件事：让 AI 随时知道项目规矩，在合并前卡住违规，给慢慢积累的技术债定期体检。开发者提交 PR 时，会多一道代理审查。如果误报，得花时间和它掰扯清楚，这是要接受的成本。
为什么重要：测试管对错，harness 管像不像自己
传统单元测试回答一个问题：这段代码做的事对不对。AI 助手最容易犯的错不是功能性 bug，而是它不知道你的项目从不用全局可变状态，不知道所有数据库写入必须走某个封装层。代码照样能跑、测试照样能过，只是悄悄破坏了团队定好的架构规矩。
| 检查方式 | 回答什么问题 | 会不会阻断合并 |
|---|---|---|
| 单元测试 | 功能对不对 | 会 |
| Lint / 静态检查 | 格式和简单规则有没有违反 | 会 |
| Harness 三层循环 | 架构、命名、约定、代码熵有没有漂移 | 视层级而定，middle loop 阻断，inner 和 outer 不阻断 |
这个思路最早由 Birgitta Boeckeler 在 ThoughtWorks 语境下提出，属于一个方法框架，不是行业标准。这次的新增是把它工程化：自我改进、审计、自动化都是插件加上去的，不是原始框架自带的部分。
最值得盯的限制：代理审查靠谱吗
代理审查让语言模型看代码、判断是否违反约束。这类判断能捕捉脚本抓不到的语义问题，但它本身不确定，会漏检也会误报，最后仍需要人复核。
真正靠谱的是确定性检查：脚本、linter、结构断言，跑出来就是过或不过，没有商量余地。插件给出的路径是渐进硬化——一条约束从“未验证”到“交给代理判断”，等团队看清这类违规的规律、能写成精确规则后，再固化成 CI 里的确定性检查，代理判断随之退场。
对负责引入 AI 编程工具的技术负责人来说，工作量不会因为上了插件就消失。反而多了一项：维护 HARNESS.md，盯着代理判断的准确率，决定哪些违规值得写成脚本。生产代码能不能合并，最后仍是人拍板，不是代理。
对已经在用 AI coding assistant 的团队，更现实的做法是先挑出现频率高、又能说清楚规则的违规类型下手做自动化，而不是指望一步到位全靠代理兜底。团队规模小、项目还在快速迭代阶段，这套体系的维护成本可能高于收益，不必急着上。
接下来值得盯的，是这套插件有没有更多团队公开使用数据，代理审查的误判率能不能被量化下来。目前看到的还是一个方法框架的早期插件化实践，谈不上被行业验证过。