Fable 5 × Codex 实战：用一个 Loop 完成 AI SDK 7 全量升级

从 Fable 5 上线那天早上开始，到现在，我让 Fable 5 和 Codex 一起跑完了第一个完整 Loop。

目标很具体：帮我的 CodePilot 完成 AI SDK 7 的全部升级。

连续跑了两天，额度还没用完。实际体验下来，Fable 5 不需要一上来就开很高的思考额度。只要任务拆得清楚，代码库状态稳定，低一点的配置也能持续推进。

这套方法适合什么场景？

大版本依赖升级
API 批量迁移
老项目重构
多文件联动修改
需要反复测试、修复、再测试的工程任务

核心不是让模型一次性写完所有代码。

核心是让它进入一个可控的循环：

读取项目
  ↓
制定修改计划
  ↓
执行一小批改动
  ↓
运行类型检查和测试
  ↓
读取报错
  ↓
修复问题
  ↓
继续下一批

这才是 AI 编程真正能落地的姿势。别指望一句“帮我升级到最新版”就能收工，那更像是在给自己预约一场调试马拉松。

这次升级的任务边界

这次任务围绕 CodePilot 展开，目标是把项目迁移到 AI SDK 7。

大版本升级通常会碰到几类问题：

导入路径变化
方法名和参数结构变化
Provider 配置变化
流式输出接口变化
类型定义变严格
旧版兼容代码失效
测试用例和 Mock 需要同步调整

这些问题很少集中在一个文件里。

模型改了一个调用点，可能会影响类型定义；类型修好了，测试又可能暴露出运行时差异。把任务当成单次问答，成功率不会太高。把它当成一个持续运行的工程 Loop，结果会稳定很多。

一个实用的 Loop 怎么跑

1. 先让模型认识项目，不要急着改

把仓库交给 Fable 5 和 Codex 后，我会先要求它完成项目扫描：

请先不要修改代码。

扫描当前项目，确认：
1. 使用了哪些 AI SDK 相关包
2. 所有 SDK 调用点分布在哪些文件
3. 当前版本和目标版本的差异
4. 可能受影响的类型、Provider、流式响应和测试文件
5. 升级过程中最可能出现的风险

请输出：
- 受影响文件列表
- 修改优先级
- 推荐执行顺序
- 每一步完成后的验证命令

这一步看起来慢，实际是在省时间。

如果模型没有建立项目地图，后面很容易出现漏改、重复改、误删配置的问题。代码库越大，扫描阶段越不能省。

2. 把大升级切成小批次

不要直接下达这种指令：

把项目全部升级到 AI SDK 7，确保能运行。

这句话目标太大，验收标准也太模糊。

可以拆成几批：

请处理第一批：
- 升级 AI SDK 相关依赖
- 更新所有直接导入路径
- 暂时不要修改业务逻辑
- 修改完成后运行类型检查
- 如果出现报错，先修复本批次引入的问题
- 汇报改动文件和剩余风险

然后再处理：

请处理第二批：
- 迁移文本生成调用
- 迁移流式响应处理
- 保持现有函数签名不变
- 为每个改动点补充必要的类型修正
- 运行测试并报告失败用例

这样做有两个好处：

出错时容易定位
模型不容易跨文件乱改

一次只给它一个明确的小目标，工程质量通常比“全包”更好。

Fable 5 不需要一开始就拉满思考额度

这次连续运行了两天，额度还没有用完。

我的实际策略是：

项目扫描：使用中等思考额度
常规导入替换：使用较低额度
类型报错修复：根据复杂度临时提高
跨模块架构调整：再给更充足的思考空间

不是每个动作都值得消耗最高配置。

批量改导入、修正明显的类型错误、更新简单参数，这些工作更依赖上下文完整和验证及时。把大量额度用在机械修改上，性价比不高。

真正需要提高配置的情况，通常是：

报错信息互相牵连
同一个 API 在多个抽象层被封装
流式响应行为发生变化
类型通过了，运行时却失败
模型连续两轮修复仍然没有解决问题

判断标准很简单：连续两次修改没有让测试结果变好，就别让模型继续盲修。提高思考额度，或者人工介入重新整理问题。

每个 Loop 都要有明确的验收点

AI 改完代码后，不能只看它说“已完成”。

每一轮都安排固定检查：

pnpm install
pnpm typecheck
pnpm lint
pnpm test
pnpm build

具体命令按项目实际情况替换。

重点是让模型自己跑验证，而不是把验证工作留给你。可以直接这样要求：

完成修改后，请依次执行：
1. 类型检查
2. lint
3. 单元测试
4. 构建

不要只描述结果，请读取实际命令输出。
如果失败：
- 判断是本轮修改造成的问题，还是项目原有问题
- 给出失败原因
- 直接修复本轮相关问题
- 重新执行失败的命令

这段话很关键。

没有“读取实际输出”这句，模型可能只会根据代码表面推测成功。代码升级最怕这种“看起来对，跑起来炸”的情况。

给 Codex 的推荐任务模板

你可以把下面这段作为通用模板，放进升级任务里：

你正在维护一个真实运行中的项目。

目标：将当前项目升级到 AI SDK 7。

工作规则：
- 修改前先读取相关文件和依赖配置
- 不要凭记忆猜 API，优先以项目代码、类型定义和官方变更为准
- 每次只处理一个明确批次
- 不要顺手重构无关代码
- 保持现有业务行为不变
- 修改后运行类型检查、测试或构建
- 记录每个失败命令的完整输出
- 遇到不确定的问题，先说明假设，再继续执行

本轮任务：
[填写具体任务]

验收标准：
[填写必须通过的检查]

完成后请输出：
1. 修改了哪些文件
2. 每个文件改了什么
3. 执行了哪些验证命令
4. 哪些命令通过
5. 还有哪些风险或待办

这个模板的重点不在措辞多漂亮，而在于给模型加上边界、验证和汇报机制。

升级过程中最容易踩的坑

坑一：让模型一次性重写整个项目

看起来省事，实际很容易带来大范围噪音。

模型可能顺手改掉命名、目录结构、错误处理，甚至动到和升级无关的业务逻辑。后面出问题时，你很难判断是哪一处改动造成的。

**处理方式：**限定文件范围和本轮目标。无关重构全部延后。

坑二：只升级 package.json

依赖版本更新只是起点。

真正麻烦的是调用方式、类型、流式处理和测试代码。只改依赖，不跑检查，基本等着后续报错。

**处理方式：**依赖升级后，立刻搜索旧 API、旧导入和旧配置。

坑三：看到类型错误就直接加 any

这是 AI 修代码时很常见的偷懒路线。

类型错误消失了，问题被藏起来了。等到生产环境遇到异常响应，排查成本更高。

**处理方式：**要求模型解释类型冲突的来源，优先调整真实类型和数据流，不要用 any 盖住问题。

坑四：测试失败后不断重试同一个方案

模型有时会在同一个方向上来回打补丁。代码越来越复杂，测试结果却不动。

**处理方式：**连续两次失败后暂停，让模型重新总结：

当前方案连续两次没有通过测试。
请停止继续打补丁，重新分析：
1. 失败是否来自 API 迁移方向错误
2. 当前封装是否仍然使用旧版假设
3. 是否需要回退最近一轮修改
4. 请提出两个替代方案，并比较风险

这一步能把模型从“修补模式”切回“分析模式”。

坑五：忽略运行时验证

类型检查通过，不代表 AI 调用真的正常。

尤其是流式输出、工具调用、错误处理、Provider 配置，这些地方经常出现类型层面看不出的差异。

**处理方式：**准备一个最小可运行场景，验证真实请求、流式返回和异常分支。

一套适合日常开发的操作节奏

如果你也要用 Fable 5 和 Codex 做大规模升级，可以照着这个节奏走：

开始前

建立独立分支
保存当前测试结果
确认依赖管理命令
找出所有 SDK 入口文件
准备回滚方案

执行中

每轮只改一类问题
每轮都跑验证命令
记录失败输出
及时提交小版本
不要把多个未验证批次叠在一起

收尾时

检查是否还有旧 API
搜索旧版本配置
跑完整测试和构建
手动验证关键 AI 流程
清理临时兼容代码
让模型生成升级变更记录

提交粒度越小，回滚越轻松。别等改了四十个文件、堆了两百处变化，才发现第一步就走偏了。

这次实践得到的结论

Fable 5 和 Codex 适合处理这类持续型工程任务，但前提是你要把它们放进一个明确的 Loop 里。

任务拆分、命令验证、错误回读、分批提交，这几件事缺一不可。

思考额度也不用盲目拉高。简单迁移交给低额度，复杂报错再临时加码，通常更省资源。连续跑两天，额度没有耗尽，说明稳定的流程比堆配置更重要。

真正好用的 AI 编程，不是模型替你敲完所有代码。

是它能持续读取项目、执行修改、面对报错、调整方案，并且每一步都留下可检查的结果。

这才是一个能用于真实项目的 Loop。