Claude Code工程师Thariq亲授Fable 5内行心法：模型强到这份上，卡住你的已经不是它，而是你没想清的那些「未知的未知」。
就在刚刚，Claude Code 团队核心工程师 Thariq 发了篇干货，核心就一句话——
用Fable 5这种级别的模型，卡住你的已经不是模型，是你自己。
浏览量很快冲上了几十万。
他说，和Fable 5朝夕相处这段时间，自己反复被同一个老道理教育：地图，不是领土。
什么意思？
你写的prompt、你调的技能、你喂的上下文，这些是「地图」——你塞给Claude的那份说明书；而真正干活的地方——代码库、真实世界、那些绕不开的约束，才是「领土」。
地图和领土之间的差距，他管它叫「未知」。
Claude每撞上一个未知，就只能猜——按它对「你想要什么」的最佳猜测做决定。
任务越长、干的活越多，撞上的未知就越多，猜错的机会自然也越多。
以前模型不够强，瓶颈在模型那边，你只管拼命把需求写清楚。
但Fable 5不一样。Thariq的原话是：这是第一个让他觉得，工作质量被「我澄清未知的能力」卡住的模型。
模型强到一定程度，瓶颈就悄悄换了位置——从「模型能不能做到」，变成「你能不能说清楚你到底要什么」。
而给指令这件事，本身就是走钢丝。
你说得太具体，Claude会死守你的话，哪怕当下明明该转向，它也一条道走到黑。
你说得太模糊，它又会按「行业最佳实践」自己猜，猜出来的未必对你的路子。
不把未知想在前面，你就两头翻车——路上有坑你不知道，路明明是通的你也不知道，还在那儿瞎指挥。
更扎心的是，光提前做计划还不够。
有的未知埋在实施深处，挖到一半才冒头；有的未知一露面，你才发现整个问题都该换个解法。
四类未知
最坑的是最后一类
那怎么把「未知」说清楚？
Thariq先把它拆成四类，说人话就是：
- 已知已知：写进prompt里的，你明确知道自己要什么；
- 已知未知：你还没想明白，但你知道自己没想明白；
- 未知已知：显而易见到你懒得写下来、但一看到就知道对不对的东西，比如审美；
- 未知未知：你压根没想过、甚至不知道自己不知道的东西。
最坑的就是最后一类。你不知道该问什么问题，不知道什么叫好，不知道前人踩过哪些坑。
而顶尖的agentic coder，比如Anthropic的Boris、Jarred，未知都很少——看他们写prompt就知道，要什么门儿清，对代码库和模型的脾气也门儿清。
但他们照样会给未知留预案。
某种意义上，减少未知、为未知做预案，就是agentic coding这门手艺本身。
好消息是，这不是天赋，是能练的。
而练这门手艺，最好的陪练恰恰是Claude自己：它翻你的代码库和整个互联网比你快得多，大多数话题它懂得比你多，从失败里爬起来也比你快。
你要做的，只是把起点交代清楚——你想到哪一步了、对这个问题和这套代码有多少经验，然后让它像个思考伙伴，陪你把未知一个个挖出来。
多数时候，一个能上手点、能改的HTML页面，就是把未知摆上台面的最好方式。
一套闭环SOP
于是Thariq给了一整套流程，分实施前、中、后三段。
实施前，五招。
第一，盲区扫描。进陌生代码库、干不熟的活，直接对Claude说：「帮我做一次blindspot pass，找出我的unknown unknowns，讲给我听。」让它把你的盲区挖出来，顺便教你怎么把prompt写得更好。
第二，头脑风暴加原型。视觉设计这种「看到才知道要什么」的东西，别急着接后端，先让Claude用一个HTML页面甩你四个截然不同的方向，你挑。
道理很简单：未知已知在原型期发现，成本几乎为零；拖到实施期才发现，规格上一个小改动，代码可能天翻地覆，回滚都费劲。
第三，采访。让Claude一次一个问题地反问你，专挑那些「答案会改变架构」的先问。
第四，给参考。说不清就别硬说，最好的参考是源代码。
你喜欢某个库的实现、某个网站上的组件，把Claude指向那个文件夹或模块就行，哪怕是另一种语言——它读的是底层代码，不是截图，拿到的细节比你嘴上描述的丰富十倍。
第五，实施计划。动手前让Claude写份计划给你审，把最可能变卦的放最前面——数据模型、类型接口、用户看得见的流程；机械性重构压到最底下，那部分信它。
实施中，一招：让Claude维护一个implementation-notes.md。
计划再周全也有意外，撞上edge case偏离了计划，就选保守方案，在「Deviations」下记一笔，接着干——下次复盘全靠它。
实施后，两招：一是打包推介，把原型、规格、笔记攒成一份能直接丢群里拿批准的文档——评审的人和你当初有一样的未知，这份文档替他们省了一遍。
二是做测验，让Claude就这次改动出一套题考你，全对才许合并——读diff只能懂个皮毛，大量行为藏在既有代码路径里，考一遍才知道自己是不是真懂了。
不懂剪辑，却用Claude剪出了Fable发布视频
最有说服力的是他自己的例子：Fable的发布视频，完全是Claude Code剪的，而他压根不是剪辑出身。
他就从已知开始。
知道Claude能用代码剪视频、能转录，但不确定精度够不够，就先让它讲讲Whisper这类转录是怎么工作的、能不能用ffmpeg把「呃」和长停顿精准剪掉。
想要字幕跟着他说的每个词同步蹦出来，不确定能不能实现，就让Claude先拿Remotion加转录文本做个原型试试。
成片看着发闷，他知道是调色的锅，第一反应是让Claude出几版让他挑——挑着挑着才发现，自己根本不知道「调色好」长什么样。
于是干脆掉头，让Claude先教他什么是调色。
先搞清楚自己的未知，再谈选择。
模型越强，「问得准」越值钱
这套方法背后，藏着一个更大的信号：模型越强，用对方法能达成的就越多，而人的价值，正在从「写得多快」，悄悄挪到「问得多准」。
前几天Claude Code团队的人还在说，他们的工作方式已经从「验证Claude干得对不对」，变成「验证它干的是不是对的事」。
Thariq这篇讲的，正是这枚硬币的另一面——当模型足够强，你能不能把职责交代明白、能不能提前把未知想清楚，直接决定了它替你干出来的活是惊艳还是返工。
每一次讲解、头脑风暴、采访、原型、参考，都是在代价变高之前，廉价地找出你原本不知道的东西。
说到底，长任务返回一个错误结果，往往不是模型不行，是你还没把未知想清楚。
参考资料：https://x.com/trq212/status/2073100352921215386
本文来自转载新智元 ，观点仅代表作者本人，发现AI平台仅提供信息存储空间服务。
如若转载，请联系原作者；如有侵权，请联系编辑删除。
微信扫一扫 
