--- title: '廉价 Fable 5 本周结束，这些地方才真正重要' video_id: B1sYKOWVHR0 url: https://youtu.be/B1sYKOWVHR0 title_en: "Cheap Fable 5 Ends This Week. Here's Where It Actually Matters." channel: Ray Amjad published: 2026-07-05 duration: "15:48" topics: [Agent 工程, Claude Code 定制扩展, 模型与能力] noted: 2026-07-06 value: A views: '4191' --- [![封面](https://i.ytimg.com/vi/B1sYKOWVHR0/maxresdefault.jpg)](https://youtu.be/B1sYKOWVHR0) > Ray Amjad · 15:48 · 发布 2026-07-05 · 4191次观看(截至抓取) · [观看原视频](https://youtu.be/B1sYKOWVHR0) ## 主旨 Fable 5 订阅制即将结束、回归 API 计价，视频给出一套判断"该把它花在哪"的实操框架，而不是无脑清空 backlog。 ## 核心论点 1. **Fable 5 真正的优势不是"更聪明"而是"想得更远"**——它能看到四五六阶效应，做出普通模型给不出的架构判断，这也是判断该把它用在哪的依据。([[#1-多想几步fable-5-的差异化到底在哪-0146|→ 详解1]]) 2. **别把订阅期当成"清空 backlog 的窗口"**——直接甩一堆任务进去指望跑完就是赚到，回到 Opus 4.8 后什么持久收益都留不下。([[#2-别把订阅期当清空-backlog-的窗口该喂给它能留下架构改动的活-0246|→ 详解2]]) 3. **该给 Fable 5 的任务是"能留下架构改动"的活**——用 impact×opportunity（落地为 churn×complexity 打分）找出代码库里真正的高杠杆热点。([[#3-impactopportunity先打分再决定喂给-fable-5-哪些文件-0432|→ 详解3]]) 4. **模型更擅长"重新生成"而非"编辑存量"**——与其修补旧 skill、旧实现，不如让 Fable 5 从头重建，再交给便宜模型验证是否够用。([[#4-技能与黄金参照重建优于修补-0713|→ 详解4]]) 5. **回到 API 计价后，把 Fable 5 降级为"编排者"而非"打工者"**——让它自主判断该委派给哪个子模型执行，只专门复核不可逆决策，长期该砸钱打磨的是 harness 而不是模型本身。([[#5-苦涩教训与过期标签唤醒后最值得跑的两条-prompt-1049|→ 详解5]]) ## 知识点详解 ### 1. 多想几步：Fable 5 的差异化到底在哪 [01:46](https://youtu.be/B1sYKOWVHR0?t=106) 作者观察到，Opus 4.8 通常能推演五六步之后的影响，但仍会漏掉一些细节，所以才需要独立的verification 或 code review 环节兜底。Fable 5 的进步在于能想到第四、第五、甚至第六阶效应，这让它的架构判断更接近真实系统设计师（虽然还没到那个水平），也就是能"看到更多拐角"。 这份差异化的实际意义是：常规任务 Opus 4.8 已经够用，Fable 5 该被留给那些确实需要多步推演才能做对的架构性决策，而不是随手扔给它日常琐事。 ### 2. 别把订阅期当清空 backlog 的窗口：该喂给它"能留下架构改动"的活 [02:46](https://youtu.be/B1sYKOWVHR0?t=166) 作者观察到很多人把 backlog 一股脑喂给 Fable 5，指望"跑完就是赚到"，订阅到期回 Opus 4.8 后却打回原形——因为这类 prompt 只解决了眼前的 issue，没在代码库里留下任何持久价值。更好的做法不是"帮我修完这堆 issue"，而是"看完 backlog 后，想想哪些架构性改动能让以后更弱的模型也顺手修掉这些问题"，这样即使换回 Opus 4.8，输出质量也会因为代码库架构变好而提升。 作者把长期用 agent 编码的代码库比作"地质层"：不同时期的模型（Opus 4.1、4.5、4.6，甚至短暂试用过的 GLM 5.2）各自留下自己的编码风格层，新 agent 探索代码库时又容易照抄到最烂的旧层。小项目可以直接推倒重来，大代码库则该先挑出"承重结构"（load-bearing parts），优先让 Fable 5 集中处理。 ### 3. Impact×Opportunity：先打分再决定喂给 Fable 5 哪些文件 [04:32](https://youtu.be/B1sYKOWVHR0?t=272) 判断"承重结构"的具体框架是 Impact×Opportunity 打分框架：impact（改动能带来多大价值）× opportunity（这处修复的可行性有多高），二者都高的"热点区域"才是真正该花 Fable 5 预算的地方。落地成可执行指标时，作者让模型按 1-5 分给每个文件的 git churn（改动频率）与 complexity（复杂度）打分并相乘 [05:24](https://youtu.be/B1sYKOWVHR0?t=324)，排出技术债前十名，再让模型针对 GitHub backlog 里的 issue 提出对应的架构性修复建议。 这本质上是把"该重构哪里"从直觉判断变成可复算指标，给 Fable 5 的多步判断力一份明确的输入清单，而不是让它漫无目的地通读整个代码库。 ### 4. 技能与"黄金参照"：重建优于修补 [07:13](https://youtu.be/B1sYKOWVHR0?t=433) 多数模型生成新代码的能力强于编辑既有代码，所以作者的做法是：先在 `/usage` 里找出用得最多的 Claude Skills，回溯到当初创建它的原始 prompt 和种子数据，在一个全新、看不到旧 skill 的目录里让 Fable 5 重新生成一遍，再跟旧版做对比择优——这样即使 Fable 5 下线，留下的仍是一份更好的 skill。若这份 skill 以后要配合 Opus 4.8 使用，还可以让 Fable 5 派一个 Opus 4.8 Subagent 做几次试跑、根据输出反过来微调 skill。 同一逻辑也用在 Golden Reference（黄金参照）上 [09:18](https://youtu.be/B1sYKOWVHR0?t=558)：像 hosted MCP server 接口、websocket 并发处理这类反复踩坑、网上又没有好范式的实现，作者会让 Fable 5 在独立目录里生成一份权威的 canonical 示例存起来，以后便宜模型只需要照抄这份参照稍作修改套用，不必每次都重新摸索。 ### 5. 苦涩教训与"过期标签"：唤醒后最值得跑的两条 prompt [10:49](https://youtu.be/B1sYKOWVHR0?t=649) 其中一条是让 Fable 5 深入研读 Richard Sutton 的《苦涩的教训》（Bitter Lesson）论文，套用到审视自己的 AI coding harness 上，系统列出所有"过度工程"违背该教训的地方，产出一份让 harness 更适配未来更强模型的改造方案。作者的建议是先用 Opus 4.8 跑一遍看是否已经够用，再用 Fable 5 复核是否真的更好，避免为了用大模型而用大模型。 另一条实际跑出来的洞察是给 CLAUDE.md 和所有 skill 里的每处 workaround 加一个 Expiration Tag（到期重审标签）[11:57](https://youtu.be/B1sYKOWVHR0?t=717)，防止临时绕过的补丁被悄悄当成永久规则、日后无人再问是否还需要。作者说 Opus 4.8 跑同一条 prompt 时没能给出这个想法，打算把它固化进自己所有的 skill 模板。 ### 6. 回到 API 计价后：编排者角色、单向门复核、任务专属 harness [12:57](https://youtu.be/B1sYKOWVHR0?t=777) 作者转述 Simon Willison 博客里、来自 Claude Code 产品团队（Cat Wu、Thariq Shihipar）的建议：让 Fable 5（乃至一定程度上的 Opus）自主判断该调用哪个更便宜的模型去执行具体编码任务，而不是人工每次指定模型；再逐步把这套判断固化进 CLAUDE.md 里一张"什么任务配什么子模型"的对照表，长期只需按表运行 Subagent，直到下一代模型发布再调整。 除了当编排者委派任务，Fable 5 还该专门盯 One-Way Door——也就是公开 API 这类一旦宣布就很难撤回的不可逆决策 [13:44](https://youtu.be/B1sYKOWVHR0?t=824)；相比之下 UI 文案、feature flag 这类"双向门"可逆改动不值得为它专门花钱审。 最后，很多任务其实不需要顶级模型，靠一个针对该任务量身定制的 Dynamic Workflow（本质是 [[Harness]] 的一种，比如 builder-reviewer 来回迭代、独立 verifier、按维度排序找安全漏洞）就能让 Kimi K2.7、GLM 5.2 这类更便宜的模型跑出接近甚至超过大模型的效果 [14:14](https://youtu.be/B1sYKOWVHR0?t=854)——这印证了"更好的 harness 能打败更大模型"在 bug 排查和安全审查上尤其成立。 ## 可执行步骤 - [ ] 把"帮我清完这堆 issue"型 prompt 改写成"考虑架构性改动，让以后更弱的模型也能顺手修掉这些问题"。 - [ ] 让模型按 1-5 分给代码库文件的 git churn 与 complexity 打分并相乘，取排名靠前的文件作为重构优先级清单。 - [ ] 在 Claude Code 设置里把 transcript 保留期从默认 30 天调大，避免日后找不到某个 skill 最初的创建 prompt。 - [ ] 挑一个自己用最多的 skill，回到创建它的原始 prompt，在全新目录（看不到现有 skill）里重新生成一版做对比。 - [ ] 给 CLAUDE.md 与各 skill 里每处 workaround 补一个"到期重审"标签。 - [ ] 在 CLAUDE.md 里维护一张"任务类型 → 该配哪个子模型"的对照表，替代每次手动指定模型。 - [ ] 上线前先判断决策是否可逆，只对不可逆（单向门）决策申请顶级模型复核。 ## 关联 - 印证：[[Harness]](首见《Harness为王的能动工程大师课》)——本视频补上具体证据："更好的 harness 能打败更大模型"，尤其在 bug 排查与安全审查场景。 - 印证：Blast Radius(首见《给编码agent一张代码库地图codebase-memory-MCP》)——同一概念在此被用作 PR 合并的实操判据（"blast radius 小就直接合并"）。 - 印证：Orchestrator(编排器) / Subagent(首见 Agentic 工作流课)——本视频给出 Fable 5 委派子模型执行的真实案例，呼应 DOE 框架里"编排层负责路由决策"的定义。 ## 一手来源与延伸 - Simon Willison《Agentic Engineering Patterns》（simonw.substack.com）——转述了 Claude Code 产品团队 Cat Wu、Thariq Shihipar 的建议原话："for all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent"，与视频引用一致。 ## 术语 - Impact×Opportunity：影响力×可行性打分框架，用于筛选值得重构的代码热点 - Golden Reference：为反复出现、缺乏好范式的实现固化出的一份权威示例代码 - 地质层隐喻（Geological Layers）：长期用多代 agent 编码的代码库里，不同模型时期留下的风格层层叠叠 - One-Way Door / Two-Way Door：不可逆 / 可逆决策，前者才值得高成本复核 - Bitter Lesson：Richard Sutton 提出的"通用方法+算力最终会胜过手工先验知识"的论断 - Churn×Complexity：git 改动频率×代码复杂度的打分指标 ## 金句 > "Many code bases... are kind of like geological layers." → 老代码库是层层叠叠的模型考古现场，新 agent 很容易照抄最烂的那一层。 > "A better harness can beat a bigger model on some set of tasks." → 比起砸钱订阅顶级模型，把任务专属的 harness 打磨好往往更划算。 ## 立场与利益 视频中多次提及作者自己的产品与课程：他在推广自家 customer support agent stack（application agent stack）、开源项目 Hyper Whisper（求 star），以及正在做 4th of July 促销的 agent coding school（30% off，声称退款率极低）。这些信息判断价值有限，已在本笔记中剥离；框架性内容（impact×opportunity、one-way door、动态工作流）本身独立于这些推销可单独成立。 ## 价值定位 面向已经在高强度使用 agentic coding 的进阶开发者，教的是"订阅制顶级模型该如何分配任务"的实操心法。认知增量在于给出几个可复用的判断框架（impact×opportunity、one-way door、动态 harness vs 大模型），但具体的架构修复建议被作者刻意隐去，照搬前需要在自己的代码库里重新验证。 ## 自检问题 1. Fable 5 相比 Opus 4.8 的核心差异化能力是什么？为什么这意味着不该拿它做常规任务？ 2. 为什么"直接把 backlog 喂给 Fable 5"是一种低价值用法？更好的 prompt 该怎么改写？ 3. Impact×Opportunity 框架具体怎么落地成可执行指标？ 4. 回到 API 计价后，作者建议把 Fable 5 的角色从"打工者"换成什么？具体怎么操作？ 5. One-way door 和 two-way door 的区别是什么？为什么只有前者才值得花钱用顶级模型复核？