同一个模型，两种结果
把同样一份需求交给同一个模型，一次给出清晰的三段式上下文，一次把十份文档一股脑塞进去，结果往往差得很远。很多人把这归结为「提示词玄学」，其实大部分差异来自上下文的结构，而不是措辞。
上下文工程要解决的问题很具体：在有限的窗口里，放进去的东西要能让模型知道目标、知道已确认的事实、知道边界，而不是让它从一堆材料里自己猜。
第一件事：把状态显式化
长任务里最常丢的不是知识，是状态。做过什么、否决了什么、还差什么，如果不写下来，模型每一轮都在重新推断。我的做法是把上下文切成四块，用固定的小标题隔开：
- 目标：一句话，验收标准写清楚；
- 已确认事实：只放验证过的，注明来源与时间；
- 待办：按依赖排序，一次只推进一项；
- 禁止项：不能碰的文件、不能用的库、不能改的行为。
这四块的顺序也有讲究：目标和禁止项放两端，中间放材料。模型对开头和结尾的注意力最强，中间那段最容易「看了但没记住」。
第二件事：检索要少而准
把整个代码库或整本手册塞进去，除了烧 token，还会稀释真正相关的信号。有效的做法是先粗排再精读：用关键词或向量召回 20 条，人工或轻量模型筛到 3 到 5 条，再完整读入。
一个常被忽略的细节是引用位置。把文件路径和行号写进上下文，模型在需要修改时才能准确定位；只给一段没有出处的代码，它很容易改错地方。
第三件事：工具输出要裁剪
工具返回的原始结果往往又长又吵：几百行日志里只有三行有用，JSON 里嵌套了十几层。直接把原始输出塞回上下文，是最常见的浪费。
稳妥的做法是在工具层做摘要：保留状态码、关键字段、错误栈的前若干行，其余丢弃；需要细节时再按需二次读取。这样既控制了长度，也保留了可追溯性。
第四件事：让失败可恢复
上下文里要留出「上一轮为什么失败」的位置。只说「再试一次」，模型大概率重复同样的错误；写上「上次失败是因为端口被占用，换 8080 之后仍报权限错误」，它才会换方向。
压缩历史时也要小心：把失败记录一起删掉，等于把教训也删了。
我的判断
上下文工程听起来像新概念，做的其实是老事情——把需求写清楚、把材料整理好、把状态记下来。区别只在于，以前这些是给人看的，现在要给一个不会追问、只会照做的读者看。
所以判断一段上下文好不好，有个很朴素的标准：换一个新人来看，他能不能只凭这段文字就接着干下去。能，模型大概率也能。
暂无评论内容