一个案例让你直观感受 Fable 5 的能力上限和成本

强模型接入工程流程，先算失败代价，再看模型能力。任务失败后只是多改一行文档，低成本模型足够；任务失败后可能造成静默数据丢失、公开接口破坏或安全事故，模型等级就要上调。

Simon Willison 是 Django 共同作者、Datasette 作者，也是 sqlite-utils 的维护者。七月初，sqlite-utils 准备从 rc1 推进到 rc2。Fable 5 给出的复查报告列出了 5 个 release blockers，最严重的问题出在 delete_where()：这个方法没有提交事务。

程序表面上一切正常：删除一行不报错，插入新数据也不报错；连接关闭后再打开，刚删掉的行还在，刚插入的数据没有落地。没有 crash，没有 traceback，只有一份看起来成功、实际上失败的记录。

这次复查最终回算出约 $149.25 的 API 成本。这个数字单独看不便宜，和静默数据丢失放在一起看，性质就变了。

发版案例的能力账与成本账

失败代价决定模型等级

模型路由的第一道判断，是失败代价。低风险任务可以接受低成本模型先跑一遍；高风险任务一旦出错，后续修复成本会远高于本次调用成本。

delete_where() 的事务缺失属于高风险任务。SQL 指令已经发出，事务却没有提交。在同一连接内，SQLite 允许后续查询看到未提交修改，表面上一切生效；连接中断后，从未抵达磁盘的变更随之消失。更隐蔽的是连续调用：先 delete_where()，再 insert()，中间状态都正常，重连后删没删、写没写，全不算数。

这类问题如果进入稳定版，修复就可能变成 breaking change，并影响依赖 sqlite-utils 的下游项目。$149.25 买到的是一次发布前的风险拦截，远高于普通检查的价值。

原则很简单：失败代价越高，越应该提高模型等级。强模型优先处理“错一次就很贵”的任务，而不是日常低风险操作。

闭环能力决定任务上限

第二道判断，是任务是否需要闭环能力。很多模型可以指出疑点，真正困难的是把风险识别、复现、修复和文档补齐连成一条链路。

静默缺陷尤其需要这种闭环。它不会强制流程停下，也不会在日志里留下明显信号。一次调用、一次返回、无错误、无告警，普通代码审查很容易从旁边经过。等业务侧发现数据异常，问题可能已经经过几个月、几十个提交，排查成本被不断放大。

Fable 5 的发版闭环

这次任务中，Fable 5 不只标记了 delete_where() 的事务风险。它构造可复现的端到端用例，解释根因，提交修正代码，并补写事务模型文档。审阅过程中还遇到 Python 3.12 autocommit 语义导致的大批测试失败，模型继续补齐相关处理。

强模型适合处理整条风险链路：从识别问题一直推进到可发布状态。如果任务只需要候选补丁，低成本模型先跑；如果任务需要完整闭环，强模型才有进入主线的理由。

成本分布决定执行分工

第三道判断，是成本分布。强模型贵，通常贵在深度推理主线；外围扫描、上下文检索、测试执行，并不一定需要同一等级的模型。

这次发版任务包含 37 prompts、34 commits，修改覆盖 30 separate files。使用 AgentsView 回算后，main session 约 141.02，多个子 agent 合计约 8.23，总计约

Fable 5 成本拆解

这组数字的重点是成本分布。主 session 承担深度推理和关键修复，所以消耗最高；子 agent 做扫描、复查、补充验证，成本很低。

因此，执行分工应顺着成本结构设计：低成本模型做外围，高能力模型做关键路径。让 Fable 5 长期处理格式整理、API 查询、候选补丁收集，相当于让外科医生每天削铅笔；问题出在岗位安排。

预算闸门决定能否持续

第四道判断，是预算是否可持续。中文开发团队接入强模型时，通常不只面对 API 账单，还要向团队和决策层解释：为什么这个任务必须调用高成本模型，为什么低成本模型不足以完成。

没有预算闸门，强模型会同时造成两类损耗：高风险任务因为成本焦虑被限制，低风险自动化任务却在后台持续消耗。前者压低能力上限，后者抬高运行成本，最终都会让团队误判工具价值。

Fable 5 接入分层

更稳的接入方式，是把调用边界写进流程。上下文检索、API 扫描、测试执行、候选补丁整理，交给低成本模型。静默数据丢失排查、关键重构风险评估、发版前风险扫描，才动用 Fable 5。单任务预算触顶后先停，再由人工判断是否继续。

预算闸门用于保证强模型出现在失败代价最高的地方。没有这道闸门，“再试一次”很容易变成默认动作，账单负责最后提醒。

团队接入的三条前置规则

规则一：为任务预先分配模型等级。 低风险任务锁定低成本模型；数据丢失、安全漏洞、breaking change 相关任务，才解锁高能力模型。分配规则写进 CI 配置或团队 checklist，不靠运行时临时判断。

规则二：升级强模型前先留下证据。 低成本模型已经无法收敛、复现链路已经出现、失败代价已经高于调用成本，三项至少满足两项，才进入强模型主线。

规则三：预算触顶立即中断。 单任务 API 预算达到上限后停止自动重试，由人工记录任务目的、已消耗金额、中断原因，再决定是否继续。

Fable 5 的能力上限已经足够清楚：它能进入真实发版流程，抓住静默数据丢失，并把修复链路推进到可发布状态。成本上限同样清楚：默认使用会迅速抬高运行成本。强模型值得用，但应留给那些失败后最昂贵的任务。