人工智能编码与安全自动化之间的缺失层

约束体系工程不是让自主智能体今天就接管流水线。它是在现在构建结构，让安全自动化在未来成为可能。

大多数企业工程团队的实际位置

咱们先从现实说起。

在大型金融机构，大多数开发者正在用 GitHub Copilot、Cursor 或 Claude 来更快地写代码。一些团队在本地用这些工具来搭建服务、生成样板代码和起草单元测试。更小的一群人在实验能在开发环境内规划和执行多步编码任务的智能体工具。

这就是 2026 年 3 月大多数企业团队所处的位置。

自主人工智能智能体自行向仓库提交代码、运行流水线或做出部署决策，目前尚未大规模运行。监管、变更管理和单纯的风险承受力让这最早也是 2027 或 2028 年才能聊的事。

但一个真实的问题已经在这里了。

开发者们产出的代码比以前多得多。这些代码流经的是为更慢节奏设计的同一套测试关卡、同一套安全扫描和同一套审批工作流。为每周开 10 个合并请求的团队构建的测试套件，现在要支持每周开 40 个合并请求的团队。安全发现成倍增加。评审队列增长。发布经理、应用安全工程师、测试人员和合规团队吸收着额外的负载。

这就是约束体系工程旨在弥合的缺口。

约束体系到底是什么

这个词来自 OpenAI 2026 年 2 月的文章，约束体系工程：在智能体优先的世界中利用 Codex，关于构建和发布一个「0 行手写代码」的内部测试版产品。他们的设置很极端：一个小团队在大规模运行高度自动化的智能体工作流。大多数企业工程组织远未达到这个程度。

但核心理念是可以迁移的。

约束体系是围绕人工智能辅助软件交付构建的一套约束、上下文和反馈循环，让下游的人——测试人员、安全工程师、发布经理和合规团队——不必为人工智能的每个错误买单。

长期优势不会属于拥有最大模型的组织。它将属于围绕该模型拥有最佳运营环境的组织。成败更少取决于原始模型智能，而更多取决于包裹它的系统的质量。

那个系统不会一下子出现。它分三个阶段发展：基础、增强和自动化。

为什么在受监管环境中这很重要

对于美国金融机构，人工智能采用并非发生在监管真空中。银行很大程度上被期望将现有控制措施应用于新的人工智能用例：模型风险管理、第三方风险管理，以及在决策影响消费者时的可解释性。约束体系工程之所以重要，是因为它把人工智能辅助工作变成更容易治理的东西：有文档记录的输入、有边界的工作流、可追溯的决策和清晰的评审点。

约束体系成熟度的三个阶段

大多数团队将经历相同的演进。

第一阶段：基础

基础是团队创建人工智能需要才能有用而不制造混乱的结构。仓库上下文开始成形。核心标准被写下来。需求文档开始在实现之前存在。提示词模式、提交前检查和工作流纪律成为共享实践而非个人习惯。在这个阶段，目标不是自动化任何东西。而是让人工智能辅助开发变得可读、可重复且更容易治理。

在银行业，这一基础也支持模型风险纪律。团队需要定义预期用途、约束输出、验证高影响行为，并让人类对决策负责。一个好的约束体系让这些控制成为工程工作流的一部分，而非单独的事后练习。

第二阶段：增强

一旦结构存在，团队就开始用人工智能来加强交付系统本身。人工智能不再只是帮助开发者更快地写代码。它帮助生成测试修复、起草部署文档、解释安全发现、总结风险，并将代码变更连接回标准和需求文档。人类仍然明确掌权，但他们的工作流现在在交付摩擦最大的地方被人工智能放大了。

第三阶段：自动化

只有在基础和增强到位之后，自动化才变得安全。智能体开始在定义的权限边界内作用于交付过程。一些修复可以自动完成。一些测试可以自我更新。一些部署可以在没有人类干预的情况下进行。一些回滚决策可以由策略和遥测触发。人类仍然治理系统，但他们不再需要手动执行其中的每一步。

这个顺序很重要。

自动化只在增强已经使工作流结构化和机器可读之后才有效。增强只在基础已经创建了可靠的上下文和标准之后才有效。试图跳过的团队通常会发现，他们缺少的正是自动化所依赖的输入。

知识库：一切之下的层

在测试、部署、安全或合规之前，有一个基础层在它们之下：仓库内部持续维护的知识库。

OpenAI 的团队在同一篇文章中将此确定为他们约束体系的第一个也是最重要的部分。对于企业团队来说，这可能是最高杠杆的起步点。

这也是需求文档驱动开发从理论走向实践的地方。关于这一方法的有用概述，参见 Thoughtworks 2025 年 12 月的文章，需求文档驱动开发：解读 2025 年关键的新人工智能辅助工程实践。

仓库需要知道什么

当人工智能编码工具没有有意义的上下文时，它产生的代码看起来合理却不适合周围的系统。它破坏本地模式、忽略服务边界、错过资深工程师记在脑子里的领域特定约束。

那些知识必须活在仓库本身：架构决策、服务边界、数据契约、性能约束、合规要求和批准的模式。不在 Confluence 里。不在 Slack 里。不在资深工程师的记忆里。而是在版本控制文件中，与它们描述的代码生活在一起。

OpenAI 的团队先尝试了显而易见的捷径：一个包含每条规则的大型指令文件。它变成了过时规则的墓地。当所有东西都被标记为重要时，没有东西是容易使用的。

更好的方法是模块化、可导航的文档。为架构、服务边界、数据契约、部署约束和运营标准准备单独的文件。处理特定任务的智能体应该能找到正确的上下文，而不必吞掉整个仓库。

这就是需求文档驱动开发的实践价值。需求文档不只是生成代码的提示词。它们是捕捉意图、约束和设计选择的活产物，既服务于人类也服务于人工智能。

两种仓库知识

Birgitta Böckeler 在 Martin Fowler 的文章 理解需求文档驱动开发：Kiro、spec-kit 和 Tessl 中提出了一个有用的区分：记忆库 vs 需求文档。

记忆库是始终开启的层。它包括架构、模块边界、数据分类规则、批准的模式、反模式、性能期望和监管约束。它告诉人工智能它正在处理什么样的系统。

需求文档是任务特定的。它们在代码生成之前描述一个功能应该做什么：输入、输出、边界情况、约束和验收标准。人工智能使用需求文档来生成代码，而需求文档留在仓库中作为未来变更的真实来源。

这两个层共同回答了每个人工智能系统都在隐含问的两个问题：

我在什么样的世界里运作？

我到底应该建造什么？

在银行里这看起来是什么样

大型金融机构已经拥有大部分这些知识。只是没有以人工智能能用的形式写下来。

批准的加密套件、个人身份信息处理规则、数据驻留要求、服务所有权、通信模式和变更分类已经存在于某处的政策文档、架构委员会或资深工程师的头脑中。工作就是将其翻译成简短的精确文档，活在仓库里。

一个简单的起始结构可能长这样：

这些文档不需要很长。一份 300 字的安全标准文件，带两个具体例子，比一份 40 页的政策 PDF 更有用。目标不是完整性。目标是足够的清晰度，让人工智能生成的代码看起来属于这个系统，而不是某个通用的示例应用。

应用于知识库的三个阶段

第一阶段：基础

从在几乎每个人工智能编码会话中都有帮助的记忆库文档开始：架构概述、安全标准和性能概况。保持简短并提交到仓库。团队开始为选定的功能编写轻量级需求文档，让意图在实现之前存在。目标很简单：创建一个可靠的仓库上下文基础，减少可避免的人工智能错误。

第二阶段：增强

一旦这些文档存在，它们就开始塑造工作流。需求文档在代码生成之前成为预期。记忆库有明确的负责人和更新期望。需求文档与代码一起被评审，所以团队不仅问代码是否有效，还问它是否符合需求文档。当代码变更影响已记录的行为时，人工智能可以为人类审批起草文档更新。在这个阶段，知识库成为承重结构。流水线引用它。静态应用安全测试规则从中提取。合规证据追溯回它。

第三阶段：自动化

后台智能体扫描文档与实现之间的漂移：不再匹配契约的数据模型、超出其文档边界增长的服务、不再匹配行为的需求文档。它们打开合并请求来修复不一致，让知识库保持诚实。在这个阶段，需求文档不只是文档。它成为自动化的运营输入。

知识库让其他每个领域都更好。更好的上下文改善测试。更好的标准改善安全。更好的映射改善合规。更好的性能概况减少低效的人工智能生成代码。

先构建这一层。

测试

现在的问题

一个开发者用 Cursor 或 Copilot 在两小时内而不是八小时内构建了一个功能。他们开一个合并请求。现有测试套件运行。一些测试失败，要么是因为人工智能引入了缺陷，要么是因为它改变了测试没预料到的接口。

现在开发者必须调试他们没有写的测试中的失败，而代码也不是他们从头完全手写的。这很慢、很令人沮丧，而且越来越常见。

还有另一种模式：人工智能生成的代码通常主路径处理得好，但错过边界情况。覆盖率可能看起来不错，即使生产风险在上升。

第一阶段：基础

定义用于测试感知编码的共享提示词模板。例如：基于 /docs/specs/[feature].md 中的需求文档实现一个功能，并生成覆盖主路径、空输入以及两种最可能错误条件的单元测试。引用需求文档保持提示词简短，并让需求文档成为真实来源。

添加一个提交前钩子，当新逻辑出现时检查测试文件。如果开发者添加了一个包含有意义业务逻辑的文件却没有相关的测试文件，在持续集成之前抓住它。

改进测试失败输出，让人工智能能帮助修复它。包括测试验证哪条业务规则、映射到哪个需求文档，以及自上次通过以来发生了什么变更。这给开发者提供了结构化的输入，可以反馈回他们的编码工具。

第二阶段：增强

测试成为人工智能加强交付过程的最清晰例子之一。持续集成在呈现测试失败的同时，附带人工智能生成的修复建议，追溯回需求文档。人工智能生成代码中的覆盖率缺口在合并前触发第二轮来生成缺失的边界情况测试。不稳定测试被自动分类，这样基础设施噪音不会淹没真正的回归。

第三阶段：自动化

测试套件在定义的范围内成为自修复。如果人工智能生成的代码变更了一个接口，而需求文档确认行为变更是有意为之，断言可以自动更新。智能体为每个新服务生成基线覆盖率。人类从手写每个测试转变为评审测试策略和批准覆盖率标准。

部署

现在的问题

发布和变更管理流程没有改变，但流经它们的代码量变了。发布经理评审更多变更。审批队列增长。而且与这些变更绑定的文档往往变得更糟，因为使用人工智能生成代码的开发者事后并不总能清晰解释每个实现细节。

第一阶段：基础

从需求文档生成部署文档。需求文档已经解释了变更了什么、为什么变更、哪些契约受到影响以及如何衡量成功。在开合并请求之前，开发者用这些材料生成一份通俗语言的变更摘要、受影响的服务、回滚计划和测试覆盖率说明。

更新合并请求模板以捕获人工智能使用和需求文档引用。两个问题能起大作用：这个变更中使用了人工智能吗？它实现了哪个需求文档？这给评审者提供了上下文，并在意图、实现和批准之间创建了可追溯的链接。

以结构化形式编写部署运行手册。编号的步骤、回滚触发器和显式命令现在更有用，以后也机器可读。

第二阶段：增强

这是人工智能开始改进发布过程而不仅仅是往里面塞更多工作的地方。部署文档从合并请求元数据和链接的需求文档自动生成，然后由人类评审而非从头编写。流水线关卡根据映射到记忆库中标准的策略即代码规则进行验证。人工智能生成的风险评级帮助评审者关注影响范围和服务影响，而非手动重建变更意图。

第三阶段：自动化

低风险服务在批准的策略边界内自动部署。中风险服务使用自动化金丝雀验证，并在服务等级目标违约时回滚。高风险变更仍然需要人类签字，但那个签字聚焦于判断，而非机械流程。人类拥有政策。智能体处理规模。

安全

现在的问题

一个应用安全工程师支持 50 个开发者已经是瓶颈了。给这些开发者能让他们更快产出更多代码的人工智能工具，发现量就会随之上升。更糟糕的是，模型会重复训练数据中的常见模式，包括不安全的那些。应用安全团队最终不得不一遍又一遍地分类相同类别的问题。

第一阶段：基础

部署与内部标准绑定的集成开发环境静态应用安全测试。Semgrep、Snyk 或 SonarLint 等工具在根据仓库自身安全文档派生的规则配置时最有用：批准的加密套件、参数化查询要求、个人身份信息处理期望和禁止的模式。如果人工智能生成了不安全的东西，开发者应该立即在编辑器中看到它，并附带返回相关标准的链接。

添加一个密钥扫描提交前钩子。这实现起来很快，并消除了一整类可预防的事件。

保持安全标准简短且可链接。同一份在代码生成期间给人工智能上下文的文档，也应该在扫描器触发时帮助开发者理解和修复问题。

第二阶段：增强

安全是另一个增强应该显而易见的地方。发现在合并请求级别出现，附带人工智能生成的修复建议，既关联到漏洞类型也关联到它违反的内部规则。来自集成开发环境工具、提交前钩子和持续集成扫描的发现被关联到一个视图中，而不是创建重复的分类工作。应用安全团队花更少时间评审重复错误，花更多时间改进防止它们的规则。

这对第三方风险也很重要。许多银行通过供应商采用人工智能，无论是编码助手、模型提供商还是云平台。约束体系让机构对访问、评审、日志记录和证据保留有了更清晰的边界，这让供应商风险在实践中更容易管理。

第三阶段：自动化

定义严重度阈值以下的充分理解漏洞类别可以进入自动修复循环。安全标准文档成为智能体在生成代码之前检查的活策略层，而非只是在扫描器抓住问题之后。来自动态应用安全测试和生产环境的运行时信号反馈回知识库，让系统随时间变得更聪明。

合规

现在的问题

开发者正在人工智能聊天会话中做出真实的技术决策：架构权衡、安全选择、实现方法。几乎没有推理过程被记录。所以当审计师问为什么某物以某种方式实现时，答案可能只存在于几周前就已关闭的工具窗口中。

与此同时，合规证据仍然是事后组装的。已构建内容与文档所说已构建内容之间的差距，是审计痛苦的反复来源。

第一阶段：基础

把需求文档当作决策日志。实现之前编写的需求文档已经记录了意图、约束和选择的方法。与代码一起提交它，你以后就不需要重建推理过程。对于更广泛的架构决策，在 /docs/architecture/ 中使用简短的架构决策记录。

当人工智能影响面向消费者的决策时，这种可追溯性甚至更重要。美国消费者金融保护局指导意见明确，使用人工智能或其他复杂模型的贷款人仍需要提供具体且准确的不利行动原因。如果一个团队无法重建系统为什么表现出某种行为，它就还没准备好做受监管的决策。

使用人工智能从需求文档和变更元数据起草合规产物。变更工单、数据流描述、影响评估和风险摘要都可以从已有信息开始。人工智能起草它们。人类评审并批准它们。

在合并请求标题和描述中强制执行结构化元数据。将变更映射到控制标识符的标题在实现和合规要求之间创建了可追溯的链接。当这些控制映射活在记忆库中时，开发者更可能在整个交付过程中将它们保持在视野内。

第二阶段：增强

合规工作变得更少追溯性且更少手动。产物从链接的需求文档和合并请求元数据自动生成，然后被评审而非被撰写。控制标识符直接映射进活证据矩阵。文档架构与部署现实之间的漂移通过流水线数据变得可见，而非在审计准备期间才暴露。

第三阶段：自动化

每个流水线动作在发生时发出一个结构化合规事件。报告从该事件流生成。预审计证据包自动组装并由人类在提交前评审。「为什么这东西要以这种方式实现？」现在有一个默认答案，从事件追溯到合并请求再到需求文档。

优化

现在的问题

优化仍然是大多被动的。东西坏了或变慢了，有人调查，修复被做出，而学习经常消失在即时通讯线程或个人记忆中。

人工智能生成的代码在这里添加了特定风险：它通常足够正确能通过，但足够低效会在以后造成损害。模型可能生成一个在功能上有效的数据访问模式，却导致 N+1 查询或不必要的计算，因为它从未被给予性能约束。

第一阶段：基础

把性能概况放进记忆库。对每个服务，捕获预期数据量、延迟服务等级目标、已知瓶颈和之前导致事故的模式。当开发者提示人工智能工具在该服务中构建时，那个上下文应该随之而来。

用回顾会来改进约束体系，而不只是记录经验教训。事故之后，问什么规则、测试、检查清单项或提示词模板本可以更早抓住问题。然后把它加回系统。随着时间推移，知识库开始反映组织的失败模式，而非通用最佳实践。

把人工智能特定检查添加到完成的定义中。变更是否在有正确性能上下文的情况下生成的？合并请求是否链接到需求文档？本地是否运行了密钥扫描？架构选择是否有清晰的决策记录？这就是知识库如何成为工作习惯而非摆设。

第二阶段：增强

性能工作变得更主动。概况自动包含在相关服务的人工智能上下文中。回顾会生成标准、模板和代码检查规则的候选更新供人类批准。成本异常触发结构化调查，人工智能总结来自近期部署历史的可能 contributing 变更，并将它们连接回性能概况。

第三阶段：自动化

可观测性数据、延迟、错误率和基础设施成本与仓库知识库一起成为智能体上下文的一部分。定时清理智能体识别过时需求文档、已弃用的功能标志、孤立的基础设施和过时的文档，然后要么直接修复要么路由项目以供评审。系统保持最新，因为漂移被积极管理。

回报

这里的重点不是急于奔向自主智能体。而是构建那个演进路径，让它们在时机成熟时安全且有用。

基础 创造结构。

增强 减少人类瓶颈。

自动化 变得可能，因为前两个阶段让系统变得可读。

这就是知识库如此重要的原因。每个领域在人工智能拥有更好上下文时都会改善。

更好的上下文产生更好的测试。

更好的标准产生更好的安全扫描。

更好的映射产生更好的审计轨迹。

更好的性能概况产生更少低效的代码。

其他一切都是它的下游。

等待工具成熟才添加结构的团队，以后转型会更痛苦。向代码库追溯添加上下文总是比早期就构建进去更痛苦。组织将在自动化上挣扎，不是因为它们缺乏访问先进模型的能力，而是因为它们没有可靠的东西供那些模型推理。

好消息是，这不需要从大型平台采购或专业人工智能团队开始。

基础几乎对任何 DevOps 组织都是可触及的。从知识库开始。三份文档就够了：架构概述、安全标准和性能概况。保持简短。提交它们。然后挑选痛苦最明显的地方，开始围绕它增强工作流。

约束体系会复利增长。

在需要它之前，先构建它。