文章探讨了驱动式开发（SDD）在基础设施领域的适用性。作者认为，与应用程序代码不同，基础设施代码（IaC）本质上是声明式的，强调可复现性而非创造性。SDD 假设从规范到代码的单向流动，但这与平台团队处理基础设施“漂移”的实际工作方式相悖。真正的自动化差距在于部署编排。文章提出，应将基础设施重构为标准化的“构件”和“蓝图”，并发布到目录中，结合“云图”来管理实际运行状态。这样，AI 代理才能安全地执行部署，而不是仅仅生成代码。
译自：Is Spec-Driven Development Key for Infrastructure Automation?
作者：Idan Yalovich
自从 GitHub Universe 和 GitHub Spec Kit 发布 以来，驱动式开发 (SDD) 席卷了开发界。其前提极具吸引力：在 AI 代理编写代码之前，通过 markdown 规范为它们提供结构化的上下文，这样你将拥有这一切。终结关于 API 的幻觉、仓促的编码和低质量的产出。
通过 SDD，AI 代理将更像人类开发者，接收产品需求文档 (PRD)，分解任务并系统地执行。
这个概念将开发团队多年来的工作形式化。产品经理编写需求。开发人员消化 PRD 或规范，将工作分解为任务，然后开始编码。SDD 只是为 AI 时代构建了这种工作流程，将自然语言规范转化为 大型语言模型 (LLM) 生成有意义的代码所需的上下文。
作为一名深度参与 DevOps 和平台工程的人，我不禁问了一个显而易见的问题：这对基础设施工作意味着什么？我们是否应该争相为我们的 Terraform 模块和 Kubernetes 配置采用 SDD？
基础设施代码不是应用程序代码
基础设施代码看起来像代码，但它的行为方式与应用程序代码截然不同。
看看任何 Terraform 文件、Helm Chart 或 CloudFormation 模板。你看到了什么？规范。基础设施即代码 (IaC) 本质上就是驱动式开发。它是声明式的。我们描述期望的状态。我们说“我想要一个具有这些属性的数据库”，而不是“执行这些命令来创建一个数据库”。
但有趣的地方在于此。
- 应用程序代码偏爱创造性。 给 10 位开发人员相同的需求，你会得到 10 种不同的实现。每一种都可能是有效的，并且在各自的方面都非常优雅。目标是用新颖的方法解决业务问题，优化用户体验或找到巧妙的性能提升。这种解决方案的多样性是有价值的。
- 基础设施代码偏爱可复现性。 当我在 us-east-1、eu-west-1 和 ap-southeast-1 中启动基础设施时，我需要完全相同的配置。相同的网络设置、相同的安全组、相同的数据库配置。标准化意味着可预测的成本、可互换的组件和可靠的灾难恢复。
这种区别对 SDD 很重要，因为 AI 代理擅长创造性地解决问题，但却难以严格地实现可复现性。我们不希望 AI 代理对我们的虚拟私有云 (VPC) 配置进行创造性地修改。我们希望每次都能完美地部署完全相同的蓝图。
更重要的是，基础设施代码很少遵循从规范到实现的流程。考虑一下基础设施实际是如何演变的。FinOps 调整实例类型以优化成本。安全团队直接在生产环境中修补漏洞。有人在事件期间通过控制台扩展数据库。你的 Terraform 仍然描述了原始状态，但现实已经发生了变化。这就是漂移：当你的实际云资源不再与你的 IaC 匹配时。基础设施团队反向工作，不断更新规范以匹配现实。
SDD 假设从需求到代码的单向流动。但这并不是平台团队的工作方式。我们不需要 AI 根据规范编写更多的 Terraform；我们需要的是完全不同的东西。
真正的自动化差距在于部署编排
SDD 将影响基础设施工作，但并非总是以平台团队会欢呼的方式。
如今，开发人员在使用 AI Copilot 方面的生产力已经是几年前的 10 倍。SDD 有望将这一点推向更远：从规范生成完整的模块，从 markdown 计划中实现整个功能。应用程序代码的体积将呈爆炸式增长。
所有这些代码都需要运行的地方。每个功能都需要基础设施。每个微服务都需要其数据库、消息队列和网络。代码生产的加速给部署速度带来了前所未有的压力。
然而，部署仍然是顽固的手动过程。当开发人员拥有将规范转化为代码的 AI 助手时，平台工程师仍然通过手动协调复杂的部署。我们可以在几个小时内生成一个完整的微服务，但却花费数天时间来弄清楚如何安全地设置和 部署其基础设施。
为什么 AI 代理无法编排基础设施部署
AI 驱动部署的障碍在于当前基础设施代码组织方式中的结构性问题。
- Terraliths：庞大的噩梦。 我们创建了巨大的 Terraform 文件，其中规范、值和逻辑纠缠在一起。单个文件可能同时定义了网络、数据库和应用程序配置。小的改动会产生不可预测的连锁反应。当一切都相互关联时，无法理解其影响范围。
- 异构工具。 单个环境使用 Terraform 进行基础设施管理，Helm 管理 Kubernetes，还使用 Python 脚本。每种工具都有不同的输入、输出和状态管理。跨工具进行编排需要理解未在任何地方记录的隐藏依赖关系。
- 反向追溯漂移。 基础设施团队不断协调漂移，更新代码以匹配现实。AI 代理首先需要 映射所有云中实际存在的内容，包括区域和账户，然后才能尝试更新任何内容。
我们真正需要的是重构基础设施，使其为 AI 做好准备。
蓝图驱动部署：面向 AI 时代的基础设施
前进的道路很明确。我们需要改变基础设施的打包、部署和管理方式。以下是如何使基础设施为 AI 做好准备：
- 转换每一块基础设施。 将每个 Terraform 模块、Helm Chart 和 Python 脚本转化为具有标准化输入和输出的构件。这些构件成为可重用的构建块，组合成蓝图。
- 将构件组合成清晰、版本化的蓝图，并具有明确的边界。 数据库蓝图创建数据库。网络蓝图处理 VPC 和子网。没有混合，没有混乱。
- 将它们发布到目录中。 决定哪些可以暴露给 AI 代理，以便它们知道哪些是安全且允许部署的。
这种方法解决了我们之前提到的结构性问题：
- Terraliths 被分解为构件和蓝图。 那个 10,000 行的代码巨石变成了一系列集中的组件，每个组件都有自己的生命周期和清晰的接口。更改被范围化。影响范围被控制。AI 与蓝图协同工作，而不是与纠缠的代码协同工作。
- 异构工具变得统一。 Terraform、Helm、Python 等都通过标准化成为具有标准输入和输出的构件。编排层不关心是什么创建了构件。
在此基础上，您可以解决漂移问题：
- 定期映射存在的内容：将所有账户和区域中的实际云状态发现并整合到云图中。
- 从生产环境中提取模式并创建/更新蓝图。
这个循环变得可持续：现实指导蓝图，蓝图指导部署，部署在图中进行跟踪。
现在 AI 代理可以真正工作了：
请求：“我们需要扩展到亚太地区以降低延迟。”
代理查询蓝图目录和云图，并找到已经在欧洲和美国运行的标准区域基础设施蓝图。它从图中理解依赖关系，例如先于应用程序的网络数据库。
“我将把区域基础设施蓝图 v2.3 部署到 ap-southeast-1。根据依赖图，这需要 12 分钟。不会影响任何现有资源。”
一次批准。编排器处理其余部分。
基础设施与应用程序代码不同
当您构建功能时，驱动式开发是有意义的。但当您构建这些功能运行的平台时，它就没有意义了。
基础设施需要：
- 蓝图，而非规范： 可重用、版本化的模式，您可以在各个区域和环境中进行部署。
- 编排，而非仅仅代码生成： 跨基础设施、配置和应用程序协调的多步工作流程。
- 明确的边界，而非纠缠的模块： 每个蓝图和构件都有明确的范围，以便更改能够得到控制。
- 云图，而非代码转储： 实时了解每个账户、区域和云中实际运行的内容。
未来不是 AI 代理生成 Terraform。而是 AI 代理使用预先验证的蓝图安全地执行部署。
这就是 AI 最终进入部署游戏的方式。
