拥有坚实的文档、要求和QA基础将有助于防止人工智能技术债务成倍累积。　

　　一份报告显示，2026年，92%的开发人员每天使用人工智能编码工具，现在全球所有代码的41%是人工智能生成的。所有这些代码会提供价值、运营问题还是不断增加的人工智能债务？我与几位专家讨论了如何保持人工智能生成的代码与组织标准保持一致，以及如何定义人工智能代码生成器的上下文，而不仅仅是功能要求。

　　像建筑规范一样的文件

　　建筑业的总承包商将审查建筑信息模型，以提供他们正在开发的内容。但许多细节都在施工规范中，包括组件规定和性能要求。在人工智能前时代，没有其组织、架构和应用程序等效文档的Devops团队可能会逃脱这种遗漏。但机构知识和合规性要求是上下文AI代码生成器在您与他们共享第一个功能提示之前需要的。

　　Glean的创始工程师Eddie Zhou说：“只有当工程标准明确、可用且难以绕过时，人工智能生成的代码才会与工程标准保持一致。”“将架构、已批准的库、数据处理规则、安全控制、命名惯例、可观察性、测试预期和非功能要求放入规格和自动检查中。然后，确保您为模型提供上下文，但将其输出视为不可信，直到它通过与人类编写的代码相同的审查、测试、扫描和生产监控。”

　　克服部落知识总是具有挑战性的，因为devops团队在推动功能方面承受了太大的压力，而维护文档的动力很小。我的两个人工智能领导技能是变革管理和敏捷协作领导，因为devops团队在引入人工智能能力的同时需要实践协调。

　　周补充说：“人工智能像良好的工程一样有效地放大了模棱两可和薄弱的治理。如果标准只存在于部落知识中，人工智能将揭露这个问题，而不是解决它。”

　　将非功能要求编码为自动测试

　　需求文档和参考架构的问题在于，它们不能直接对人类或人工智能开发人员强制执行。一旦开发团队就标准达成一致并将其记录，下一步是开发方法，将其编码为CI/CD管道中的自动验收标准。

　　Adeptia人工智能产品管理副总裁Michael Bevilacqua说：“人工智能代码生成器和人工开发人员优化功能正确性——使功能工作——并悄悄跳过大多数真实标准的非功能要求，包括性能、安全态势、错误处理、可观察性和可审计性。”“将您的NFR编码为可执行接受标准，生成的代码在合并前必须通过，因此'与我们的标准保持一致'成为管道在每次更改上强制执行的门。”

　　示例：在拉取请求期间，可以验证所有网页的总页面重量应低于2MB的性能要求，并且可以在暂存环境中在CI/CD中自动执行，要求第一个字节（TTFB）的时间低于800毫秒。

　　对利益相关者和人工智能的要求

　　涵盖性能、安全性和其他组织级合规性要求的架构和自动化非功能要求应成为与AI代码生成器共享的基本级上下文标准。设置准确上下文的下一组考虑因素从应用程序和代理特定要求、其预期用例和特定合规护栏开始。

　　Pegasystems产品战略和营销高级总监Matt Healy说：“首席信息官正在授权人工智能更快地构建应用程序，但许多人意识到速度不是瓶颈，因为更多的代码不会自动创造业务价值。”“在开发人员编写任何代码之前，组织必须了解客户需求，评估遗留系统，及时了解法规和实践，映射企业架构和集成，并协调业务和IT。”

　　考虑理解要求的三个阶段。一旦利益相关者设定了业务价值和意图，开发人员必须首先就实施策略达成一致，并讨论性能、成本和其他权衡。然后，开发人员应该与利益相关者重新会面，并审查实施权衡。Healy补充说：“在大型项目中，定义解决方案和成功指标可能需要与构建它一样多的时间。领导者不仅使用人工智能来加速开发，还帮助高管、业务分析师、产品所有者和IT团队更有效地协作。”

　　第三阶段是将目标、用户要求和实施方法收集到特定于开发的背景下。但我们还没有完成，因为数据要求和操作考虑因素也必须包含在输入到人工智能代码生成器的上下文中。

　　将治理纳入规范中

　　正在开发的应用程序或人工智能代理如何使用它可以访问的数据需要明确的规范。数据治理计划应有基于数据集、定义的角色、授权和使用规范的标准。

　　Reltio副总裁兼现场首席技术官Kash Mehdi表示，正在向前迈进的团队将数据治理视为对人工智能的输入，而不是之后的审计。“他们将工具以可信的、语义一致的数据模型、批准的规范和安全策略为基础，因此人工智能继承了组织的标准，而不是发明自己的标准。如果没有受控的上下文层，您不会从少数人工智能辅助的工作流程扩展到数千个；您只是更快地积累不一致的代码，”Mehdi说。

　　以下是创建标准时需要考虑的两个选项：首先，将可重复使用的数据集建立为具有定义集成和使用规则的数据产品。拥有大量数据集和集成点的组织应该考虑数据结构。第二个（也是关键要求）是标准化数据合同的格式，使用人类和机器可读的格式，以便数据所有者、用户和人工智能代码生成器从一套一致的原则中运行。

　　TiDB联合创始人兼首席执行官Ed Huang说：“人工智能编写的代码可以编译并通过测试，但会悄悄地忽略您的数据合同，因此故障在生产中显示为损坏状态，而不是构建错误。”“修复方法是使治理机器可检查，包括在数据库层强制执行的模式约束、访问策略和数据质量规则，人工智能无法绕过它们路由，没有记录在模型从不阅读的维基中。将数据库视为您标准的执行点，它不再重要，无论是人类还是代理编写查询。”

　　可观察性和测试优先

　　当人工智能生成代码时，做法是使用静态应用程序安全测试（SAST）和其他代码分析工具来执行自动代码审查。另一个做法是让应用程序通过渗透测试和其他应用程序安全验证。但考虑到人工智能的开发，其中许多工具都在外面。为了获得内部视图，必须将可观察性和测试要求作为标准，并围绕您要求人工智能开发的关键交易提出具体要求。

　　Kosmos首席执行官兼创始人Sanjay Gidwani说：“更多的代码量只是意味着花更多的时间进行调查，而修复方法并没有在发货前更仔细地阅读代码。它将可观察性信号，即断裂的东西，与导致它的特定变化联系起来。没有那个链接，你正在做和以前一样的手动调查，只是用更大的干草堆。”

　　测试要求必须超越生成自动测试、使用合成数据扩展测试模式和实施连续测试。Monte Carlo联合创始人兼首席技术官Lior Gavish说：“与其针对一个输出测试一个输入，不如测试一个不变量是否在广泛的生成输入中成立，这非常适合人工智能的无限输入空间和非确定性输出。”“我把它当作堆栈中的一层，评估映射输入空间，基于属性的测试压力测试边缘情况和脆性，以及实时流量的可观察性检查生产是否从您定义为不可协商的属性中漂移。”

　　打包和发展标准

　　Appfire的首席技术官Ed Frederici建议将标准编纂为机器可读的规则，包括林特、格式化程序和类型检查。将组织和应用程序标准合并到与人工智能代码生成工具共享的上下文中。他的其他建议：

　　在持续集成中执行标准，以便违规块合并。

　　提供AI持久上下文，如CLAUDE.md、样式指南和架构文档。

　　保持小且可审查的更改。

　　需要人工审查每个拉取请求，因为人工智能生成的代码必须得到与任何贡献者相同的审查。没有例外。

　　用坚实的测试覆盖率支持这种方法，以捕捉回归。

　　随着标准的变化，定期审核漂移。

　　同样重要的是要记住，当代码必须扩展和维护时，基础开发标准也必须扩展和维护。Qodo首席执行官兼联合创始人Itamar Friedman说：“只有当人工智能生成的代码由不断学习的上下文引擎提供支持时，它才会与您的标准保持一致，而不是规则的静态快照。”“这意味着一个不断适应您代码库不断变化的标准、您团队的公关历史以及您的工程师之前已经做出的决定的引擎，因此人工智能不仅遵循指示，而且实际上了解您的团队是如何工作的。”

　　随着越来越多的devops组织依赖人工智能代码生成工具，开发人员有一个重要的机会来开发所需的标准和自动验证，以确保构建的内容符合工程和合规性要求。