Fable 5 从发布之日起,命运就像模型的名字一样玄幻。
从万众期待的「AI 封神时刻」,到美国政府一纸禁令强制下线,再到禁止非美国人访问,可以说是吸引了全球的目光。
到现在,风波逐渐归于平静。模型终归是要回归到生产力里去的。
为此,Claude Code 工程师 Thariq Shihipar 在社交媒体上发布了长博客,详细地说明了使用 Fable 5 的技巧。
这篇文章解决了一个大家长久以来的疑惑。明明现在的模型能力已经进化到如此强大的地步了,为什么我在使用模型的时候依旧感觉它做不对任务?
Thariq 的博客让人豁然开朗。简而言之:人和模型之间存在着信息差,也就是用户提供的提示词、Skill、上下文和实际任务执行之间的差异。
为此,整篇博客正是在教你如何打破这种信息差。下面,机器之心将附上博客全文,以飨读者。
博客标题:A Field Guide to Fable: Finding Your Unknowns
博客链接:https://x.com/trq212/status/2073100352921215386
与 Claude Fable 5 一起工作,不断让我重新意识到一个老道理:地图并不等于疆域。
所谓「地图」,是对待完成工作的表征,也就是我的提示词、技能和上下文,是我交给 Claude 的东西。所谓「疆域」,则是真正需要发生工作的地方:代码库、现实世界,以及其中真实存在的约束。
我把地图与疆域之间的差距称为「未知项」。当 Claude 遇到一个未知项时,它就必须根据自己对我意图的最佳猜测来做决定。工作越复杂,Claude 可能遇到的未知项就越多。
Fable 是第一个让我明显感觉到工作质量的瓶颈,取决于我澄清其未知项能力的模型。
重要的是,仅仅提前规划并不总是足够的。你可能会在实现深处发现未知项;也可能发现这些未知项指向一个事实:你其实应该用完全不同的方式来解决这个问题。
我发现,与 Fable 协作,本质上是一个在实现前、实现中和实现后不断发现未知项的迭代过程。
作者提供了一些发现「未知项」的示例,读者可以与全文共同查看。
示例链接:https://thariqs.github.io/html-effectiveness/unknowns/
了解你的未知项
什么是未知项?当我带着一个问题来找 Claude 时,通常会从四个角度拆解它:
已知的已知:这基本上就是我写在提示词里的内容。我告诉智能体,我想要什么?
已知的未知:有哪些事情我还没有弄清楚,但我知道自己还没有弄清楚?
未知的已知:有哪些东西对我来说显而易见,以至于我根本不会写下来,但一旦看到就能认出来?
未知的未知:有哪些事情是我完全没有考虑过的?有哪些知识是我还不知道自己不知道的?我是否知道一件事可以做到多好?
最优秀的智能体式程序员往往拥有相对更少的未知项。他们非常清楚自己想要什么,而且细节非常充分。他们与代码库和模型行为都保持着高度同步。
但他们也会预设未知项的存在。从很多意义上说,减少并提前规划你的未知项,就是智能体式编程的核心能力。幸运的是,这是一项可以通过与 Claude 协作不断提升的技能。
帮助 Claude 以帮助你自己
给 Claude 下指令是一种微妙的平衡。如果你过于具体,即使转向另一种方案可能更合适,Claude 也会严格照着你的指令执行。如果你过于模糊,Claude 往往会基于行业最佳实践做出选择和假设,而这些选择不一定适合你的任务。
当你没有充分考虑自己的未知项时,两种情况都会失败。你不知道前方道路何时会布满障碍,也不知道什么时候道路其实很顺畅,但你仍然希望 Claude 能在必要时做出调整。
Claude 可以帮助你更快发现未知项。它能够极快地搜索你的代码库和互联网,并且在大多数主题上掌握的通用知识比你更多。它也能更快地从失败中迭代。
这个过程中最重要的一点,是给 Claude 足够的起点上下文。例如,告诉它你目前思考到哪一步;说明你对这个问题和代码库的熟悉程度;让它像一个思考伙伴一样与你协作。
我之前写过关于如何用 Claude 生成 HTML 的内容。在几乎所有这些场景中,HTML 工件都是最适合用来可视化和表达想法的方式。
在这篇文章中,我会详细介绍一些自己用来发现这些未知项的模式。我并不是每次都会使用所有技巧,但把它们作为一组可调用的方法储备起来,会非常有用。
实现前
盲点扫描
开始工作时,最有用的事情之一,就是理解自己的盲点。例如,如果你正在代码库中一个新的模块里编写功能,或者让 Claude 帮你处理某种你不熟悉的工作,比如迭代一个设计方案,那么你很可能会有大量「未知的未知」。
你可能不知道该问什么问题,不知道什么才算好,不知道过去已经做过哪些历史工作,也不知道有哪些坑应该避免。
要做到这一点,你可以让 Claude 帮你找出「未知的未知」,并向你解释。我喜欢直接使用「blindspot pass」和「unknown unknowns」这些字眼。通常来说,告诉它你是谁、你知道什么,也很重要。
示例提示词:
「我正在添加一个新的身份认证提供方,但我对这个代码库里的认证模块一无所知。你能不能做一次 blindspot pass,帮我找出相关的 unknown unknowns,并帮助我更好地给你写提示词?」
「我不了解调色,但我需要给这个视频做调色。你能不能教我理解自己在调色方面的 unknown unknowns,这样我就能写出更好的提示词?」
头脑风暴与原型
当我在一个有很多「未知的已知」的领域工作时,也就是那些只有看到之后我才知道如何定义标准的事情,我会让 Claude 和我一起头脑风暴、做原型。
在原型阶段尽早识别并表达这些「未知的已知」非常有价值,因为如果到了实现阶段才发现它们,代价往往会相对更高。功能或规格中的一些小变化,可能会导致代码实现发生巨大差异,而且让智能体回退之前的修改也会更困难。
例如,你可能只是想看看在某个框架里加一个按钮是什么效果,而并不想真正接入后端路由,也不想在前端维护额外状态。
视觉设计对我来说就是一种很难清楚表达的东西,但我看到之后会知道自己想要什么。在这种情况下,我会要求 Claude 针对一个工件给出几种不同的设计方向。
我几乎也会在每次编码会话一开始,都先进行探索或头脑风暴。这能帮助我带着明确意图来定义项目范围。Claude 经常会发现一些我本来会错过的高价值方案,但它有时也会只见树木不见森林。头脑风暴可以防止我一开始就把范围设得过窄或过宽。
示例提示词:
「我想为这组数据做一个仪表盘,但我没有什么视觉品味,也不知道可以做到什么程度。帮我做一个 HTML 页面,给出 4 种风格差异很大的设计方向,好让我根据结果做反馈。」
「在真正接线之前,先用假数据做一个单独的 HTML 文件,模拟新的编辑器工具栏。我想先对布局做反馈,然后你再去动真实应用。」
「这是我的粗略问题:用户在完成 onboarding 后流失。搜索代码库,头脑风暴 10 个我们可以介入的地方,从最低成本到最有野心的方案都列出来。我会告诉你哪些方向更有感觉。」
反问
在完成了足够的头脑风暴之后,我通常仍然会有未知项。
这种情况下,我会让 Claude 围绕任何不明确或存在歧义的地方来采访我。让 Claude 采访你时,尽量提供关于问题的上下文,以便它提出更有针对性的问题。下面是一些例子。
示例提示词:
「请一次只问我一个问题,围绕任何存在歧义的地方采访我。优先提出那些我的回答会改变架构设计的问题。」
参考资料
有时候,你无法详细描述自己想要什么。比如,你可能没有对应的表达语言,或者这件事太复杂,要完整描述会花很长时间。
在这种情况下,最好的答案就是参考资料。你可以提供图表、文档或图片,但最好的参考资料其实是源代码。
如果你有一个库用某种特定方式实现了某个功能,或者有一个你非常喜欢的设计组件,那就直接把 Fable 指向对应文件夹,并告诉它该看什么。即使参考代码是另一种语言写的,也没有关系。
这也是 Claude Design 的工作方式。你不一定非要给它一个文件,当然你也可以这么做。你可以把它指向你喜欢的某个网站模块,它会读取底层代码,而不仅仅是截图。这样可以提供更丰富的细节,包括标记结构、组件组织方式,以及这个组件实际上是如何构建的。
示例提示词:
「vendor/rate-limiter 里的这个 Rust crate 实现的正是我想要的回退重试行为。请阅读它,并在我们的 TypeScript API 客户端中重新实现相同的语义。」
实现计划
当我觉得已经准备好开始实现时,我通常会让 Claude 先整理一份实现计划供我审阅,并重点关注那些最可能发生变化的部分,例如数据模型、类型接口或 UX 流程。这样可以让 Claude 提前暴露出一些我可能确实需要调整的地方。
示例提示词:
「用 HTML 写一份实现计划,但开头先呈现我最可能会修改的决策点:数据模型变更、新的类型接口,以及任何面向用户的内容。机械性的重构放在最下面,那部分我相信你可以处理。」
实现中
实现笔记
当我对计划满意后,会开启一个新的会话,并把相关工件传入提示词。例如,我可能会传入一份规格文件和一个原型,然后让智能体来实现它。
但事实是,无论你做了多少规划,总会有未知的未知潜伏着。智能体在工作过程中可能会发现,由于代码中的某个边界情况,它必须换一种思路。
我会要求 Claude Code 维护一个临时的 implementation-notes.md 文件,或者 .html 文件,用来记录它做出的决策,这样我们就能从下一次尝试中学习。
示例提示词:
「请维护一个 implementation-notes.md 文件。如果你遇到某个边界情况,导致你必须偏离原计划,请选择保守方案,在 ‘Deviations’ 下面记录原因,然后继续推进。」
实现后
推介与解释文档
发布某个东西时,最重要的事情之一,是获得他人的理解、支持和批准。在最终文档中构建推介和解释类工件,有助于:
当评审者一开始也带着和你相同的未知项时,加速他们理解。
当专家想确认你已经考虑到他们本来会预见的未知项和常见失败点时,加速审批。
示例提示词:
「把原型、规格说明和实现笔记打包成一个单独的文档,我可以直接发到 Slack 里争取支持。开头先放演示 GIF。」
测验
经过一次漫长的工作会话后,Claude 可能已经完成了比我意识到的更多工作。只看代码 diff 往往只能让我对发生了什么有一个浅层理解,因为很多行为都取决于既有代码路径。
让 Claude 在给我大量上下文之后,再围绕这次变更来测试我,可以帮助我真正理解发生了什么。我只有在完美通过测验之后,才会合并代码。
示例提示词:
「我想确保自己理解了这次变更里发生的一切。请给我一份 HTML 报告,帮助我阅读和理解这些变更,包括上下文、直觉解释、具体做了什么等等,并在底部附上一份我必须通过的测验。」
串联方法:以发布 Fable为例
Fable 的发布视频完全是由 Claude Code 剪辑完成的。这对我来说是一个全新的领域,而我绝不是这方面的专家。
所以我从自己已知的部分开始。我知道 Claude 可以用代码来编辑视频并进行转录,但我不确定它的准确度是否足够。于是我让 Claude 向我解释 Whisper 这类转录技术是如何工作的,以及我是否能够用 ffmpeg 准确剪掉「嗯」这样的语气词或较长的停顿。
我希望 Claude 创建一个 UI,并让它与我说出的词语在时间上同步,但我不确定它是否能做到。于是我让 Claude 使用 Remotion 和转录文本创建一个视频原型,看看这个想法是否可行。
最后,视频本身看起来有些灰暗。我知道这是调色问题,但我并不真正了解什么是调色。我第一次尝试时,是想让 Claude 做几个版本让我来选,但我意识到,当涉及调色时,我并不知道什么才算「好」。于是,我没有继续让它盲目生成版本,而是让 Claude 教我调色,以此发现自己的未知项。
让地图与疆域匹配
模型越强,你就越能通过正确的方法完成更多事情。当一个长周期任务返回了错误结果时,很可能说明你需要花更多时间定义自己的未知项,或者创建一份实现计划,让 Claude 能够在这些未知项中灵活应对。
每一份解释文档、头脑风暴、访谈、原型和参考资料,都是一种低成本的方法,可以在修复代价变高之前,先发现那些你原本不知道的事情。
所以,在开始下一个项目时,先让 Claude 帮你找到自己的未知项。
本文来自微信公众号“机器之心”,编辑:机器之心编辑部
