刷完 Fable 5 爆火玩法，我发现自己用 AI 第一步就错了

Fable 5 回归之后，一些使用案例又开始在网上爆火。每看到一个，心里大概都想过，怎么我没有发现这样的玩法。

最近流行的《哈利·波特》中汤姆·里德尔日记本，开发者用 Fable 5 把自己的 reMarkable 平板改造成一个魔法手帐。我们在纸上写下提示词，会自动淡出消失，然后 AI 的回复慢慢淡入，就像魔法般从纸上浮现。

目前这条视频在 X 上已经有上百万次浏览。也有网友很快用 iPad 也实现了类似的功能，用 AI 生成单个 HTML 文件，打开就是一个魔法笔记本，在屏幕上写下提示词后，得到魔法般的回答。

另一个热门的玩法是 Google AI Studio 产品和设计负责人 Ammaar Reshi 用 Fable 5 做了一个游戏，他将一款 2003 年发行的游戏《命令与征服：将军零点》，顺利移植到了 iPhone 和 iPad 上，并且不需要模拟器。

视频来源：X@ammaar

就连 Claude Code 负责人都在下面留言表示惊讶。Ammaar 也给出了完整的实现经历，在 GitHub 的开源仓库里，详细描述了如何在自己的 iOS 设备运行这款游戏、心路历程以及项目存在的问题。

更有意思的是这条超过 300 万次浏览的「Fable 5 自画像」。网友要求 Fable 5 向他展示它最具表现力的形态。

Fable 5 没有使用任何已有的视频生成器，而是在电脑的终端里编写了自己的渲染引擎，还合成了自己的声音，从零开始写了一个生成式的 ASCII 编码引擎，来描绘 Fable 5 最有表现力的形态。

视频来源：X@VoidStateKate

有网友质疑 Fable 5 在其中是否发挥作用，她贴出了简单的提示词信息，像是「嗨，Fable，请你用 ASCII 字符，通过语音、音频和动画，制作一个短视频来表达你最真实的内心世界。」

上下更多内容

Fable 5 在拉开 AI 使用的差距这方面，真的做到了淋漓尽致。

即便是一些基础的玩法，有人用 Fable 5 就能做出一个几乎能完美上线的游戏。从最初的想法、游戏美术到 3D 模型和代码，网友用 Fable 5 在 Rork 里完美克隆了地铁跑酷，总用时 1 小时。

视频来源：X@alexcooldev

随着模型能力的提升，那些知道怎么使用模型的人，写出更好的提示词，应用更完善的 Skill，选择合适的框架，他们得到的结果比大多数用着同样一个 Fable 5 的用户都更好。

能用 Fable 5 和不能用是一道门槛，但是会用 Fable 5 和不会用同样是一个明显的差距。

YCombinator 合伙人发 X 说 Fable 太好用了，评论区表示你用到的只是冰山一角

Claude Code 工程师前几天在 X 发文，核心主题就是如何在使用高阶 AI 模型时，文中举例使用的是 Claude Fable 5，通过「理清未知领域」来突破生产力瓶颈。

在我们看来，其实除了 Fable 5，就是手边能接触到的最强模型，我们或许都可以用这套方法去挖掘模型潜力的同时，发现自己的潜力。

原文链接：https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns

地图非疆域

这个上世纪三十年代的哲学概念，著名的「语义学命题」，描绘的是我们的认知与实际情况之间有着一定的差异。

就像地图无法完全呈现真实世界的所有细节和复杂性一样，我们的描述，也只是对事物的简化和抽象，这种描述通常无法准确反映外部世界。

APPSO 曾在 AI 模型疯狂发布的那段时间分享了我们的思考，里面也提到了类似的观点。

放在今天的 AI 开发语境里，我们丢给 AI 的 prompt、skills、上下文，更详细一点还有需求说明，这些都只是「地图」，是我们对任务的描述。

而复杂的代码库、真实世界的业务场景、现实约束和运行规则，才是真正的「疆域」。

在「地图」和「疆域」之间，有着各种未知的情况。丢给导航一张路线地图，它能告诉我们从 A 到 B 怎么走，但是路面情况，这些只有在现场才会出现的东西，是我们无法用一句提示词可以穷尽的。

当我们在 Vibe Coding 时，输入一句提示词「帮我做一个编辑器工具栏」，Claude 真动手时发现：现有组件怎么复用、按钮放哪里、状态怎么存、移动端会不会挤、你喜欢简洁还是功能铺满。

这些未知，即便提示词描述的再清楚，也只是任务的压缩版本，真正的工作仍然需要在 Claude 执行过程中，才会暴露更多的细节。

这些细节被称为 Unknowns，未知项或者空白地带。有些空白我们自己知道，但有些空白是我们心里有标准，却无法描述清晰，还有一些根本没有意识到的部分。

具体来说，根据我们与 AI 协作时的认知，Claude Code 工程师把这些未知分为四个象限。

已知已知（Known Knowns）：我们明确地写在提示词里的需求说明。

已知未知（Known Unknowns）：我们意识到自己还没搞懂、需要去查明或做决定的问题。

未知已知（Unknown Knowns）：那些我们觉得理所当然、甚至懒得写进文档，但一旦看到就能做出判断的直觉，比如隐藏的审美偏好或肌肉记忆等。

未知未知（Unknown Unknowns）：我们根本没有意识到、甚至不知道自己不知道的盲区。

模型越强，这些未知越容易被放大。

过去我们总觉得，AI 工具不好用是因为它「不够聪明」，写出来的代码有 Bug。但到了 Claude Fable 5 这一代，一个新事实浮出水面：

阻碍项目推进的终极瓶颈，不再是 AI 的代码编译能力，而是人类发现并澄清自身「未知」的能力。

换句话说，别急着把需求丢给 AI，而要先帮它找到那些你没说清、你自己也没想透的地方。

如何暴露未知

以前大家谈 AI 使用技巧，最常见的建议是把 prompt 写清楚、写具体、写完整。

到了更聪明的模型这里，问题变细了。我们要做的未必是把指令越写越长，从开发前、到开发过程中、以及开发完成后，都应该有专门的实用技巧和提示词模板。

先做 10 个 Demo 给我看看

如果我们要进入一个陌生的代码模块，或者要用一个从未接触过的框架，最聪明的做法是直接对 Claude 说：

我准备接入一个新的鉴权模块，但我对这个代码库的鉴权逻辑一无所知。请帮我做一次「盲区扫描（Blind Spot Pass）」，把那些我还没意识到的「未知未知」找出来，并教我怎么更好地向你提问。

而面对那些「说不清道不明」的未知已知，不要直接让 AI 去改生产环境的代码，先让它生成独立的、带有假数据的 HTML 页面。

比如做前端设计，一些工程师是典型的「直男审美」，让他们描述理想的界面，很难组织成具体的语言。但只要看到成品，他们就能立刻挑出刺来。

这时候，我们可以告诉 AI：

我想做个数据看板，但我没什么审美。请帮我生成一个 HTML 页面，包含 4 种截然不同的设计方向，让我能有个直观的反应。

这并不是在浪费算力，其实整个暴露未知的核心逻辑，就是用极低的成本去试错，避免在核心代码中付出昂贵的纠错代价。

上下更多内容

在开发前的 Demo 里，用几个低成本的 HTML 原型，去对齐彼此的默契，把我们脑子里的隐性判断倒逼出来。

而当任务会影响架构时，最好让 AI 询问我们。以反向面试的方式，让 AI 把我们模糊的想法变明确。

其中，问题要挑那种答案会改变方案的，比如数据存在前端还是后端，权限跟用户走还是跟团队走，某个流程要一步完成还是拆成审批。

请像面试官一样，每次只问我一个问题，帮我厘清需求中的模糊地带。优先提那些会影响架构设计的关键问题。

还是说不清楚的时候，甚至可以直接把现成的优秀源码/案例，哪怕是不同语言，丢给 AI 去像素级模仿。

等差不多能动手了，再让 AI 写 implementation plan，并把最需要我们拍板的「数据模型、接口定义、UI 流转」等需要修改主意的内容，放在最前面审核，机械化的重构放在后面。

循环工程和线束工程

在真实世界的疆域里，哪怕最完美的计划，也会遇到各种偏离原计划的极端案例。

大多数长周期的任务落地过程中，聪明的 Agent 会不断去发现任务中可能存在的问题。例如，它可能会发现某个第三方库不兼容，也可能发现某个接口的响应变慢了。这时候，AI 需要自己做主。

如果没有防御机制，AI 跑了一个小时后，我们再看对比，常常只能看到改了哪些文件，看不出它为什么这么改。AI 的自我修正是把问题解决了，但也可能悄悄埋下了一个我们根本不知道的雷。

因此在执行中，Claude Code 工程师建议让 Claude 维护一个临时文件，比如 implementation-notes.md。它每次遇到边界情况、偏离原计划、做了什么保守取舍，都写进去。

在开发过程中，一旦你遇到任何逼迫你偏离原定计划的极端情况，请选择最保守的退路，并且立刻在执行笔记的「路线偏离」一栏里记上一笔。不要瞒着我，继续往前走。

Claude，请给我出一张卷子

当 Claude Code 帮我们改完了几千行代码，生成了大量的新文件，看着那些密密麻麻的代码差异对比，很多时候，我们只是机械地点击了「接受修改」，心里却在打鼓。

为了继续从自主化的 AI 手里重新掌控全局，Claude Code 工程师给出的做法是：让 AI 给我们出期末考试题。

在项目的正式交付之前，先把所有的上下文和变更记录打包喂给 Claude：

我需要确保我完全消化了这次的所有改动。请基于这次的代码变更，为我生成一份详细的 HTML 业务报告。并且，在报告最下方，给我出 5 道原理单选题。我必须全部答对，才会允许自己合并这段代码。

除了这种极端的考试，我们还可以让 AI 把原型、规格、实现记录整理成一份给同事看的说明。它要讲清楚做了什么、为什么这么做、还剩哪些风险。

AI 越聪明，做得越多的时候，人越容易失去过程感。我们只看到一个完成的结果，却不知道里面有多少取舍。让模型解释、让自己被测一遍，本质上也是用极低的成本，把那些被 AI 偷偷带过的知识点，重新交给我们。

在 Fable 5 的官方发布视频里，这种方法论也得到了验证。那个演示视频背后的底层脚本剪辑、音频切除、甚至 Remotion 动画，全都是由 Claude 亲自操刀的。

但视频的创作者并不是个专业的剪辑师和调色师。他之所以能搞定这一切，是因为他从一开始就没把 Claude 当成一个服从人类指令的工具。

他让 Claude 去解释 Whisper 的音频裁切原理，让 Claude 去恶补色彩学常识，用最低的成本，把自己从一个不懂视频制作的人，变成了一个能跟上 AI 节奏的「入门制片人」。

回头再看那些刷屏的 Fable 5 案例，汤姆·里德尔的日记本、iPhone 上运行《命令与征服》、会给自己画 ASCII 自画像……这些作品背后，除了那句神奇的 Prompt，还有一连串不断暴露未知、验证想法、推翻重来的过程。

一个强大的模型，把这些过程的成本压低了。

以前，一个大胆的想法可能要花几周才能验证；现在，一个下午就足够知道它值不值得继续。

模型越来越强以后，真正拉开人与人差距的，也许除了拥有更好的 AI，还有愿意不断提出新的问题、验证新的假设，再把一个看似离谱的念头，一步步变成现实。

互联网下一批真正有意思的产品、玩法，甚至新的创业方向，大概率都会从这些一次又一次的实验里长出来。