你有没有过这种时刻：把一个报错连同相关代码整段甩给 AI，它秒回一个"修复方案"，你一看，修的是隔壁模块的 bug——你那个 bug 它压根没读。
【所有被喂进去的材料，和能被用上的材料，中间隔着一段名为"组织方式"的距离。】
【场景：凌晨一点，我对着一个 REST API 误用错误，给 Claude Code 塞了整包文档】
它给我产出了一版"修复"，优雅，工整，甚至带了注释。
唯一的问题是：它修的是一个三年前就已经废弃的参数，而报错信息里写的那个字段，它仿佛没看见。
我把报错又贴了一遍。它说"抱歉，我理解错了"。
我把文档再贴一次。它给了我一版新的修复方案——修的是我贴的这份文档里第一个出现的方法名，而不是报错里那个。
那一刻我意识到：AI 不是在读代码，它是在抽卡。
顺便说一句，这篇论文的五个作者里有两个姓 Inoue——一个排在作者列表第一个，一个排在中间。你看，连研究团队自己都在演示什么叫"顺序影响被检索到的概率"。
【这个类比不严谨，但我一时半会找不到更贴切的。】
论文结论我用人话翻译一遍：修 REST API 误用这回事，AI 修得好不好，不取决于你喂了多少文档，取决于你怎么组织这些文档——按版本分一分、按内容类型归归类，修复率能高出一大截。
这个结论让我想起上个月的一次崩溃。
不是线上崩溃。是某种更隐蔽的、属于开发者的慢性病：那天我接手一堆文档，官方文档加 README 加交接说明，全塞进知识库，指望 agent 能自己翻出正确答案。结果它处理业务代码还行，一碰到"旧 API 怎么调新参数"就现出原形——不是因为材料不够，是因为全塞进去的材料活活变成了"屎上雕花"的安全垫：它总能找到一个"看似相关"的段落，自信地给出一版"看似合理"的修复，然后编译通过，运行报错。
【在座的各位有没有同感：AI 修完 bug 后，你的心理活动不是"感谢"，而是"你到底改了我哪里"。】
论文里有个数字，我盯了很久：基线修复率 54.3%，而采用四种数据库分别组织 API 规范后，修复率能到 88.6%。
54.3% 意味着什么？AI 修 API 误用这回事，本来就有一半多的概率蒙对——你感觉它在帮你，其实是它在用概率赌你的容忍度。
而 88.6% 这个数字真正的看点不在"涨了 34 个点"，在于它是靠"组织方式"涨的，不是靠"加更多文档"涨的。
——这个结论放到日常里，翻译成一句人话就是：你往 prompt 里塞的东西不决定结果，你塞东西的方式决定结果。
我试过一次。把一个官方 API 手册按"版本号 + 资源类型"拆成几个目录喂进去，而不是一整个 PDF 拍给它，它确实老实了很多——至少报错里出现的关键参数，它能从正确的上下文里找到对应描述，而不是从目录第一章末尾翻出一个看起来很像的参数名，硬安上去。
那一刻我理解了什么叫"显灵"：AI 没有变聪明，只是我的文档终于从一堆没人想翻的 PDF，变成了一份它能按图索骥的地图。
反直觉的是，这论文里最扎眼的配置，恰恰不是那个叠加了 11 种数据库结构的"全都要"方案，而是只用了四个库、按版本和内容类型组织的那个。修复率最高的不是材料最多的，是材料分得最清楚的。
【在这个"信息越多越好"的时代，AI 用自己的修复率告诉我们：你的库存没有价值，你的目录才有价值。】
——但你我都懂，这个道理放在别的领域或许成立，唯独放在"知识库怎么建"这件事上，真正动手去做的时候，大多数人还是选择了最省力的路径：把所有 PDF 拖进同一个文件夹，取名叫"资料"，然后让 AI 自己想办法。
有没有可能，AI 界的"屎上雕花"，就是从这一下回车开始的？
（友情提示：以上情绪波动，与本人知识库中 37 个名为"新建文件夹（3）"的目录结构无关。如有雷同，建议去数数自己收藏夹的层级。）