线束工程

线束工程线束工程是通过确定性工具、基于代理的审查和定期熵检查围绕人工智能辅助代码生成的实践，以便人工智能生成的代码随着时间的推移保持正确和一致。本文档解释了这个想法的来源、它的组成以及这个插件如何实现它。起源 该术语来自 Birgitta Boeckeler 在 martinfowler.com 上的文章，该文章是在 ThoughtWorks 背景下编写的，团队使用 AI 编码助手交付真实软件。博克勒观察到许多团队都独立注意到的事情：人工智能助手生成看似合理的代码，但如果不受约束，它们就会漂移。他们忘记约定，重复错误，并慢慢侵蚀代码库的内部一致性。代码继续编译并通过测试。退化是安静的。 Boeckeler 的见解是，这个问题在软件工程中已经有了一个类似的解决方案：测试工具。测试不会通过构造使代码正确。他们检测代码何时不再正确。测试工具并不限制您编写的代码；而是对您所编写的代码进行限制。它是一种不断检查您编写的内容是否符合标准的机制。线束不信任程序员。它验证了。同样的逻辑也适用于人工智能辅助开发，但有一个关键区别。测试工具检查功能的正确性：程序是否执行了它应该执行的操作？人工智能编码的工具需要检查更广泛的内容：代码库是否仍然体现团队商定的架构决策、命名约定、安全约束和结构规则？功能测试是必要的，但还不够。您需要一种不同类型的安全带。这就是线束工程所提供的。三个组成部分 Boeckeler 描述了安全带必须解决的三类问题。情境工程人工智能编码助手只能在它知道的范围内工作。如果它不知道您的项目使用特定的日志记录库，它将发明自己的方法。如果它不知道您从不使用可变全局状态，它会在方便时使用它。如果它不知道所有数据库写入必须经过特定的抽象层，它将绕过该层。情境工程是一门确保人工智能知道它需要知道什么的学科。实际上，这意味着维护一个文档（在此插件的约定中为 HARNESS.md），该文档捕获堆栈、架构决策、命名约定、约束以及它们背后的基本原理。本文档不是供人类使用的自述文件。它是人工智能的知识库。它需要准确、具体并保持最新。区别很重要：自述文件解释了该项目的用途。上下文文档告诉 AI 代理必须做什么、不能做什么以及原因。这些是不同的文档，具有不同的受众和不同的更新节奏。架构约束 了解规则和执行规则是不同的问题。你可以将每一个约束写入 HARNESS.md 中，AI 仍然会违反它们，因为 AI 是一个针对合理性进行优化的概率系统，而不是一个遵循规则的机器。上下文工程减少了违规行为。它并没有消除它们。架构约束是捕获违规行为的机制。 Boeckeler 将执行点称为“验证槽”——开发工作流程中定义的时刻，在该时刻运行检查并通过或阻止进度。每个验证槽的关键设计决策是它是使用确定性工具还是基于代理的审查。确定性工具是 linter、脚本、正则表达式检查、文件结构断言 - 任何无需判断即可生成通过/失败结果的工具。当可以精确地表达约束时，这些是优选的。它们快速、便宜且在其规格范围内完全可靠。基于代理的审查是一种语言模型，根据约束描述查看代码并做出判断。当约束涉及难以表达为机械规则的意图、语义或模式时，这是必要的。代理成本更高，确定性更差，但它们可以捕获脚本无法捕获的内容。两种类型的验证槽都属于线束。随着时间的推移，目标是将约束从基于代理迁移到确定性，因为您对约束的理解足够清晰，可以精确地指定它。这就是渐进强化原理，如下所述。垃圾收集 代码库是一个有生命的系统。即使有良好的上下文工程和严格的架构约束，熵也会累积。死代码不断增长。 TODO 评论持续数月。依赖关系变得陈旧。在项目某个阶段有意义的抽象在后期就会成为障碍。早期建立的约定在变得不方便时会被悄悄放弃。垃圾收集是对抗这种熵的周期性过程