面向 AI 开发的平台工程

为原型提供进入生产的路径

员工可以使用不同 AI 工具探索想法，同时由组织提供共同的生产交付路径。平台团队负责让这条路径清楚、有支持且可重复。

对于有用的原型，收集用户任务、示例工作流、可获得的源代码和预期使用的数据。评估是修改原有代码，还是根据已掌握的要求重新开发。在接入真实凭据或机密输入前，按照必要控制措施验证应用、开发工具和运行时。

如果服务必须运行在自己的基础设施中，就提供将其部署到组织云账户或网络的受支持方式。纳入身份、秘密信息处理、发布证据、监控和恢复。另行审查模型数据流；拥有运行环境，不代表能控制每项开发服务。

把平台视为服务用户的产品

平台为团队提供受支持的软件构建和运维能力。这些能力可以包括身份、环境、交付流水线、数据库、监控和策略检查。有用的基本单元，是能够满足反复出现需要的完整工作流。

CNCF 将平台描述为围绕内部用户设计的能力，具备一致接口，并在适当情况下支持自助使用。门户可以展示这些能力，但仅有门户并不等于拥有平台。参见 CNCF 平台白皮书。

从真实需求开始。在一家虚构公司中，多个团队需要带员工登录和托管数据库的内部 Web 服务。先为这一需求建立受支持路径，再考虑添加很少使用的大量功能。

将智能体纳入平台用户

AI 智能体可以快速生成基础设施代码。但如果缺少当前平台上下文，也可能选择不受支持的区域、身份模式或部署方式。生成更快，不能解决组织约束缺失的问题。

为智能体提供可靠接口。定义输入、允许值、输出和失败行为。提供与已安装版本一致的示例。返回能指导行动的错误，同时不泄露秘密信息。对人员和智能体调用方采用相同的授权检查。

对于内部服务，请求可以标明负责人、数据类别、环境、恢复要求和受支持的运行时。平台随后可以选择经过审查的配置，或说明该请求为什么需要单独决策。

定义受支持路径及其边界

这只是职责划分示例。应与实际团队和提供方确认。未明确归属的职责，不会因为平台存在就消失。

公布默认方案之外要求的例外处理路径。明确决策负责人和必要证据。过于困难的例外流程，可能促使团队绕开平台创建不受支持的系统。

创建之后继续维护服务

模板是一个起始版本，不会自动给基于它创建的应用打补丁。决定平台变化如何到达现有服务，以及如何检查兼容性。

为共享接口和模块管理版本。公布移除条件。必要时提供受支持的迁移方案。需要安全修复时，追踪哪些服务仍使用受影响版本。

不要让平台团队成为每项常规操作都要经过的人工审批队列。自动执行可重复的检查，把人工决策留给后果尚未明确的问题。衡量成功使用情况、等待时间、恢复结果和维护投入。

将平台与软件工厂连接

平台工程定义受支持能力和运行边界。软件工厂贯通要求、规划、实现、证据和交付。当软件工厂根据实际平台规划工作时，二者可以互补。

评估时纳入持续运维。验证由谁扫描新漏洞、部署修复、响应事件并维护合规证据。这些能力需要约定范围和负责人；“软件工厂”这个名称不会自动保证它们存在。

在具体环节评估集成：生成的修改能否使用现有部署路径，并保留其控制措施？团队能否检查为什么需要例外？平台改变时，谁更新共享上下文？

DORA 的研究把 AI 能力放在周围的组织条件中考察。采用这个视角评估完整工作流，包括仍由平台团队承担的工作。参见 DORA 2025 年报告。