2026年，用Claude Fable 5做长周期代理编码的人越来越多。模型本身已经强大到能持续工作数小时而不迷失方向，但实际项目里，很多人还是会遇到同一个问题：任务做到一半突然偏离预期、实现方式次优、或者后期发现关键约束根本没被考虑。

问题往往不在模型“不够聪明”，而在我们给它的地图和真实领土之间存在巨大落差。

地图是你提供的prompt、技能描述和上下文。领土是真实的代码库、业务约束、历史实现和边缘情况。两者之间的空白，就是未知。Fable 5把这个差距放大了：模型越强，它遇到未知时做出的“最佳猜测”就越有影响力，而这些猜测累积起来，就会决定最终交付物的质量。

四类未知：把模糊的“不知道”结构化

我起初以为只要把需求写得足够详细、上下文给得足够全，模型就能自己把事情做对。后来反复在复杂项目中实践后发现，真正卡住进度的，是那些我自己都没意识到的空白。

把未知拆成四类，能把模糊的感觉变成可操作的检查清单：

• 已知已知：你已经明确写在prompt里的部分。
• 已知未知：你知道自己还没想清楚，但至少知道有这个缺口。
• 未知已知：对你来说显而易见、所以从来没写下来的假设（但模型不一定默认知道）。
• 未知未知：你完全没考虑过的领域、更好的做法、或者潜在的重大约束。

顶级代理编码者（比如Boris或Jarred那种水平）的一个共同点是：他们对前三类未知的管理非常清晰，同时主动假设第四类未知的存在，并设计流程去发现它们。

不同阶段发现未知的实用模式

发现未知不是一次性动作，而是贯穿项目始终的迭代过程。下面按阶段拆解最有效的方法（已逻辑重构，保留核心思路）：

预实现阶段：把盲区暴露出来

当进入一个陌生模块或全新领域时，最大风险是未知未知。此时最有效的做法是主动请求“盲点扫描”。

示例结构化提示（重构版）：

我是团队里对这个认证模块完全不熟悉的人。现在要新增一个认证提供商。
请帮我做一次盲点扫描（blindspot pass），列出我可能存在的未知未知，并解释为什么这些未知会影响后续prompt的质量。

另一个高价值做法是头脑风暴 + 原型。当你对“好的样子”只有模糊感觉（未知已知）时，让模型先生成多个 wildly different 的方向，用HTML artifact快速可视化，供你快速反应和收窄范围。

实现阶段：用笔记捕捉动态未知

即使做了充分规划，模型在真实代码库里依然会遇到计划外的情况。最好的做法是要求它维护一个临时的 implementation-notes.md 文件，专门记录任何偏离计划的决策和原因。

这样下一次迭代时，你和模型都能从失败中真正学习，而不是把经验留在不可搜索的聊天记录里。

实现后阶段：用测验和解释器闭环

交付前最容易被忽视的是“自己其实没完全理解改动”。让模型基于上下文生成一份带直觉解释的变更报告，并在最后附上小测验。只有你能100%通过测验，才真正掌握了这次变更的全部影响。

这个方法特别适合大型代码库——diff本身往往无法完整传达行为变化。

不同阶段未知发现方法的对比

为什么“发现未知”比“写更好prompt”更重要

更好的模型让长时程任务成为可能，但也让未知的代价更高。模型越能自主决策，它对未知的处理就越会直接影响最终结果。

传统提示工程的瓶颈是“如何更精确地描述需求”。Fable 5时代的瓶颈变成了“如何更快、更系统地发现自己还没意识到的需求和约束”。

这其实是一种可训练的技能。通过反复和Fable合作做盲点扫描、原型验证、笔记记录，你会越来越清晰地知道自己在哪些地方容易有盲区，下一次项目启动时就能主动补上。

把“地图与领土”的差距当成核心北极星，而不是把模型当黑箱。每次任务跑偏时，先问自己：这次我漏掉了哪类未知？

你在当前或下一个项目里，最想先暴露哪一类未知？把具体场景说出来，我们可以一起设计对应的发现流程。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。