模型表现不稳，先排查上下文与验证流程

AI 把复杂问题讲得头头是道，却反复改不对一个小 bug，第一反应往往是换个更贵的模型。作者建议先查三件事：它拿到的信息对不对，工作过程是否合理，最后有没有验证结果。

这篇文章的价值，是把「AI 不够聪明」拆成了可以排查的工程问题。检索、上下文、推理预算、任务验收和记忆各管一段，模型升级只是其中一个选项。对日常用 AI 查文档、改代码、跑长任务的程序员，这套排查顺序比追模型榜单更容易落地。

答错之前，先看它到底读到了什么

接入知识库，不等于模型能找到答案。检索增强生成（RAG）的常见流程是：文档切块、向量化、存入数据库，提问时找出相关片段，再交给模型回答。问题经常出在「相关」上。

用户查错误码 TS-999，系统却召回了一堆通用排障文章。主题接近，具体答案没有。向量检索擅长找语义相似内容，但错误码、产品型号、API 名称还需要精确匹配。作者建议把语义检索和 BM25 关键词检索结合起来，合并、去重，再用重排序模型（reranker）挑选片段。

找到了那句话，也未必找到了完整证据。比如「这个版本不支持批量导入」，如果切块时丢掉产品名、版本和章节，模型就可能把旧版本限制套到当前产品上。给片段补充标题、版本、章节及必要上下文，解决的是「这句话究竟在说谁」。

原文引用 Anthropic 的实验：带上下文的分块结合混合检索和重排序，使 top-20 检索失败率从 5.7% 降到 1.9%。这是特定实验里的检索指标，不是作者团队的实测，也不等于最终回答错误率降到了 1.9%。

模型答错时，先检查实际送进上下文的材料。

正确文档根本没被召回，继续打磨提示词通常很难救回来。

长对话要留下进度，不要留下指令冲突

项目背景、报错日志、临时想法和废弃方案都塞在一个聊天窗口里，轮次越多，模型未必越懂项目。上周定了 A，昨天改成 B，今天又补了例外，历史消息就成了一份没有标注有效期的需求记录。

作者引用 Lost in the Middle 研究：在其测试的模型和任务上，关键信息放在长输入中间，效果常常不如放在开头或结尾。原文也明确限制了结论，不能直接推广到所有当前模型。能接收长输入，与能充分利用每一段输入，是两种能力。

上下文工程（context engineering）落到日常工作，就是决定「这一步需要看什么」。排查网站收录，先看 robots.txt、sitemap、页面响应和站长后台，需要时再读相关日志。没有必要一开始加载整个代码仓库和全部历史对话。

长任务中途则应留下交接记录：已经做了哪些决定，改过哪些文件，通过了哪些检查，还有什么没解决。它把当前状态从聊天记录里提炼出来，让后续工作有明确起点。

但压缩也有成本。验收条件、关键约束和未解决问题被删掉，后面仍会返工。好的交接记录需要保留影响下一步决策的信息，不能只剩一句「功能基本完成」。

多花推理预算，必须配一个判对错的方法

测试时计算（test-time compute）研究的是：模型回答时增加计算，能否改善结果。例如尝试多个方案后选择，或者生成答案，再根据反馈修改。

原文援引的研究表明，在特定任务和计算预算下，合理分配计算，可以让较小模型超过大得多的模型。这里有两个条件：候选方案怎么找，以及答案好坏怎么判。

生成五个方案，并不会自动得到一个可靠方案。代码要运行测试，计算结果要代回原题，事实主张要对照一手资料。反馈越具体，下一轮修正才越有方向。回答长一倍，不能证明推理质量更好。

而缺少事实时，增加推理预算也补不齐。当前价格、刚更新的 API 文档，应该先查资料。作者倾向于让整理、分类、抽取任务优先追求速度，把更多推理预算留给难题和重要代码修改，同时准备检查方法。

这也解释了作者为什么关注 agent harness，即围绕智能体安排的任务拆分、工具调用、进度保存和结果检查机制。

原文引用 Anthropic 在 2026 年 3 月描述的一项实验：把规划、生成和评估分开，生成者搭建应用，评估者操作运行中的页面、检查 API 和数据，再返回具体问题。一个游戏编辑器案例中，单智能体约运行 20 分钟、花费 9 美元；完整 harness 约运行六小时、花费 200 美元，结果更加完整。

但两者时间和预算相差太大，不能据此断言多智能体更划算。

更容易借鉴的是验收方式。发布博客时，上传接口返回成功还不够，还应确认页面能打开、正文完整、canonical URL 正确、语言链接指向对应版本。让模型「再检查一下」也不够，第二个模型同样可能宽松打分。

完成标准要落在测试、页面操作或真实数据上。

重试次数和花费也需要上限，否则一个小问题可能让系统循环一整晚。

记忆要分有效范围，项目状态要现场读取

作者希望助手记住写作风格，以及「公众号文章只放草稿箱」这样的长期偏好。但「这一篇先别发公众号」只约束当前任务，不能被记成以后都不处理公众号。

这类区别决定了记忆系统是否可靠。原文提到 Mem0 等研究探索从对话中提取、整合并检索重要信息，但真正棘手的是信息会变化，也会互相冲突。

因此，作者希望记忆除了内容，还携带来源、日期、适用范围，以及是否已被后续决定替代。这是作者提出的要求，原文没有给出一套已经验证的完整实现。

对程序员而言，另一个边界更实用：用户偏好可以记，项目状态应该检查。服务端口、依赖版本和部署情况，优先从当前环境读取。两周前的对话只能说明当时发生过什么。

作者也给微调划了范围：稳定、反复出现的分类需求、输出格式和领域任务，可以考虑微调；经常更新的材料交给检索，实时状态交给工具结果。先判断信息的性质，再决定把它放在哪里。

我的判断

我赞同这篇文章的排查顺序。它把「模型不行」拆成了材料没找到、要求没保住、推理出错、完成后没验收等不同故障。团队可以逐项定位，也更容易知道下一笔预算应该花在哪里。

但它是一套工程建议，不能当成效果承诺。检索数据来自被引用的实验，harness 案例没有等预算比较，长期记忆的元信息设计也主要是作者的主张。原文没有展示作者拿同一批任务，比较这些措施与直接升级模型的收益，因此不少取舍仍属于经验之谈。

常见替代做法，比如换强模型、开更长上下文、多加一个评审智能体，都可能有效。只是原文没有证明它们能解决所有问题，也没有证明流程改造始终更便宜。对一次性小任务，搭一套复杂流程可能得不偿失；对反复发生的失败，检索修复和明确验收才更值得投入。

能拿来做什么

• 收集二十到三十个真实失败任务，记录是资料缺失、要求遗忘、推理错误还是虚假完成。每次只改一两项，用同一批任务比较成功率、成本、等待时间和人工收尾量，并留出部分任务检验陌生问题。
• 用 AI 查前端或 Node 文档时，检查召回片段是否包含准确的 API 名、适用版本和章节。出现「主题相关但答非所问」，优先检查检索结果和精确匹配能力。
• 让 AI 接续长时间代码修改前，整理当前决定、变更文件、已通过检查和未解决问题；依赖版本、端口及运行状态则重新读取当前环境。
• 开始修改前写清可验证的完成条件，再设置重试和花费上限。重要页面要实际操作，涉及 API 和数据要检查结果，把发现的具体失败交回下一轮修复。