如今，许多 DevOps 组织都在使用 AI 代码生成器、vibe coding（氛围编程），并采纳规范驱动开发（spec-driven development）的实践，问题也随之增多：AI 怎么知道你们组织的标准？有哪些流程在监控并强制这些标准？开发者对交付结果承担什么责任？

"生成式 AI 会很乐意交给你一个电影布景般的应用——从街上看就是一座房子，门窗都能打开，演示跑得干干净净，"Blumira 安全与 IT 总监 Mike Toole 说，"但布景背后既没有管道也没有布线：没有输入校验，没有认证边界，没有任何真正支撑它的东西。如果你唯一的验收标准是'它能跑、看起来对'，那你交付的是布景，不是大楼。"

一份报告显示，2026 年有 92% 的开发者每天都在使用 AI 编码工具，全球所有代码中已有 41% 由 AI 生成。这些代码最终会带来价值、运维问题，还是不断累积的 AI 债务？我与多位专家交流了如何让 AI 生成的代码符合组织标准，以及如何定义 AI 代码生成器在功能需求之外的上下文。

像写建筑规范一样写文档

建筑行业的施工总承包商会审阅建筑信息模型（BIM），从中了解自己要建造的东西。但许多细节其实写在施工规范里，包括构件规定和性能要求。对于自身组织、架构和应用缺乏对等文档的 DevOps 团队而言，在 AI 之前的时代，这种缺失或许还能蒙混过关。但机构知识与合规要求，恰恰是你在向 AI 代码生成器发出第一个功能提示之前就必须给它的上下文。

"只有当工程标准是明确的、随时可得的、且难以绕过的，AI 生成的代码才会与之一致，"Glean 创始工程师 Eddie Zhou 说，"把架构、经批准的库、数据处理规则、安全控制、命名约定、可观测性、测试期望和非功能需求写进规范和自动化检查里。然后，把这些上下文交给模型，但在它通过与人写代码相同的评审、测试、扫描和生产监控之前，一律把它的输出视为不可信。"

克服"部落知识"（口口相传的隐性知识）从来都是难题，因为 DevOps 团队承受着交付功能的巨大压力，却几乎没有维护文档的激励。我最看重的两项 AI 领导力技能是变革管理和敏捷协作式领导，因为 DevOps 团队在引入 AI 能力时需要实践对齐。

Zhou 补充道："AI 放大模糊性和薄弱治理的效率，和它放大优秀工程的能力一样高。如果标准只存在于部落知识中，AI 只会暴露这个问题，而不是解决它。"

把非功能需求编码为自动化测试

需求文档和参考架构的问题在于，它们无法直接对人或 AI 开发者形成强制约束。一旦 DevOps 团队就标准达成一致并形成文档，下一步就是想办法把这些标准编码为 CI/CD 流水线中的自动化验收标准。

"AI 代码生成器和人类开发者都会为功能正确性做优化——把功能做出来——然后悄悄跳过非功能需求，而你真正的标准大多恰恰藏在其中：性能、安全姿态、错误处理、可观测性和可审计性，"Adeptia 的 AI 产品管理副总裁 Michael Bevilacqua 说，"把你的非功能需求编码为可执行的验收标准，生成的代码必须通过才能合并，这样'符合我们的标准'就变成了流水线在每一次变更上强制执行的关卡。"

举个例子：性能需求可以规定所有网页的总页面体积低于 2MB，这可以在拉取请求（PR）阶段完成校验；而要求首字节时间（TTFB）低于 800 毫秒，则可以在预发布环境中的 CI/CD 里自动化验证。

为相关方和 AI 明确需求

覆盖性能、安全及其他组织级合规要求的架构与自动化非功能需求，应当成为与 AI 代码生成器共享的基础层上下文标准。而下一组用于设定准确上下文的考量，则始于应用与智能体特有的需求、其预期用例以及具体的合规护栏。

"CIO 们正强制要求用 AI 更快地构建应用，但许多人开始意识到速度并不是瓶颈，因为更多代码并不会自动创造业务价值，"Pegasystems 产品战略与营销高级总监 Matt Healy 说，"在开发者写下任何代码之前，组织必须理解客户需求、评估遗留系统、紧跟法规与最佳实践、梳理企业架构与集成，并对齐业务与 IT。"

不妨把理解需求分成三个阶段。相关方设定业务价值与意图之后，开发者必须先就实现策略达成一致，并讨论性能、成本等权衡；随后，开发者应再次与相关方会面，复核实现层面的取舍。Healy 补充道："在大型项目中，定义解决方案和成功指标所花的时间可能与开发本身一样多。领导者使用 AI 不仅是为了加速开发，也是在帮助高管、业务分析师、产品负责人和 IT 团队更有效地协作。"

第三个阶段，是把目标、用户需求和实现方法汇聚成面向开发的专属上下文。但这还没完，因为数据需求和运维考量同样必须纳入喂给 AI 代码生成器的上下文中。

把治理写进规范

正在开发的应用或 AI 智能体如何使用它能访问的数据，需要明确的规范。数据治理项目应当基于数据集、既定角色、权限和使用规范来制定标准。

Reltio 的副总裁兼现场 CTO Kash Mehdi 表示，跑在前面的团队会把数据治理当作 AI 的输入，而不是 AI 之后的审计。"他们把自己的工具扎根于可信、语义一致的数据模型、经批准的规范和安全策略之上，让 AI 继承组织的标准，而不是自创一套。缺少这层受治理的上下文，你无法从少数几个 AI 辅助工作流扩展到数千个，只会更快地累积出不一致的代码。"

在制定标准时，有两个方向可以考虑。第一，把可复用的数据集建立为"数据产品"，明确其集成方式和使用规则；拥有大量数据集和集成点的组织，则可以考虑数据编织（data fabric）。第二（也是关键要求），是统一"数据契约"的格式，采用人类与机器都可读的形式，让数据所有者、使用者和 AI 代码生成器都基于一套一致的原则来工作。

"AI 写出的代码能编译、能通过测试，却悄悄地无视你的数据契约，于是故障不会表现为构建错误，而是在生产环境中以状态损坏的形式出现，"TiDB 联合创始人兼 CEO Ed Huang 说，"解决办法是让治理变成机器可校验的东西，包括在数据库层强制执行的模式约束、访问策略和数据质量规则——在 AI 绕不过去的地方，而不是写在模型根本不会去读的 wiki 里。把数据库当作标准的执行点，那么查询是人写的还是智能体写的，就不再重要了。"

可观测性与测试优先

当代码由 AI 生成时，一项最佳实践是使用静态应用安全测试（SAST）等代码分析工具执行自动化代码评审。另一项最佳实践是让应用接受渗透测试及其他应用安全验证。但这些工具大多只能从外部视角看待 AI 所开发的东西。要获得内部视角，就必须把可观测性和测试需求纳入标准，并针对你要求 AI 开发的关键事务提出具体要求。

Kosmos 创始人兼 CEO Sanjay Gidwani 说："代码量更大只意味着排查问题花的时间更多，而解决办法并不是在发布前更仔细地读代码，而是把可观测性信号——那个坏掉的东西——与造成它的具体变更连接起来。没有这条链路，你做的还是和以前一样的人工排查，只不过干草堆更大了。"

测试需求必须超越生成自动化测试的层面，还要用合成数据扩展测试模式，并落地持续测试。"与其用一组输入对一组输出做测试，不如检验不变量是否在大量生成的输入下依然成立，这非常契合 AI 无界的输入空间和非确定性的输出，"Monte Carlo 联合创始人兼 CTO Lior Gavish 说，"我把它当作整个技术栈中的一层：用评估（evals）刻画输入空间，用基于属性的测试对边界情况和脆弱性施压，再对线上流量做可观测性，检查生产环境是否偏离了你定义为不可妥协的那些属性。"

打包并持续演进标准

Appfire 的 CTO Ed Frederici 建议把标准编纂为机器可读的规则，包括 linter、格式化和类型检查工具，并把组织级标准与应用级标准合并成一份上下文，共享给 AI 代码生成工具。他的其他建议包括：在持续集成中强制执行标准，违规即阻止合并；给 AI 提供持久化的上下文，例如 `CLAUDE.md`、风格指南和架构文档；让变更保持小而可评审；要求每一个拉取请求都经过人工评审，因为 AI 生成的代码必须像任何贡献者的代码一样接受同等审视，没有例外；用扎实的测试覆盖为这套做法兜底，以捕获回归；并随着标准演进，定期审计是否出现偏离。

同样重要的是要记住，代码需要扩展和维护，底层的开发标准也一样。"只有当 AI 生成的代码由一个持续学习的上下文引擎驱动，而不是你规则的静态快照时，它才能与你的标准保持一致，"Qodo 联合创始人兼 CEO Itamar Friedman 说，"这意味着这个引擎要不断适应你代码库中演进的标准、你团队的 PR 历史，以及你的工程师已经做出的那些决策，这样 AI 就不只是在遵循指令，而是真正理解你的团队是如何工作的。"

随着越来越多 DevOps 组织依赖 AI 代码生成工具，开发者面临一个重要机会：制定出所需的标准和自动化验证手段，确保造出来的东西满足工程与合规要求。