与 Claude Fable 5 协作,一直在给我反复上一堂老课:地图不等于疆域。
地图,是对"要做的工作"的一种表征——是我的 prompt、技能(skills)和上下文,是我交给 Claude 的东西。疆域,是工作真正发生的地方——代码库、真实世界,以及它们实打实的约束。
地图与疆域之间的落差,就是我所说的未知数(unknowns)。当 Claude 撞上一个未知数,它只能基于"对我想要什么的最佳猜测"来做决定。要做的工作越多,Claude 可能撞上的未知数就越多。
Fable 是第一个这样的模型:我发现工作质量的瓶颈,就在于我厘清它未知数的能力。
重要的是,只靠事前规划并不总是够用。你可能在实现深处才发现未知数;你的未知数也可能把你指向一个事实:这个问题其实应该换一种方式来解。
我发现,与 Fable 协作,是一个在实现之前、之中、之后持续发现自己未知数的迭代过程。
我做了一些用来寻找未知数的示例工件(artifacts),但记得回到这里,把"什么时候该用哪一个"的直觉建立起来。
你的未知数是什么?当我带着一个问题来找 Claude 时,我习惯把它拆成四类:
最好的 agentic 程序员,未知数通常都不多。看 Boris 或 Jarred 这样的人写 prompt,你一眼就能看出:他们对自己想要什么了如指掌,和代码库、和模型行为都深度同频。
但他们同样会预设未知数的存在。从很多角度说,减少并规划你的未知数,正是 agentic 编程的那项核心技能。而幸运的是,这项技能可以练——就在与 Claude 的协作中练。
给 Claude 下指令是一种微妙的平衡。太具体,即使转向(pivot)可能更合适,Claude 也会照你说的执行;太模糊,Claude 往往会按"行业最佳实践"来做选择和假设——而那未必适合你的任务。
不把未知数纳入考虑,两头都会栽:你不知道路上什么时候会布满障碍,也不知道路什么时候其实是通畅的——但你依然希望 Claude 该变道时变道。
Claude 能帮你更快发现未知数。它能以极快的速度搜索你的代码库和互联网,随便挑一个话题,它平均下来都比你懂得多;它还能更快地从失败里迭代。
这个过程中最重要的一环,是把"你的起点"作为上下文交给 Claude。比如:告诉它你的思考走到了哪一步;坦白你对这个问题、这个代码库的经验深浅;让它像一个思考伙伴(thought partner)一样和你一起工作。
我之前写过用 HTML 与 Claude 协作这件事——在几乎所有这些场景里,HTML 工件都是可视化与呈现的最佳载体。
这篇文章里,我会详细讲我用来揭开这些未知数的一些模式。我并不是每次都用全套,但这是一套值得常备的技巧。
动工之前,最有用的事情之一是搞清自己的盲区。比如,你要在代码库的陌生区域写一个功能,或者让 Claude 帮你做不熟悉的活儿(比如反复打磨一个设计),那你多半带着一大堆未知的未知。
你可能不知道该问什么问题、不知道"好"长什么样、不知道前人做过什么、不知道哪里有坑要绕。
这时,你可以让 Claude 帮你找出你的未知的未知,并讲解给你听。我喜欢直接使用 "blindspot pass"(盲区扫描)和 "unknown unknowns"(未知的未知)这两个字面原词。把"你是谁、你已经知道什么"作为上下文交代清楚,通常很关键。
示例 prompt:
当我在一个充满未知的已知的领域工作——判断标准只有"见到了才说得出"——我喜欢让 Claude 陪我头脑风暴、做原型。
在原型阶段就尽早识别并说出这些未知的已知,价值极大。因为等到实现阶段才发现,代价(相对)就贵了:功能或规格里的一点小改动,可能导致代码实现天差地别,而让 agent 回滚之前的修改会更加困难。
比如,你可能只是想看看"往某个界面上加一个按钮"是什么效果,而不想为此接一条后端路由,或在前端多维护一份状态。
视觉设计对我来说就是那种"说不清、但见到就认得"的东西。这种时候,我会要求对同一个工件给出好几个设计方向。
我还几乎在每个编程会话的开头都安排一段探索或头脑风暴。这让我带着明确意图开局,划定项目范围。Claude 经常发现我自己会漏掉的高价值路径,偶尔也会只见树木不见森林。头脑风暴让我不至于把范围定得太窄或太宽。
示例 prompt:
充分头脑风暴之后,我多半还留着一些未知数。
这时,我会让 Claude 就任何未知数或模糊之处来访谈我。让 Claude 访谈你时,记得把问题的上下文交代给它,让它据此设计提问。举几个例子:
示例 prompt:
有时候,你没法细致描述你想要什么。比如,你可能缺少那套语言,或者它复杂到要说清楚得花上好一阵。
这种情况下,最好的答案是给一个参照物。图表、文档、图片都可以,但最好的参照物是源代码。
如果有一个库以某种方式实现了你想要的东西,或者有一个你特别喜欢的设计组件,直接把 Fable 指向那个文件夹,告诉它要看什么——哪怕它是用另一种语言写的。
Claude Design 也是这么工作的。你不必递给它一个文件(当然也可以)。你可以把它指向某个你喜欢的网站上的模块,它读的是底层代码,而不只是截图。这能给出丰富得多的细节:标记、结构,以及这个组件到底是怎么搭起来的。
示例 prompt:
当我觉得自己准备好动手了,我一般会让 Claude 先拟一份实现计划给我审——重点放在最可能变动的部分,比如数据模型、类型接口、UX 流程。这能让 Claude 把"我可能真的需要改"的东西亮出来。
示例 prompt:
对计划满意之后,我会开一个新会话,把所有工件传进 prompt。比如,我可能把一份 spec 文件和一个原型交给 agent,让它去实现。
但真相是:无论你规划得多充分,总有未知的未知潜伏着。agent 干活时可能发现,由于代码里的某个边界情况,它得换一条路走。
我会让 Claude Code 维护一个临时的 implementation-notes.md(或 .html)文件,把它做的每个决定记下来,好让我们从下一次尝试中学到东西。
示例 prompt:
交付一件东西,最重要的环节之一是拿到认同与批准(buy-in)。在最终文档里内置提案(pitch)和讲解(explainer)工件,有两个好处:
示例 prompt:
一场长时间的工作会话之后,Claude 完成的东西可能比我意识到的多得多。只读代码 diff,我对发生了什么只能有个浅层理解,因为大量行为取决于既有的代码路径。
给足上下文之后,让 Claude 就这次改动考考我,能帮我真正理解发生了什么。只有满分通过测验,我才会合并。
示例 prompt:
Fable 的发布视频完全由 Claude Code 剪辑。这对我是个全新领域,我绝算不上专家。
所以,我从"我确实知道的"开始。我知道 Claude 能用代码剪视频、做转写,但不确定精度够不够。于是我先让 Claude 给我讲清楚 Whisper 这类转写是怎么工作的,以及我能不能用 ffmpeg 把"嗯啊"之类的口头语和长停顿精准剪掉。
我想让 Claude 做一个跟我说的话逐词同步的 UI,但不确定它做不做得到,于是我让 Claude 用 Remotion 和一份转写稿做了一个原型视频,先验证可行性。
最后,视频本身看起来色彩有点寡淡。我知道这是调色(color grading)的结果,但我并不真的懂调色是什么。我的第一反应是让 Claude 做几个版本让我挑,但我随即意识到:在调色这件事上,我根本不知道"好"长什么样。于是我换了个方向,让 Claude 教我调色,以此发现我自己的未知数。
你可以在这里看到关于这一段更深入的讲解。
模型越强,方法对了,你能做成的事就越多。当一个长程任务的结果不对,多半说明你需要花更多时间界定你的未知数,或者做一份允许 Claude 在未知数中随机应变的实现计划。
每一次讲解、头脑风暴、访谈、原型和参照,都是一种便宜的办法,让你在"修起来变贵"之前,发现自己原来不知道的东西。
所以,下一个项目,就从让 Claude 帮你找到你的未知数开始吧。