Harness Engineering 落地实践：别再重复造轮子了，这些框架值得一看

最近开启了一个新项目，主要精力都花在了“Harness Engineering”（套索工程？或者是管理 AI 那个绳套？）的搭建上。说实话，这词儿听起来挺玄乎，但干起来全是实打活的。

为什么我们需要 Harness？

现在的软件开发，尤其是引入了 AI 辅助编程后，最怕的是什么？就是 AI 瞎写。你让它写个功能，它可能给你整出一堆看起来能跑但实际上不仅不符合项目规范，甚至可能带着安全漏洞的代码。

Harness Engineering 核心概念：通过 Rules、Skills 和 Hooks 约束 AI 生成。

Harness Engineering 的核心目的，就是要把项目规范和开发流程固化下来，像给 AI 套上缰绳一样。这里就要提到几个关键概念：

• Rules（规则）：基础的代码规范，比如命名法、禁止使用的库等。
• Skills（技能）：项目特定的能力，比如如何调用内部的 API，如何处理特定的业务逻辑。
• Hooks（钩子）：在代码生成的特定阶段介入，进行检视或修改。
• MCP (Model Context Protocol) & Subagents：通过子代理和上下文协议，让 AI 能理解更宏大的项目背景。

CC vs Codex：理念之争

CC 强调约束与连续性，更适合规范化落地。

在具体选型时，我对比了 CC（Continuity and Constraints，这里泛指一类强调约束和连续性的设计理念）和 Codex 的设计思路。

坦白讲，CC 的设计理念明显更适合 Harness。Codex 更像是一个“大力出奇迹”的生成器，你给它需求，它给你代码。而 CC 强调的是在约束中生成，它能更好地利用 Rules、Skills 和 Hooks 来限制 AI 的发挥空间。这不仅能防止 AI 跑偏，还能让生成的代码更贴合现有项目的架构。

真的有必要每个人都自己造轮子吗？

搭建这套东西，初期真的挺痛苦的。你要定义规则、编写 Skills、配置 Hooks……我不禁在想：这种基础设施建设的工作，真的有必要每个团队都从零开始吗？

Superpowers：全能型开箱即用方案。

软件开发领域已经非常成熟了，没人会现在从写汇编开始搞一个 Web 框架。但在 AI 工程化领域，大家似乎又回到了“手工作坊”时代。

Spec-kit：更灵活、可控的“硬核”方案。

成熟的框架推荐

如果你也在做类似的事情，别急着全部自己写，市面上已经有一些值得参考的框架或工具链了，主要有两个方向值得重点关注：

1. Superpowers

这个框架的定位比较全能。它试图把 Harness Engineering 需要的各个环节都串起来。如果你希望有一个开箱即用、功能大而全的方案，Superpowers 是个不错的起点。它的社区活跃度还不错，文档也比较全。

2. Spec-kit

相比之下，Spec-kit 走的是一条更“硬核”、更灵活的路。它更侧重于“规范即代码”（Spec as Code）。如果你对定制化要求极高，或者你的项目流程非常独特，不想被框架束缚住手脚，Spec-kit 可能更适合你。它可能需要你多写一些配置代码，但换来的却是极高的可控性。

总结与建议

• 别盲目从零搭建：除非你的业务逻辑真的天下无双，否则先看看 Superpowers 或者 Spec-kit 能不能解决你 80% 的问题。
• CC 思维很重要：在配置这些工具时，多思考如何通过“约束”来保证质量，而不是单纯依赖 AI 的“生成能力”。
• 循序渐进：先定基础 Rules（代码风格），再上 Skills（业务逻辑），最后玩转 Hooks 和 MCP 工作流。

Harness Engineering 绝对是未来的趋势，毕竟把 AI 管好用好，比单纯让它写代码更重要。如果你也在搞这个，欢迎交流踩坑经验！