AI 作为初级平台工程师：我如何‘Onboard’编码代理

Source: Dev.to

（请提供您希望翻译的具体文本内容，我将为您翻译成简体中文，并保留原始的格式、Markdown 语法以及技术术语。）

介绍

我第一次在 DevOps 工作流中认真使用 AI 时，犯了我见过的许多其他人也会犯的同样错误。当一名新工程师加入团队时，我们并不指望他们立刻就能高效工作。我们也不会直接把生产系统的访问权限交给他们，然后要求他们立刻产出成果。

• 关于系统的背景
• 文档
• 边界
• 一个安全的贡献环境
• 了解系统运作方式的时间

没有这些，即使是有才华的工程师也会感到吃力。AI 也不例外。好与坏的 AI 输出之间最大的区别之一是 上下文。缺乏上下文时，AI 代理会给出通用答案——技术上是正确的，但并未与您的系统、架构或约束相匹配。这正是 context.md 文件能够发挥极大作用的地方。

• 您的基础设施如何组织
• 命名约定
• 环境和工作流
• 约束（成本、安全、合规）
• Terraform 模块的组织方式
• 系统中“良好”状态的表现

一旦 AI 获得了这些上下文，它的建议就不再显得千篇一律，而更像是适用于您系统的方案——就像一位终于弄清楚系统如何连接的初级工程师一样。

平台概述

概览

本仓库使用 Terraform 管理 AWS 基础设施。主要工作负载运行在 dev、staging 和 production 环境的 EKS 集群上。

核心原则

• 尽可能使用托管服务
• 将变更的影响范围（blast radius）降到最低
• 避免跨环境耦合
• 所有变更必须通过 PR 审核

Terraform 结构

• modules/ → 可复用的基础设施组件
• envs/dev → 开发环境
• envs/staging → 预发布环境
• envs/prod → 生产环境

命名约定

资源命名遵循：--
示例： prod-payments-eks

保护措施

• 绝不直接修改生产环境
• 未经 PR 批准不得执行 terraform apply
• 除非明确需要，否则避免导致资源替换的变更

成本约束

• 除非有充分理由，否则优先选择更小的实例类型
• 自动伸缩必须始终设定上限

安全性

• IAM 角色必须遵循最小权限原则
• 除非明确批准，禁止使用通配符权限

审核期望

审查 Terraform 计划时，关注以下方面：

• 资源替换
• 网络或 IAM 的变更
• 扩容或成本影响
• 跨模块影响

“优秀” 的表现

• 小范围、孤立的变更
• 清晰的 PR 描述
• 最小的影响范围（blast radius）

与 AI 共事的初级平台工程师

在为新工程师入职时，我们也会定义边界：他们应该做什么、不应该做什么、可以进行哪些更改以及哪些需要审查。同样的做法也适用于 AI。

AI 不应：

• 直接应用基础设施更改
• 绕过审查流程
• 做出需要运营判断的决定

这些都是有意的设计选择。就像新工程师一样，目标是安全贡献，而不是最大化自主权。

当新工程师加入时，我们通常让他们从以下开始：

• 小的更改
• Pull Request
• 代码审查
• 有指导的反馈

这会随着时间的推移建立信心和信任。同样的模型在 AI 上也非常有效。与其让 AI 直接操作基础设施，我把它当作 PR 工作流的贡献者。它可以：

• 生成更改
• 解释差异（diff）
• 标记潜在问题
• 提升可读性

最终决定仍然由人工审查完成，既保持系统安全，又能受益于 AI 的加速。

初级工程师通过反馈不断进步；AI 系统也通过迭代不断提升。当出现问题时，答案很少是“AI 不起作用”。更常见的是 上下文不完整。随着时间推移，完善上下文和期望会让 AI 变得更可靠——它不再像随机生成器，而更像一个理解系统的团队成员。

把 AI 视作初级平台工程师会改变你设计工作流的方式。不要再问：

“这个工具能做什么？”

而是开始问：

“我该如何让某人加入这个系统？”

这个问题自然会引导出：

• 更好的上下文
• 更清晰的边界
• 更安全的工作流
• 更可预测的结果

在 DevOps 中，AI 并不需要被当作自主操作员。在许多情况下，它作为一名经过良好入职的初级工程师效果最佳：

• 受上下文指引
• 受防护栏约束
• 通过安全工作流贡献
• 随时间不断改进

目标不是取代工程师，而是让系统更易理解、更安全运行、演进更快。有时实现这一目标的最佳方式不是赋予 AI 更多权力，而是更有思考地对其进行入职。

期待听到你对这种方法的看法。

Originally published on Medium: