大规模 Legacy 代码库的 AI 治理

渐进引入：Strangler 与 codemod，别大爆炸

背景与原理

Martin Fowler 的 Strangler Fig：不重写，而是在边界处长出新结构，逐步「绞杀」旧代码，直到旧的可以摘除。落到治理上有两条具体手法。其一，changed-files-only gating：新规则（类型检查、lint、复杂度上限）只对 PR 里实际改动的文件强制，存量豁免但冻结——这样开发者「碰到哪改到哪」，治理随自然改动渗透，而非一夜之间引爆。其二，机械的存量改造交给 codemod（jscodeshift / OpenRewrite / ast-grep）——AST 级脚本批量改，而不是人逐文件手搓。AI 在这里的角色很明确：codemod 写不动的长尾（语义不规整、需要判断的）交给 agent 批量改，但每个改动仍走后面 §3/§4 的门。

实战示例

# 只对本次 PR 改动的文件跑严格检查，存量不动
CHANGED=$(git diff --name-only origin/main... | grep '\.ts$')
if [ -n "$CHANGED" ]; then
  npx tsc --noEmit --strict $CHANGED      # 新/改的文件必须过 strict
  npx eslint --max-warnings 0 $CHANGED    # 存量旧文件不在列表里，豁免
fi
# 机械迁移用 codemod，不是手工：
# npx jscodeshift -t rename-api.js src/   ·   ast-grep --pattern '...' --rewrite '...'

核心 mental model：把治理接到 diff 上，而不是接到全库扫描上。全库扫描产出几千个你今天不会修的 violation，只会训练团队「忽略红色」——这是治理之死。

棘轮与护栏即代码：让库只能变好

背景与原理

Ratchet（棘轮）：记录当前 violation 数为 baseline，CI 只在「比 baseline 更差」时 fail。存量被容忍，新增被挡住；每修好一点就把 baseline 调低，且不可回升——像棘轮一样只朝一个方向转。工具如 betterer 把这做成了通用机制。配套的是护栏即代码 / fitness functions（《Building Evolutionary Architectures》）：把架构约束写成可执行测试——依赖方向、分层边界、禁止 import、复杂度上限——用 ArchUnit / dependency-cruiser / import-linter 跑。治理从此从「文档 + 人盯」变成「CI 红绿」，不依赖谁记得。AI 的位置：让 agent 每个 PR 顺手降一点 baseline（修一两个存量），长尾债在日常改动中被慢慢磨平，而不是立一个永远没空做的「重构 sprint」。

实战示例

# fitness function：把「UI 层不许直接 import 数据库」写成测试
import { dependencyCruiser } from "dependency-cruiser"
forbidden = [{
  name: "ui-not-to-db",
  from: { path: "^src/ui" },
  to:   { path: "^src/db" },          # 违反 = CI 红，不靠 code review 抓
}]

# ratchet：只挡「比昨天更糟」
BASE=$(cat .debt-baseline)               # 例如 412
NOW=$(count_violations)
if [ "$NOW" -gt "$BASE" ]; then echo "债增加了：$BASE→$NOW"; exit 1; fi
[ "$NOW" -lt "$BASE" ] && echo "$NOW" > .debt-baseline   # 变好就锁住新低点

让 review 不成瓶颈（上）：自动门先过滤

背景与原理

把 code review 想成 Day 34 HITL 的 confidence routing 落在代码上：每个 PR 先过一排 pre-human gate（机器门）——测试、类型、lint、coverage delta、SAST/secret 扫描、依赖审计、变更影响分析。门没过 = deny，根本不进人的队列；门全过才轮到人决定要不要细审。这对 AI 生成代码尤其值钱：AI 最高频的失败——幻觉不存在的 API、把失败测试改成 assert True 让 CI 转绿（见 Day 31 的 test tampering）、漏掉 null / 并发 edge case——很大一部分是机器可检测的。让 sanitizer、类型系统、mutation test、secret scanner 去抓这层，人的注意力才不会浪费在「机器本可以查出来的东西」上。关键原则反过来也成立：别让人去做机器更擅长的（人眼读不出 race condition，但 ThreadSanitizer 能）。

让 review 不成瓶颈（下）：风险分级 · 抽样 · provenance

背景与原理

三件事把人的注意力压到「能认真审」的量级。① 风险打分：按改动碰到的路径定级——支付 / 认证 / 数据迁移 / 加密 = 高；文案 / 测试 / 注释 = 低——再叠加 diff 体量与 blast radius（见 Day 31）。高风险强制 full review + CODEOWNERS 指定 owner；低风险抽样人审 + 全量事后审计。② 信任分层：给「AI 作者」与「人类作者」不同的默认 review 强度，并随 track record 调整（同 Day 34 的审计回归阈值）——新接入的 agent 严审，跑稳了再放宽。③ Provenance / attestation：标注哪些代码由 AI 生成、用了什么模型 / prompt（SLSA 式溯源）。出事时能精确定位、能批量召回「某个坏 prompt 产出的所有代码」——这是 AI 规模化后的必需品，不是合规摆设。

实战示例

def review_policy(pr):
    paths = pr.changed_paths
    high = any(p.startswith(("src/payment","src/auth","migrations/")) for p in paths)
    risk = "high" if high or pr.diff_lines > 400 else "low"
    trust = author_trust(pr.author)         # AI 新手 < 人类资深，随记录调整
    if risk == "high": return "full_review + CODEOWNERS"
    if trust < 0.7:      return "full_review"
    return "sample_5pct + post_merge_audit"   # 低风险高信任 → 抽样

# PR 元数据带上来源，出事可溯源 / 召回
provenance = { "ai_generated": True, "model": "claude-opus-4-8", "prompt_id": "refactor-v3" }