周末去亚马逊参加了场线下活动。一天下来笔记记了不少，回来翻的时候发现，真正值得写的就三件：两件来自王老师的分享，一件来自活动组织的一场掼蛋游戏。

这三件事看着不相干，但我连起来想了一路，发现它们其实在回答同一个问题：AI 时代做系统，复杂度应该放在哪儿。

一、垃圾文档会精准投毒

王老师讲 RAG 的时候说了一句大白话，我印象很深：知识库问答做不好，先别急着调检索算法，回头看看库里都放了些什么。

这话值得展开。RAG 的流程是先检索、后生成，模型本身不判断检索结果的对错：检索到什么，它就顺着什么讲，还能讲得头头是道。库里要是有份过时的制度、一份新旧口径打架的规范、一份扫描得糊成一团的 PDF，它们不会安静躺着：总会在某次检索里被命中，然后被模型一本正经地引用出去。

所以垃圾文档的问题不是拉低平均分，是投毒：专挑你最需要正确答案的那次查询起作用。

这块我有体感。自己做知识库问答服务那阵子就发现，检索质量的上限由数据治理决定，换模型、调分块策略，都只是在脏数据上打转。对策也没什么玄技，全是纪律：入库要有门槛，来源、格式、时效过得去才放进来；过期文档定期下线，别想着"万一有用"；口径打架必须裁决一个，不能新旧都留着，让检索随机翻牌。

宁可库里 100 份干净的，不要 1000 份说不清的。

二、200 字的提示词，赢了 700 字的

活动下午组织了场游戏：写提示词，驱动模型打掼蛋。

结果有点反直觉。赢家的提示词普遍只有 100 到 200 字，说说目标、风格和几条底线就完了。写得最认真的一位，700 字左右的战术大全，拆牌逻辑、记牌策略、队友配合全写了，没赢。

为什么？我的理解是：现在的模型跟去年不是一回事了。掼蛋这种规则清晰的游戏，算牌、拆牌这些基本功模型自己就会，你再教一遍就是多余的。更糟的是，700 字里那些硬规则会互相打架，把模型天然的判断力框死了，等于在用去年的弱模型标准，调教今年的强模型。

掼蛋是游戏，但规律通用：提示词里最贵的成分不是技巧，是对模型的不信任。

我现在的做法是，每次换更强的模型，第一件事把存量提示词拿出来重测，逐条问"这条还需要吗"，先删后加。删完经常发现，效果反而更好。

三、不要相信用户的 query

这句还是王老师说的，观点很挑衅。

用户带着模糊的意图来，写出来的 query 往往不是他真正想问的：词不对，粒度不对，缺限定。传统做法是工程补救：建同义词库、写纠错规则、训意图分类器，一个 bad case 补一条规则。代码越垒越高，而且系统变聪明的速度，取决于工程师排期的速度。

现在更划算的做法：把 query 交给模型扩写。一句模糊的话，发散成好几路检索形态（同义改写、上位扩展、拆解子问题、补充限定词），并行去检索，召回合并之后再生成。

我觉得这里最值钱的不是扩写本身，是升级路径变了。以前系统变聪明靠写代码、发版本；现在扩写是模型做的，模型升级那天，你这套扩写自动跟着变好，一行代码不用改。写死的规则不会自己长大，模型驱动的能力会。

当然工程不是没事干了。评测集、兜底逻辑、召回质量的度量，这些还是工程的活，只是"理解用户"这类事的实现权交给了模型，验收的责任留给人。

连起来看

回来路上我把这三件事过了一遍，发现它们指向同一个选择：复杂度放在哪。

垃圾文档的对策，是把功夫下在数据治理上，不是算法缝补；掼蛋的输赢，说明模型自己会的东西别硬教，700 字不如 200 字；query 扩写说明，系统能力可以长在模型上，跟着模型自动升级。

我的结论：数据自己养好，理解和发散交给模型，代码只留它真正不可替代的那部分。模型接下来还会继续变强：把系统里会自己变强的部分交给模型，你的系统就免费跟着变强。

别把复杂度锁死在代码和长提示词里。这是我这个周末最大的收获。