以下是关于如何充分利用 Claude Fable 5 的深度指南，帮助你打造和我下面示例一样疯狂的东西。

https://t.co/XemOHH7K8E

我是如何向 Fable 下 prompt 的

来源：https://simplemarkdowneditor.com/pub/IbaCrTjLJT?key=uQOQ2NPO3TTUSXyYDjyLf

每次我展示用 Fable 造出来的东西，大家都会问同样的问题：“我做不到这种效果。”“你是怎么做到的？”“这不可能是真的。”

而且大家都觉得每个作品都来自某个极其复杂的 prompt，或者花了大得多的功夫。其实往往相反。这些示例比看起来简单。我只是用模型的方式和别人不一样。

Fable 是真正的下一代模型。如果你用现在模型的方式来给它下 prompt，那结果也就和现在差不多。但如果你改变下 prompt 的方式，改变你对它能做什么的认知，那门就真的打开了。

以下是我的实际做法。

给出目标，而非步骤

最大的改变是我不再详细说明怎么做。用以前的模型，你都得指定如何做，否则它们常常跑偏。Fable 正相反。你给它的空间越大，它做得越好。

所以我交给它宏大、粗放、未指定细节的工作——就像把目标交给一个你信任的天才，让它自己找到最佳路径。只不过 Fable 在琢磨“怎么做”这件事上常常比我更强。我每指定一步，其实都是用我的判断覆盖了它的判断，而我的判断通常更差。

一开始会感觉有点冒险，因为你习惯了控制细节。但真正让人放心的，是下一部分。

设定“家规”，让自己能信任它

一个未指定细节的目标，只要用几条不可逾越的规则围住它，就安全了。“家规”就是几条你希望始终成立的原则，不管 Fable 用什么方式达成目标。

比如，当我构建一个 agent 时，模型总喜欢过度工程。它们会为了捕捉某个特例而用正则过滤，而我真正想要的是写一段 prompt 来描述行为，让模型自己处理。所以我的一条固定规则是：不要硬编码特例，用 agent 的系统 prompt 描述你想要的，让 agent 自行推理。

为了多加一层保护，你可以让 Fable 始终交给一个子 agent 一项任务：在推送任何东西之前，对照家规检查工作。这样你就可以让 Fable 放开手脚去实现目标，同时知道它不会发出违背你核心原则的东西。

给出真实的“完成”标准

如果你告诉 Fable 做成“高质量”，它会停在自己认为足够好的水平上，而这通常低于你的标准。所以我不使用形容词。我给它一个可以自我对照的标杆，而且我把标杆设得很高。

有时候我自己写测试……具体的东西，比如“陌生人分不清我们的渲染图和真实照片”。有时候我甚至不知道怎么衡量我想要的东西，那我干脆也把这个难题交给 Fable。

举个例子，有个朋友想克隆一个组件库，一直没进展。有两个问题。第一，他基于 ShadCN 构建，又想去克隆 ShadCN 上的组件，结果 Fable 一直在对抗 ShadCN 的约定，而不是直接构建组件。第二，他没有办法判断什么时候算完成。他只是告诉它“克隆这个”。

于是我们做了两件事。我们抛弃了 ShadCN，从头开始，因为组件库完全可以从零构建，而现有代码只是负担。然后，由于我们俩都不知道如何衡量“是否匹配原版”，就让 Fable 自己想办法。它录制了真实组件使用的屏幕视频，将其转化为每个部件移动的热力图，然后持续工作直到自己的版本匹配。我们从未告诉它怎么做。我们只定义了“完成”的含义，让它自己发明测量标尺。

我这里有一条从不打破的规则：无论谁构建了东西，都不能自己来评分（“构建” agent 常常有偏见，并且有一整套“我为什么做这些决策”的轨迹可以用来为自己辩护）。我始终让系统启动一个独立的 Fable 子 agent，使用全新的上下文窗口，指向真正的输出（真实的像素、正在运行的应用等），让它试图证明东西不合格。

循环直到达标（尤其是创意任务）

一旦有了标准，我就让 Fable 对着它循环，放手让它干。它构建、自我检查、找到最大差距、弥补差距、再重来……持续数小时，有时甚至数天。我经常使用 /loop 来做这件事，尤其是创意工作，因为总有具体的东西可以持续衡量，直到真正的达成。

整个循环的关键是：Fable 永远不能自己决定完成。总有下一个差距。它在我宣布完成时停止，或者当它真的找不到任何需要修复的问题时停止（如果你设置得当，这种情况很少见）。

我每次长时间运行都会用一个小技巧：让 Fable 构建一个简单的 HTML 页面，部署到某个地方，并在工作时持续更新——截图、笔记、任何反映进度的情况。这样我只需看一眼手机，就能在不碰任何东西的情况下了解进展。

让它基于已有成果继续构建

你对一件事已经做得越多，Fable 就越擅长，所以旧成果会成为新成果的燃料。

Fable 刚出来时我做的第一个像样的东西是一个逼真 3D 森林。我写那个 prompt 比之后任何东西都更仔细，因为我没有参考点……没有想要的品质示例，也不知道如何达到那种效果。要写出初始 prompt 确实费了很大功夫。

但一旦我有了一个出色的 3D 场景，之后的一切都变得更容易了。当我构建霍格沃茨示例时，我只需把森林指给 Fable：这是代码，这是品质标准，照着这个做并超越。我不需要重新解释任何东西。

这还不只是代码复用。Fable 能读取我旧 Claude Code 会话的痕迹……当时构建森林实际尝试过的内容，哪些有效哪些无效。所以我不需要告诉它“为场景中的每个对象使用独立的子 agent”，只需说“阅读森林痕迹并学习哪些方法有效”。它自己就掌握了方法。霍格沃茨的构建速度远快于森林，很大程度上就是因为这个。

别挡它的路

每次 Fable 不得不停下来问你，你都在损失时间。所以我预先扫清障碍。例如，如果我要连接一个花钱的真实服务，我会给它一个预算，而不是让它每次使用都请求许可。我告诉它密钥和凭据在哪。我明确告诉它：自己去做决策，除非真的卡住或遇到只有我能决定的事，否则不要回来找我。

唯一的例外是规划（但仅针对巨大、影响极深远的事情）。在真正大型的构建中，我希望在写任何代码之前先看到计划，而且我希望它提前问清所有不确定的事。一旦计划确定，它就一气呵成地运行。

我运行的两种方式

以上所有内容，无论我在发布功能还是构建世界（或任何创意工作）都一样。变化的是其周边的设置。

对于工程，我运行一个团队。 同时运行多个 Fable 会话，从清单、Linear 面板或我直接分配的任务中拉取任务。每个会话完成自己的任务，用子 agent 三重检查自己的成果，然后打开一个包含我上文提到的证据的 PR。然后还有一个 Fable 只做集成：它合并 PR、运行所有内容、像真实用户一样测试，并保持整个流程绿色。当两个功能有重叠时，我告诉一个 Fable 在构建过程中监视另一个的痕迹，保持兼容……它们是并行工作的，所以一个会盯着另一个，并在落地时集成。

对于创意工作，我依赖 momentum 和细节。 同样的循环、同样严格的标准，但我会派出子 agent 去打磨各个独立部件，而不是让一个 Fable 包揽全部……比如，让独立的子 agent 完美化森林中的每一种树。有时我会同时运行几个完全独立的尝试，保留最好的一个，并把有效方法带入下一轮。

你可以根据自己的需要自由混合这些方法。具体取决于你在构建什么。

何时使用 ultracode

有一种更重的模式叫 ultracode，费用高很多。我基本上不用。一个足够有雄心的目标加上好的循环，不需要它也能达到。

ultracode 真正值得的是在打基础的时候。如果我正在从零构建一个未来几个月都会持续开发的新系统（例如，某样成为业务或代码库核心的东西），我希望从第一天起就打好基础。这和我们抛弃 ShadCN 是同一个道理：好的基础让在其上构建的一切都更简单，坏的则会让一切永远更难。对于这类工作——几乎只有这类工作——额外的成本是值得的。

还有一件事

如果你觉得这些信息量太大，记不住，没关系。把本文丢给你的 Fable，告诉它从今以后帮你写 prompt。它知道该怎么做。

这一切都不复杂。大家使用的都是同一个模型。我的结果看起来不同，因为我不手把手喂它，我给它设定了一个它无法敷衍过去的标准，并且我让它在已有成果上不断构建。从那里开始。