--- source: wechat source_url: https://mp.weixin.qq.com/s/-G3_u09LHwoOn5NkAoZ6-Q ingested: 2026-07-04 feed_name: AI寒武纪 source_published: 2026-07-04 19:32 sha256: 512f5a906f1d733e414514d97cec6c361cd9df81f3b8274e53d9a1898d01f6a3 --- # Anthropic内部人员撰写！Fable 5使用硬核指南：搞定未知盲区，AI 编程效率直接起飞 ↑阅读之前记得关注+星标⭐️，😄，每天才能第一时间接收到更新   如何更好的使用Fable 5？claude code 团队内部成员Thariq的这篇文章《A Field Guide to Fable: Finding Your Unknowns》可能会给你一些启发，一句话来说，要驾驭好Fable 5，发现未知领域是一个重要技能。非常值得一读。 在使用Claude Fable 5的这段时间里,claude code 团队成员Thariq反复得到同一个教训:地图不等于疆域。 地图,是你交给Claude的东西,包括你的prompt、技能设定和上下文,代表你对要做的事情的描述。疆域,则是工作真正发生的地方:代码库、现实世界,以及它们本身的各种限制。 地图和疆域之间的落差,就是Thariq所说的未知数。当Claude在工作中碰到一个未知数,它就得根据自己对你意图的猜测做出决定。要做的工作越多,Claude可能碰到的未知数也就越多。 Thariq认为,Fable是第一个让他明显感觉到,工作质量的瓶颈在于自己能不能把未知数讲清楚的模型。 需要说明的是,提前把计划做足并不总是够用。有些未知数只有深入到实现阶段才会暴露出来,甚至这些未知数会告诉你,应该换一种完全不同的思路去解决问题。 Thariq把和Fable一起工作的过程,描述成一个在实施之前、之中、之后不断发现自己未知数的迭代过程。 ### 认识你的未知数 面对一个问题,Thariq习惯把自己的认知拆成四类: **已知的已知** :告诉agent我想要什么,基本就是写在prompt里的内容。 **已知的未知** :自己还没想清楚,但清楚地知道自己没想清楚的部分。 **未知的已知** :自己见到才会认出来、但从来不会主动写下来的标准和要求。 **未知的未知** :完全没有考虑过的东西,包括不知道自己不知道的知识,以及不知道一件事到底能做到多好。 Thariq观察到,最擅长做agentic coding的人,未知数往往最少。像Boris和Jarred这样的人,明显对自己想要什么了如指掌,他们和代码库、和模型行为都高度同步。 但他们同样也在假设未知数的存在。在很大程度上,减少并规划自己的未知数,正是agentic coding这件事本身的核心技能。好消息是,这项技能可以通过和Claude一起工作来提升。 ### 让Claude帮你发现未知数 指挥Claude是个精细活。指令太具体,Claude会严格照做,哪怕换个方向明显更合适。指令太模糊,Claude又常常按行业最佳实践去猜,而这些猜测未必适合你的具体任务。 如果你没有把自己的未知数考虑进去,两头都会出问题:你不知道前面的路什么时候布满障碍,也不知道什么时候一路畅通,但你仍然希望Claude能在恰当的时候转向。 Claude能帮你更快地发现未知数。它能极快地搜索你的代码库和互联网,对大多数话题的了解也比你多得多,失败后迭代的速度也更快。 这个过程里最重要的一步,是把你的起点告诉Claude,比如: * • 告诉它你现在的思考进展到了哪一步 * • 说明你对这个问题和这个代码库的熟悉程度 * • 让它像一个思考伙伴一样,和你一起工作 Thariq提到,自己之前写过关于用HTML和Claude协作的内容,在几乎所有场景里,HTML artifact都是可视化和呈现这些内容的最佳方式。 接下来他详细介绍了自己用来挖掘这些未知数的几种方法,不是每次都会全部用上,但作为一套工具集非常实用。 ## 实施之前 ### 盲区扫描 刚开始做一件事的时候,搞清楚自己的盲区往往是最有用的一步。比如你要在代码库一个陌生的部分写新功能,或者让Claude帮你做设计迭代这类不熟悉的工作,你大概率会有很多未知的未知。 你可能不知道该问什么问题,不知道什么算好,不知道之前做过哪些相关工作,也不知道该避开哪些坑。 这种情况下,Thariq会直接让Claude帮他找出未知的未知,并解释清楚。他习惯直接用盲区扫描和未知的未知这两个说法,同时告诉Claude自己是谁、了解多少,这一点通常很关键。 比如可以这样问Claude:我在给一个新的auth provider做接入,但对这个代码库里的auth模块完全不了解,能不能做一次盲区扫描,帮我理清楚相关的未知的未知,让我之后能问得更准。 再比如:我不懂调色是什么,但需要给这段视频调色,能不能教我理解调色里我不知道的部分,让我能问得更好。 ### 头脑风暴与原型 在一个未知的已知特别多的领域里,也就是那些你只有看到才知道对不对的标准,Thariq会让Claude和自己一起头脑风暴、做原型。 在原型阶段尽早把这些未知的已知说清楚非常有价值,因为等到实施阶段才发现,代价会高得多。一个功能或规格上的小改动,可能导致代码实现天差地别,agent想要撤回之前的改动也会更困难。 比如你可能只想看看给一个框加个按钮长什么样子,并不需要真的去接后端路由,也不需要在前端维护额外的状态。 视觉设计对Thariq来说是很难用语言描述的东西,但他看到了就知道自己想不想要。这种情况下,他会让Claude给出几种不同的设计方向。 Thariq几乎每次写代码前都会先做一轮探索或头脑风暴,这能帮他一开始就明确项目范围。Claude经常能找到他自己都会漏掉的高价值方案,但有时候也会只见树木不见森林。头脑风暴能防止他把范围定得过窄或过宽。 示例问法包括:我想给这份数据做个仪表盘,但我完全没有审美判断,也不知道能做成什么样,给我做一个HTML页面,展示4种风格完全不同的设计方向,我来挑。 或者:先别急着接后端,做一个单独的HTML文件,把新的编辑器工具栏用假数据模拟出来,我想先看看布局,再让你动真正的应用代码。 又或者:我遇到的问题是,用户在完成新手引导后就流失了。去代码库里搜一搜,给我头脑风暴10个可以介入的地方,从成本最低到最有野心排序,我来告诉你哪些方向有戏。 ### 提问式访谈 做完足够的头脑风暴之后,Thariq可能还是会剩下一些未知数。 这时他会让Claude反过来采访自己,针对任何模糊或不确定的地方提问。让Claude做这种访谈时,最好给它一些背景信息,帮它把问题问到点子上。 示例问法:一次只问我一个问题,针对任何有歧义的地方,优先问那些答案会改变整体架构的问题。 ### 参考物 有时候你没办法把想要的东西讲清楚,可能是因为你缺少合适的表达方式,也可能是因为这件事太复杂,讲清楚要花很久时间。 这种情况下,最好的办法是给一个参考物。虽然图表、文档、图片都可以作为参考,但最好的参考物是源代码。 如果有一个库用某种方式实现了你想要的东西,或者有一个你很喜欢的设计组件,直接把Fable指向那个文件夹,告诉它要找什么就行,哪怕那是用另一种语言写的。 Claude Design的工作方式也是这样。你不需要一定上传文件,也可以直接把它指向你喜欢的某个网站模块,它读的是底层代码,而不只是截图,这样能拿到关于标记、结构以及这个组件具体是怎么搭出来的更丰富的信息。 示例问法:vendor/rate-limiter这个Rust crate实现的退避行为正是我想要的,读一下它,然后在我们的TypeScript API客户端里实现相同的语义。 ### 写实施计划 当Thariq觉得可以开始实施了,他会让Claude先做一份实施计划给自己审阅,并且重点放在最可能发生变化的部分,比如数据模型、类型接口、用户体验流程这些。这样Claude就能把他真正可能需要调整的地方摆出来。 示例问法:用HTML写一份实施计划,但把我最可能想改的决策放在最前面,比如数据模型的变化、新的类型接口,以及任何面向用户的部分。把那些机械式的重构放在最底下,这部分我信得过你。 ## 实施过程中 ### 实施笔记 计划确定之后,Thariq会开一个新会话,把之前的artifact都传进去,比如一份规格文件加一个原型,然后让agent去实现。 但事实是,不管前期规划做得多充分,实施过程里总会藏着一些未知的未知。agent可能在工作中发现,代码里有个边界情况迫使它必须换一种做法。 Thariq会让Claude Code维护一份临时的implementation-notes.md(或者html版本)文件,记录它做出的各种决定,方便之后复盘。 示例问法:维护一份implementation-notes.md文件。如果遇到某个边界情况,必须偏离原计划,就选保守的那个方案,在Deviations这一节里记下来,然后继续往下做。 ## 实施完成之后 ### 说明文档与汇报材料 要把一件事情顺利上线,拿到别人的认可和批准是很重要的一环。在最终文档里加上说明性的artifact有两个好处: * • 能让评审者从和你一样的起点理解这件事,加快理解速度 * • 能让专家看到你已经把他们会预料到的未知数和常见失败点都考虑进去了,加快审批速度 示例问法:把原型、规格文档和实施笔记打包成一份文档,方便我直接丢进Slack去争取大家的认可,把演示动图放在最前面。 ### 测验 一段长时间的工作会话结束后,Claude完成的东西可能比Thariq意识到的要多得多。光看代码diff只能给他一个模糊的了解,因为很多行为其实取决于既有的代码路径。 给足够的背景信息之后,让Claude来考考自己,能帮他真正搞懂发生了什么。他只有完全答对测验才会合并代码。 示例问法:我想确认自己完全理解这次改动的所有内容。给我一份关于这次改动的HTML报告,包含背景、直觉判断、具体做了什么,最后再加一个关于这次改动的测验,我必须答对。 ### 案例:Fable发布视频是怎么做出来的 Fable的发布视频完全由Claude Code剪辑完成。这对Thariq来说是个全新的领域,他不是这方面的专家。 所以他从自己已经知道的东西入手。他知道Claude能用代码剪辑视频、做转录,但不确定精度够不够,于是让Claude给自己讲清楚像Whisper这样的转录技术是怎么工作的,以及能不能用ffmpeg准确地把嗯啊之类的语气词和大段停顿剪掉。 他希望做出一个能和自己说话节奏对上的界面,但不确定Claude能不能做到,于是让Claude先用Remotion和一段转录文本做一个原型视频,验证是否可行。 最后,视频本身看起来有点发闷,他知道这是调色的问题,但并不真的了解调色是什么。他第一次尝试是让Claude做几个不同版本供自己挑选,但很快意识到自己根本不知道好的调色是什么样子。于是他改成让Claude教自己认识调色,来发现这方面的未知数。 ### 让地图匹配疆域 模型能力越强,用对方法能做到的事情就越多。当一个长周期任务的结果不对劲,往往说明你需要花更多时间把自己的未知数讲清楚,或者做一份能让Claude在遇到未知数时自行应变的实施计划。 每一次说明、头脑风暴、访谈、原型和参考物,都是在事情变得代价高昂之前,提前发现自己不知道什么的低成本方式。 所以,下一个项目开始前,不妨先让Claude帮你把未知数找出来。 参考： https://x.com/trq212/status/2073100352921215386   \--end-- 最后记得⭐️我，每天都在更新：如果觉得文章还不错的话可以点赞转发推荐评论 /...@作者：你说的完全正确（YAR师）