---
title: "一次大重构，我只在前两步用了 Fable | 行开心的颠倒世界"
description: "用 Claude Fable 做大重构时，顶级模型跑全程不仅消耗数百刀等价额度，更会频繁触发 5 小时速率限制导致工期中断。关键工程杠杆在换档：Fable 负责顶层规划与敲定样板，后续批量实施降档给 Opus 或 Sonnet，既保质量又避开速率熔断。"
canonical: "https://xingkaixin.me/posts/model-downshift-point/"
language: "zh-CN"
---

# 一次大重构，我只在前两步用了 Fable

用 Claude Fable 做大重构时，顶级模型跑全程不仅消耗数百刀等价额度，更会频繁触发 5 小时速率限制导致工期中断。关键工程杠杆在换档：Fable 负责顶层规划与敲定样板，后续批量实施降档给 Opus 或 Sonnet，既保质量又避开速率熔断。

2026年9月23日·1,806 字·5 分钟

[AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[Claude](https://xingkaixin.me/tags/Claude/)代码重构

![一次大重构，我只在前两步用了 Fable](https://xingkaixin.me/cover/model-downshift-point.webp)

上个月我重构一个服务的错误处理层，十四个文件，要把散落在各处的字符串报错换成带错误码、调用上下文和 cause 链的结构化错误。

第一次我开着 Fable 加上高推理档位跑全程。十四个文件改完，虽然测试全绿，但代价极其昂贵：折算下来这一趟直接烧掉了将近七百美元的等价 token 额度。更要命的是刚改到第七个文件，密集的超长上下文加上高推理消耗，直接撞上了订阅制的 5 小时用量上限。任务被迫中断，我只能干等下一个 5 小时窗口重置才能继续，原本半天能搞定的活硬生生被拖了一整天。

两周后遇到类似的任务，我走向另一个极端，换成廉价小模型跑全程。它在第一步就把方向定歪了，把错误转换直接塞进每个底层数据库调用点，而不是在 API 边界做统一收口。等我发现不对，十几个文件已经改完，推倒返工又花了大半天。

这两种跑法都走偏了。真正的工程杠杆在于找到那个精准的换档点：**用 Fable 做顶层设计与定模，用 Opus 或 Sonnet 承接批量实施。**

## 顶级模型买的是第一个正确的形状

用顶配模型完成前期的架构设计，并让它亲手改完第一个文件；一旦代码模式定下来，立刻把任务交接出去。

这套做法的核心在于“亲手改完第一个文件”。

一份写着“在业务边界统一做错误收口”的重构文档，根本管不住后面的具体实现。真正定下代码形状的，是第一个文件里的那几十行具体代码：错误码枚举怎么命名、底层的原始 error 怎么包进 cause、HTTP 状态码映射写在哪里、单元测试里的断言结构怎么写。

这些工程约定很难巨细靡遗地全写进 prompt 里，但后面的十三个文件全都会严格照着这第一个样本模仿。

顶配模型在复杂系统的边界抽象和架构权衡上极具优势。用它跑前两步，买的是第一个真正正确的代码形状。前两步只占极少数的交互轮次，既能把最核心的规矩立稳，又完全不会触碰 5 小时速率限制的红线。

## 实施阶段降档给性价比模型

样板一旦立住，后续的工作本质上是高质量的模仿与适配。

这时候把任务交接给 Opus 或 Sonnet，不仅消耗降了一个数量级，更关键的是它们的速率上限宽裕得多。十四个文件的重构，后半段十个模块的处理直接降档，整个任务不仅不会把一周的高配额度抽干，更可以一口气连续跑完，不需要在 5 小时限制面前被迫“中场休息”。

在日常开发里也是同样的逻辑：机械改动交给性价比模型，只有在探索新架构或者大重构时，才动用最高规格模型的预算。

任务分层清晰之后，模型的额度消耗与开发节奏才能达到真正的平衡。

## 换档的依据只有一个：是否在做新决策

刚开始做分档时，我常按“这个任务难不难”来选模型，后来发现这个标准极不可靠。难易往往是主观感觉，同一个任务今天觉得棘手，明天理清了又觉得简单。

真正客观的判定标准是：**这一步需要做新决策吗？**

把重构计划拆成明确的任务节点，然后挨个评估：这个节点是在引入新的设计，还是在把前面确定的 pattern 照搬到下一个模块？

回到那次错误处理的重构。第一个接口的处理涉及全局架构设计，用 Fable 跑。剩下十几个接口只是换个数据结构和方法名，直接降到 Sonnet 或 Opus，我只需要扫一眼 diff 的代码形状是否变形。中间如果遇到一个带重试和退避逻辑的特殊模块，超出原有模板，那就把这一步单独升回高档位。

一次完整的重构里，顶配模型通常只出现两次：前期规划一次，敲定第一个样板文件一次。其余时间让它待机。

![定模覆盖主要变体，批量实施遇到例外时再升档](https://xingkaixin.me/posts/images/model-downshift-point/model-downshift-point-01.webp)

## 模式没立稳就降档，返工更贵

换档也有陷阱，最容易翻车的情况是样板还没完全定型就过早降档。

我曾经踩过一次坑：重构一个 API 模块时，第一个节点只写了一个普通的同步 CRUD handler，我就以为 pattern 已经立稳，把任务全交给了便宜模型。

但我忽略了系统里还有带长连接和异步推送的流式接口。便宜模型拿到同步接口的样板，机械地把它硬套在流式接口上，直接吞掉了 context 取消信号和超时控制。测试用例由于 mock 不够细甚至跑通了，直到联调压测时才发现连接泄露。

要避免这种返工，第一个节点必须把主要的变体覆盖全。如果系统里同时存在同步调用、异步流式和带重试的链路，样板阶段就得让顶配模型把这三种形态各做出一份标准解法，再把后续的搬砖任务分发下去。

## 换档发生在任务边界，保护 Prompt Cache

换档在工程落地时还有一个关键细节：**档位切换必须发生在任务边界上，不要在单次对话中途临时改模型。**

在同一个会话中途修改模型配置，往往会破坏已有的 prompt cache，为了省几个 token 反而导致整段长上下文被重新计算，既慢又费。

更顺畅的工程做法是按步骤切断上下文：

1.  **定模阶段**：用 Fable 开一个全新会话，完成方案规划并落地第一个文件的代码，确认无误后提交 git commit。
2.  **实施阶段**：开启一个使用 Sonnet 或 Opus 的工作会话，只把刚才提交的 diff 和规范当作参考输入，让它专注于按样板批量修改剩余文件。
3.  **验证阶段**：在实施全部完成后，起一个干净会话做最后一轮审查与边界测试。

成熟的重构流程应当是：规划与样板用高配，批量实现交给性价比模型，并在任务边界上完成干净的交接与验证。

下次发现订阅额度见底或者频繁撞上限制时，不要直接把整个流程切到廉价模型。**先看清楚，任务里的哪一步是在定义规则，哪一步只是在执行规则。**

## 版权声明

作者

XingKaiXin

标题

一次大重构，我只在前两步用了 Fable

发布时间

2026年9月23日

文章链接

[https://xingkaixin.me/posts/model-downshift-point/](https://xingkaixin.me/posts/model-downshift-point/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

导览

展开导览