BotOf Tech — 技术与植物养护笔记

Fable 5 最让工程团队警觉的案例，是 Stripe 据称把一个 5000 万行 Ruby 代码库迁移任务压缩到一天内完成，而人工团队原本可能需要两个月。

这类新闻很容易被读成“AI 要替代工程师”。但从工程角度看，更准确的理解是：Fable 5 把大型迁移里的协调成本、搜索成本和验证成本压缩了。

真正难的不是写代码，而是知道改哪里、按什么顺序改、怎么证明没改坏。

大迁移的难点从来不只是代码量

企业级迁移通常有几类隐性成本：

所以，50M 行迁移案例的重点不是“Fable 5 能输出多少代码”。如果只是生成大量 patch，反而危险。它的价值在于能在长上下文里维持一套迁移规则，并不断用测试反馈修正。

如果把这类案例拆开，底层应该不是一个 prompt，而是一条工程流水线。

在这条链路里，Fable 5 最适合做三件事：

最不应该让它做的是无审查直接合并。大迁移不是“模型输出即真理”，而是“模型把可验证候选方案推进到人类 review 前”。

Ruby / Rails 这类大型代码库，往往有动态调用、元编程、运行时约定、历史包袱和业务 DSL。迁移难点不是 AST 重写本身，而是很多行为无法只靠静态类型完全证明。

这意味着 Agent 需要组合多种信号：

Fable 5 的长任务能力如果成立，恰好能把这些信号维持在一个工作会话里。普通模型也能写 codemod，但很容易在第三轮之后忘记前两轮失败的约束。

我更建议把这类工作拆成多 Agent 或多阶段，而不是让一个模型从头干到尾。

这个分工的核心是把“昂贵推理”用在结构性判断上，把机械工作交给工具和便宜模型。

Fable 5 的 API 价格很高，公开价格信息显示每百万 input tokens 10 美元、output tokens 50 美元。单价看起来贵，但迁移任务不该按单轮调用算账。

更合理的公式是：

迁移总成本 =
  模型 token 成本
+ 工具执行时间
+ CI 资源
+ 人工 review 时间
+ 回滚和事故风险
- 被节省的协调和等待成本

如果一个小模块迁移本来半天能做完，Fable 5 没必要。如果一个跨团队迁移要持续两个月，会议、等待、冲突和返工才是大头，强模型才可能有经济性。

Stripe 级案例有一个前提：目标清楚、工程系统成熟、测试足够强、迁移结果能被自动验证。没有这些，Fable 5 只会更快地产生不可审查的复杂 diff。

团队在尝试前应该先问：

Fable 5 在大迁移里的价值，不是“自动写代码”，而是“自动维持迁移上下文”。

它能让一个原本靠会议、文档和经验传递的过程，变成可循环的工程流水线：扫描、计划、改写、测试、修正、验收。

这才是大型代码项目里的真正杠杆。未来工程组织使用强模型，不会是每个开发者都开着最贵模型写日常代码，而是把最贵模型放在迁移、重构、排障、架构审计这些高协调成本任务上。