YT 学习笔记

廉价 Fable 5 本周结束，这些地方才真正重要

15分钟阅读下载 MD

封面

Ray Amjad · 15:48 · 发布 2026-07-05 · 4191次观看(截至抓取) · 观看原视频

主旨

Fable 5 订阅制即将结束、回归 API 计价，视频给出一套判断”该把它花在哪”的实操框架，而不是无脑清空 backlog。

核心论点

  1. Fable 5 真正的优势不是”更聪明”而是”想得更远”——它能看到四五六阶效应，做出普通模型给不出的架构判断，这也是判断该把它用在哪的依据。(→ 详解1)
  2. 别把订阅期当成”清空 backlog 的窗口”——直接甩一堆任务进去指望跑完就是赚到，回到 Opus 4.8 后什么持久收益都留不下。(→ 详解2)
  3. 该给 Fable 5 的任务是”能留下架构改动”的活——用 impact×opportunity（落地为 churn×complexity 打分）找出代码库里真正的高杠杆热点。(→ 详解3)
  4. 模型更擅长”重新生成”而非”编辑存量”——与其修补旧 skill、旧实现，不如让 Fable 5 从头重建，再交给便宜模型验证是否够用。(→ 详解4)
  5. 回到 API 计价后，把 Fable 5 降级为”编排者”而非”打工者”——让它自主判断该委派给哪个子模型执行，只专门复核不可逆决策，长期该砸钱打磨的是 harness 而不是模型本身。(→ 详解5)

知识点详解

1. 多想几步：Fable 5 的差异化到底在哪 01:46

作者观察到，Opus 4.8 通常能推演五六步之后的影响，但仍会漏掉一些细节，所以才需要独立的verification 或 code review 环节兜底。Fable 5 的进步在于能想到第四、第五、甚至第六阶效应，这让它的架构判断更接近真实系统设计师（虽然还没到那个水平），也就是能”看到更多拐角”。

这份差异化的实际意义是：常规任务 Opus 4.8 已经够用，Fable 5 该被留给那些确实需要多步推演才能做对的架构性决策，而不是随手扔给它日常琐事。

2. 别把订阅期当清空 backlog 的窗口：该喂给它”能留下架构改动”的活 02:46

作者观察到很多人把 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

判断”承重结构”的具体框架是 Impact×Opportunity 打分框架：impact（改动能带来多大价值）× opportunity（这处修复的可行性有多高），二者都高的”热点区域”才是真正该花 Fable 5 预算的地方。落地成可执行指标时，作者让模型按 1-5 分给每个文件的 git churn（改动频率）与 complexity（复杂度）打分并相乘 05:24，排出技术债前十名，再让模型针对 GitHub backlog 里的 issue 提出对应的架构性修复建议。

这本质上是把”该重构哪里”从直觉判断变成可复算指标，给 Fable 5 的多步判断力一份明确的输入清单，而不是让它漫无目的地通读整个代码库。

4. 技能与”黄金参照”：重建优于修补 07:13

多数模型生成新代码的能力强于编辑既有代码，所以作者的做法是：先在 /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：像 hosted MCP server 接口、websocket 并发处理这类反复踩坑、网上又没有好范式的实现，作者会让 Fable 5 在独立目录里生成一份权威的 canonical 示例存起来，以后便宜模型只需要照抄这份参照稍作修改套用，不必每次都重新摸索。

5. 苦涩教训与”过期标签”：唤醒后最值得跑的两条 prompt 10:49

其中一条是让 Fable 5 深入研读 Richard Sutton 的《苦涩的教训》（Bitter Lesson）论文，套用到审视自己的 AI coding harness 上，系统列出所有”过度工程”违背该教训的地方，产出一份让 harness 更适配未来更强模型的改造方案。作者的建议是先用 Opus 4.8 跑一遍看是否已经够用，再用 Fable 5 复核是否真的更好，避免为了用大模型而用大模型。

另一条实际跑出来的洞察是给 CLAUDE.md 和所有 skill 里的每处 workaround 加一个 Expiration Tag（到期重审标签）11:57，防止临时绕过的补丁被悄悄当成永久规则、日后无人再问是否还需要。作者说 Opus 4.8 跑同一条 prompt 时没能给出这个想法，打算把它固化进自己所有的 skill 模板。

6. 回到 API 计价后：编排者角色、单向门复核、任务专属 harness 12:57

作者转述 Simon Willison 博客里、来自 Claude Code 产品团队（Cat Wu、Thariq Shihipar）的建议：让 Fable 5（乃至一定程度上的 Opus）自主判断该调用哪个更便宜的模型去执行具体编码任务，而不是人工每次指定模型；再逐步把这套判断固化进 CLAUDE.md 里一张”什么任务配什么子模型”的对照表，长期只需按表运行 Subagent，直到下一代模型发布再调整。

除了当编排者委派任务，Fable 5 还该专门盯 One-Way Door——也就是公开 API 这类一旦宣布就很难撤回的不可逆决策 13:44；相比之下 UI 文案、feature flag 这类”双向门”可逆改动不值得为它专门花钱审。

最后，很多任务其实不需要顶级模型，靠一个针对该任务量身定制的 Dynamic Workflow（本质是 Harness 的一种，比如 builder-reviewer 来回迭代、独立 verifier、按维度排序找安全漏洞）就能让 Kimi K2.7、GLM 5.2 这类更便宜的模型跑出接近甚至超过大模型的效果 14:14——这印证了”更好的 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 能打败更大模型”，尤其在 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 的区别是什么？为什么只有前者才值得花钱用顶级模型复核？

关系图谱

反向链接