夜雨聆风Claude Fable《Finding your unknowns》深度解读
如果让 AI 完成一个简单、封闭、答案明确的任务，提示词写得清楚通常就够了。
但当任务变成设计产品、改造陌生代码库或完成业务分析时，问题就不再只是如何下达指令。真正决定结果的，是原需求没有覆盖的边界、难以言明的偏好、冲突的目标，以及我们从未意识到需要回答的问题。
Anthropic 技术成员 Thariq Shihipar 在 2026 年 7 月 6 日发布的文章 《A field guide to Claude Fable 5: Finding your unknowns》 中，把这些落差统称为 unknowns，未知。他认为，在 Claude Fable 这样的智能体模型上，工作质量越来越取决于使用者能否澄清未知，而不只是模型能否执行指令。
这篇文章表面上讲的是 Claude Code 工作技巧，深层讨论的却是一个适用于所有 AI 协作的问题：
当 AI 的执行能力不断提高，人类最重要的工作不再是告诉它每一步怎么做，而是尽早发现哪些事情还没有被想清楚。
下面先沿着原文的顺序，完整拆解作者的方法，再讨论它的局限，以及怎样把它升级为一套更稳健、可迁移的“未知管理”工作流。
一、地图不等于领土：提示词永远不是任务本身
原文从“地图与领土”的差别讲起。
地图是我们交给 AI 的提示词、技能说明、上下文、需求文档和计划。 领土是真实任务所处的环境，包括代码库、用户行为、组织规则、历史包袱、时间预算和现实限制。 未知则是地图与领土之间尚未被表达、发现或验证的差距。
假设你对 AI 说：“帮我给应用增加一个新的登录方式。”这句话看起来很明确，实际执行时却可能连续遇到问题：
现有账号如何与新登录方式绑定？ 相同邮箱是否允许合并身份？ 登录失败时应该回到哪个页面？ 公司对第三方身份提供商有什么合规要求？ 当前项目是否已有一套不能破坏的鉴权约定？
这些问题未必是故意遗漏的，很多时候我们自己也不知道它们存在。AI 遇到空白后只能暂停询问，或者照着常见做法猜测。任务越长、牵涉的事情越多，开头猜错一点，后面就可能越走越偏。因此，复杂任务失败不一定是模型不够强，更可能是我们交给了 AI 一张信息残缺的地图。
二、四类未知：你不知道的，并不只有一种
作者借用一个经典的四象限，把任务中的信息分为四类。
1. 已知的已知：把你确定的事情明确告诉 AI
这类信息常因“大家应该都知道”而被遗漏。应明确告诉 AI 目标是什么、哪些事情不能做、先做什么，以及怎样才算完成。
2. 已知的未知：不要用模糊措辞掩盖未决问题
“后续视情况优化”“采用合适方案”经常只是把未决问题伪装成需求。应明确由谁决定、需要什么证据、何时决定，以及决定前允许做哪些可逆工作。
3. 未知的已知：很多偏好只能通过看见来发现
你可能说不出理想首页的完整规范，却能迅速指出哪个方案“更像我们”。此时低成本原型比完美描述更有效，它能把隐性判断转化成可以讨论的语言。
4. 未知的未知：最危险的不是没答案，而是没问题
这类未知不能靠“再认真想想”解决，因为缺少的正是提出正确问题所需的知识。需要借助 AI、资料、代码、专家或实验扩展问题空间。
原文有一个很重要的判断：优秀的智能体使用者不是没有未知，而是会预设未知一定存在，并主动设计发现它们的过程。
三、过度具体和过度模糊，为什么都会失败
作者把给 AI 下指令描述为一种微妙的平衡。
指令过于具体时，AI 可能忠实执行一条已经不再合理的路线。即使它在环境中发现更好的做法，也会因为“用户明确要求”而继续向前。指令过于模糊时，AI 又会用通用最佳实践填补空白，而这些实践未必适合当前任务、团队或用户。
这意味着，高质量指令既不是无限增加细节，也不是把选择全部交给模型，而应该区分三种内容：
不可偏离的约束：目标、红线、兼容范围、预算和安全边界。 允许模型自主处理的细节：机械性修改、低风险实现和可逆选择。 必须停下来问人的问题：会改变架构、用户流程、数据模型或对外承诺的决定。
更成熟的做法，是提前告诉 AI 哪些路不能走、哪些地方可以自行判断、哪些发现必须回来讨论。同时说明自己的知识起点，例如“我熟悉业务但不了解数据管道”。AI 只有知道你已掌握什么，才能判断应该补知识、提问题，还是执行。
四、实施前：先把“未知”找出来，别等做完再推倒重来
原文的大部分方法都发生在实施之前，包括盲点扫描、头脑风暴与原型、访谈、参考资料和实施计划。这五组方法共同解决一个问题：在真正动手之前，尽早找出还没有想清楚的地方。
1. 盲点扫描：先找“我不知道自己不知道什么”
当你进入陌生领域时，最先缺少的通常不是答案，而是问题清单。作者建议直接请 Claude 做一次 “blind spot pass”，也就是盲点扫描。
一次有效的盲点扫描至少应该提供：
当前要完成的任务； 你对这个领域和环境的熟悉程度； 已经掌握的事实与做过的尝试； 你最担心的结果； AI 可以检查的资料、代码或数据范围。
AI 随后应列出可能影响方向的缺口，而不是直接给出宏大方案。盲点扫描的产物不是结论，而是一张待验证的风险地图。
原文示例（意译）：我正在添加一种新的认证方式，但对这个代码库里的认证模块一无所知。请先做一次盲点扫描，帮我找出相关的“未知的未知”，也帮助我更准确地描述后续任务。
2. 头脑风暴与原型：把说不清的标准变成看得见的选择
当任务中存在大量“看到才知道”的偏好时，作者倾向于先让 Claude 提供多个方向或制作轻量原型。
例如，先用假数据做一个单页界面，而不是同时接入后端、状态管理和正式组件；先提出十种改善新用户流失的干预点，再决定要深入哪几种；先生成四种差异足够大的版式，让使用者通过比较说清楚自己真正重视什么。
这里的关键词是 低成本 和 差异足够大。如果四个方案只是颜色略有不同，它们无法帮助你发现偏好；如果每个原型都接入完整业务，原型又失去了降低决策成本的意义。
这样的探索既能避免过早把范围定死，也能防止 AI 把任务越做越大。
3. 访谈：只问真正会改变方案的问题
完成初步探索后，未知不会自动消失。作者会让 Claude 逐个采访自己，尤其优先询问答案会改变架构的问题。
“逐个”很重要。一次抛出二十个问题，看起来全面，实际上容易得到仓促、互相矛盾的回答。高质量访谈应该根据前一个答案继续追问，并区分：
不回答就无法继续的问题； 会明显改变方向的重要问题； 可以采用默认值的低风险问题； 能从环境中查到、不该打扰人的事实问题。
访谈应让人只参与确实需要价值判断或明确授权的部分，而不是把所有责任退回给用户。
原文示例（意译）：请围绕所有含糊之处，每次只问我一个问题；优先询问那些答案会改变系统架构的问题。
4. 参考资料：源代码有时比截图更接近真实意图
当完整描述的成本太高时，图片、文档、已有页面或源代码等参考物比抽象形容词更有用。
原文特别强调：对实现类任务而言，源代码通常是信息最丰富的参考。截图能展示结果，却未必包含结构、状态、边界条件和行为语义；代码则能暴露这些细节。即使参考实现使用不同语言，AI 也可以先理解其行为，再迁移到当前环境。
不过，给参考物时仍要说明“参考什么、不参考什么”。否则 AI 可能连同参考中的缺点、过时约束或不适合当前品牌的部分一起复制。
5. 实施计划：把最可能改变的决策放在最前面
准备实施前，作者会让 Claude 生成计划，并优先展示最可能被调整的部分，例如数据模型、类型接口和用户流程；机械性重构则放在后面。
这背后是一条很实用的评审原则：人的注意力有限，计划不应该平均展示所有细节，而应该把注意力集中到高影响、难回滚和涉及价值判断的决策上。
一份真正可执行的计划，至少应明确：目标与非目标、关键接口或交付物、数据或信息如何流动、异常如何处理、哪些决策已经锁定、哪些仍需验证，以及如何判断任务完成。
原文将 “brainstorm and prototype” 放在同一组，因此可以说它提供了八组实践；如果把头脑风暴与原型视为两项独立动作，则一共是九项。无论如何，重点不在计数，而在它们覆盖了实施前、实施中和实施后的完整周期。
五、实施中：计划不是承诺书，偏差才是学习材料
计划完成后，作者会开启一个新的会话，把规格、原型等规划产物作为干净上下文交给 Claude 执行。这样既避免探索阶段的噪声继续占据上下文，也保留了已经形成的关键决策。
但新会话和完整计划仍不能消灭未知。AI 可能在真实环境中发现边界条件，证明原路线不可行，或者必须在多个次优方案之间做临时选择。
作者的做法是维护一份临时的 implementation-notes.md 或 HTML 实施笔记。当实际情况迫使 AI 偏离计划时，先选择保守方案继续推进，同时把偏差记录下来。
原文示例（意译）：请维护一份
implementation-notes.md。如果遇到迫使你偏离计划的边界情况，先选择保守方案继续，并把原因记录在“偏差”部分。
这个做法有三层价值：
防止 AI 在长任务中悄悄改变方向； 让评审者知道成品与计划为什么不同； 把本次踩到的坑转化为下一次规划可复用的知识。
它承认计划是基于当前信息的假设，而不是必须无条件服从的承诺书；现实推翻计划时，必须留下可追溯的理由。
六、实施后：AI 做完了，人还得真正看懂
AI 可以在短时间内完成大量工作，但这也带来一种新风险：结果已经生成，负责人却不清楚 AI 到底做了什么。
原文用两种方式解决这个问题。
1. 提案与解释材料：让审阅者看见完整过程
作者建议把原型、规格和实施笔记整理成一个便于分享的解释材料，并优先展示最能帮助理解的内容，例如演示动图。
这不仅是包装。审阅者可能拥有你最初也没有的专业知识，他们会关心常见故障、关键取舍和风险是否被覆盖。一份好的解释材料应让人快速看见：解决了什么、为什么这样解决、尝试过什么、实际偏离了什么、还有哪些残余风险。
2. 反向测验：不要把“AI 做完了”误认为“我理解了”
只阅读代码差异或最终文档，可能只能获得表面理解。很多行为依赖旧系统、隐藏状态和跨模块调用，单看新增内容无法推断真实影响。
因此，作者会让 Claude 先制作一份报告，用通俗方式说明前因后果，再根据本次修改对自己进行测验。他甚至提出，只有完全答对才合并代码。
这个动作很有启发性：过去通常是人测试 AI 是否理解需求，现在也应该让 AI 测试负责人是否理解交付物。反向测验能暴露“我以为我知道”的错觉，并确保负责人仍然对结果负责。
七、Fable 发布视频：未知是怎样被逐层消除的
原文最后用 Fable 发布视频作为完整案例。作者并不是视频制作专家，却使用 Claude Code 从头到尾参与了视频编辑。
整个过程不是从一条“帮我做完视频”的万能提示词开始，而是连续处理不同类型的未知：
先确认能力边界。 作者知道 Claude 可以借助代码处理视频和转录，却不确定精度是否足够，于是先了解 Whisper 一类转录机制，以及能否通过 FFmpeg 精确删除语气词和长停顿。 再用原型验证可行性。 他希望画面中的界面元素与说话内容同步，但不确定方案能否成立，因此让 Claude 用 Remotion 和转录结果制作原型视频，而不是直接完成整支成片。 最后补齐评价标准。 成片显得有些灰暗，他知道问题可能与调色有关，却不知道怎样才算“调得好”。最初他想生成多个版本来选，后来意识到自己缺少的不是更多版本，而是判断版本的知识，于是先让 Claude 教他理解调色。
这个案例对应了三种不同动作：解释帮助建立知识，原型帮助验证能力，教学帮助形成评价标准。它也说明，面对陌生领域时，人不必先成为专家才能开始，但必须知道什么时候应该暂停执行、转而学习如何判断。
八、这套方法还不够：还要回答五个现实问题
原文提供了一套非常实用的个人工作流，但它主要来自作者使用特定模型完成真实任务的经验，也出现在 Claude Fable 的产品介绍语境中。它是有价值的一手实践，不是经过对照验证的普遍定律。要把方法用于更高风险、更复杂的任务，还需要补上几个关键环节。
发现了一堆未知，应该先解决哪一个？
原文强调尽早发现，却没有充分讨论如何决定先处理哪个。如果盲点扫描列出五十个问题，团队仍可能陷入新的分析瘫痪。
可以用三个维度排序：
影响程度：答案不同会不会改变目标、架构、预算或对外承诺？ 可逆性：做错后能否快速、低成本地撤销？ 验证成本：需要查资料、做实验、请专家，还是只能在真实环境中观察？
高影响、难回滚的问题必须先验证；低影响、容易撤销的问题可以采用默认值并记录；成本极高但当前不阻塞的问题则进入风险清单，而不是无限研究。
AI 提出的“盲点”，如果本身就是错的怎么办？
模型擅长生成结构完整、措辞专业的问题清单，但其中可能包含不适用的通用风险、对环境的错误推断，甚至根本不存在的限制。
因此，盲点扫描必须与证据绑定。对于每个重要未知，都要追问：它来自哪段代码、哪份文档、哪条数据或哪位决策者？如果只是模型基于常识的推测，应明确标为假设，而不是事实。
AI 可以扩大搜索范围，却不能同时垄断问题发现、证据提供和最终判断。
实施笔记只写“改了什么”为什么还不够？
一条“遇到边界情况，所以改用保守方案”的记录，仍不足以支持后续评审。更完整的决策记录应包括：
发现了什么情况； 原计划为什么不再适用； 证据位于哪里； 考虑过哪些选项； 为什么选择当前方案； 当前置信度是多少； 谁需要确认； 如何回滚或再次验证。
这样，实施笔记才从流水账升级为真正的决策日志。
能够解释清楚，就代表结果一定正确吗？
负责人能够解释一项变更，不代表变更一定正确。测验检验的是理解，不是系统行为、数据质量、法律合规或用户体验。
代码仍需要测试和评审，数据分析仍需要复算与口径检查，内容仍需要事实核验，产品仍需要可用性测试，重要上线仍需要监控与回滚方案。反向测验应该是质量保障的一层，而不是合并或发布的唯一门槛。
所有任务都需要走完这套流程吗？
给一封内部邮件润色，与改造支付系统显然不该使用同样的流程。未知管理本身也有成本。
更合理的原则是按风险调整流程：任务越长、影响越大、越难回滚、越依赖陌生领域，就越需要盲点扫描、原型、计划和决策记录；低风险、可快速撤销的工作则可以先行动，通过反馈学习。
九、增强版六步法：发现—分类—排序—验证—记录—复盘
结合原文方法和以上缺口，可以把未知管理整理为六个连续步骤。
这六步不是只能按顺序走一遍的直线流程。验证可能暴露新的盲点，实施偏差可能迫使团队重新分类和排序，复盘也可能证明最初解决了错误的问题。真正重要的是让未知有地方进入流程，而不是要求第一次计划就覆盖一切。
十、举一反三：这不只是一套编程方法
1. 产品设计
需求是“提高新用户留存”。先让 AI 扫描可能的未知：流失发生在哪一步、不同渠道用户是否相同、指标口径是否稳定。随后列出从修改文案到重构流程的多级方案，用低保真原型测试最关键的交互，最后再决定是否投入开发。
2. 内容写作
任务是写一篇医疗科普。已知的未知可能是最新指南内容，未知的未知则可能是哪些日常说法会造成误导。AI 可以先列风险点和待核事实，但关键结论必须回到权威来源验证。成稿后再让 AI 以普通读者、医生和平台审核者三种视角提出问题。
3. 数据分析
业务要求解释“本月转化率下降”。在直接跑报表前，先检查指标定义、埋点变化、样本结构和活动周期。对每个可能原因标记证据强弱，区分相关性与因果推断。最终报告不仅给结论，也保留尚未验证的解释和下一步实验。
4. 视觉设计
使用者只能说“想要更高级”。与其让 AI 无限微调一个方案，不如先给出几种差异明显的视觉方向，并要求说明每种方向的字体、留白、颜色和信息密度。通过选择与排除，把“高级”逐步转化成可执行的视觉标准。
5. 个人学习
准备进入一个陌生领域时，不要只问“给我一份学习路线”。先告诉 AI 你的基础、目标和使用场景，让它做盲点扫描；再通过小测验识别“以为自己会”的部分。学习计划应优先补足会阻塞实践的概念，并用真实任务持续暴露新的未知。
这些案例的共同点是：AI 不只生成答案，也能帮助我们发现问题、快速试验、检查自己是否真正理解。但什么算可靠证据、最终怎样取舍、出了问题由谁负责，仍要由人决定。
十一、完整案例：一个 iOS 工程师如何用 AI 从 0 到 1 实现完整网站
假设你是一名熟悉 Swift 和 iOS 客户端开发、但没有 Web 开发经验的工程师。你想借助 AI 做一个可以正式上线的个人技术作品集网站，包含首页、个人介绍、项目展示、文章列表和联系方式，并支持移动端访问、基础 SEO 和公开部署。
这里的“完整”不是堆满账号、支付和管理后台，而是从一个模糊想法出发，经过需求澄清、原型、技术决策、开发、测试和部署，最终得到一个你能维护、能解释、出了问题也知道如何恢复的网站。
下面八条 prompt 不是彼此独立的咒语。每一步都会生成下一步需要的需求说明、原型、计划或实施记录，它们共同构成一条不断发现和处理未知的工作链。
使用这些 prompt 时还有两条贯穿全程的规则：如果 AI 无法访问指定文件、链接或工具，必须明确说明并请求你提供内容，不能假装已经读取或验证；个人经历、项目数据和成果只能来自你提供的材料，缺失内容使用明确标记的占位符，不能自行编造。
1. 先做盲点扫描，不要急着选择框架
这一轮的目标不是得到框架名称，而是先知道一个可上线的网站究竟由哪些部分组成。
2. 让 AI 逐个采访，锁定网站目标和范围
这里特意要求“一次只问一个问题”，是为了让后一个问题建立在前一个答案上，而不是一次收到一张难以认真回答的调查表。
3. 用参考网站和原型发现自己真正喜欢什么
对不熟悉 Web 设计的 iOS 工程师来说，“做几个版本让我选”通常比继续堆叠“简洁、现代、高级”之类的形容词更有效。
4. 确认技术方案，并生成可评审的实施计划
这一阶段不是追求一份越长越好的计划，而是让 iOS 工程师能够在动手前看懂 Web 项目的关键结构，并审查那些做错后代价较高的决定。
5. 按计划开发，同时记录为什么改变计划
这条 prompt 的重点不是要求 AI 永远服从计划，而是不允许它悄悄改变计划。
6. 不只检查“能打开”，还要检查真实使用质量
这一轮能暴露客户端工程师容易忽略的 Web 特有问题，例如键盘导航、搜索引擎元数据和不同浏览器的表现。
7. 完成部署，但保留验证和回滚路径
这一步把“代码写完”和“网站真正可以被访问”区分开，也明确哪些外部操作必须由人授权。
8. 让 AI 解释网站，再反过来测试你是否真正理解
走完这八步，最终得到的不只是一个由 AI 生成的网站，还包括需求说明、原型、实施计划、偏差记录、上线清单和交接文档。更重要的是，网站负责人没有因为 AI 承担了大量执行工作，就失去对最终结果的理解和控制。
十二、从提示词工程，走向不确定性管理
原文最有价值的地方，不是提供了几个新的提示词句式，而是重新划分了人与 AI 的职责。
AI 的优势是快速搜索、生成备选方案、制作低成本原型、在失败后继续迭代；人的优势是理解真实目标、承担价值判断、决定风险边界，并对结果负责。好的协作不是人把一切想清楚后让 AI 执行，也不是人给出一句模糊目标后等待奇迹，而是双方通过一轮轮探索，把未知转化成问题，把问题转化成证据，把证据转化成决策。
模型越强，一次能完成的任务越长。开头猜错一点，执行得越久，就可能偏得越远。未来真正稀缺的能力，未必是写出一条看起来完美的提示词，而是建立一种能够及时发现、核实和纠正未知的工作方式。
优秀的 AI 使用者，不一定更会下命令，但往往更早发现自己不知道什么。
原文信息
原文：A field guide to Claude Fable 5: Finding your unknowns：https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns 作者：Thariq Shihipar，Anthropic 技术成员 发布日期：2026 年 7 月 6 日
