2026年用Claude Fable 5做长周期代理编码的人越来越多。模型本身已经强大到能持续工作数小时而不迷失方向但实际项目里很多人还是会遇到同一个问题任务做到一半突然偏离预期、实现方式次优、或者后期发现关键约束根本没被考虑。问题往往不在模型“不够聪明”而在我们给它的地图和真实领土之间存在巨大落差。地图是你提供的prompt、技能描述和上下文。领土是真实的代码库、业务约束、历史实现和边缘情况。两者之间的空白就是未知。Fable 5把这个差距放大了模型越强它遇到未知时做出的“最佳猜测”就越有影响力而这些猜测累积起来就会决定最终交付物的质量。四类未知把模糊的“不知道”结构化我起初以为只要把需求写得足够详细、上下文给得足够全模型就能自己把事情做对。后来反复在复杂项目中实践后发现真正卡住进度的是那些我自己都没意识到的空白。把未知拆成四类能把模糊的感觉变成可操作的检查清单已知已知你已经明确写在prompt里的部分。已知未知你知道自己还没想清楚但至少知道有这个缺口。未知已知对你来说显而易见、所以从来没写下来的假设但模型不一定默认知道。未知未知你完全没考虑过的领域、更好的做法、或者潜在的重大约束。顶级代理编码者比如Boris或Jarred那种水平的一个共同点是他们对前三类未知的管理非常清晰同时主动假设第四类未知的存在并设计流程去发现它们。不同阶段发现未知的实用模式发现未知不是一次性动作而是贯穿项目始终的迭代过程。下面按阶段拆解最有效的方法已逻辑重构保留核心思路预实现阶段把盲区暴露出来当进入一个陌生模块或全新领域时最大风险是未知未知。此时最有效的做法是主动请求“盲点扫描”。示例结构化提示重构版我是团队里对这个认证模块完全不熟悉的人。现在要新增一个认证提供商。 请帮我做一次盲点扫描blindspot pass列出我可能存在的未知未知并解释为什么这些未知会影响后续prompt的质量。另一个高价值做法是头脑风暴 原型。当你对“好的样子”只有模糊感觉未知已知时让模型先生成多个 wildly different 的方向用HTML artifact快速可视化供你快速反应和收窄范围。实现阶段用笔记捕捉动态未知即使做了充分规划模型在真实代码库里依然会遇到计划外的情况。最好的做法是要求它维护一个临时的implementation-notes.md文件专门记录任何偏离计划的决策和原因。这样下一次迭代时你和模型都能从失败中真正学习而不是把经验留在不可搜索的聊天记录里。实现后阶段用测验和解释器闭环交付前最容易被忽视的是“自己其实没完全理解改动”。让模型基于上下文生成一份带直觉解释的变更报告并在最后附上小测验。只有你能100%通过测验才真正掌握了这次变更的全部影响。这个方法特别适合大型代码库——diff本身往往无法完整传达行为变化。不同阶段未知发现方法的对比阶段主要面对的未知类型核心方法输出形式价值点预实现未知未知 未知已知盲点扫描 头脑风暴HTML原型 / 列表避免后期昂贵返工实现中已知未知 动态未知实现笔记 保守回退Markdown笔记文件保留学习轨迹实现后已验证的未知解释器 测验HTML报告 测验题确保理解闭环与买单全程所有类型参考代码 访谈指向真实源码/模块用真实实现对齐“地图”为什么“发现未知”比“写更好prompt”更重要更好的模型让长时程任务成为可能但也让未知的代价更高。模型越能自主决策它对未知的处理就越会直接影响最终结果。传统提示工程的瓶颈是“如何更精确地描述需求”。Fable 5时代的瓶颈变成了“如何更快、更系统地发现自己还没意识到的需求和约束”。这其实是一种可训练的技能。通过反复和Fable合作做盲点扫描、原型验证、笔记记录你会越来越清晰地知道自己在哪些地方容易有盲区下一次项目启动时就能主动补上。把“地图与领土”的差距当成核心北极星而不是把模型当黑箱。每次任务跑偏时先问自己这次我漏掉了哪类未知你在当前或下一个项目里最想先暴露哪一类未知把具体场景说出来我们可以一起设计对应的发现流程。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。