当模型不再是瓶颈:Thariq 的 Fable 5 心法(中文译注版)

2026 年 7 月 4 日,Claude Code 团队核心工程师 Thariq 发了一条推,两天内阅读量冲到 50 万。被反复转发的只有一句话:用 Fable 5 这种级别的模型,卡住你的已经不是模型,是你那些「你不知道自己不知道」的事。

这篇是那条推的中文译注版。原文核心结构(四类未知 + 三段式 SOP)是完全普适的,我在英文人名(Boris、Jarred)之外,补了一些对中文开发者更直接的语境。译注部分我会用 [注:...] 标出来。

原文(英文):Thariq on X · 中文首发由 新智元 于 2026-07-04 转载报道。

地图不是领土

你写的 prompt、你配的 skill、你喂的上下文 —— 这些是「地图」,是你塞给 Claude 的那份说明书。真正干活的地方 —— 代码库、真实世界、那些绕不开的约束 —— 才是「领土」。

地图和领土之间的差距,Thariq 把它叫做「未知」(the unknown)。

Claude 每撞上一个未知,就只能猜 —— 按它对「你想要什么」的最佳猜测往下走。任务越长、动的环节越多,撞上的未知就越多,猜偏的概率也越大。

模型弱的时候,瓶颈在模型这边,你拼命把 prompt 写清楚就行。Fable 5 不一样。Thariq 自己的原话是:这是第一个让他觉得,工作质量被「我澄清未知的能力」卡住的模型。模型强到一定程度,瓶颈就悄悄换了位置 —— 从「模型能不能做到」变成「你能不能说清楚你到底要什么」。

而「说清楚」本身就是走钢丝。你说得太具体,Claude 会死守你的话,哪怕当下明明该转向,它也一条道走到黑;你说得太模糊,它又会按「行业最佳实践」自己猜,猜出来的未必对你的路子。不提前把未知想清楚,两头翻车 —— 路上有坑你不知道,路明明是通的你也看不见,还在那儿瞎指挥。

四类未知

Thariq 把「未知」拆成四类。说人话就是:

• 已知已知 (known knowns) —— 写进 prompt 里的,你明确知道自己要什么。
• 已知未知 (known unknowns) —— 你还没想明白,但你知道你还没想明白。
• 未知已知 (unknown knowns) —— 显而易见到你懒得写下来,但一看到就知道对不对 —— 审美、判断、那种「看一眼就懂」的东西。
• 未知未知 (unknown unknowns) —— 你压根没想过,甚至不知道自己不知道 —— 不知道该问什么问题,不知道什么叫好,不知道前人踩过哪些坑。

最坑的就是最后一类。[注:在 agentic coding 语境下,Anthropic 的 Boris Cherny 和 Jarred Capehart 是公认的顶尖工程师。Thariq 拿他们举例,意思是他们的 prompt 不是靠「聪明」,而是「清楚」—— 你看他们的 prompt,「我要什么」明明白白,而且他们对代码库和模型两边都熟到能写出贴两边的 prompt。]

但他们也照样给未知留预案。从某种意义上说,减少未知、为未知做预案,就是 agentic coding 这门手艺本身。

好消息:这不是天赋,是能练的。最好的陪练恰恰是 Claude 自己 —— 它翻你代码库比你快,搜整个互联网比你快,从失败里爬起来也比你快。你要做的只是把起点交代清楚 —— 你想到哪一步了、对这个问题和这套代码有多少经验 —— 然后让它像个思考伙伴,陪你把未知一个个挖出来。

三段式 SOP

Thariq 给了一整套流程,分实施前、中、后三段。每一步在写代码之前做都很便宜,写完才发现代价就上去了。下面是中文整理,稍作编辑以适应中文表达。

实施前 · 五招

1. 盲区扫描 —— 进陌生代码库,或者干不熟的活,直接对 Claude 说:「帮我做一次 blindspot pass,找出我的 unknown unknowns,讲给我听。」 让它把你的盲区挖出来,顺便教你下一轮 prompt 怎么写更好。
2. 头脑风暴 + 原型 —— 视觉设计这种「看到才知道要什么」的事,别急着接后端。让 Claude 用一个 HTML 页面甩你四个截然不同的方向,你挑。[注:这里的关键洞见是,「未知已知」这种东西在原型期发现成本几乎为零,拖到实施期才发现 —— 规格上一个小改动,代码可能天翻地覆,回滚都费劲。]
3. 采访 —— 让 Claude 一次一个问题地反问你。优先挑那些「答案会改变架构」的先问。
4. 给参考 —— 说不清就别硬说。最好的参考是源代码。你喜欢某个库的实现、某个网站上的组件,把 Claude 指向那个文件夹或模块 —— 即便是另一种语言,它读的是底层代码,不是截图,拿到的细节比你嘴上描述的丰富十倍。
5. 实施计划 —— 动手前让 Claude 写份计划给你审。把最可能变卦的放最前面:数据模型、类型接口、用户看得见的流程;机械性重构压到最底下 —— 那部分信它。

实施中 · 一招

让 Claude 维护一个 implementation-notes.md。计划再周全也有意外,撞上 edge case 偏离了计划,就选保守方案,在 ## Deviations 下记一笔,接着干。下次复盘全靠它 —— 你(或队友)三个月后回来看代码,这笔记是最快回到原始思路的入口。

实施后 · 两招

1. 打包推介 —— 把原型、规格、笔记攒成一份能直接丢群里拿批准的文档。评审的人和你当初有一样的未知,这份文档替他们省一遍。
2. 做测验 —— 让 Claude 就这次改动出一套题考你,全对才许合并。读 diff 只能懂个皮毛,大量行为藏在既有代码路径里,考一遍才知道自己是不是真懂了。

他自己的身体力行:Fable 发布视频

最说服人的例子是 Thariq 自己 —— Fable 的发布视频(三分钟成品)全程用 Claude Code 剪的,而他不是剪辑出身。

他从「已知」起步。知道 Claude 能用代码剪视频、能转录,但不确定精度够不够,就先让它讲讲 Whisper 类转录是怎么工作的、能不能用 ffmpeg 精准剪掉「呃」和长停顿。

想要字幕跟着他说的每个词同步蹦出来,他不确定能不能实现,就让 Claude 先拿 Remotion + 转录文本做个原型试试。

成片看着发闷,他是调色的锅。第一反应是让 Claude 出几版让他挑 —— 挑着挑着才发现,自己根本不知道「调色好」长什么样。于是掉头,让 Claude 先教他什么是调色。

先搞清楚自己的未知,再谈选择。

模型越强,「问得准」越值钱

模型越来越强。用对方法能达成的上限跟着往上抬;而人的价值,正在从「写得多快」悄悄挪到「问得多准」。

[注:Claude Code 团队自己也说过,他们最近的工作方式已经从「验证 Claude 干得对不对」变成「验证它干的是不是对的事」。Thariq 这篇讲的,正是同一枚硬币的另一面 —— 当模型足够强,你能不能把职责交代明白、能不能提前把未知想清楚,直接决定了它替你干出来的活是惊艳还是返工。]

每一轮讲解、每一轮头脑风暴、每一次采访、每一个原型、每一份参考,都是在代价变高之前廉价地找出你原本不知道的东西。

说到底,长任务返回一个错误结果,往往不是模型不行,是你还没把未知想清楚。