YT 学习笔记

Plan F3:为 Mythos 级模型重写 /Plan 元技能

27分钟阅读下载 MD

封面

IndyDevDan · 1:02:49 · 发布 2026-06-22 · 1.7万次观看(截至抓取) · 观看原视频

主旨

IndyDevDan 在 Fable 5 / Mythos 级模型上线节点上,把自家 /Plan 元技能从零重写成 Plan F3(PLANS For Fable 5):HTML-first 富媒体输出 + GPT Image 2 每阶段配图 + append-only metadata 的 living artifact + 嵌入式 checklist 验证闭锁,目标是让 plan 在 codebase 寿命内持续演化,只在前置一次性投入大量 token,换来 Mythos 级模型时代的稳定结果与「plan more, review less」落地。

核心论点

  1. Fable 5/Mythos 级模型解锁规划深度,「外包思考」是工程师群体性贬值的主因——把 /Plan 默认甩给 agent 等同假设模型知道你要什么,工程技能不是被替代而是被放弃;重写 plan skill 是这一波模型升级前必须做的前置工程。(→ 详解1)
  2. 取舍三角「性能 > 速度 ≥ 成本」是规划阶段该用的预算观——Fable 5 的甜区不在便宜或快,而是能在一次性大 spec 上给出高保真结果;堆 HTML token 与图像 token 才是匹配 Mythos 级模型的正确投资。(→ 详解2)
  3. HTML-first + 每 phase 一张 GPT Image 2 图,把 spec 从纯文本升级到多模态——给 agent 更可用 token、给团队一份「打开即读」的视觉文档、给后续多模态 spec 留好前置,这是「plan 值得花 token」的具体落点。(→ 详解2)
  4. Plan 是 codebase 里的 living artifact,metadata 必须 append-only——modified、commits、agent name、session id、back/forward references 只能 append 不能覆盖,留下完整执行史;后续 spec 引用前一 spec 一次就能重建因果链。(→ 详解3)
  5. 嵌入式 checklist + 验证闭锁把「plan more, review less」压成可执行模板——每个 task 用 4 状态(空/WIP/done/F),box 没勾+验证命令没跑通就 block 下一 phase,plan 不是文档而是约束。(→ 详解4)
  6. 9/10 次严格模板 + 1/10 次「run free」注释优于完全放手——详尽 plan format 给 agent 训练上下文,notes 段把细节自由权还回去;完全自由看着诱人,但与「domain knowledge 才是差异化」相悖。(→ 详解5)

知识点详解

1. 重写 /Plan 的核心理由:Fable 5 解锁规划深度 00:16

作者开场就把整段视频绑定到一个断言上——「great planning is great engineering」。这不是修辞,而是 Mythos 级模型时代的工程判断:Fable 5 解锁的不是代码生成速度,而是能否消化一份长而精确的 spec 直接出站。

具体批评是「mass deprecation of raw engineering talent」00:40:大多数工程师把 /Plan 默认甩给 Claude Code / Codex,模型不知道你想要什么,只能靠语言模型的先验补偿——结果就是把工程技能外包给模型自己。对应解药是「don’t outsource your thinking」00:51:在 Mythos 级模型上写一份够大的 spec,模型能直接执行;不写,模型就替你猜。这与 Agentic Engineering 在「harness 占 90%」的主张同向,只是把 90% 进一步压到「planning skill」这一个具体载体上。

投入量级在视频里被反复强调:planning skill 是「one of the most important tools you and your agents have」00:22,重写它应当视为 Mythos 级模型上线的同等优先级——不是「等模型升级再说」,而是「模型升级前必须做完」。这条判断也回应了 vibe coder 与 plan-thinker 的分水岭:同样的 Fable 5,vibe coder 拿到的是「更好用的 vibe 工具」,plan-thinker 拿到的是「一次到位的高保真 spec 执行器」,模型只是放大了原有工作流。

2. 取舍三角与 HTML-first + GPT Image 2 多模态输出 05:22

第二个论点把整套设计绑到一组预算观上。作者给出 trade-off trifecta——performance / speed / cost 三者最多同时满足两项05:22,并明确把新模板的优先级写成「performance greater than speed greater than equal to cost」05:56。这不是反对速度与成本,而是承认 Mythos 级模型的甜区在「值得花 token 的任务」上,简单前后端小改不必动用 Plan F3。

落地形态是 HTML-first 输出 + GPT Image 2 每阶段配图。HTML 相对 markdown 给 agent 更可用 token,作者在视频里引用 Anthropic 公开工程文章的判断「the more valuable tokens you give your agents, it gives them a slight edge on producing the result you’re looking for」;同时 HTML 对团队与工程师本身也更易打开阅读。图像的作用是「an image is worth a thousand words」11:53——每 phase 一张聚焦图把抽象任务变可见。

GPT Image 2 在视频里被反复强调为「best image generation model on the market」19:27。Plan F3 的图像 prompt 控制规则是「prompt 控制在 10 个词以内、避免文字密度过高」31:55,每张图只承载 1-2 个核心概念,以「professional software engineers convey exactly what is going to be built」为目标。这种「宽图像、低文字密度、宽屏 + 高质量」的取舍是与多模态 spec 的未来形态对齐——下一波 spec 会是图像/音频/视频统一,Plan F3 把图像作为第一波落地。

整套组合的成本是明牌的:HTML 把单份 spec 的 token 量级显著抬高,图像再加 8-10 张图的工作量;但配合 Skill Creator 体系,Plan F3 把 image generation 拆成独立 workflow,与 create / update / build 并列,单 skill 撑全套。「花钱在前置规划」的态度也是「scale our compute to scale our impact」11:25 的具体表达——投入换产出,在 Mythos 级模型上第一次变得划算。

3. Plan 作为活体 artifact:append-only metadata + 前后引用 12:30

第三个机制把 plan 从「写一次就过期」的文档升级为 codebase 里的活体 artifact。关键约束是 metadata 必须 append-only——modified、commits、agent name、session id、back references、forward references 都用 comma-sep list 持续追加,只保留 created ISO 这一项作为定值40:53。

这条规则的工程意义是:每次 plan 被 update / build / image-gen,都会留下「哪个 agent 在哪个 session 里改了什么」的完整因果链,后续 audit 不需要查 git log 之外的任何外部系统。back references 把这份 plan 用了哪些前置 spec、AI docs、app docs 记下来;forward references 把这份 plan 会被未来哪些 spec / AI docs 引用记下来。

配合 update references workflow,后续 spec 创建时 agent 自动回写引用,把整个 codebase 的 spec 关系网逐步织起来——plan 不再是「写完就丢」的 markdown 文件,而是「代码库里持续演化的工程资产」。视频里把 plan 比作 living artifact21:44的核心意思是:agent 可以读它、可以更新它、可以基于它建分支,plan 自己不老化。

这一组合与 forward-goal 的目标驱动模式互补:forward-goal 关注单次任务怎么跑完,活体 artifact 关注多次任务之间怎么互相引用、互相支撑;前者是运行时机制,后者是知识沉淀机制。在 Mythos 级模型能稳定产出的前提下,把 plan 沉淀为可审计的工程资产,是 harness 的进一步进化方向。

4. 嵌入式 checklist + 4 状态机 + 验证闭锁 11:29

第四个机制把 plan 从文档升级为约束。视频给每个 phase 配 step-by-step tasks + 嵌入式 checklist11:29,任务状态用 4 个值表达43:27:「empty, work in progress」对应 WIP、「done」对应 X、「failed」对应 F。

这套状态机的设计目标不是给 agent 看,而是给 build workflow 看的——build workflow 必须按 phase 顺序执行、每 phase 跑完所有 task 才能进入下一 phase、每个 task 必须勾选并跑过对应的 validation command 才能标 done。闭锁规则被写得很直白:「Plan is not complete until every box is checked and every command passes」46:30。

如果某 task 真的阻塞,允许标 F 并继续——这给真失败模式留了出口,而不是死锁。闭锁的实现细节在 build workflow 里:agent 读 plan → 读所有 back refs 深度 1 → 读所有图像 → 按 phase top-to-bottom 执行 → 每 task 调对应 validation 命令 → 通过才标 done → 全部 done 才进下一 phase → 末 phase 跑完做最终 validation 并 update metadata。整套机制把 review 成本前移到 plan 内,而不是事后由人手动审查每个产物。

这套机制与 Ralph Loop 有结构相似性:Ralph Loop 也是「清单 → 验证 → 推进」,但 Plan F3 的差异是它把清单与验证嵌进 plan 本身,而不是外部循环驱动——plan 即约束,build workflow 只是约束的执行者。这让 spec 在不同 agent、不同 model 间复用时不会丢约束,这是 plan-as-template 的另一层价值。

5. 9/10 次严格模板 + 1/10 次「run free」注释 45:32

第五个机制回应一个常见反驳:「你这样把 agent 框死,会不会比放手让模型自由发挥更差?」作者承认这是合理疑问,并给出明确答案——「9 out of 10 times spelling out the exact plan format you want and then creating a section like this for the agent to run free」45:43更高产。

具体做法是在 plan 里给一个 notes 段,允许 agent 在严格模板之外自由补充任何它认为重要的内容——parity matrix、风险提示、参考文档、实验计划都可以塞进去。视频的 demo 里,agent 在 notes 段自动生成了一份 feature parity matrix,比较现有 HTTP-based agent-to-agent 通信与新 Iroh gossip 实现的差异;它还把图像嵌进 notes 让整体可视化更强。

这部分内容如果放在模板里就要靠 agent 一开始就准确预判,代价高;放在 notes 段则是「执行时再补」,自然且便宜。这与「domain knowledge is what differentiates you」62:24的核心断言呼应——工程师的领域知识沉淀为模板的 90%,剩下 10% 留给 agent 在运行时基于上下文补足,既不浪费模板的强引导,也不剥夺 agent 的灵活性。

这套机制的工程化基础是「templating your engineering」08:24——工程师把自己的工程方式沉淀为模板,教 agent 如何按你的方式工作。模板里有 90% 的可复用骨架,notes 是 10% 的灵活空间;两者不是矛盾,是「domain knowledge 才是差异化」的具体表达。这一立场也与 Vibe Coder 的反面呼应——vibe coder 是把 100% 都甩给模型,这一立场是把 90% 沉淀成可复用模板 + 10% 留给运行时上下文。

6. 真实任务 demo:用 Iroh gossip 重写 agent-to-agent 通信 48:18

第六段是真实 demo。IndyDevDan 启动自家 pi coding agent,用 Plan F3 写一份 spec 任务——把 Pi to Pi 系统(原本基于 HTTP + 中央 hub)重写成基于 Iroh gossip swarm 的对等网络。Iroh 的特性被作者简述为「Tailscale, but for application」48:50,即应用层直接嵌入对等网络,无需中心服务器。

demo 跑在 Opus 4.8 而非 Fable 5——作者直言 Opus 已能拿到 Fable 80-90% 等价产出50:15,Mythos 级模型只是把天花板再往上推一档。spec 在约 6 分钟内输出完整 HTML16:07,形态包括 hero image、metadata header、purpose/problem/solution、existing files/new files、phase-by-phase 分块(每 phase 一张配图)、嵌入式 checklist、validation commands、parity matrix 附录、amend section。

这个 demo 的价值不只是「Plan F3 能跑通」,而是「Mythos 级模型能用、Opus 4.8 也能 80-90%」的可验证基线。对应 Fable5 被禁 那篇里的「80% 工程师 Opus 够用」论点,本片把它压实到 spec 长度门槛——能写 100-500 行级别 HTML+图+验证的长 spec,才到 Mythos 甜区;否则 Opus 即可,与本文「plan 模板升级 = 模型升级前置」的逻辑完全自洽。Plan F3 在 Opus 4.8 上能用,在 Mythos 级模型上还能进一步突破,这是「plan 是模型升级的最大杠杆」的可观察证据。

可执行步骤

  • 把当前 /Plan 模板的输出格式从 markdown 迁到 HTML,加上 hero image 与每 phase 配图,给 agent 与团队双读者都准备视觉入口。
  • 给 plan 顶部加 append-only metadata 字段(created ISO 唯一不可变;modified、commits、agent name、session id、back refs、forward refs 全部 comma-sep list 持续追加),并在 update references workflow 里自动回写。
  • 把 build / update / create / update-references / image-gen 拆为独立 workflow 收纳进同一 skill 文件,主入口根据 user prompt 派发到对应 workflow。
  • 给每 phase 的 step-by-step task 加上 4 状态(空/WIP/done/F)+ 对应 validation command;build workflow 用闭锁规则强制所有 box 勾选且命令通过才进下一 phase。
  • 在 plan 末尾留一段 notes 自由区,允许 build agent 自由补充 parity matrix、风险提示、参考文档等非模板化信息。
  • 用 Plan F3 跑一份 100-500 行级别的真实 spec(例如重写某个内部模块),对比 Opus 4.8 与 Mythos 级模型的输出差距,把「Plan F3 在我的 codebase 上值不值得」的可观察证据落到 git 上。

关联

  • 进阶:Fable5被禁 给出「80% 工程师 Opus 4.8 够用」「plan more, review less」的判断基线;先读它了解模型选型与 spec 长度门槛,再读本片看 Mythos 级模型上限的工程化形态——两篇构成「判断要不要升级 + 怎么用 Plan F3 兑现升级」的进阶对。
  • 互补:Pi to Pi 对等双向 是本片 demo 任务的「被替换基线」——同样是 agent-to-agent 通信,本片用 Plan F3 把它从 HTTP+中央 hub 重写成 Iroh gossip,先读 Pi to Pi 理解原架构,再看本片看 spec 是怎么在 Opus 4.8 上把替换路径全部走通的。
  • 印证:Harness 主张「加速上限的 90% 在 harness」——本片把 90% 进一步压到「planning skill」这一个具体载体上,等于把 harness 的最大杠杆点显式化、模块化、可重用化,与 Harness 概念同向但粒度更细。
  • 印证:00-总览 给出 Pi Coding Agent 的中央调度式 agent team 配置;本片 Plan F3 嵌在 Pi Coding Agent 上跑,印证「agent 框架是 spec 的执行壳层,planning skill 是壳层里的核心载体」的层级关系——读 Pi 课程理解壳层,读本片理解壳层里的核心 skill。

一手来源与延伸

  • /plan F3 GitHub 仓库:作者把整套 /Plan F3 skill 开源到该仓库,可直接 fork 改造;README 里列了 Plan F3 的 workflow 表与 image generation 调用入口。
  • Tactical Agentic Coding 课程页:作者自家课程,与本片底层方法论(tactical agentic coding)同源,适合想把 Plan F3 整套心法延伸到更大 harness 设计的人。
  • Pi to Pi Agent Communication:本片 demo 任务的「被替换基线」原视频,把两者串读可看 spec 是怎么把已有架构重写为对等 gossip 的。
  • Fable 5 公告:Mythos 级模型定位与能力的官方说明,本片「Mythos 解锁规划深度」论的背景来源。
  • Fable 5 / Mythos 访问说明:订阅下架与访问变化的官方说明,本片讲 Fable 时背景上下文出处。
  • Iroh 文档:demo 任务中替换 HTTP+中央 hub 的对等网络协议,「Tailscale, but for application」的具体技术细节出处。
  • GPT Image 2 发布:Plan F3 中「每 phase 一张聚焦图」所用的图像生成模型,Plan F3 选它而不是同类竞品的官方依据。

术语

  • PLANS For Fable 5(Plan F3):作者重写的 /Plan 元技能,三个 F = Fable 5 / forwards / focused,定位 Mythos 级模型时代的下一代规划模板。
  • Trade-off Trifecta:performance / speed / cost 三角取舍,agentic 工程选型基本约束,本片把新模板优先级明确为「performance > speed ≥ cost」。
  • HTML-first:规划输出用 HTML 而非 markdown,给 agent 更可用 token、给团队一份「打开即读」的视觉文档。
  • Living Artifact:在 codebase 寿命内持续演化的规划文档,append-only metadata + 前后引用,留下完整执行史。
  • Agent Trifecta:规划要满足工程师、工程团队、AI agent 三个读者,不只为模型服务。
  • Append-only Metadata:metadata 字段只能 append 不能覆盖,保留每次 plan 变更的因果链。
  • Per-phase Imagery:每 phase 一张聚焦图,把抽象任务视觉化,prompt 控制在 10 词以内避免文字密度过高。
  • Templating Your Engineering:把工程师自己的工程方式沉淀为模板,教 agent 按你的方式工作。
  • Run Free 注释:在 plan 末尾的 notes 段允许 agent 自由补充非模板化内容(parity matrix、风险、参考),作为「严格模板+运行时自由」的混合策略。

金句

“Engineers… the future is built by those who PLAN it, not those who vibe code it.” → 一句话把 Mythos 级模型时代的工程判断压到极致——vibe coder 在 Fable 5 上仍是 vibe coder,plan-thinker 才会把模型变成工具。15:23 “9 out of 10 times spelling out the exact plan format you want and then creating a section like this for the agent to run free and add all the details it wants is going to be more valuable.” → 把「严格模板 vs 自由发挥」的伪命题拆掉——不是二选一,是 9:1 的混合。45:43

立场与利益

视频 description 末尾附有作者课程链接 agenticengineer.com/tactical-agentic-coding?y=DzbqeO_diOQ,带 ?y=<video_id> 后缀——这是独立创作者常见的引流归因参数,用于把 YouTube 引流关联到具体视频。因此「Plan F3 是 Mythos 级模型时代的必备前置」「升级 spec 格式是当下最高 ROI 工程」「规划技能是 agent harness 里最值得花时间的工具」系列主张与作者自家课程的卖点天然耦合,观看时建议把这些课程相关论断与通用共识(例如 HTML 给 agent 更可用 token、append-only metadata 利于审计、checklist 闭锁降低 review 成本等)区分看待。同时,「Iroh 是 agent-to-agent 通信的对等替代」「HTML-first 比 markdown 更适合 Mythos 级模型 spec」「append-only metadata 是 plan 长期可审计的关键」等结论与作者商业利益无直接关联,反倒是相对独立的工程观察、可信度较高。

价值定位

适合已经在用 Claude Code / Pi Coding Agent / 类似工具写 spec、并准备升级到 Fable 5 / Mythos 级模型的实践者——视频不重复 Fable 5 的能力说明,而是把 Mythos 级模型时代的规划工程压成一份可复用模板(HTML-first、append-only metadata、嵌入式 checklist、统一 skill 多 workflow),并用真实 demo 验证「Opus 4.8 跑出 80-90% Fable 5 效果」的具体 spec 形态。认知增量明确:之前大多数工程师对 plan 的认知停留在 markdown 文本,看完本片会知道 Mythos 级模型时代 plan 是富媒体 + 活体 artifact + 可执行约束的三位一体。重叠内容方面,与本频道 Fable5被禁 在「升级判据 + 算账方式」上一致、与 Pi to Pi 在 demo 任务上互补,推荐三篇交叉读以形成完整的「该不该升级 + 怎么用 plan 兑现升级 + 真实 spec 长什么样」的视图。

自检问题

  1. 为什么在 Mythos 级模型时代重写 /Plan skill 是必须的前置工程,而非可推迟的优化? 答案:Fable 5 解锁的不是代码生成速度,而是「消化长而精确 spec 直接出站」的能力;若 spec 还是工程师甩给模型的一行指令,模型就只能靠先验补偿,等于「don’t outsource your thinking」。把 planning skill 重写为 Mythos 时代的富媒体模板,等于把模型升级的红利一次性兑现到 harness 上——不重写,模型升级等于浪费。见详解1。00:16 00:40
  2. Plan F3 为何采用 HTML-first + GPT Image 2 多模态输出,而不是延续 markdown? 答案:HTML 给 agent 更可用 token(Anthropic 公开工程文章已论证),HTML 对团队也更易打开阅读;每 phase 一张 GPT Image 2 图把抽象任务视觉化,prompt 控制在 10 词以内、保持专业聚焦。这套组合的成本(HTML token + 图像生成)在 performance > speed ≥ cost 的预算观下是值得的——Mythos 级模型的价值就在「堆 token 换 quality」。见详解2。05:22 05:56 11:53
  3. 为什么 plan 的 metadata 必须是 append-only 而非可覆盖? 答案:append-only 留下完整执行史——modified、commits、agent name、session id、back refs、forward refs 全部 comma-sep list 持续追加,只 created ISO 不可变;后续 audit 不依赖 git log 之外的任何外部系统,前后引用织起整个 codebase 的 spec 关系网。这是 plan 从「写一次就过期」升级为「活体 artifact」的核心机制。见详解3。12:30 40:53
  4. 嵌入式 checklist + 4 状态机的闭锁规则怎么把「plan more, review less」压实? 答案:每 task 用 4 状态(空/WIP/done/F)+ 对应 validation command,build workflow 强制所有 box 勾选且命令通过才进下一 phase;真失败可用 F 标记并继续(避免死锁)。这一机制把 plan 从文档升级为约束——plan 不再是描述,而是 build agent 必须遵循的执行手册,plan 本身自带 review 路径。见详解4。11:29 43:27 46:30
  5. Plan F3 demo 用 Opus 4.8 而非 Fable 5 跑出 Iroh gossip 任务的实际意义是什么? 答案:demo 验证 Mythos 级模型的「前置 spec 形态」能在 Opus 4.8 上拿到 80-90% 等价产出——意味着把 planning skill 重写到 Mythos 时代的形态后,即便暂时没 Fable 5 也能在 Opus 上拿到接近上限的产出;而真正拿到 Fable 5 时再跑同一份 spec,天花板会被进一步推高。这与「80% 工程师 Opus 够用」的判断同向,但把判断从「够不够用」升级到「plan 模板升级后在哪一档模型上都跑得动」。见详解6。50:15 16:07

关系图谱

反向链接