想让 AI 更聪明，先别急着换模型

用 AI 最让人头疼的，是你摸不准它什么时候靠谱。

复杂问题讲得头头是道，一个小改动却能反复出错。资料已经给了，它还是漏看；代码说修好了，一运行，问题还在。

碰到这种情况，很容易觉得：模型不够强，换个更贵的吧。

换模型当然可能有用。但我更愿意先看看，它拿到的资料对不对，做事的过程有没有问题，以及最后到底靠什么判断自己做对了。

这几处没弄好，更强的模型也可能在同一个地方栽跟头。

资料明明在，为什么它就是找不到？

给 AI 接知识库，现在已经不稀奇了。把文档切块，转成向量，存进数据库，提问时找几段相关内容，再让模型回答。这就是常说的 RAG，检索增强生成。

流程看着挺顺，问题经常出在“找几段相关内容”这一步。

比如你问一个具体的错误码 TS-999，系统找回来的却是几篇通用故障排查。内容确实相关，但关键答案没找到。

向量检索擅长理解意思，错误码、产品型号、接口名称这些东西，还得靠精确匹配。所以我会优先考虑把语义检索和 BM25 关键词检索一起用，结果合并去重，再用 Reranker 重排序，挑出真正有用的片段。

还有一种更隐蔽的问题：文档切碎之后，意思也跟着丢了。

假设检索出来一句：“该版本不支持批量导入。”

哪个产品？哪个版本？已经淘汰的旧版本，还是现在正在用的版本？少了这些背景，AI 很容易张冠李戴。

给片段补上标题、版本、所属章节和必要的上下文，会更有帮助。Anthropic 做过相关实验，结合分块上下文、混合检索和重排序后，前 20 条结果的检索失败率从 5.7% 降到了 1.9%。

这不是说照着做，所有知识库都能得到同样的提升。但它提醒了我一件事：回答不对的时候，先看看 AI 到底拿到了什么资料。

资料没找对，后面再怎么打磨提示词，也很难救回来。

聊得越久，它不一定越懂你

很多人的习惯是，有什么都往同一个对话里放。项目背景、报错日志、临时想法、旧方案，几十轮下来，感觉 AI 应该越来越了解自己。

但里面也可能已经混进了一堆互相打架的信息。

上周说用 A，昨天改成 B；前面讨论过一个方向，后面已经放弃了。人回头看都得捋一遍，模型也一样。

早期的《Lost in the Middle》研究发现，在它测试的模型和任务中，关键信息放在长文本中间，表现往往比放在开头或结尾差。这不能直接套到今天所有模型身上，但“能接收很长的文本”和“能把每一处都用好”，确实是两回事。

所以，上下文工程听起来挺技术，落到实际工作里，其实就是认真整理：这一步到底需要让 AI 看见什么。

排查网站收录，就先看 robots.txt、Sitemap、页面状态和站长后台。查到哪一步需要日志，再读对应日志。没必要开局就把整个网站源码和全部聊天记录塞进去。

长任务做到一半，也可以留一份交接：哪些决定已经定了，改了哪些文件，什么检查通过了，还有哪些问题没解决。

我宁愿它带着一份准确的进度继续干，也不希望它抱着几十万字历史记录猜我们现在要干什么。

当然，压缩也不能只追求短。关键限制被压没了，后面一样要返工。

让它“多想一会儿”，钱花得值不值？

推理时计算，英文叫 Test-time Compute，研究的就是模型在回答问题时，怎样通过更多计算改善结果。

比如多尝试几个解法，再筛选；或者先生成答案，根据反馈继续修正。

相关研究表明，在特定任务和计算预算下，合理安排这些计算，可以让较小的模型超过大得多的模型。但这里有个很重要的前提：怎么试，怎么判断，都会影响结果。

我觉得最容易踩的坑，是把“多想”和“多说”混在一起。

答案长了一倍，不代表问题解决得更好。生成五个方案，也得有办法挑出靠谱的那个。

写代码可以运行测试，算数可以代回去验证，查事实可以对照原始资料。这些反馈，才让下一轮尝试有了依据。

如果缺的是最新价格、刚更新的接口说明，那就先去查。模型再认真，也不能靠推理补出一个它没拿到的事实。

我的预算会这么安排：整理、分类、提取信息，先求快；复杂推理、关键代码修改，再增加推理时间，并准备好检查办法。

值得花的钱，是能减少错误和返工的钱。

别光让 AI 干活，还得让它碰到真实结果

我比较关注 Agent Harness 这个方向。可以把它理解成，给模型配上一套干活的安排：任务怎么拆、工具怎么用、进度怎么留、结果怎么检查。

Anthropic 在 2026 年 3 月介绍过一个实验，把规划、生成和评估分开。生成环节做应用，评估环节去操作真实页面，检查接口和数据，发现问题后再交回去修改。

这里有个很值得看的细节：成本。

其中一个游戏编辑器案例，单 Agent 跑了约 20 分钟，花了 9 美元；完整流程跑了约 6 小时，花了 200 美元。后者做得更充分，也贵了很多。

所以我不会看到效果好，就立刻得出“多开几个 Agent 更划算”的结论。它们投入的时间和预算，本来就差得很远。

真正值得借鉴的是：先讲清楚什么算完成，做完以后去检查，不通过就带着具体问题回来改。

比如发布一篇博客，不能只看上传接口有没有返回成功。页面能不能打开，正文有没有漏，canonical 对不对，各语言链接有没有串，这些都应该实际核对。

检查也不能完全交给一句“你再看看有没有问题”。模型评价自己的成果，有时候会太宽松；换一个模型来评，也不保证立刻变严格。

验收标准得具体，最好能被测试、页面操作或者真实数据验证。同时设好重试次数和预算，别为了一个小问题循环到天亮。

记忆越多，就越懂你吗？

我不希望每次写文章，都重新解释一遍自己的口吻。也不希望每次同步公众号，都提醒它只放草稿箱。

这些长期要求，值得记住。

但“这次先别发公众号”，显然只管当前任务。系统得分得清适用范围，不能从此把所有公众号任务都停掉。

Mem0 等研究在做的，就是从对话里提取重要信息，再整合、检索。真正麻烦的地方，是信息会变，也会冲突。

所以我觉得，一条记忆除了内容，最好还带着来源、时间、适用范围，以及有没有被后来的决定替代。

用户偏好可以记，项目的实时状态还是要查。服务器端口、依赖版本、线上部署情况，能读当前环境，就别拿半个月前的聊天记录当依据。

至于微调，我会留给那些相对稳定、重复出现的需求，比如固定分类、输出格式和特定领域任务。经常变动的资料交给检索，实时状态交给工具读取，各有各的用处。

真要动手，我会从失败的任务开始

这些技术都有用，但没必要一次装齐。

我会先留二三十个真实任务，记下 AI 是怎么失败的。

资料找不到，就改检索；聊到后面忘要求，就整理上下文和交接；知道事实却推理出错，再考虑更强的模型或更多推理预算；总说完成、实际没做完，就补上验证。

每次只改一两处，再拿同一批任务比较：成功率有没有提高，花了多少钱，等了多久，还要人工收拾多少。

另外留一些没参与调试的任务，看看换个问题还管不管用。否则提示词越改越漂亮，可能只是把那几道题练熟了。

我对“AI 更聪明”的期待挺实际：以前要解释五遍，现在两遍能接住；以前说做完了，我还得重新检查一轮，现在它能带着验证结果交回来。

模型升级值得关注。但在等下一代模型之前，这些地方就已经有不少活可以干。

参考资料：