去年年底老周带了 6 个人给一家区域物流公司做客服异常处理助手。客户把三样东西甩过来近 90 天运单轨迹、客服工单、还有一本 120 页的异常处理手册。现场演示很漂亮——模型能把「签收后破损」「超时未更新」「地址改派」对上条款。一上线就翻车手册整本塞进去窗口直接爆砍掉历史轨迹二次改派又漏判。群里改三天提示词线上窗口策略又漂回去。隔壁老吴路过说了一句别再拿聊天记录当上下文策略把窗口预算、装填顺序、压缩规则和位置锚定写进 SPEC。这就是 2026 被反复提起的上下文工程Context Engineering。提示词工程管的是「怎么说」上下文工程管的是「这一轮到底给模型看什么」。窗口就那么大塞多了模型迷路塞少了条款对不上。可以把它想成给值班员发一份当班资料袋封面是岗位和红线中间是本班必看的运单和条款封底是输出格式资料袋超重就先摘要旧班记录而不是把整本手册复印进去。它和 RAG 不是一回事。RAG 解决的是「从哪找」上下文工程解决的是「找来之后怎么排、排多少、排在哪」。检索召回十条条款不等于这十条都该进窗口历史二十轮工单也不等于每一轮原文都该留下。谁先谁后、谁留谁压本身就是一份要版本化的资产。上下文工程落地核心是四件套。窗口预算。系统角色、红线、本轮证据、历史对话、工具返回每一项都要占 token。不设预算手册一贴就截断预算写死成「最多 8K」也不行短工单浪费、长工单又裁掉关键条款。预算要按任务类型拆而不是拍一个整数。分层装填。先放角色和红线再放本轮运单与命中条款最后放输出 schema。历史客服记录只能以摘要进场工具原始 JSON 要先裁字段。谁先谁后比再写一句「请认真阅读」有用得多。压缩与摘要。超窗口不是把尾巴砍掉那么简单。旧轮次按「结论未闭环项」压缩手册按条款号检索后再贴原文轨迹只保留状态跳变点。压缩本身也要有规则否则摘要把「二次改派已同意」弄丢模型就会重复开通工单。位置锚定。长上下文有中间丢失关键红线放在开头和结尾各一份证据放中段输出格式贴在最后。同一条「禁止编造运单状态」放在中间和放在首尾服从度差一截。为什么 2026 必须认真对待交付已经从能聊变成能办——异常处理要对照手册条款给出动作不是陪客户聊天。同一套口头装填规则在 Qwen、DeepSeek、Kimi 上窗口服从度差很多。上下文策略是最便宜也最容易漂的资产写在群公告里换一个人、换一个模型就没了。私有化场景最吃这一套运单和地址出不了内网本地客户端一升级窗口策略就丢。落地常见三道门槛。环境不稳本地 IDE 和各人笔记本的上下文截断策略对不齐演示能过、现场窗口长度对不上。模型不灵一套装填顺序只在某一个基座上好看换模型就 lost in the middle。规则易飘预算和压缩口径写在群里加班一晚又改回「把手册全贴进去」。MonkeyCode 适合把这件事跑通。浏览器打开就能用免安装每个任务自带云端环境不用在自己电脑上对齐截断和编码。GLM、Kimi、MiniMax、Qwen、DeepSeek 可以按任务一键切换同一套 SPEC 交叉验证。需求和 SPEC 管理能把角色、窗口预算、装填顺序、压缩规则、输出 schema 固化下来而不是散落在聊天记录。完全开源也支持私有化运单和地址可以不出内网。我们按三步做。第一步新建任务。主实验用 Qwen对照用 DeepSeek再加一条 Kimi 短上下文基线专门看「手册全贴」和「按条款检索再贴」的差别。第二步把规则写进 SPEC。角色等于物流异常处理助手。红线是不编造运单状态、不确定就升级人工、地址与电话脱敏。窗口预算按块切系统加红线 1.5K本轮证据 4K历史摘要 1K输出预留 1K。装填顺序是角色红线再到本轮运单与命中条款再到历史摘要最后是输出格式。压缩规则是旧工单只保留结论和未闭环项轨迹只留状态跳变。输出只要异常类型、命中条款号、动作清单、是否升级思维链不对用户展示。第三步用同一批 20 条真实异常工单对比。手册全贴导致截断 11 次降到 0漏判二次改派 6 次降到 0把手机号写进回复 4 次降到 0。短上下文基线在「条款检索后再贴」之后准确率和主实验持平窗口占用少一半。四点建议。先拿一个小任务试点别一上来就灌整本手册。规则写进 SPEC窗口预算和装填顺序跟代码一起版本化。多模型交叉验证别只信一个基座的窗口感觉。敏感数据能私有化就私有化运单和地址不必上公网。上下文工程不是把提示词写得更长是决定这一轮模型究竟看见什么。窗口会满记忆会漂规则会丢。把预算、顺序、压缩和锚定写进 SPEC再放到云端环境里用多个模型对着跑比在群里改三天聊天记录靠谱得多。