该文章介绍了“驾驭工程”这一实践，即通过确定性工具、基于代理的审查和定期熵检查来约束AI辅助代码生成，确保AI生成代码长期保持正确和连贯。文章阐述了其起源、构成及插件实现方式。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删减了与主题无关的链接和格式信息。

标题：驾驭工程（Harness Engineering）

核心概念： 驾驭工程是一种实践，旨在通过确定性工具、基于AI代理的审查和定期熵值检查，来约束AI辅助代码生成，确保AI生成的代码在长期内保持正确性和一致性。

起源： 该术语源自Birgitta Boeckeler在martinfowler.com上发表的文章。她观察到，AI编程助手倾向于生成看似合理但会逐渐偏离团队约定的代码，例如遗忘规范、重复错误，导致代码库内部一致性缓慢退化。Boeckeler的洞见在于，这个问题在软件工程中已有类似解决方案：测试框架。测试不保证代码正确，但能检测代码何时不再正确。同理，AI代码也需要一个“驾驭框架”，但它检查的范围更广，不仅包括功能正确性，还包括架构决策、命名规范、安全约束等团队约定。

三大组成部分：

1. 上下文工程： 确保AI了解其所需的所有项目知识。这通过维护一个专门的文档（如HARNESS.md）来实现，该文档记录技术栈、架构决策、命名规范、约束及其理由。它不同于面向人类的README，是AI的知识库，需要精确、具体且保持更新。

2. 架构约束： 即使有上下文文档，AI仍可能违反规则。架构约束是捕捉这些违规行为的机制，即“验证点”。验证点分为两类：

   • 确定性工具： 如linter、脚本、正则检查等，能精确表达约束时优先使用，快速、可靠。
   • 基于代理的审查： 当约束涉及意图、语义等难以用机械规则表达时，由语言模型进行判断。成本更高，但能捕捉脚本无法发现的问题。 目标是遵循“渐进硬化”原则，随着对约束的理解加深，逐步将基于代理的检查迁移为确定性检查。

3. 垃圾回收： 代码库是活的系统，熵会随时间累积（如死代码、过期的TODO注释、过时的依赖）。垃圾回收是定期对抗熵的过程，通过定时运行的代理或脚本检查代码库是否仍符合“清洁”标准，并生成报告，在问题变得严重前引起注意。

活的驾驭框架： 一个优秀的驾驭框架是动态的。HARNESS.md被设计为自引用文档，它不仅声明了哪些约束在生效，还追踪每个约束的状态（未验证、代理审查中、确定性执行）。通过“驾驭审计员”等机制，文档会定期更新以反映真实情况，形成一个反馈循环。这使得文档既是规范，也是健康记录，避免了被忽视和过时。

渐进硬化： 约束的成熟度遵循一个晋升阶梯： * 未验证： 已声明约束，但尚无检查机制。 * 代理： 通过AI代理进行审查，能捕捉大部分违规，但不可靠，需人工复核。 * 确定性： 约束被精确编码为脚本或linter规则，在CI中运行，通过或阻止合并。目标是始终向确定性状态演进。

插件实现方式： 该插件将验证点组织为三个执行循环： * 内循环（编辑时）： 轻量级、建议性的检查，在保存文件时运行，旨在尽早发现问题而不打断工作流。 * 中循环（PR时）： 严格的检查，在提交PR时运行，包含代理和确定性检查，有权阻止合并，是架构约束的主要执行点。 * 外循环（定时）： 调查性的检查，按计划（如每日、每周）运行，执行垃圾回收和驾驭审计，生成报告而非阻止操作。

自我改进维度： 该插件在原始框架基础上增加了自我学习能力。通过/reflect命令记录每次编码会话的经验教训，驾驭代理会利用这些记录进行决策。回归检测会分析违规历史，识别模式，并自动生成改进建议（如加强约束或更新上下文文档）。harness-init过程甚至能通过分析现有代码，自动推断并生成候选的HARNESS.md，降低初始构建成本，并支持团队逐步采用。

总结： 驾驭工程通过上下文、约束和垃圾回收三大组件，结合渐进硬化和自我改进机制，为AI辅助开发提供了一个动态、可演进的“安全网”，确保代码质量与团队约定的一致性。

根据评论内容，总结如下：

主要观点与论据：

1. 对“Harness Engineering”概念的质疑

   • 评论认为该术语是“提示工程”的翻版（评论15：“Is Harness Engineering the new Prompt Engineering?”），且部分内容被指为AI生成、面向机器而非人类（评论14：“this text is not only entirely AI generated, but meant for other agents to read, not us humans”）。
   • 评论指出“Harness”概念缺乏清晰定义，如“垃圾回收”被列为组件但实际未解决（评论7：“I don't know any harness that solves 'Garbage Collection'”）。

2. 对“AI Literacy框架”的批评

   • 评论质疑框架的实用性，认为其过度工程化，且作者背景可疑（评论2：“What even is this 'AI Literacy framework'? ... the author runs a consultancy ... listing a bunch of books he did not write”）。
   • 评论认为内容晦涩难懂（评论3：“very dense and doesn't read like something I could glean info from easily”）。

3. 对术语滥用的反思

   • 评论指出“Harness”“Agent”“RAG”等术语缺乏深刻语义，更多是营销工具（评论4：“words that do not have profound semantics ... people like to use them to claim a new knowledge, or to market a product”）。
   • 建议使用更精确的术语（如“agent loop”“CLI”“IDE”）替代抽象概念（评论4：“we could use AI tooling instead of harness in the abstract”）。

4. 对技术发展的观察

   • 部分评论认为“Harness”概念是技术演进中的自然现象（评论12：“This is oddly reassuring”），并提供了相关资源链接（评论9、10、13）。
   • 有评论指出“Harness”概念最早由Mitchel Hashimoto提出，后被OpenAI采用（评论14：“first used by Mitchel Hashimoto ... immediately picked up by OpenAI”）。

平衡性说明：
- 负面观点占主导，主要批评概念模糊、术语滥用及内容质量。
- 少数评论提供背景信息或工具链接（如评论5、11、16），但未形成系统性支持。
- 无评论明确肯定“Harness Engineering”的实用性或创新性。