Fable 5 时代：为什么你的 AI 提示词总是翻车？

导读：在 B 站 UP 主“慢学AI”的最新视频《Fable 5 后，瓶颈在于你澄清未知的能力》中，深度解读了 Anthropic Claude Code 工程师 Thariq Shihipar 的一篇爆火指南——《A Field Guide to Fable: Finding Your Unknowns》。

视频揭示了一个反直觉的真相：在 Fable 5 这样的强模型时代，真正拉开人与人差距的，不再是提示词技巧，而是你“澄清未知”的能力。

如果你在使用 AI Agent（如 Claude Code）时，经常遇到“模型自信满满地写出了一堆完全偏离需求的代码”，那么这篇文章将彻底重塑你的提示词设计思维。

一、核心心法：地图不是疆域 (The Map is Not the Territory)

Thariq 在指南中反复强调一个哲学概念：地图不是疆域。

地图 (The Map)：你写给 AI 的提示词、调用的 Skills、写在 CLAUDE.md 里的规范，以及你提供的上下文。
疆域 (The Territory)：真实的代码库、 undocumented（未文档化）的历史包袱、以及你脑海中真正想要实现的业务意图。

AI 无法直接作用于“疆域”，它只能根据你给的“地图”来行动。只要地图上有沉默、错误或过时的地方，AI 就会在那里犯错——而且因为模型太强，它会极其自信地错下去。

弱模型 vs 强模型的致命差异

很多人以为模型越强，提示词就可以越随便。事实恰恰相反：

弱模型：遇到模糊指令会犹豫、报错，或者生成明显错误的代码。这种失败是局部且廉价的，你一眼就能看出来并修改。
强模型 (Fable 5)：会把你模糊的指令当成绝对真理，自信地将一个错误的假设传播到整个多文件、多步骤的复杂任务中。这种失败是悄无声息且极其昂贵的，往往到最后代码跑不通时，你才发现最初的假设就错了。

二、认知矩阵：找出你的“未知”

Thariq 将我们在与 AI 协作时的认知状态分为了四类，这也是提示词设计的核心靶点：

已知的已知 (Known Knowns)：你在提示词中明确写出来的知识。
已知的未知 (Known Unknowns)：你知道自己还没搞清楚，但意识到存在的问题（比如：“我知道这里需要加密，但我还没想好用哪种算法”）。
未知的已知 (Unknown Knowns)：那些太显而易见、你从未写下来，但如果看到会立刻认出来的常识（比如视觉设计中的某些默认规范，你默认 AI 懂，但 AI 其实不懂）。
未知的未知 (Unknown Unknowns)：最致命的盲区。你根本没有考虑到的事情。

结论：强模型时代的瓶颈，在于你发现“未知的未知”的能力。

三、实战指南：高质量提示词设计框架与案例

视频中最具价值的部分，是 Thariq 分享的一套“在动手前澄清未知”的提示词工作流。以下是文中提到的高质量提示词（Prompt）案例与设计模式，你可以直接复制使用。

1. 盲点扫描提示词 (The Blindspot Pass Prompt)

适用场景：在开始一项你不熟悉的复杂任务前，不要急着让 AI 写代码，而是先让它帮你找出你的“未知的未知”。

高质量 Prompt：
"I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns and help me prompt you better."

中文释义：“我正在着手添加一个新的身份验证提供商，但我对这个代码库中的身份验证模块一无所知。你能做一个盲点扫描，帮我找出相关的‘未知的未知’，并帮助我更好地向你提供提示吗？”

2. 结构化面试提示词 (Structured Interview Prompt)

适用场景：当你有一个模糊的想法，但不知道从何下手时。让 AI 反过来面试你，逼迫你澄清需求。

高质量 Prompt 设计思路：
让 Claude 逐一向你提问关于当前任务的模糊之处。要求它优先提出那些“答案会改变底层架构”的核心问题，而不是纠结于细枝末节。通过这种一问一答，将“已知的未知”转化为“已知的已知”。

3. 原型探索提示词 (Prototyping / Throwaway Prompts)

适用场景：针对“未知的已知”（如视觉设计、UI 交互）。不要直接让 AI 实现最终代码，而是让它生成多个截然不同的“一次性原型”。

高质量 Prompt 设计思路：
让 Fable 5 生成几个截然不同的设计方向（例如作为 HTML artifacts 或伪代码原型），然后人类再去审视和反应。
核心原则：过于具体和过于模糊一样糟糕。过于具体会导致模型僵化执行，即使需要改变方向；过于模糊会导致模型基于行业默认值做出不符合特定任务的决策。通过原型探索，你可以低成本地试错。

4. 实施过程控制提示词 (Implementation Notes & Edge Cases)

适用场景：在长任务执行过程中，防止 AI 遇到边缘情况时“自作主张”或“陷入死循环”。

高质量 Prompt：
"Please keep a temporary implementation-notes.md file where you track the decisions you make so we can learn from them. When you encounter unexpected edge cases, pick the conservative option, log the deviation in the notes, and keep working."

中文释义：“请维护一个临时的 implementation-notes.md 文件，记录你做出的决策。当你遇到意想不到的边缘情况时，请选择保守的选项，在笔记中记录偏差，然后继续工作。”

5. 让模型复述计划 (Restate the Plan)

适用场景：在模型开始执行耗时较长的任务前，进行最后一次“地图与疆域”的对齐。

高质量 Prompt 设计思路：
要求 Agent 在执行前，用你自己的话重述一遍它的理解和执行计划。如果 Claude 的转述让你感到惊讶，那就是“地图/疆域的差距”在早期、低成本地浮现，此时修改提示词的成本几乎为零。

四、进阶技巧：给 Agent 看的 PR 描述模板

在团队协作中，我们写 Pull Request (PR) 描述通常只考虑人类审查者。但在 AI 时代，你的 PR 描述也是下一个接手工作的 Agent 的“地图”。

Thariq 提出了一种双轨制 PR 描述模板，极其适合作为团队使用 AI 协作的规范：

## For reviewers (给人类审查者)
[放置截图、GIF、前后对比等视觉信息。因为有些信息（如微妙的布局偏移、动画时间）无法用文本压缩，不要强迫人类从文字中重建视觉画面。]

## For agents (给后续接手的 Agent)
- **Changed**: [修改了什么，例如 `Button.tsx` 点击处理程序现在通过 `requestAnimationFrame` 防抖]
- **Constraint**: [约束条件，例如 必须保持在每帧 16ms 的预算内 (见 PERF.md)]
- **Not in scope**: [不在本次范围内的内容，例如 禁用状态的样式，在 FOLLOWUP-142 中跟踪]
- **Assumption**: [做出的假设，例如 现有的快照测试未涵盖动画时间，已添加新测试]

这种设计确保了人类获得直观的视觉反馈，而 Agent 获得结构化的文本上下文，完美解决了“地图”受众不同的问题。

五、结语：廉价的探索，昂贵的修复

视频的最后，Thariq 分享了他用 Claude Code 剪辑 Fable 5 发布视频的经历。作为一个对代码库最熟悉的工程师，他依然在转录、节奏和色彩分级上踩了坑（他甚至不知道“好的色彩分级”长什么样，最后只能让 AI 先教他什么是好的色彩分级）。

这给我们所有人的启示是：

“每一次解释、头脑风暴、原型制作和参考，都是一种廉价的方式，用来在修复成本变得高昂之前，发现你原本不知道的东西。”

在 Fable 5 时代，别再迷信“一句话生成完美代码”的神话了。停下来，做盲点扫描，做原型探索，澄清你的“未知”。这才是强模型时代，人类真正不可替代的核心竞争力。