从零搭建 Harness Engineering 框架 ：Rule、Skill、Sub-Agent等工程落完整路径

Harness Engineering（脚手架工程）这个概念已经流行一阵了。网上大多数文章都停留在理论层面，反复解释为什么现代 AI 开发不能再依赖单个 Prompt、也不能把模型当成"聪明的代码自动补全"。不过这里有一个实际问题被反复提及：

概念我懂了。可一旦真要落到工程上，第一步到底该做什么？

Harness 这个词听起来宽泛而且像一种抽象的方法论。如果它没法落到具体的目录结构、文档、脚本和工作流上，那就只是一句漂亮口号。Harness Engineering 在不同项目上的呈现可以差得很远——有的项目重度依赖 CI/CD pipeline，有的依赖严格的开发规范，有的依赖多智能体（Multi-Agent）编排，也有的只是把一堆脚本和模板严格组织起来。但只要往下挖，会发现它们在解决同一个核心问题：

如何让 AI 在你的项目里稳定、可靠、可预测地交付你想要的结果。

下面这张图把脚手架成熟度模型（Harness Maturity Model）划分成五个等级

实际使用场景：你处在哪一级？

• Level 0：适合一次性脚本或纯粹的实验。你不在意可维护性，只想看一个想法现在能不能跑通。
• Level 1（约束）：适合个人开发者和 MVP 阶段。你需要 AI 加速样板代码，但每一行代码的架构判断和审查仍由你来做。
• Level 2（反馈回路）：生产期初创公司和小团队的最佳位置。AI 在这里成为可靠的初级伙伴。你信任代码，是因为系统本身——测试、CI、Linter——会捕获错误，而不是只靠你的肉眼。
• Level 3（专业化分工）：复杂多服务系统的必经之路。当代码库大到一个人脑子装不下，就需要拆分 AI 角色（规划者、编码者、测试者），用来管理上下文、避免回归。
• Level 4（自治）：留给平台级或 AI 原生组织。当系统需要在无人干预下持续自我修复和重构时才用得上。

本文用一个最小化的 Go 项目 crypto snapshot API 作为贯穿全文的例子，一步步讲我们是怎么把 Harness 搭起来的。哪些做法奏效、哪些地方踩了坑、哪些最初以为够用后来证明远远不够。这样你就可以在自己的项目里从零搭一套 Harness Engineering 框架，从哪里下手、按什么顺序补全后续。

https://avoid.overfit.cn/post/4d63fe6ef47742e7addd2dcf419efe27