Claude Fable 5 实战指南:8 个「找未知」提示模式,从盲点扫描到读后小测验

Claude Code 团队 Thariq Shihipar 大会演讲实录:新模型的瓶颈不再是模型本身,而是你能不能讲清自己的未知
作者:AI Engineer 大会 / Anthropic07-07 · 11 分钟⚑ 方法教程
深度 · 小互解读
速览
  • Anthropic Claude Code 团队成员 Thariq Shihipar 在 AI Engineer World's Fair 大会发表演讲《A Field Guide to Fable》,同日配套官方博客发布,据报道三天内阅读量约两百万。
  • 核心方法论:把「你知道什么」拆成四象限,已知的已知、已知的未知、未知的已知、未知的未知,减少并预先规划这些「未知」是用好新一代模型的核心技能。
  • 演讲给出 8 个可直接照抄的提示模式,按动手前、动手中、动手后组织,每个都配了现成的中英文示例 prompt。
  • 一手反直觉披露:Claude Code 系统提示词最近被删掉 80%,对新模型来说示例反而会束缚它,方向从「给约束」转向「给上下文」。
  • Thariq 用这套方法从零剪出了 Fable 的发布视频,而视频剪辑对他是完全陌生的领域。
⚑立场提示:这是 Anthropic(Claude Code 团队)自家在 AI Engineer 大会的演讲,加同名官方博客,讲的是怎么用好自家的 Claude Fable 5,属厂商内容。演讲里几乎没有 Fable 的跑分、架构或硬指标,主体是方法论和内部提示词工程的一手观察。
1这在讲什么

这场演讲到底在讲什么

Anthropic Claude Code 团队成员 Thariq Shihipar,在 AI Engineer World's Fair 大会做了主题演讲,同步发布同名官方博客《A field guide to Claude Fable 5: Finding your unknowns》。

这场演讲讲的是一件很具体的事:Fable 这一代模型能干到什么程度,卡点已经从模型本身转移到你身上,转移到你能不能把「自己不知道什么」讲清楚。演讲里几乎没有 Fable 的硬指标或架构,通篇是「怎么和更强的模型协作」。
📌
为什么值得看:Claude Code 系统提示词最近被删掉 80%,方向从「给约束」转向「给上下文」,这是 Anthropic 内部提示词工程的一手变化;同时它把「怎么用好更强的模型」总结成 8 个能直接复制粘贴的提示模式,每个都带现成示例。

演讲里反复出现一个词:解放模型(unhobbling)。意思是真正约束模型的,往往是你自己套在它身上的框架、和写提示词的老习惯,这些框架本质上是「你对模型理解程度」的映射。改掉它们,就能把它本来就有的能力放出来。

打个比方

给一匹本来就能跑的马,卸掉那些不必要的缰绳和眼罩。

约 200 万
配套官方博客发布三天内的阅读量(据报道)
80%
Claude Code 系统提示词最近被删减的比例,方向从「给约束」转向「给上下文」
8 个
演讲总结的、可直接复制使用的提示模式数量
完整演讲 · 中英双语字幕(约 19 分钟,点封面加载) · 原视频 YouTube 英文 ↗
2背景 · 提示词做减法

模型是「尖刺式」变聪明的,提示词反而要做减法

要理解为什么这代模型「少喂示例、多给上下文」,先看两个背景。这一节是铺垫,重点在后面。

第一个背景是能力悬垂(capability overhang):模型不是齐头并进变强,而是在某些具体任务上突然跳出一大截。网上有条火帖问「为什么大模型说不出哪些宝可梦名字以 AW 结尾」,普通聊天模型答不上来,虽然它显然知道所有宝可梦的名字。但 Claude Code 能答,因为它会把每个宝可梦抓下来、写个脚本筛出以 AW 结尾的。同一份「知识」,给不给它代码执行工具,结果天差地别。

打个比方

像地下埋着深浅不一的矿脉,工具就是决定你能挖到哪条矿脉的镐子。用好新模型的一半功夫,就是搞清现在到底有哪些新的可能。

第二个背景更反直觉:系统提示词正在越变越小。Thariq 把提示词工程的最佳实践分成三段,看得出趋势。

Sonnet 3.5 New 时代
小提示词 · 少工具
主要靠堆大量示例,教它照着做。
模型变强之后
大提示词 · 多工具
能塞更多信息和指令,它开始能照单执行,示例照旧堆。
Fable 这一代
系统提示词删掉 80%
示例反而束缚它,它比你给的示例更有想象力。给上下文,别给约束,尽量不写「不要做这个」。

工具也在跟着模型能力一起进化。以 ask-user-question 工具(让模型在规划时反过来弹多选问题问你)为例:Opus 4 时它勉强能调用;Opus 4.5 时你能让它「问我 40 个关于需求的问题」,它开始能采访你;到 Opus 4.8 和 Fable,它能直接生成一整份把问题嵌在里面的 HTML 报告。理解模型这件事,更像生物学,很经验、很有机,需要你去建立直觉。

3核心框架

核心框架:把你的未知分成四格

你脑子里的计划、提示词、spec,是「地图」;真实的代码库、现实约束,是「疆域」。每当 Claude 在疆域里撞上地图上没标的东西,它就得靠猜你到底想要什么,做一个决定,这个点就叫一个「未知(unknown)」。它要干的活越多,撞上的未知越多。

核心框架

Thariq 的原话:Fable 是第一个让他觉得,产出质量的瓶颈在于他能不能把它的未知讲清楚的模型。而且光提前规划还不够,未知可能藏在实现深处才冒出来,所以用 Fable 是一个在动手前、动手中、动手后不断发现未知的迭代过程。

面对一个问题,把「你知道什么」拆成四格。

纵轴:你有没有意识到这块 · 横轴:你实际懂不懂
KNOWN KNOWN
已知的已知
你写进 prompt 里、明确告诉它你要的东西。
KNOWN UNKNOWN
已知的未知
你还没搞清,但你知道自己没搞清的东西。
UNKNOWN KNOWN
未知的已知
太显然,你根本不会写下来,但一看到就认得出(know it when I see it)。
UNKNOWN UNKNOWN
未知的未知
你压根没想到的东西,不知道自己缺哪块知识,也不知道一件事到底能做到多好。

顶尖的 agentic coder(他点名了 Boris、Jarred)有个共同点:他们的未知很少,看他们写 prompt,能感到对代码库和模型行为都门儿清;同时他们会预设未知一定存在。所以减少并预先规划你的未知,就是 agentic coding 这门手艺的核心技能,而这门技能可以靠「和 Claude 一起练」来提升。

为什么处理未知是关键?因为给 Claude 下指令是个微妙的平衡,太具体和太模糊都会输。

指令太具体
它会死死照你说的做,哪怕此刻换个方向其实更合适。
指令太模糊
它按行业最佳实践自己脑补假设,未必贴合你的任务。

不为未知做准备,你两头都会输:不知道哪段路上有坑(该细的地方没细),也不知道哪段路其实通、可以放手让它自己走(该放的地方没放)。好在 Claude 能帮你更快找未知,它搜代码库和全网都极快,从失败里迭代也比你快。最关键的一步,是把你的「起点」给它:告诉它你在思考哪个阶段、对这个问题和代码库有多少经验,让它当你的思考伙伴。

下面是 8 个可落地的模式,按动手前、动手中、动手后三段组织。每张方法卡右上角有个小四象限图标,高亮那一格,就是这个方法主打对付的未知类型。每个示例 prompt 都给全:中文是译文(给你看懂),英文是原文(给你直接复制照抄)。

4动手前 · 方法 ①②

开工前两招:盲点扫描 + 头脑风暴与原型

开工前最该先解决两类未知:你压根没想到的(未知的未知),和你说不清、但一看就认得的(未知的已知)。

①

盲点扫描(Blind Spot Pass)本篇重点

对付「未知的未知」。当你要在代码库里一个陌生的地方写功能、或用 Claude 做你不熟的活(比如调设计),你多半有一堆盲区:不知道该问什么、不知道「好」长什么样、不知道有哪些坑要绕。Thariq 说他会字面地用 "blind spot pass" 和 "unknown unknowns" 这两个词,并且一定给它「你是谁、你已经懂什么」的上下文。
给陌生的认证模块加功能前,先让它扫出你的盲区
「我要给这个代码库加一个新的 auth(认证)provider,但我对这里的认证模块一无所知。你能不能做一次盲点扫描(blind spot pass),帮我找出我相关的『未知的未知』、并教我怎么把提示写得更好。」
"I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt you better."
做完全不懂的活(调色)前,让它教你认清盲区
「我不懂什么叫调色(color grading),但我需要给这段视频调色。你能不能教我理解我在调色上的『未知的未知』,好让我能把提示写得更好?」
"I don't know what color grading is but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading, so that I can prompt better?"
②

头脑风暴与原型(Brainstorms & Prototypes)

对付「未知的已知」。当你在一个「标准只有看到才说得出(know it when you see it)」的领域,让 Claude 陪你头脑风暴、做原型。为什么要趁早:等到实现阶段才发现,代价很贵,spec 上一个小改动可能让代码实现天差地别,回滚也更难。视觉设计是典型,难以用语言描述,但一看就知道要不要。
没视觉品味时,让它出四个截然不同的方向给你挑
「我想给这份数据做个仪表盘,但我没什么视觉品味、也不知道能做成什么样。给我做一个 HTML 页面,放四种截然不同的设计方向,让我来挑、来反应。」
"I want a dashboard for this data but I have no visual taste and don't know what's possible. Make me an HTML page with 4 wildly different design directions so I can react to them."
动真代码前,用假数据先 mock 一个布局给你反应
「先别接任何东西。用一个单独的 HTML 文件、拿假数据把新的编辑器工具栏做个 mock 出来。我想在你动真正的 app 之前,先对着布局反应一下。」
"Before wiring anything up, make a single HTML file mocking the new editor toolbar with fake data. I want to react to the layout before you touch the real app."
给个粗糙问题,让它搜代码库头脑风暴 10 个切入点
「这是我一个粗糙的问题:用户在 onboarding 之后就流失。搜一下代码库,头脑风暴出 10 个我们可以介入的地方,从最便宜到最有野心排。我来告诉你哪些戳中了我。」
"Here's my rough problem: users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell you which ones resonate."
5动手前 · 方法 ③④⑤

开工前还有三招:让它采访你、给它参考、要一份实现计划

头脑风暴做够了,多半还剩一些未知。剩下三招,把模糊逼出来、给它一张更好的地图、让计划把「最可能改的决策」排在最前面。

③

让模型采访你(Interviews)

让 Claude 反过来采访你,把问题里的模糊和没考虑到的地方逼出来。采访时给它你的问题背景来引导提问。
让它反过来采访你,把有歧义的地方逼出来
「一次问我一个问题,围绕任何有歧义的地方采访我;优先问那些『我的回答会改变架构』的问题。」
"Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture."
④

参考物(References)

有时你没法把想要的东西描述清楚,要么缺词,要么复杂到讲清要花很久。最好的办法是给一个参考。图、文档、截图都行,但最好的参考是源代码,哪怕它是另一种语言写的。相比截图,源代码给了它关于标记和结构远为丰富的细节。
把它指到一段参考源代码,哪怕是另一种语言写的
「vendor/rate-limiter 里这个 Rust crate 实现了我想要的那种退避(backoff)行为。读懂它,然后在我们的 TypeScript API 客户端里把同样的语义重新实现一遍。」
"This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client."
⑤

实现计划(Implementation Plans)

觉得可以动手了,先让 Claude 出一份实现计划给你审。关键是让它把「你其实可能要改」的东西主动浮出来,机械性的重构放最后。
传统实现计划
从机械细节、文件结构一路往下写,你最该拍板的决策淹在中间。
这套方法
开头先放你最可能要改的:数据模型改动、新类型接口、面向用户的东西;机械性重构埋在最底下。
让它出实现计划,把你最可能改的决策放最前
「用 HTML 写一份实现计划,但开头先放我最可能要调整的决策:数据模型改动、新的类型接口、以及任何面向用户的东西。把机械性的重构埋在最底下,那部分我信你。」
"Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part."
6动手中与动手后 · 方法 ⑥⑦⑧

动手中和动手后:实现笔记、推介文档、让它反过来考你

计划满意后,开一个新 session,把 spec、原型这些 artifacts 传进去,给它一个干净的上下文窗口,但带着规划阶段的全部信息。接下来三招,管的是干活途中和交付之后。

⑥

实现笔记(Implementation Notes)

对付实现深处才冒出来的「未知的未知」。无论规划多充分,agent 干着干着可能因为代码里某个边界情况需要换打法。让它维护一个临时的 implementation-notes.md,把决定记下来,方便下次学习。
让它边干边把被迫偏离计划的决定记进一个文件
「维护一个 implementation-notes.md 文件。如果你撞上一个边界情况、被迫偏离计划,就选保守的那个选项,把它记在『Deviations』(偏差)标题下,然后继续干。」
"Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going."
⑦

推介与讲解(Pitches & Explainers)

交付一个东西,很重要的一环是拿到认同和审批。用 Claude 把原型、spec、实现笔记打包成一份「推介、讲解」文档:当审阅者和你一开始有同样的未知时,加速他们理解;当专家想看到「你考虑到了他们会预料的失败点」时,加速审批。
把原型、spec、实现笔记打包成一份能拿去要认同的文档
「把原型、spec 和实现笔记打包成一份我能丢进 Slack 拿认同的文档。开头先放演示 GIF。」
"Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF."
⑧

让它考你(Quizzes)

一段长会话之后,Claude 干的活可能比你意识到的多得多。只看代码 diff 只能给你浅层理解,因为很多行为依赖既有的代码路径。让它在给你一堆上下文之后反过来考你。Thariq 说他只在自己完美通过测验之后才会 merge。
让它给你出一份关于这次改动的测验,你必须全过
「我想确保我完全理解这次改动里发生的一切。给我一份关于这些改动的 HTML 报告,带上上下文、直觉、做了什么等等,让我读懂;并在最底下出一套关于这些改动的测验,我必须全过。」
"I want to make sure I understand everything that's happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass."
7完整案例

活教材:他自己怎么把这套方法用了一遍

Fable 的发布视频,是 Thariq 用 Claude Code 从头到尾剪出来的,而视频剪辑对他是个全新领域,他并非专家。他的做法正好把上面的方法串成一条链。

已知的已知知道 Claude 能用代码剪视频、能转录,但不确定精度够不够。
→
主动发现未知让它讲清 Whisper 这类转录怎么工作,能不能用 ffmpeg 精确切掉 um 和长停顿。
→
原型验证不确定想要逐字同步字幕的 UI,就让它用 Remotion 加转录做个原型视频先验证。
→
先学再做视频发灰是调色问题,但他不知道「好的调色」长什么样,于是先让 Claude 教他、把未知找出来,再动手。
每一个讲解、头脑风暴、采访、原型、参考,都是在「变贵之前」便宜地搞清你原先不知道的东西。Thariq Shihipar,A Field Guide to Fable
8落地

落地清单:从下一个项目开始怎么用

把 8 个模式按开工时机汇总成一张清单,照着对号入座就行。

动手前
  • ① 盲点扫描钻进陌生模块、做不熟的活时
  • ② 头脑风暴与原型标准靠「看到才认得」时
  • ③ 让它采访你头脑风暴后还剩模糊时
  • ④ 参考物想要的东西说不清时
  • ⑤ 实现计划准备动手前,让它先列给你审
动手中
  • ⑥ 实现笔记干着干着被迫偏离计划时
动手后
  • ⑦ 推介与讲解要拿认同、审批时
  • ⑧ 让它考你合并前,逼自己真看懂改动
心态收尾 · 处理失落

Thariq 说第一次用 Fable 这类模型,收获感和失落感一起来。他热爱手写代码、热爱在脑子里翻转整个代码库的感觉,但唯一的出路是穿过去,保持在环内、把模型放开,就能走到另一头,带更多东西回来。

心态收尾 · 做个不讲道理的人

他最喜欢 Anthropic 的一点,是相信「取舍」并不真实存在。逼现实把取舍摊出来:好、快、便宜过去是三选二,现在三个全要。最后一个提醒是,构建变容易了,创造价值依然很难,别把心思全花在搭建过程和你的配置上。

从下一个项目开始,先让 Claude 帮你找未知。
来源:Thariq Shihipar 于 AI Engineer World's Fair 大会主题演讲《A Field Guide to Fable》,及配套官方博客《A field guide to Claude Fable 5: Finding your unknowns》(claude.com/blog)。本文为方法拆解,所有示例 prompt 按原文完整保留:中文为译文(便于理解),英文为可直接复制照抄的原文。文中数据(80%、约 200 万阅读量等)为演讲与博客口径。
来源
AI Engineer 大会 / AnthropicAI Engineer 大会 / Anthropic·查看主材料
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。