自动化不是写更多脚本：平台工程的共识是“黄金路径 + 护栏”

自动化运维经常从“把重复动作写成脚本”开始。但当脚本越来越多、环境越来越多、变更越来越快时，新的问题出现了：脚本无人维护、配置逐渐漂移、出错后难以回滚。行业正在用平台工程回答这个问题。

共识一：AI 让 IaC 产量上升，治理成为真正的瓶颈

生成式 AI 可以快速产出 Terraform、Ansible 或 Kubernetes 配置，但也带来了新的风险。近期行业调查显示，多数云团队认为 AI 增加了 IaC 产量，同时有相当比例的组织发现 AI 生成的配置更难治理，甚至已经遇到过 AI 直接引入的错误配置。人工评审很难跟上 AI 的变更速度。

因此，行业共识不是“少用 AI”，而是把治理内嵌到交付路径：策略即代码、自动漂移检测、自动修复、强制审批和可审计的回滚。仅靠“扫描出问题”已经不够，系统需要能在合并和部署阶段阻止高风险变更。

共识二：平台工程和内部开发者平台成为运营模型

平台工程的核心不是再做一个工具，而是把基础设施能力产品化：提供标准环境、服务模板、自助入口和清晰的边界，让应用团队可以按“黄金路径”完成常见交付，而不必每次从零拼装。

行业预测显示，大型软件工程组织普遍在设立平台工程团队，内部开发者平台（IDP）的采用率持续上升。一个可用的 IDP 通常包含三部分：服务模板与目录、自动化治理引擎、可观测性集成。缺少任何一部分，平台都容易退化成“又一个门户”。

共识三：人从执行者变成规则与路径的策展人

AI Agent 正在进入资源开通、故障处理和变更执行环节。行业对治理的讨论也随之变化：黄金路径告诉 Agent“应该怎么做”，护栏告诉它“不能怎么做”，安全网负责在出错时兜底，人工复核负责处理高风险或不确定的决策。

这意味着运维团队的能力重心会从“手工操作”转向“设计规则、验证路径、审计结果”。对管理者而言，需要同时投资平台能力、策略治理和人员技能，而不是只买一套自动化工具。

对运维与建设团队的启示

先选高频、低风险、可验证的场景做自动化，不要一开始就追求全量覆盖。
为常见交付定义黄金路径，并提供模板、文档和自助入口。
把策略即代码、漂移检测和自动回滚放进交付流水线。
为 AI 生成的变更设置人工复核门槛，保留审计记录和回退能力。