别再只聊 AI 写代码了：技术负责人要把“变更治理”提到第一优先级

亚马逊开始"严管 AI 代码"后，我才意识到：CTO 真正该管的是变更

亚马逊最近在内部沟通里释放了一个信号：在经历与 AI 代码代理相关的故障后，他们要对 AI 辅助改动加更多监督，并让低/中级工程师的 AI 改动需要更资深的人签核。

这事最值得技术管理者学的，不是"AI 行不行"，而是它背后的工程判断：

当生成变快，系统的风险会从"写代码"迁移到"变更治理"。你不把治理补上，AI 只会把团队带入一种更快、更频繁、也更难定位责任的变更洪水。

我想用一个我很熟悉的场景，把这件事讲透：Docker Compose + 蓝绿部署的团队，如何在"用 AI 提效"的同时，把上线风险稳稳压住。

────────────────────────────────────────────────────────────────────────────────

1）一个典型事故：能启动不代表能服务，依赖变更最阴

我们团队曾经踩过一次非常典型的坑（细节已模糊化）：

服务跑在 Ubuntu 基础镜像上，核心是 Python 服务，调用 OpenAI SDK，同时依赖 PostgreSQL。
一次看似"无害"的变更里，我们更新了部分依赖 / 镜像层（属于依赖/运行时类变更）。
上线后很"迷惑"：容器都能正常启动、健康检查也过了，但用户侧表现是------chat 功能就是不工作：请求卡住/异常返回，像是某个运行时链路悄悄断了。

这类事故为什么难？

启动期检查覆盖不到：进程活着不等于关键链路可用。
蓝绿也未必兜住：如果你的"切流门禁"只看 healthz，而不跑关键链路 smoke test，蓝绿只是更体面地把问题放大。
依赖变更的 diff 不显眼：不像业务代码那样能一眼看出风险，review 很容易放过。

结论很简单：AI 会提高代码产能，但"未经消化的变更"会更多；真正翻车的，常常是依赖、配置、部署路径。

2）"更高等级签核"不是官僚，是风险分级后的护栏

很多团队对签核有抵触，觉得慢、觉得麻烦。但成熟的签核不是一刀切，而是风险分级：

低风险：改注释、日志文案、非核心功能的小修小补
中风险：触及关键链路、权限逻辑、发布配置
高风险：依赖大版本升级、基础镜像变更、数据库迁移、鉴权/支付等核心域

关键是：AI 辅助改动应当默认"中风险起步"，除非你能用证据把它降级。证据不是"我觉得没问题"，而是可判定的规则 + 自动化验证。

3）给你一套可判定的风险规则：命中即升级门禁

只要 PR 命中以下任意一条，直接判定为中/高风险（触发更严门禁与资深签核）：

触及：docker-compose.yml / compose.*.yml / .env / 发布脚本
触及：Dockerfile / 基础镜像 tag / 系统包安装（apt）
触及：Python 依赖锁（requirements.txt / poetry.lock / pipfile.lock）
触及：OpenAI / 数据库客户端相关依赖版本
新增/修改数据库 schema 或迁移脚本
PR 标记 AI-assisted: yes 且改动文件数/行数超过阈值（例如 >10 files 或 >300 LOC）

这套规则的意义是：把"主观谨慎"变成"客观分级"。你可以和团队争论观点，但不该让上线安全靠争论。

4）在 Docker Compose + 蓝绿下，把可控性做成系统能力

我建议 CTO 直接推动"三件套"：可追溯、可验证、可回滚。

4.1 可追溯：AI 参与必须写进系统，而不是口头说

最低成本做法：在 PR 模板里强制勾选（把责任边界写清楚）。

PR 模板（可直接复制）：

（示例字段按你们流程改即可）

markdown 复制代码

  ## 变更摘要
  - 这次解决了什么问题：

  ## 风险分级（必填）
  - [ ] 低风险（不涉及依赖/配置/发布/核心链路）
  - [ ] 中风险（涉及关键链路/配置/发布脚本/AI 辅助改动）
  - [ ] 高风险（依赖大版本/基础镜像/数据库迁移/核心安全域）

  ## 依赖/运行时变更（必填）
  - [ ] 无
  - [ ] 有：类型（基础镜像 / 语言运行时 / 核心库 / 中间件客户端 / 其他）

  ## AI 辅助（必填）
  - [ ] AI-assisted: no
  - [ ] AI-assisted: yes
    - 主要用于：生成代码 / 改写重构 / 写测试 / 写脚本 / 其他
    - 人工复核点：我重点检查了哪些边界条件：

  ## 发布与回滚
  - 发布方式：蓝绿 / 灰度 / 直发
  - 回滚方案：一键回到上一版本（是/否）
  - smoke test（列出 3-5 条关键链路）：
    1.
    2.
    3.

一旦出事，你至少能回答：这次是否 AI 参与、是否依赖变更、风险等级怎么判的。追溯能力，是治理的起点。

4.2 可验证：蓝绿切流门禁要测关键链路，不是只看 healthz

你们这类"能启动但不能 chat"，本质就是：门禁没覆盖关键路径。

建议把切流前门禁做成脚本化 smoke test，至少覆盖：

/healthz（存活）
PostgreSQL 连通性（依赖）
一个真实 chat 最小闭环（关键链路）

硬规则：门禁不通过，禁止切流；切流后 5 分钟内指标异常自动切回。

│ 下面是伪代码示例，请按你们实际接口与返回字段调整。

bash 复制代码

  #!/usr/bin/env bash
  set -euo pipefail

  BASE_URL="$1"   # green 环境地址

  echo "[1/3] healthz"
  curl -fsS "${BASE_URL}/healthz" >/dev/null

  echo "[2/3] postgres connectivity"
  curl -fsS "${BASE_URL}/internal/checks/postgres" >/dev/null

  echo "[3/3] chat smoke test"
  RESP=$(curl -fsS -X POST "${BASE_URL}/api/chat" \
    -H "Content-Type: application/json" \
    -d '{"message":"ping"}')

  echo "$RESP" | grep -q "pong\|ok\|assistant"  # 按你们实际返回改

  echo "SMOKE OK"

如果你不方便暴露内部检查接口，也可以在服务内部提供只对内网开放的 /internal/checks/*，只做连通性与权限校验，不泄露数据。

核心原则：切流门禁要覆盖"用户真正关心的成功标准"。

4.3 可回滚：把"理论可回滚"变成"演练过的能力"

蓝绿的价值是回滚快，但前提是你真的练过。

我建议 CTO 把回滚演练制度化：

每月至少一次：从 green 切流到 blue，再切回
要求 5--10 分钟内完成
演练要记录：耗时、阻塞点、是否需要人肉改配置

AI 加速变更后，回滚能力会成为团队的安全阀。发生问题时，第一反应是回滚，而不是在生产上 debug。

5）给 CTO 的稳健路线：先治理变更，再扩大 AI 使用半径

最后给一个我认为更稳健、可执行的推进顺序（建议收藏）：

允许 AI 辅助，但强制 PR 可追溯（模板先上）
把依赖/镜像/Compose/发布脚本列为高风险变更，默认资深签核
把蓝绿切流门禁升级为关键链路 smoke test（覆盖 chat 最小闭环）
把回滚演练变成制度（每月一次）
等数据证明稳定（事故率、回滚次数、平均恢复时间），再逐步放宽限制

亚马逊所谓"更高等级签核"，其实是在告诉我们：

工程管理的主战场，正在从"写代码"迁移到"控制变更"。

当你把这件事做对，团队会更敢用 AI，也更敢快。