Harness Engineering：防止 AI 代码失控
AI 生成的代码看似完美，却会悄悄侵蚀代码库的一致性。Birgitta Boeckeler 提出的 Harness Engineering 概念，通过上下文工程、架构约束和定期垃圾回收，为 AI 辅助开发构建了一套确定性防护网。这套方法不依赖 AI 的自觉，而是利用测试夹具的逻辑，持续验证代码是否符合团队约定的架构决策与命名规范。从 Unverified 到 Deterministic 的渐进硬化机制，让约束随项目成熟而进化。最终，这套系统不仅防止代码熵增，还能通过自我反思循环，让防护网本身随经验不断升级，确保人类始终掌握最终决策权。
测试夹具并不信任程序员，它负责验证。
HN 评论区
42- ricardobeat
Harness Engineering 这个术语并非源自 Birgitta Boeckeler 在 martinfowler.com 上的文章。它最早是由 Mitchel Hashimoto 在几个月前的博客文章《My AI adoption journey》[1] 中提出的，随后在一周内就被 OpenAI [2] 迅速采用。
另外值得注意的是，这篇文章不仅完全是由 AI 生成的，而且其目标读者是其他 AI 代理，而非我们人类。
- iTokio
亲历一项新技术的诞生，并观察人们如何边摸索边试图理解它，这确实令人着迷。
就我个人而言，我认为围绕 AI 的许多词汇，如 harness、SKILLS、agents、RAG 等，大多是生造词，或者接近生造词。尽管人们（往往是在事后）试图赋予它们意义，但这些词本身并没有深刻的语义。
它们只是流行语，因为足够新颖，人们便喜欢用它们来标榜新知识，或者用来推销产品。
但在抽象层面上，我们可以用 AI tooling 代替 harness；而在更具体的应用场景中，使用更精确的术语会更好，比如 agent loop、CLI、IDE 等。
在论文争相博取眼球的阶段，这曾是一场有趣的游戏。但现在既然它已成为一项成熟的技术，我希望我们能找到更精确、更有意义的词汇。
- gardnr
这里是这篇文章所基于的原文：https://martinfowler.com/articles/harness-engineering.html
以下是原作者在播客中谈论该话题的链接：https://open.spotify.com/episode/4FxEdjXldNhoh67KYVmbDu
- davedx
这部分内容似乎很相关——他们明确区分了 HARNESS.md 文档和 AGENTS.md 文档。这其实挺有意思的：https://habitat-thinking.github.io/ai-literacy-superpowers/p...
- lacoolj
我不说这是 AI 生成的，但这篇文章内容非常密集，读起来不像那种能让我轻松获取信息的东西。