一页结论
这篇文章的核心不是“如何写更好的 prompt”，而是“如何管理 unknowns”。 prompt、skills、上下文只是地图；代码库、真实用户、历史约束、运行环境才是领土。地图和领土之间的差距，就是 Agent 会替你猜的地方。
当模型变弱时，猜错通常走不远；当模型像 Fable 5 这样能做长程任务时，猜错会被执行成一套看似完整的系统。因此，强模型时代更考验人类对未知的挖掘能力。
我的判断：这篇应该放进 AI Engineering 的核心方法库。它和 Agent Harness、Context Engineering、Loop Engineering 是同一条主线：让 Agent 走得更远之前，先把上下文、证据、决策轨迹和复核机制补齐。
资料来源
| 官方原文 | A field guide to Claude Fable 5: Finding your unknowns |
|---|---|
| 中文详解 | Kate's Blog 中文详解 |
| 中文示例页 | 认识你的未知 |
| 英文示例页 | Know your unknowns examples |
四层未知
| 类型 | 含义 | 工程例子 |
|---|---|---|
| Known Knowns | 已经明确告诉 Agent 的内容 | 要改哪个模块、实现什么功能、交付什么文件 |
| Known Unknowns | 知道自己还没想清楚的部分 | 数据模型未定、影响范围未知、UX flow 未定 |
| Unknown Knowns | 自己有判断标准，但没法提前讲清楚 | 审美、文案语气、交互手感、团队代码风格 |
| Unknown Unknowns | 完全没意识到的问题 | 历史坑、隐藏边界、领域常识缺口、更优解法 |
这个分类的价值是诊断。AI 交付不理想时，不要只说“模型不行”，而要问：是已知内容没给清楚，还是已知未知没暴露，还是隐性偏好没通过原型显化，还是存在完全没意识到的盲区。
八个方法
1. 盲区扫描
陌生模块或新领域前，先让 AI 找 unknown unknowns、上下文缺口、历史坑和风险。
2. 头脑风暴与原型
用低成本 artifact 让人“看见”选择，从而表达原本说不出的偏好。
3. 访谈
让 AI 一次问一个问题，优先问会改变架构、数据模型或 UX flow 的问题。
4. 参考物
语言不够时给参考。源代码通常是最好的参考，因为它带着结构、边界和真实约束。
5. 可调整计划
计划开头先列最可能需要人调整的决策，机械性步骤放后面。
6. 实现笔记
实现中记录偏离计划、edge cases、保守选择和需要 review 的地方。
7. 说明文档
交付后整理 demo、风险、关键决策和 reviewer 应看的区域。
8. 合并前测验
让 AI 反过来考你，确认你真的理解了变更，而不是只扫了一眼 diff。
对 OpenClaw/Codex 的启发
- 复杂任务默认先做 blindspot pass，尤其是代码库、知识库、发布、部署、外部动作。
- 设计、报告、产品体验类任务应优先给可比较 artifact，而不是一次性定稿。
- 长程任务要维护 implementation notes，避免 compact 或多轮协作后丢失判断轨迹。
- 交付时要输出 explainer、验证证据和剩余风险，不只说“已完成”。
- 高风险改动可以加入 quiz/checklist，让人确认自己理解 Agent 的实际变更。
可复用工作流
我接下来要做的任务是：[任务描述]。
请不要直接开始实现。先按以下流程协作：
1. 做一次 blindspot pass：
- 找出我可能没意识到的 unknown unknowns；
- 指出哪些上下文会显著改变实现方向；
- 提醒我可能的历史坑、边界情况和风险。
2. 区分四类信息：
- Known Knowns：我已经明确告诉你的内容；
- Known Unknowns：我知道还没决定的内容；
- Unknown Knowns：我可能需要通过原型/对比才能表达的偏好；
- Unknown Unknowns：我可能完全没考虑到的问题。
3. 如涉及 UX、设计或产品判断，先做低成本原型或方案对比。
4. 如存在关键歧义，请一次问一个高影响问题。
5. 确认后写实现计划，并标出事实、假设和可调整决策。
6. 实现中维护 implementation-notes.md。
7. 实现后输出 explainer、reviewer checklist、行为变化总结和 quiz。