这两年我面试过不少自称提示词专家的候选人发现一个很有意思的现象2023年还能靠几套花式提问模板惊艳全场的人到2025年已经很难打出差异化了。不是他们不努力而是这行的水位整体抬高了——模型越来越听话现成的提示词模板随手就是一大把连不写代码的运营同学都能用内置工具调出不错的效果。真正把差距拉开的反而是那些不太聊咒语、一开口就是你这套系统上下文是怎么组织的的人。这类人正在变成一种新角色提示工程架构师。往小了说他们负责决定一次AI交互里模型到底该看到哪些信息往大了说他们管理的是整个AI应用的认知入口——所有进到模型视野里的文字、图片、表格、历史记录都由他们设计、调度、度量。这篇文章基于我自己在真实项目里的观察和复盘拆解未来一段时间内这个岗位最值得投入的6个能力升级方向也聊聊哪些能力正在贬值哪些能力会越来越值钱。无论你刚入行、正在负责AI应用落地还是已经带团队这篇都应该能给你一些坐标系。1. 先聊一个扎心的事实提示词写得好正在变得越来越不值钱1.1 从怎么写指令到怎么安排信息这一行发生了什么我先说结论提示词本身没有死但靠提示词建立的门槛正在崩塌。现在随便一个AI应用配置界面里都有现成的角色设定、输出格式、示例管理很多模型本身对指令的遵从能力也比两年前强了不止一个档次。换句话说把话说清楚已经从一种稀缺技能变成了一种基础素质。那稀缺的是什么是信息安排的能力。同一个模型你给它一段孤零零的问题和给它一套精心组织过的背景材料、约束条件、历史决策记录两者的回答质量可以差出好几个量级。我见过太多这样的团队Prompt写得倒挺漂亮但压根没想清楚模型需要什么信息才能答好——该给的背景不给不该给的噪声全塞进去结果就是模型一本正经地胡说八道团队还以为是模型不行。这就是上下文工程登场的背景。如果提示词解决的是怎么问上下文工程解决的就是让模型在什么信息环境里作答。前者是单点的、局部的后者是系统的、全局的。1.2 为什么说上下文工程是提示工程的下一站业界对上下文工程这个词还没有绝对统一的定义但大家公认的核心是围绕一次或一系列AI调用对输入信息进行全生命周期的设计与管理。它包括选什么信息进上下文、信息以什么形态组织、信息的先后顺序、信息的时效与回收、信息的使用成本以及多轮、多智能体之间怎么共享这些信息。我用一个生活类比来解释提示词是你向一位顾问提了一个好问题上下文工程是你为这位顾问准备了完整的项目资料包。资料包里有什么、按什么顺序排放、哪些涉密信息要抽掉、过期的数据有没有标注这些直接决定了顾问给出的建议靠不靠谱。只有问题没有资料顾问就只能给你一套正确的废话。所以我的判断是未来两年AI应用团队里真正稀缺的岗位画像从会写提示词的人转向会架构上下文的人。提示工程架构师这个名字会越来越常被提起而且它的能力要求远不止写Prompt。2. 上下文工程的能力坐标系六个方向从哪来2.1 提示工程与上下文工程的分水岭把两者放到一张表里对比会更直观维度提示工程上下文工程关注对象指令文本本身模型可见的全部信息作用范围单次对话、单条消息会话全周期、多系统协同核心问题怎么说模型才懂给什么模型才答得准信息形态文本为主文本、图片、表格、代码、历史记录混合主要手段角色设定、示例、格式约束信息选取、剪裁、检索、缓存、度量失败代价一次回答质量下降系统性成本上升、行为漂移、维护灾难顺着这个分水岭往下走上下文工程要求的能力其实可以归纳成一个四象限信息资源侧喂什么、信息维护侧怎么管、信息协同侧怎么传、信息度量侧凭什么。每个象限再拆细就得到了前面提到的六个方向。2.2 面对同一个问题两种工程师的思考路径差异我举个实际例子。某电商客服系统遇到了用户问退款到账时间模型回答不准确的问题。提示工程师的第一反应是改指令你告诉他你是客服专家请基于退款流程回答。改了之后有一定效果但遇到复杂的售后单子还是翻车。换成做上下文工程的同事他的排查路径完全不一样他会先去看模型在回答时到底看到了什么。结果发现上下文里塞了整段原始聊天记录用户真正关心的退款单状态字段反倒不在里面系统里明明有退款进度接口压根没把结果组装进上下文。他做的事情是重新设计上下文结构——把用户画像、订单状态、退款流程摘要、最近几轮对话按优先级组装好再交给模型。问题很快就解决了而且没有靠任何花哨的提问技巧。这就是两者最大的区别提示工程解决表达上下文工程解决信息供给而后者才是决定AI应用效果上限的地方。2.3 六个方向的能力地图基于上面的逻辑我把未来提示工程架构师要升级的六个方向定义为上下文预算管理你给模型的每一段信息都在花钱。多模态上下文编排文本之外还有图像、表格、代码片段。上下文生命周期与状态管理上下文不是一次性的它是会过期、会失效、需要回收的。可观测性与评估体系搭建看不见上下文就谈不上优化。跨智能体上下文协调多智能体协作时信息不能各自为政。成本与价值建模上下文工程的每一笔投入都要算得清ROI。接下来我用三章分别展开每一章里都放具体的实操案例和踩坑记录。3. 方向一与方向二把给模型喂什么变成一门精确的手艺3.1 上下文预算管理不是所有信息都该进模型视野先做一个简单的思想实验。假设你要给一位业务副总裁汇报项目你手上有一份200页的文档。你会把200页全塞给他让他自己找重点吗大概率不会。你会做一页摘要把关键数据、风险、需要的决策单独拎出来再告诉他完整版可以随时查阅。给模型喂上下文本质是同一件事。很多团队在这件事上的做法恰恰相反。他们觉得上下文窗口越来越大反正塞得下就什么都往里放——完整聊天记录、全套知识库文档、十几个示例全部堆进去。结果往往是模型被无关信息带偏丢失关键信息而且每次调用的成本直线上升。上下文预算管理要练的是几个基本功对token有体感。中文字大概一个汉字折1到1.5个token英文一个词约0.75个token不同模型的分词器有差异。你要能做到看一眼内容大致估算出它的token量级误差不超过30%。这不是为了炫技是为了做预算决策。对信息分层。我把上下文里的信息分成三层核心层直接决定这次回答对错的信息、参考层可能用到的背景知识、环境层系统身份、格式约定、全局规则。三层按优先级分配预算核心层给足参考层要克制环境层做压缩。动态裁剪。多轮对话场景里历史是越长越好吗实测下来不是。通常最近3到5轮完整保留更早的历史做成摘要再早的沉淀到向量库里按需检索。这就是滑动窗口摘要沉淀检索召回的组合拳。我见过做得最漂亮的案例是一个售后工单系统。原来每次调用把整串工单流转记录平均4000多token全部塞进上下文模型经常被中间某条异常备注带偏。后来他们把上下文改成工单最新状态卡片200 token 最近3条关键流转记录300 token 用户情绪摘要80 token 全局规则300 token总共不到1000 token。回答准确率从81%涨到92%单次调用成本降了一大截。3.2 多模态上下文的编排让模型看图有看图的章法现在的商用模型普遍支持图片、表格、代码等多种输入形态这对上下文工程提出了新要求你不只要决定放什么文本还要决定放什么图、怎么放。这里有几个实战经验。第一图片要裁剪而不是整张丢。我做过发票识别类项目直接把整张发票图片丢给模型识别率一塌糊涂——背景噪声、无关印章、水印都会干扰。把关键区域发票号码、金额、税号先裁剪出来再配合对应的文本提示准确率可以提升10个百分点以上。第二表格要按需转换。结构规整的数据表喂Markdown或CSV格式通常比喂图片效果好。但要警惕超长表格超过模型有效注意范围的表格建议先做列裁剪或转成摘要统计。第三图文顺序有讲究。通常先给结论性文本再给支撑性图片比先图后文更容易让模型抓住重点。这个方向的核心能力是你要能判断同一条信息用哪种模态表达最省token、最不容易失真并能设计出图和文彼此印证的上下文结构。未来车载、安防、医疗影像、工业质检这类场景多模态上下文编排能力会直接变成业务指标的胜负手。3.3 实操案例一次完整的上下文瘦身过程我拿一个真实的问答系统优化过程来说明全流程这套方法可以直接复用到你自己的项目里。某团队做了一个内部知识库问答机器人最初的上下文结构非常简单用户问题 向量检索返回的Top 5文档片段文档片段经常是整段整段的长文本最长的有2000多token。症状是回答覆盖面广但深度不够引用细节经常对不上。我们做了三件事。第一把检索片段做段落级重排而不是把整篇文档丢回去。知识库文档先按子章节切开向量化时保留标题层级信息检索命中后只返回最相关的2到3个段落每段控制在300 token以内。第二在上下文里新增答案框架区——预先告诉模型回答时要包含依据、结论、操作建议三个部分让生成结构更稳定。第三加了不知道边界的约束指令检索结果实在不相关的时候允许说不知道。一轮改造下来上下文从平均4000多token降到1500 token左右人工抽检的准确率从78%提升到89%且回答明显更聚焦。这个案例里没有任何一步是高深的算法全是信息选取与组织的功夫——这就是上下文预算管理的日常。4. 方向三与方向四让上下文从一次性输入变成可维护的资产4.1 上下文生命周期管理上下文是会过期、会失效、需要回收的很多人把上下文当成每次请求现拼的字符串用完即弃。这在单次问答场景勉强够用但一旦进入多轮对话、长期智能体、企业级应用就完全不够了。上下文是有生命周期的创建、加载、使用、刷新、失效、回收。缺了哪个环节系统都会出问题。举几个真实的坑。第一个坑是上下文污染某个AI助手里上一轮对话里用户提到过想取消订阅系统把它一直保留在上下文里后面用户问帮我推荐一个套餐模型就被带偏成您是想取消订阅吗。解决这个问题的办法是给上下文分临时区和持久区临时区每一轮滚动更新持久区里才放用户长期属性。第二个坑是上下文过期知识库文档更新了但模型还在用旧版本回答。这不是模型笨是上下文缓存没设失效时间。第三个坑是上下文爆炸不考虑回收多轮只增不减最终每个请求都要处理超长上下文延迟和成本双双失控。这个方向上的进阶技能包括理解KV Cache这类机制对重复上下文的作用会设计语义缓存会为不同会话类型设计不同的上下文回收策略。把上下文当成有生命的资产去维护而不是当成一次性耗材。4.2 可观测性设计看不见上下文就谈不上优化我最初做上下文工程时最痛苦的体验是改了一版上下文结构上线后感觉效果好了一些但说不清到底哪里变好了、为什么变好。后来才明白这是典型的上下文黑箱问题——你根本不知道模型实际注意到了哪部分信息。可观测性设计要做三件事。第一日志要覆盖全链路上下文。每次请求实际发给模型的完整内容按区块记录token数和内容hash缓存是否命中检索命中的是哪几条文档模型对每个区块的注意力分布如果接口支持。没有这些数据后续所有优化都是拍脑袋。第二搭建离线的评测集。收集50到200条有标准答案的测试问题每次改动上下文结构后跑一遍评测集对比指标变化用数据说话而不是靠感觉。第三做线上A/B对比。同一问题一组用旧上下文一组用新上下文比较回答准确率、用户反馈率、单次调用成本。这里我整理了一个简单的上下文质量体检表供你在评估时参考维度体检问题不合格的信号相关性上下文每段信息与本次任务有关吗超过30%的信息与当前问题无关冗余度有没有重复或可压缩的内容同一事实在不同区块重复出现时效性信息是否仍然有效存在超过有效期仍未更新的数据一致性区块之间有没有互相矛盾系统规则与参考层内容冲突成本效率token花费是否换来回答质量成本上升但质量指标没有变化这套表格听起来简单真正坚持用的团队不多。原因是可观测性建设前期投入大、见效慢但它恰恰是上下文工程从手工作坊走向工程化的分水岭。4.3 评估体系怎么落地从直觉判断到量化指标再展开讲一下评估。很多团队评估AI应用只靠抽几个人工看几眼这在Demo阶段没问题进入生产就危险了——你无法判断一次上下文改动到底改善还是破坏了什么。我推荐建立一个三层指标集。第一层是任务效果指标比如回答准确率、信息检索召回率、推荐采纳率这些直接对应业务目标。第二层是上下文效率指标包括单次请求的输入token数、缓存命中率、上下文压缩率、修订率用户主动说不对的比例。第三层是系统成本指标包括单次请求成本、端到端延迟、失败重试率。三个层次综合看才能判断一个上下文方案到底值不值。举个例子。某搜索增强问答系统我们比较了两种上下文组织方式。方案甲是把检索到的全部文档按得分倒序拼接方案乙是只保留命中信息最密集的前两段。评测集跑下来甲乙的回答准确率几乎一样但方案乙的输入token只有方案甲的四分之一单次成本只有三分之一端到端延迟还低了30%。没有评估体系你只会觉得方案甲效果应该更好但数据清晰地告诉你多喂的信息大部分是噪声还花了冤枉钱。这就是量化评估的力量。5. 方向五与方向六跨系统与跨成本的架构视野5.1 跨智能体上下文协调别让每个Agent各说各话这两年多智能体架构越来越多一个规划智能体、几个执行智能体、一个聚合智能体。每一层都需要上下文但上下文绝不能各自为政。我见过一个典型的失败案例某售后系统里客服智能体、质检智能体和知识库智能体各自维护一份用户记忆结果客服说用户是已补偿客户质检那边还记着待安抚两边互相矛盾解决方案自然一塌糊涂。跨智能体的上下文协调要解决三个问题全局目标怎么贯穿。整个任务的最终目标、用户的核心诉求应该作为任务上下文在智能体之间透明传递不能被某个中间环节改写或丢失。局部视图怎么裁剪。执行智能体不需要知道全局所有细节它只需要做好自己的局部任务。比如质检智能体只需要看到客服回复内容和质检规则不需要用户完整的财务信息。裁剪不到位一来浪费token二来可能造成隐私风险。共享记忆怎么设计。多个智能体之间要有一层共享的事实库比如工单状态、用户关键属性、历史决策记录每个智能体在决定自己行为前都先查这层事实库而不是各自维护一套记忆。这个方向的能力本质是信息架构甚至可以说它更像是企业架构师在AI场景下的投影。未来凡是做复杂自动化、多角色协作的应用跨智能体上下文协调能力会越来越值钱。5.2 成本与价值建模上下文工程的ROI意识上下文工程做的每一个决策都在花钱这笔账不能不算。先来一个非常简单的算术假设你的应用每天有100万次请求每次请求的上下文从4000 token降到1500 token输入token单价按比较常见的商用模型价格估算每百万token大约几十元一天就能省下上千元的模型调用成本一年就是几十万。这还没算延迟降低带来的用户流失减少。上下文预算管理不只是一个技术问题它是一个实打实的成本问题。成本与价值建模能力具体体现在三个方面。第一会算账。给你一个上下文结构你能立刻折算成每次调用的token成本和对应的延迟预估给你一个业务目标你能倒推上下文预算上限。第二会做权衡。某些场景里多一点上下文确实能提升效果你需要在效果增量和成本增量之间找到平衡点。第三会向上沟通。业务方说为什么这个AI方案这么贵时你能把成本结构拆给他们看哪部分是上下文开销、哪部分是模型能力限制、哪部分可以通过上下文优化省下来。这套能力在技术团队里特别稀缺。大部分工程师习惯从能不能实现看问题很少从值不值得实现的角度做决策。而提示工程架构师恰恰需要同时掌握技术视角和商业视角。5.3 用数据说服业务方一次真实的多模态方案论证讲一个我经历过的场景。某团队想在一个图像质检场景里引入多模态方案让模型直接看产线照片来做缺陷分类。业务方觉得太贵不肯批预算。团队没有硬推而是做了两件事一是建立了一个300张图片的评测集把纯文本描述方案和图像文本上下文方案跑了一遍结果显示图像方案在特定缺陷类型上的准确率高12个百分点二是做了成本测算图像方案单次调用多花0.02元但误判减少能节省大量人工复核成本综合算下来ROI是正的。数据一摆业务方立刻点头。这个案例其实点明了成本与价值建模的核心不是让上下文方案越便宜越好而是让每一分成本都有业务价值背书。这就回到了那句话——架构师不能只懂技术还得能算账、会说话。6. 落地路线图从今天的岗位开始一步一步向架构师靠拢6.1 三个成长阶段如果你希望向提示工程架构师方向靠拢我建议把成长路径拆成三个阶段。阶段一熟练诊断自己产品的上下文。拿到任何一个 AI 功能能画出它的上下文结构图——模型到底看到了哪些信息、从哪里来、什么时候更新、哪些是冗余的。这一步最难的是建立上下文视角一旦建立起来后面很多能力都能自然生长。阶段二能改、能测、能算账。掌握上下文压缩、缓存、检索替换这些常规手段并能为每次改动配备评估指标和成本核算。到这个阶段你已经不是一个只写提示词的人了你在优化一个系统的信息供应链。阶段三能带团队做体系化设计。面向复杂的业务流程设计多智能体之间的上下文规范、建立可观测性设施、形成团队的上下文设计与评审SOP。这个阶段对标的已经是架构师的职责。到这一步你会发现自己跟提示词专家的差异已经大到没法用几句话概括。6.2 日常可以做的几个训练方法我是靠这几个小习惯保持手感你也可以试一下。第一每周挑一次真实的失败回复反向拆解它应该看到什么。问自己如果我是模型在现有上下文里我看到的信息有没有误导我缺了什么关键信息才答成这样这种反向拆解比正向写提示词更能训练上下文敏感度。第二把写过的长提示词重构为标准四段式背景、目标、约束、示例。这个方法看似普通但它强制你区分环境信息和核心信息是成本预算管理的基本功。第三给每个上下文文件配一份维护说明哪里更新、什么时候失效、谁负责修改。很多团队上下文质量下滑不是因为设计得不好而是改着改着就乱了。维护说明是一点微小的纪律但对长期可维护性影响巨大。第四建立自己的小评测集。不需要很庞大50条能代表典型任务的问答题就够了。每次调整上下文结构之后跑一遍哪怕只有50条也比拍脑袋判断靠谱得多。6.3 我踩过的坑希望你绕开最后分享几个我实打实踩过的坑。第一个坑追求全都要。早期我以为上下文给得越全越好恨不得把知识库每个角落都搬进去。结果模型被大量低价值信息稀释了注意力关键数据反而答不准。后来才明白上下文工程的核心不是加信息而是做减法。第二个坑把长上下文模型当万能胶。某段时间特别依赖大窗口模型什么问题都靠全文输入解决。结果成本失控而且因为上下文里什么都有一点模型行为变得极不稳定。长窗口是工具不是免死金牌上下文预算管理在这个前提下反而更重要。第三个坑忘了给缓存加版本号。改了一版系统提示词但缓存键里没带版本信息导致部分用户还在命中旧版本的缓存结果。这个问题的可怕之处在于它是慢性污染——你以为新方案已经生效其实数据里混着大量的旧逻辑。后来我给所有缓存设计强制带上上下文版本号字段才算根治。第四个坑过度依赖模型自我报告。早期我很喜欢问模型你刚才注意到了哪些信息让它自己总结。后来发现模型的自我报告非常不可靠它会脑补一个合理的解释。从那以后我所有上下文分析都以日志和实际数据为准模型的话只当参考。这些坑的共同特点是它们都不是模型不够聪明造成的而是上下文管理本身的工程缺陷。这也是为什么我一直强调提示工程架构师的核心竞争力在于对上下文生命周期的系统性掌控——它是工程不是咒语。 
长河君 · 2026/10/18 5:28:51 · 阅读 1.2k 上下文工程将是提示工程的下一站：拆解提示工程架构师六大能力方向
这两年我面试过不少自称提示词专家的候选人发现一个很有意思的现象2023年还能靠几套花式提问模板惊艳全场的人到2025年已经很难打出差异化了。不是他们不努力而是这行的水位整体抬高了——模型越来越听话现成的提示词模板随手就是一大把连不写代码的运营同学都能用内置工具调出不错的效果。真正把差距拉开的反而是那些不太聊咒语、一开口就是你这套系统上下文是怎么组织的的人。这类人正在变成一种新角色提示工程架构师。往小了说他们负责决定一次AI交互里模型到底该看到哪些信息往大了说他们管理的是整个AI应用的认知入口——所有进到模型视野里的文字、图片、表格、历史记录都由他们设计、调度、度量。这篇文章基于我自己在真实项目里的观察和复盘拆解未来一段时间内这个岗位最值得投入的6个能力升级方向也聊聊哪些能力正在贬值哪些能力会越来越值钱。无论你刚入行、正在负责AI应用落地还是已经带团队这篇都应该能给你一些坐标系。1. 先聊一个扎心的事实提示词写得好正在变得越来越不值钱1.1 从怎么写指令到怎么安排信息这一行发生了什么我先说结论提示词本身没有死但靠提示词建立的门槛正在崩塌。现在随便一个AI应用配置界面里都有现成的角色设定、输出格式、示例管理很多模型本身对指令的遵从能力也比两年前强了不止一个档次。换句话说把话说清楚已经从一种稀缺技能变成了一种基础素质。那稀缺的是什么是信息安排的能力。同一个模型你给它一段孤零零的问题和给它一套精心组织过的背景材料、约束条件、历史决策记录两者的回答质量可以差出好几个量级。我见过太多这样的团队Prompt写得倒挺漂亮但压根没想清楚模型需要什么信息才能答好——该给的背景不给不该给的噪声全塞进去结果就是模型一本正经地胡说八道团队还以为是模型不行。这就是上下文工程登场的背景。如果提示词解决的是怎么问上下文工程解决的就是让模型在什么信息环境里作答。前者是单点的、局部的后者是系统的、全局的。1.2 为什么说上下文工程是提示工程的下一站业界对上下文工程这个词还没有绝对统一的定义但大家公认的核心是围绕一次或一系列AI调用对输入信息进行全生命周期的设计与管理。它包括选什么信息进上下文、信息以什么形态组织、信息的先后顺序、信息的时效与回收、信息的使用成本以及多轮、多智能体之间怎么共享这些信息。我用一个生活类比来解释提示词是你向一位顾问提了一个好问题上下文工程是你为这位顾问准备了完整的项目资料包。资料包里有什么、按什么顺序排放、哪些涉密信息要抽掉、过期的数据有没有标注这些直接决定了顾问给出的建议靠不靠谱。只有问题没有资料顾问就只能给你一套正确的废话。所以我的判断是未来两年AI应用团队里真正稀缺的岗位画像从会写提示词的人转向会架构上下文的人。提示工程架构师这个名字会越来越常被提起而且它的能力要求远不止写Prompt。2. 上下文工程的能力坐标系六个方向从哪来2.1 提示工程与上下文工程的分水岭把两者放到一张表里对比会更直观维度提示工程上下文工程关注对象指令文本本身模型可见的全部信息作用范围单次对话、单条消息会话全周期、多系统协同核心问题怎么说模型才懂给什么模型才答得准信息形态文本为主文本、图片、表格、代码、历史记录混合主要手段角色设定、示例、格式约束信息选取、剪裁、检索、缓存、度量失败代价一次回答质量下降系统性成本上升、行为漂移、维护灾难顺着这个分水岭往下走上下文工程要求的能力其实可以归纳成一个四象限信息资源侧喂什么、信息维护侧怎么管、信息协同侧怎么传、信息度量侧凭什么。每个象限再拆细就得到了前面提到的六个方向。2.2 面对同一个问题两种工程师的思考路径差异我举个实际例子。某电商客服系统遇到了用户问退款到账时间模型回答不准确的问题。提示工程师的第一反应是改指令你告诉他你是客服专家请基于退款流程回答。改了之后有一定效果但遇到复杂的售后单子还是翻车。换成做上下文工程的同事他的排查路径完全不一样他会先去看模型在回答时到底看到了什么。结果发现上下文里塞了整段原始聊天记录用户真正关心的退款单状态字段反倒不在里面系统里明明有退款进度接口压根没把结果组装进上下文。他做的事情是重新设计上下文结构——把用户画像、订单状态、退款流程摘要、最近几轮对话按优先级组装好再交给模型。问题很快就解决了而且没有靠任何花哨的提问技巧。这就是两者最大的区别提示工程解决表达上下文工程解决信息供给而后者才是决定AI应用效果上限的地方。2.3 六个方向的能力地图基于上面的逻辑我把未来提示工程架构师要升级的六个方向定义为上下文预算管理你给模型的每一段信息都在花钱。多模态上下文编排文本之外还有图像、表格、代码片段。上下文生命周期与状态管理上下文不是一次性的它是会过期、会失效、需要回收的。可观测性与评估体系搭建看不见上下文就谈不上优化。跨智能体上下文协调多智能体协作时信息不能各自为政。成本与价值建模上下文工程的每一笔投入都要算得清ROI。接下来我用三章分别展开每一章里都放具体的实操案例和踩坑记录。3. 方向一与方向二把给模型喂什么变成一门精确的手艺3.1 上下文预算管理不是所有信息都该进模型视野先做一个简单的思想实验。假设你要给一位业务副总裁汇报项目你手上有一份200页的文档。你会把200页全塞给他让他自己找重点吗大概率不会。你会做一页摘要把关键数据、风险、需要的决策单独拎出来再告诉他完整版可以随时查阅。给模型喂上下文本质是同一件事。很多团队在这件事上的做法恰恰相反。他们觉得上下文窗口越来越大反正塞得下就什么都往里放——完整聊天记录、全套知识库文档、十几个示例全部堆进去。结果往往是模型被无关信息带偏丢失关键信息而且每次调用的成本直线上升。上下文预算管理要练的是几个基本功对token有体感。中文字大概一个汉字折1到1.5个token英文一个词约0.75个token不同模型的分词器有差异。你要能做到看一眼内容大致估算出它的token量级误差不超过30%。这不是为了炫技是为了做预算决策。对信息分层。我把上下文里的信息分成三层核心层直接决定这次回答对错的信息、参考层可能用到的背景知识、环境层系统身份、格式约定、全局规则。三层按优先级分配预算核心层给足参考层要克制环境层做压缩。动态裁剪。多轮对话场景里历史是越长越好吗实测下来不是。通常最近3到5轮完整保留更早的历史做成摘要再早的沉淀到向量库里按需检索。这就是滑动窗口摘要沉淀检索召回的组合拳。我见过做得最漂亮的案例是一个售后工单系统。原来每次调用把整串工单流转记录平均4000多token全部塞进上下文模型经常被中间某条异常备注带偏。后来他们把上下文改成工单最新状态卡片200 token 最近3条关键流转记录300 token 用户情绪摘要80 token 全局规则300 token总共不到1000 token。回答准确率从81%涨到92%单次调用成本降了一大截。3.2 多模态上下文的编排让模型看图有看图的章法现在的商用模型普遍支持图片、表格、代码等多种输入形态这对上下文工程提出了新要求你不只要决定放什么文本还要决定放什么图、怎么放。这里有几个实战经验。第一图片要裁剪而不是整张丢。我做过发票识别类项目直接把整张发票图片丢给模型识别率一塌糊涂——背景噪声、无关印章、水印都会干扰。把关键区域发票号码、金额、税号先裁剪出来再配合对应的文本提示准确率可以提升10个百分点以上。第二表格要按需转换。结构规整的数据表喂Markdown或CSV格式通常比喂图片效果好。但要警惕超长表格超过模型有效注意范围的表格建议先做列裁剪或转成摘要统计。第三图文顺序有讲究。通常先给结论性文本再给支撑性图片比先图后文更容易让模型抓住重点。这个方向的核心能力是你要能判断同一条信息用哪种模态表达最省token、最不容易失真并能设计出图和文彼此印证的上下文结构。未来车载、安防、医疗影像、工业质检这类场景多模态上下文编排能力会直接变成业务指标的胜负手。3.3 实操案例一次完整的上下文瘦身过程我拿一个真实的问答系统优化过程来说明全流程这套方法可以直接复用到你自己的项目里。某团队做了一个内部知识库问答机器人最初的上下文结构非常简单用户问题 向量检索返回的Top 5文档片段文档片段经常是整段整段的长文本最长的有2000多token。症状是回答覆盖面广但深度不够引用细节经常对不上。我们做了三件事。第一把检索片段做段落级重排而不是把整篇文档丢回去。知识库文档先按子章节切开向量化时保留标题层级信息检索命中后只返回最相关的2到3个段落每段控制在300 token以内。第二在上下文里新增答案框架区——预先告诉模型回答时要包含依据、结论、操作建议三个部分让生成结构更稳定。第三加了不知道边界的约束指令检索结果实在不相关的时候允许说不知道。一轮改造下来上下文从平均4000多token降到1500 token左右人工抽检的准确率从78%提升到89%且回答明显更聚焦。这个案例里没有任何一步是高深的算法全是信息选取与组织的功夫——这就是上下文预算管理的日常。4. 方向三与方向四让上下文从一次性输入变成可维护的资产4.1 上下文生命周期管理上下文是会过期、会失效、需要回收的很多人把上下文当成每次请求现拼的字符串用完即弃。这在单次问答场景勉强够用但一旦进入多轮对话、长期智能体、企业级应用就完全不够了。上下文是有生命周期的创建、加载、使用、刷新、失效、回收。缺了哪个环节系统都会出问题。举几个真实的坑。第一个坑是上下文污染某个AI助手里上一轮对话里用户提到过想取消订阅系统把它一直保留在上下文里后面用户问帮我推荐一个套餐模型就被带偏成您是想取消订阅吗。解决这个问题的办法是给上下文分临时区和持久区临时区每一轮滚动更新持久区里才放用户长期属性。第二个坑是上下文过期知识库文档更新了但模型还在用旧版本回答。这不是模型笨是上下文缓存没设失效时间。第三个坑是上下文爆炸不考虑回收多轮只增不减最终每个请求都要处理超长上下文延迟和成本双双失控。这个方向上的进阶技能包括理解KV Cache这类机制对重复上下文的作用会设计语义缓存会为不同会话类型设计不同的上下文回收策略。把上下文当成有生命的资产去维护而不是当成一次性耗材。4.2 可观测性设计看不见上下文就谈不上优化我最初做上下文工程时最痛苦的体验是改了一版上下文结构上线后感觉效果好了一些但说不清到底哪里变好了、为什么变好。后来才明白这是典型的上下文黑箱问题——你根本不知道模型实际注意到了哪部分信息。可观测性设计要做三件事。第一日志要覆盖全链路上下文。每次请求实际发给模型的完整内容按区块记录token数和内容hash缓存是否命中检索命中的是哪几条文档模型对每个区块的注意力分布如果接口支持。没有这些数据后续所有优化都是拍脑袋。第二搭建离线的评测集。收集50到200条有标准答案的测试问题每次改动上下文结构后跑一遍评测集对比指标变化用数据说话而不是靠感觉。第三做线上A/B对比。同一问题一组用旧上下文一组用新上下文比较回答准确率、用户反馈率、单次调用成本。这里我整理了一个简单的上下文质量体检表供你在评估时参考维度体检问题不合格的信号相关性上下文每段信息与本次任务有关吗超过30%的信息与当前问题无关冗余度有没有重复或可压缩的内容同一事实在不同区块重复出现时效性信息是否仍然有效存在超过有效期仍未更新的数据一致性区块之间有没有互相矛盾系统规则与参考层内容冲突成本效率token花费是否换来回答质量成本上升但质量指标没有变化这套表格听起来简单真正坚持用的团队不多。原因是可观测性建设前期投入大、见效慢但它恰恰是上下文工程从手工作坊走向工程化的分水岭。4.3 评估体系怎么落地从直觉判断到量化指标再展开讲一下评估。很多团队评估AI应用只靠抽几个人工看几眼这在Demo阶段没问题进入生产就危险了——你无法判断一次上下文改动到底改善还是破坏了什么。我推荐建立一个三层指标集。第一层是任务效果指标比如回答准确率、信息检索召回率、推荐采纳率这些直接对应业务目标。第二层是上下文效率指标包括单次请求的输入token数、缓存命中率、上下文压缩率、修订率用户主动说不对的比例。第三层是系统成本指标包括单次请求成本、端到端延迟、失败重试率。三个层次综合看才能判断一个上下文方案到底值不值。举个例子。某搜索增强问答系统我们比较了两种上下文组织方式。方案甲是把检索到的全部文档按得分倒序拼接方案乙是只保留命中信息最密集的前两段。评测集跑下来甲乙的回答准确率几乎一样但方案乙的输入token只有方案甲的四分之一单次成本只有三分之一端到端延迟还低了30%。没有评估体系你只会觉得方案甲效果应该更好但数据清晰地告诉你多喂的信息大部分是噪声还花了冤枉钱。这就是量化评估的力量。5. 方向五与方向六跨系统与跨成本的架构视野5.1 跨智能体上下文协调别让每个Agent各说各话这两年多智能体架构越来越多一个规划智能体、几个执行智能体、一个聚合智能体。每一层都需要上下文但上下文绝不能各自为政。我见过一个典型的失败案例某售后系统里客服智能体、质检智能体和知识库智能体各自维护一份用户记忆结果客服说用户是已补偿客户质检那边还记着待安抚两边互相矛盾解决方案自然一塌糊涂。跨智能体的上下文协调要解决三个问题全局目标怎么贯穿。整个任务的最终目标、用户的核心诉求应该作为任务上下文在智能体之间透明传递不能被某个中间环节改写或丢失。局部视图怎么裁剪。执行智能体不需要知道全局所有细节它只需要做好自己的局部任务。比如质检智能体只需要看到客服回复内容和质检规则不需要用户完整的财务信息。裁剪不到位一来浪费token二来可能造成隐私风险。共享记忆怎么设计。多个智能体之间要有一层共享的事实库比如工单状态、用户关键属性、历史决策记录每个智能体在决定自己行为前都先查这层事实库而不是各自维护一套记忆。这个方向的能力本质是信息架构甚至可以说它更像是企业架构师在AI场景下的投影。未来凡是做复杂自动化、多角色协作的应用跨智能体上下文协调能力会越来越值钱。5.2 成本与价值建模上下文工程的ROI意识上下文工程做的每一个决策都在花钱这笔账不能不算。先来一个非常简单的算术假设你的应用每天有100万次请求每次请求的上下文从4000 token降到1500 token输入token单价按比较常见的商用模型价格估算每百万token大约几十元一天就能省下上千元的模型调用成本一年就是几十万。这还没算延迟降低带来的用户流失减少。上下文预算管理不只是一个技术问题它是一个实打实的成本问题。成本与价值建模能力具体体现在三个方面。第一会算账。给你一个上下文结构你能立刻折算成每次调用的token成本和对应的延迟预估给你一个业务目标你能倒推上下文预算上限。第二会做权衡。某些场景里多一点上下文确实能提升效果你需要在效果增量和成本增量之间找到平衡点。第三会向上沟通。业务方说为什么这个AI方案这么贵时你能把成本结构拆给他们看哪部分是上下文开销、哪部分是模型能力限制、哪部分可以通过上下文优化省下来。这套能力在技术团队里特别稀缺。大部分工程师习惯从能不能实现看问题很少从值不值得实现的角度做决策。而提示工程架构师恰恰需要同时掌握技术视角和商业视角。5.3 用数据说服业务方一次真实的多模态方案论证讲一个我经历过的场景。某团队想在一个图像质检场景里引入多模态方案让模型直接看产线照片来做缺陷分类。业务方觉得太贵不肯批预算。团队没有硬推而是做了两件事一是建立了一个300张图片的评测集把纯文本描述方案和图像文本上下文方案跑了一遍结果显示图像方案在特定缺陷类型上的准确率高12个百分点二是做了成本测算图像方案单次调用多花0.02元但误判减少能节省大量人工复核成本综合算下来ROI是正的。数据一摆业务方立刻点头。这个案例其实点明了成本与价值建模的核心不是让上下文方案越便宜越好而是让每一分成本都有业务价值背书。这就回到了那句话——架构师不能只懂技术还得能算账、会说话。6. 落地路线图从今天的岗位开始一步一步向架构师靠拢6.1 三个成长阶段如果你希望向提示工程架构师方向靠拢我建议把成长路径拆成三个阶段。阶段一熟练诊断自己产品的上下文。拿到任何一个 AI 功能能画出它的上下文结构图——模型到底看到了哪些信息、从哪里来、什么时候更新、哪些是冗余的。这一步最难的是建立上下文视角一旦建立起来后面很多能力都能自然生长。阶段二能改、能测、能算账。掌握上下文压缩、缓存、检索替换这些常规手段并能为每次改动配备评估指标和成本核算。到这个阶段你已经不是一个只写提示词的人了你在优化一个系统的信息供应链。阶段三能带团队做体系化设计。面向复杂的业务流程设计多智能体之间的上下文规范、建立可观测性设施、形成团队的上下文设计与评审SOP。这个阶段对标的已经是架构师的职责。到这一步你会发现自己跟提示词专家的差异已经大到没法用几句话概括。6.2 日常可以做的几个训练方法我是靠这几个小习惯保持手感你也可以试一下。第一每周挑一次真实的失败回复反向拆解它应该看到什么。问自己如果我是模型在现有上下文里我看到的信息有没有误导我缺了什么关键信息才答成这样这种反向拆解比正向写提示词更能训练上下文敏感度。第二把写过的长提示词重构为标准四段式背景、目标、约束、示例。这个方法看似普通但它强制你区分环境信息和核心信息是成本预算管理的基本功。第三给每个上下文文件配一份维护说明哪里更新、什么时候失效、谁负责修改。很多团队上下文质量下滑不是因为设计得不好而是改着改着就乱了。维护说明是一点微小的纪律但对长期可维护性影响巨大。第四建立自己的小评测集。不需要很庞大50条能代表典型任务的问答题就够了。每次调整上下文结构之后跑一遍哪怕只有50条也比拍脑袋判断靠谱得多。6.3 我踩过的坑希望你绕开最后分享几个我实打实踩过的坑。第一个坑追求全都要。早期我以为上下文给得越全越好恨不得把知识库每个角落都搬进去。结果模型被大量低价值信息稀释了注意力关键数据反而答不准。后来才明白上下文工程的核心不是加信息而是做减法。第二个坑把长上下文模型当万能胶。某段时间特别依赖大窗口模型什么问题都靠全文输入解决。结果成本失控而且因为上下文里什么都有一点模型行为变得极不稳定。长窗口是工具不是免死金牌上下文预算管理在这个前提下反而更重要。第三个坑忘了给缓存加版本号。改了一版系统提示词但缓存键里没带版本信息导致部分用户还在命中旧版本的缓存结果。这个问题的可怕之处在于它是慢性污染——你以为新方案已经生效其实数据里混着大量的旧逻辑。后来我给所有缓存设计强制带上上下文版本号字段才算根治。第四个坑过度依赖模型自我报告。早期我很喜欢问模型你刚才注意到了哪些信息让它自己总结。后来发现模型的自我报告非常不可靠它会脑补一个合理的解释。从那以后我所有上下文分析都以日志和实际数据为准模型的话只当参考。这些坑的共同特点是它们都不是模型不够聪明造成的而是上下文管理本身的工程缺陷。这也是为什么我一直强调提示工程架构师的核心竞争力在于对上下文生命周期的系统性掌控——它是工程不是咒语。