AI 探索 + 元编程：Netflix 的可审计大规模代码改造

Netflix 工程师近日撰文介绍了一种将 AI 代理与元编程结合的大规模代码改造（LSC）方法。该方案先由 AI 在评估飞轮中探索问题空间，再把解法编码为一个确定性的元编程程序去执行改造，从而在速度、成本和可审计性上明显优于让 AI 代理直接对每个仓库「放手改」的方案。

问题：AI 代理直接做大规模改造的局限

大规模代码改造通常涉及成百上千个代码库同时迁移（例如把内部库从 v1 升到 v2）。这类任务具有「认知成本高」与「问题空间相对有界」的双重特征：必须处理的上下文很多，但因为变更要跨大量代码库通用，所以能被机械表达。

如果让 AI 代理直接执行这类改造，非确定性会和高认知成本叠加，带来低置信度、高开销和难以审计的结果。作者在 Netflix 内部就有周期性的依赖漏洞修复任务，覆盖约 2000 个 Go 仓库，每 6 小时跑一次。

方法：AI 探索 + 确定性程序执行

核心思路是让 AI 代理承担「探索问题空间」的角色，把解法沉淀成一个可重复运行的程序：

• 用 AI 代理在评估框架内做「发现 / 执行 / 评估」循环；
• 把新发现的情况编码成 txtar 测试，测试同时充当回归验证和审计文档；
• AI 代理根据构建与失败日志反复修正，并随稳态达成指数级扩大测试仓库集；
• 最终输出一个针对单一仓库运行的确定性程序。

相比之下，过去在没有 AI 的时代，这类工作也是手工写成「修改程序的程序」来完成的；新方法只是让 AI 代理接管了最花时间的探索与编码环节。

评估框架与测试驱动发现

以漏洞修复为例，评估信号由三部分组成：

• Go 自带的 govulncheck：判断是否存在可修复漏洞；
• 程序输出与退出码：判定修复是否成功以及失败原因；
• PR 的 CI/CD 日志：判定改造是否合法。

AI 代理在循环中持续扩展 txtar 测试覆盖，先在测试中验证，再向仓库集合提交 PR，根据失败日志重新评估。稳态后扩大测试池，作者观察到随测试规模增长，遇到的新案例越来越少。

与 Claude Sonnet 5 的基准对比

作者在 50 个仓库上对比了自研程序与 Claude Sonnet 5（中等工作量）AI 代理方案：

• AI 代理：每次约 50k tokens（约 0.15 美元），耗时约 4 分钟；
• 元编程程序：运行 < 2 秒，成本几乎只有少量 CPU 开销。

按 Netflix 约 2000 个 Go 仓库、每 6 小时跑一次估算，纯 AI 代理方案单次全量约 750 美元，而确定性程序方案成本可以忽略不计。

可审计性是另一大收益

除了成本与速度，确定性程序可直接通过常规源码控制历史审查其行为，审计难度与普通源码相当。这对于跨数千仓库批量执行的变更尤其关键——既能复用 AI 的探索能力，又不必把信任完全交给非确定性的模型输出。作者的结论是：AI 代理擅长探索与问题建模，确定性程序更适合大规模执行；两者结合可以在工程效率与可靠性之间取得更好的平衡。