说个颠覆认知的，Fable 5越强，你用它写代码反而越容易翻车，这是来自Anthropic内部的使用Fable 5的最佳实践和方法论，真正拉开人与人差距的关键是，有没有驾驭强模型的元认知能力。

先说结论，这其实不是模型能力退化，也不是什么prompt技巧不对，相反是你顺着这个问题往下挖，会发现强模型时代的游戏规则其实已经悄悄变了。

我之前也一直觉得，模型越厉害干活就越省心，直到翻到Claude团队内部的这套使用框架，才反应过来问题根本不在模型身上。

核心逻辑一句话就能讲清，你写的需求和上下文是地图，真实的代码库、历史约束、边缘场景是领地，中间的差距全是各式各样的未知。

模型弱的时候，瓶颈在模型能不能把代码写对，等模型强到Fable 5这个级别，瓶颈就彻底转移了，变成了你能不能在开工前把所有未知都挖出来。不然模型只会照着残缺的地图，把活干得又快又偏，等你发现不对的时候，返工成本已经很高了。

他们把未知分成了四类，你明确写进需求的是已知的已知，你知道自己不懂的是已知的未知，这两类都好处理。

真正坑人的是另外两种，一种是你潜意识里有偏好但没说出来的隐性认知，比如设计品味、代码风格，另一种是你连想都没想到过的盲区，比如藏在旧代码里的历史坑、架构层面的底层约束，这两类才是造成大量返工的元凶。

对应的解法也覆盖了全流程，开工前先做一轮盲点扫描，让模型帮你找出你自己都没意识到的坑，遇到审美和偏好类的问题，先做多版原型快速试错，比对着文字描述瞎猜靠谱得多，拿不准的地方让模型逐个提问澄清，优先问会影响架构的核心问题。

实现过程中让模型同步记录偏差日志，遇到计划外的边缘场景选保守方案留痕，不要擅自做主。做完之后最绝的一步，让模型基于变更内容给你出一套测验，你得满分了才能合并，逼着自己真正理解改动，而不是AI改完就完事。

已经有人把这套方法做成了开源技能，实测下来任务达标率直接从百分之六十五拉到了百分之百，简单任务不受影响，复杂模糊的场景提升最明显。

这件事真正的意义，根本不是什么写代码的小技巧。

它标志着强AI时代的协作逻辑已经彻底变了，过去是人指挥工具干活，拼的是指令清不清晰，现在是人跟AI一起探索未知，拼的是你能不能管理好自己的认知边界。

我想说的是并不是模型越强越没用，也不是这套方法能解决所有问题，我的结论是，当模型的能力已经远超大多数人的预期时，真正拉开人与人差距的关键是，有没有驾驭强模型的元认知能力。