企业官网建设流程全解析

我见过的绝大多数工程问题，其实都不是模型能力不够，而是“喂给模型的东西压根没有认真设计过”。这句话，是我读完Google那篇70页上下文工程材料之后最大的感受。那篇材料在圈子里流传得很广，不少人第一时间点了收藏，但真能沉下心把70页翻完、再转化成自己项目里可用方法的，并不多。这篇文章就是我啃完它之后整理出的一套中文解读笔记，也是我给自己做中文PPT汇报时用的底稿。我会先讲清楚上下文工程到底在解决什么问题，再把它从定义、边界、工作流到落地陷阱逐层拆开，保证你就算没看过那70页，也能直接拿来用。

1. 这份材料出圈的背景：模型能力已经够用，拉开差距的是输入组织方式

1.1 上下文窗口越来越大，使用方式却还停留在“贴文档”

先聊一个很反直觉的现象。过去两年，各家模型的上下文窗口从几千token一路卷到128K、200K甚至1M级别。单看数字，你会觉得长文本处理早就不是问题了，但真正把长上下文丢给模型跑过的人都知道：窗口大了，不代表模型能把窗口里的内容都“看懂”，更不代表它会在需要的地方精准调用信息。

我在内部一个客服助手Demo里做过对比。同样一组用户问题，A方案把所有知识库文档按顺序拼接后塞进上下文，B方案把同样的内容分成“任务指令、核心规则、参考文档、示例、输出要求”几个区块，再调整了顺序。模型的参数、温度、采样方式完全一致，最终的准确率差了将近两成。A方案还经常出现一种让人哭笑不得的情况：用户的诉求明明写在第2000行，模型却只盯着第50行的历史对话回答，把中间的内容直接“遗忘”了。

这个现象，在材料里有个专门的说法，叫“Lost in the Middle”。注意力机制天然更关注序列开头和结尾的内容，中间部分即便信息量很大，也容易被模型忽略。上下文窗口变长之后，这个问题不仅没有被解决，反而被放大了——因为人们默认“窗口大了，塞得越多越好”，结果中间区域的信息密度越来越高，真正关键的指令反而被淹没。

1.2 提示工程解决“一条提示”，上下文工程解决“整个输入环境”

以前大家说优化提示词，通常只干一件事：把那条发给模型的prompt改得更好。比如加上“你是一个资深专家”、强调“分步骤回答”、给出几个示例。这套方法当然有用，但它的视野太窄了，它把模型输入看成一条孤立的文本，而没有意识到模型实际上收到的是一个完整的“输入环境”。

我理解的上下文工程，就是把这个输入环境当成一个可设计的对象来看待。要回答什么问题、给模型什么背景、从哪里检索资料、资料按什么顺序放、模型应该遵循哪些行为准则、输出格式怎么约束、甚至让模型在动手之前先输出哪些推理，这些都是可以在上下文层面控制的变量。那篇70页的材料，本质上就是把这些分散的经验统一成了一个体系，告诉大家：模型内部权重一旦固定，你在推理期唯一能大规模干预的，就是输入上下文。

很多团队明明用的是同一款模型，效果却天差地别，根子就在这里。有的团队把上下文工程当成核心研发环节，每一轮修改都有版本记录和评测数据；有的团队只是把文档一股脑丢进去，再祈祷模型“理解一下”。我一直觉得，用好大模型不是选模型的问题，而是组织输入的问题。

2. 上下文工程的定义与边界：它和RAG、微调、提示词到底什么关系

2.1 材料里反复强调的中心论点

那份70页材料里，给我印象最深的不是某个具体技巧，而是它对上下文工程的定义方式。把它翻译成大白话就是：通过设计、组织和编码送入模型上下文窗口的信息，引导模型高质量完成指定任务。关键词是“设计”和“编码”。

我之前习惯把提示工程、RAG、微调看成三座孤岛：调提示词是文本层面的事，RAG是检索管道的事，微调是训练流程的事。读完材料之后我才反应过来，这三座岛其实都围着同一个目标转——如何让模型在正确的上下文里做出正确的行为。提示词只是上下文工程中最表层的那一部分，RAG也只是上下文内容的一种来源管道而已。

这个认知变化很关键。它意味着你把“调prompt”这件事的优先级提得再高，也只是在修一处细节，而没有系统性地管理整个输入链路。上下文工程要做的，是把任务目标、背景信息、示例演示、工具说明、输出约束、推理策略打包成一套完整的上下文方案，并且像软件工程一样，对这套方案做版本管理、评测和迭代。

2.2 一张表看清四类技术的分工

为了在中文分享会上快速说清楚这件事，我画了张对比表，效果很好，也放在这里：

这张表最大的价值是帮团队统一语言。我以前经常遇到一种情况：业务方说“模型效果不好，要不微调一下”，但实际上问题出在知识库文档太乱、检索结果顺序不对，属于典型的上文工程问题，微调不仅贵，而且解决不了输入侧的结构问题。有了这张表，至少能先对齐一下“到底该动哪个层”。

2.3 上下文工程的四个可干预要素

材料里虽然没有用“四个要素”这种口诀式说法，但通读下来，我认为可以归纳成四类干预抓手：

第一，内容。上下文里出现哪些信息，信息来自哪里，是知识库检索、用户实时输入，还是历史会话摘要。这是最基础的抓手，也是RAG主要贡献的环节。

第二，结构。信息以什么顺序排列，哪些放开头、哪些放中间、哪些放结尾，用什么样的分层标题或XML标签分隔。结构决定了注意力分配。

第三，指令。系统提示、任务目标、行为边界。指令不只是在“告诉模型做什么”，更是在短时间内建立模型的行为基线。

第四，推理参数。温度、采样策略、以及“是否要求模型先输出推理过程”。很多人忽略这一点，但模型是在写之前先列计划，还是直接作答，结果往往差异巨大。

需要说明的是，这四项不是彼此独立的。你改了结构，可能就要同步调整指令；你增加了检索内容，可能就要重新设计指令来区分“哪些是参考资料，哪些是硬性规则”。上下文工程本身就是一门协调这些要素的手艺，这也是它跟单点调prompt最本质的区别。

3. 从70页中提取的五步工作流：把“设计上下文”变成可执行的日常动作

3.1 步骤一：先用评测标准反向定义“好上下文”

读那篇材料之前，我习惯拿到任务就开始拼上下文，拼完跑几个例子感觉“差不多”就收工。材料给了一个相反的建议：先定义评测标准，再开始设计输入。

我在做客服助手时就把这一步落到了实处。任务是用户解释了“误操作”场景后，模型给出补救步骤。我没有急着写系统提示，而是先跟业务方对齐了四条衡量标准：

• 正确引用率：模型给出的补救步骤，是否能在知识库文档中找到依据；
• 步骤可执行率：步骤是否具体到用户照做就能完成；
• 格式通过率：输出是否稳定符合预设的字段结构；
• 敏感场景拒绝率：涉及违规操作时，是否知道拒绝并引导人工客服。

这四条标准就是我在后续迭代里的“裁判”。没有这个裁判，你就会陷入一种很常见的幻觉：这版上下文改了之后，单看几个例子感觉更顺了，但说不清到底哪里提升了，下一轮又会犹豫要不要回滚。有了标准，每一次修改要么被数据支持，要么被数据否决，优化才变成一件可积累的事。

3.2 步骤二：把上下文拆成可复用的模块

材料里让人耳目一新的地方，是把上下文当成“组装”出来的产品，而不是“写”出来的文本。既然是组装，就得有零件。我在客服助手里把上下文拆成了六类模块：

• 任务定位块：说明这是一个什么场景、模型承担什么角色；
• 行为规范块：硬性规则，比如“不能编造政策”“优先引导用户走自助流程”；
• 参考知识块：来自知识库的检索结果，每段带来源标记；
• 少样本示例块：3到4组标准问答，覆盖典型场景和边界场景；
• 输出格式块：JSON结构说明，或者对回复字段顺序的硬约束；
• 推理引导块：要求模型先输出“当前用户诉求的识别结果”，再输出“处理步骤”。

把这些模块化的好处有两个。第一，维护成本变低。政策更新了，只需要替换参考知识块；示例效果不好，只动示例块，系统提示一行不用改。第二，便于做版本对比。我们可以像管理代码包一样管理这些上下文模块，每个版本改动了哪个模块，一目了然。

3.3 步骤三：按“上下文语法”组装，并刻意利用位置效应

组装顺序是回报率最高的环节，也是最容易被忽略的环节。我在帮团队梳理上下文结构时，总结出了一个相对稳定的组装顺序，实测下来效果比“按素材顺序平铺”明显更稳。

开头位置，放任务定位和行为规范。这是模型注意力最集中的区域，要用来建立“你要解决什么问题、按什么原则解决”的基线。中间位置，放参考知识块和少样本示例。对于不追求即时输出的长文档，还应该在中间段开头加一行摘要，防止模型读着读着丢了主线。结尾位置，放输出格式和推理引导。模型对结尾的注意力同样很高，这里放执行要求，能有效提升输出的规范度。

这里有个很关键的心理模型：模型阅读上下文的注意力曲线，跟你自己开会时的状态其实很像——开头大家都在认真听，到中间开始走神，临近结束又打起精神。给模型喂上下文，不能只考虑“信息在逻辑上该放哪”，还要考虑“信息在注意力上放哪”。

3.4 步骤四：像调超参一样单变量迭代

很多人都经历过这个场景：模型输出不理想，你同时加了示例、改了指令、调整了顺序、换了检索策略，一通操作猛如虎，效果确实变了，但完全说不清是哪个改动起了作用。等下次需要复用这套经验时，依然两眼一抹黑。

材料给的方法非常朴素：一次只改一个变量。我给自己定了一条纪律，每次迭代只改上下文六个模块中的一处，然后到评测集里跑一组完整结果，记下指标变化，再决定下一步动作。

这个过程听起来很简单，做起来却很考验耐心。有一次我在客服助手上连续做了六轮实验，前五轮的指标几乎都没变化，第六轮我只是把示例里的“订单修改”场景从2条加到3条，且换成了一条更真实的用户话术，正确引用率就提升了3个百分点。如果没有单变量实验的纪律，这个归因根本不可能成立，我大概率会误以为是之前某轮的系统提示改对了，然后在一堆无效变量上反复横跳。

3.5 从五步工作流到我日常使用的检查清单

我在日常工作中，把上面五步浓缩成了一张检查清单，每次设计新任务时照着走一遍：

• 任务要解决的业务问题是否清晰，评测指标是否定下来了；
• 上下文是否拆成了独立模块，每个模块是否有明确的维护责任人；
• 组装顺序是否符合注意力分布规律，关键指令是否放在了开头或结尾；
• 这次迭代只改一个变量，改前是否留下了旧版本；
• 是否跑了一组评测数据，而不是只看了两三个孤立的例子。

这张清单本身不惊人，但它是把70页材料转化为日常生产力的关键。理论看得再多，最后还是要落到每一次动手之前的两分钟自问。

4. 容易被翻页跳过的六个细节：每一处都直接影响输出效果

4.1 系统提示的真正作用，是覆盖模型默认行为

很多人写系统提示，写得像一段“礼貌的开场白”。材料里的观点完全不同：系统提示是模型在本次会话里的“新默认行为”。默认行为意味着，只要上下文里没有冲突信息，模型会优先按系统提示的方式行动。它不是在给你帮忙，而是在重新定义模型。

明白了这一点，你就会理解为什么系统提示里要用肯定的陈述句，而不是模棱两可的商量语气。比如“你是一个售后客服专家，必须基于知识库文档回答，禁止编造政策”，就比“如果你知道的话，请尽量回答用户的问题”有效得多。前者锚定了模型的行为基线，后者只是给模型留了一个自由发挥的后门。

4.2 示例的位置和复杂度，比示例数量更重要

少样本示例是调节模型行为最高性价比的手段。但你不需要很多示例——过犹不及。我在实践中的体会是：3到5个高质量示例，覆盖任务的关键边界情况，效果远好于堆10个示例，因为普通同质化的示例不仅占用窗口，还会稀释模型对重点示例的注意力。

更值得留意的，是示例的摆放位置。材料里以及我后续复测都指向同一个结论：示例紧贴着输入问题之前放，比放在整段上下文最开头效果更好。因为示例本质上是在告诉模型“接下来你要用这种格式、这种语气、这种深度来回答”，它离待处理的输入越近，这种“接下来”的指向就越强。

4.3 先列计划再回答，等于给模型分配“推理预算”

如果要我选一个“性价比最高的单项改动”，我会选这个：在输出格式约束里，要求模型在给出最终答案之前，先输出一段简短的推理或计划。

我在客服助手的上下文里加了一句结构化要求：先识别用户诉求的类别，再列出处理思路，最后输出给用户的回答。就这一步，格式通过率没有明显变化，但回答的合理性和严谨性提升了一大截。原因也不难理解：直接回答相当于让模型跳过思考直接开口，而先列计划相当于给模型分配了一笔“推理预算”，让高价值推理发生在最终决策之前。

需要提醒的是，这一步会显著增加输出token数和响应延迟。如果是实时对话场景，记得在推理预算的长度和延迟之间做权衡，比如把中间推理限制在50字以内。

4.4 输出格式本身，也是上下文的一部分

我在很多项目里见过这种场景：上下文里写满了业务知识，但模型返回的答案经常是纯文本大段话，下游程序解析费劲，只好靠正则硬抠。其实，把期望的JSON Schema直接写进上下文，本身就是一种上下文编码方式。

我推荐的写法不是在系统提示里说“请以JSON格式返回”，而是把完整的字段结构、类型、示例值一并给出，甚至顺带放一个最小的示例对象。模型对结构化的输入非常敏感，你把输出骨架定义得越清晰，它遵循得越好。这不需要任何工程魔法，只需要你在组装上下文时，愿意多花一分钟把输出格式写完整。

4.5 多模态场景下，文字与图片的相对位置

那篇材料还花了不少篇幅讨论多模态上下文。提炼出来，最核心的经验是：如果你希望模型关注某张图片，那么与这张图片相关的文字描述，应该放在图片之前，并且直接引用图中的某个具体元素，而不是放一个泛泛的“见下图”。

这个原则在处理产品截图、报表图、流程图的自动解读时尤其管用。我在一个图像处理Demo里测试过两种放法，一种是把图片放在段落最后，另一种是先用文字描述图像里的关键区域，再放图片，后者的信息利用率和回答准确度都明显更高。原因是图片在上下文编码时也会占据注意力资源，先立好文字锚点，再去读图，相当于给模型指了一条路。

4.6 上下文不是越多越好，要敢于做减法

材料里反复出现一个观念：上下文质量永远优先于数量。但在实际项目里，人人都喜欢做加法，很少有人主动删上下文。

我的建议是：每次评测结束后，做一次“上下文最小化实验”。把某个模块去掉或缩短，再看看评测指标是否有变化。如果指标没有下降，这段内容就不值得留在上下文里。这个实验我做过很多轮，几乎每次都能删掉10%到20%的内容，而效果不受影响，有时甚至会更好，因为模型终于可以把注意力放到真正重要的指令上了。省钱是一方面，让模型聚焦才是更重要的收获。

5. 我做中文PPT解读时的重组框架：不逐页翻译，按六部分重新讲

5.1 要先把PPT的目的定下来，再谈内容组织

标题说要整理70页材料的中文PPT解读，很多人第一反应是“逐页翻译”，这是我最不推荐的思路。纯翻译版中文PPT除了信息量大，没有任何记忆点。分享出去之后，听众只会觉得“讲了很多”，但留不下任何可操作的东西。

我给自己定的规则是：先问一个问题，这版PPT是给谁看、干什么用的。如果是给团队做技术分享，重点放在定义、工作流和落地陷阱；如果是给决策层做汇报，重点放在上下文工程的ROI和案例数据；如果是给自己做学习笔记，重点放在概念对照和原理推导。目的不同，重组方式完全不同。我下面给出的是技术分享版的结构。

5.2 适合中文技术分享的六部分结构

我做了几十页原材料的梳理之后，把它重组成了一份不到20页的中文PPT，结构如下：

第一部分，背景铺垫。讲上下文窗口变大但效果分化加剧，抛出“Lost in the Middle”现象，用两个对比案例说明问题。

第二部分，定义辨析。讲上下文工程的定义，并放出那张与RAG、微调、提示工程的对比表，让听众快速建立坐标系。

第三部分，五步工作流。这是整个PPT的主角，用每一步配一个小例子来讲。听众可以当场对号入座，想想自己之前的流程卡在哪一步。

第四部分，核心设计原则。把材料里的位置效应、系统提示、示例策略、推理预算等凝练成规则，做到“一页一条原则、每条配一个实例”。

第五部分，现场Demo或录屏回放。我倾向于用提前录制好的效果对比，因为现场实时跑模型存在随机性，容易翻车。录屏则可以展示同一输入在优化前与优化后的输出差异。

第六部分，落地清单。最后给出三件事：明天就能做的改动、两周内要建立的工作流、长期要积累的评测集和版本管理机制。

5.3 做中文PPT时容易踩的翻译与演示坑

翻译术语这件事，比想象中更容易翻车。上下文工程相关词汇在中文社区还没有完全统一，同一个英文术语有四五种译法。我在PPT里做了一个术语对照表，每次新词汇第一次出现都采用“中文（英文）”，后面再统一用中文，避免听众来来回回猜你讲的是什么。

还有一个实操层面的建议：PPT里放截图和演示结果时，一定要提前匿名化。我见过有人在分享会上直接投屏内部知识库截图，虽然没有明文规定说不能放，但这种细节很容易把听者的注意力带偏。提前把用户名、订单号、内部系统名打码，是基本的职业素养。

5.4 给听众的一句“带走版本”

我每次做分享收尾时，都会不留长篇总结，只给一句话：上下文工程不是新模型，也不是新框架，它只是把“输入”当成一个值得认真设计的产品来对待。

这句话听上去平平无奇，但我发现听众离开会场后，最能记住的反而是这句话。因为技术细节会被时间冲淡，但一个“把输入当成产品”的心智模型，会一直影响他们之后每次写系统提示、拼上下文、做检索排序时的决策方式。

6. 看完这70页后最容易走的弯路：三个落地陷阱与我的修正

6.1 陷阱一：把系统提示写成一本塞满一切的操作手册

我见过最典型的反面案例，是把系统提示当成一个无限容器。业务规则、话术模板、后台接口说明、失败兜底策略、合规要求全部堆进去，长度直逼两千字。这样做看起来“考虑周全”，实际上系统的注意力资源是有限的，你把不太重要的规则放在长篇大论的中后部，它根本不会被模型有效吸引，更糟糕的是还会掩盖真正置顶的任务定位。

我的修正做法是：系统提示里只放任务定位、硬性行为边界和输出框架，其他所有知识，全部拆到参考知识块和示例块里。用软件架构的话说，系统提示只做“接口定义”，不做“数据存储”。

6.2 陷阱二：上下文更新靠无限追加，而不是重写

另一个高频问题是长会话上下文越拖越长。每次用户输入，系统就往上下文里追加一段流水账，不加裁剪，不做摘要。结果模型被大量重复、过时的中间过程牵着走，延迟升高、费用上升、回答质量反而下降。

正确的做法是给会话做“滚动摘要”。每隔几轮，用模型或规则生成一段简短的历史摘要，替换掉原始对话。材料里虽然没有手把手教这个操作，但它反复强调的“上下文质量优先于数量”直接指向这个方向。我在客服场景里的经验是：历史摘要控制在200字以内，保留用户核心诉求和已经给出的承诺，其余细节一律清出窗口。

6.3 陷阱三：用一两个例子判断效果，然后就宣布成功

“这版看起来好多了”，这是工程师在不确定面前最危险的默认反应。单例观察会被太多偶然因素污染：模型采样随机性、用户话术恰好匹配示例、评测集过窄导致以偏概全。我把这条弯路归结为“用叙事替代了数据”。

现在我的做法是，任何一次上下文改动，必须有至少30条评测样本的跑分记录，而且每条样本跑2到3次，观察波动。阶段性的目标是看均值提升，更重要的是看方差是否收窄。模型输出的稳定性，在生产环境里往往比单次拔尖重要得多。

6.4 一些更实际的上路建议：把上下文版本管理建起来

说句实在话，我在刚读完那篇材料时也有点不知从何下手。后来真正让这套方法论落地生根的，不是记住了多少概念，而是建立了一个最朴素的机制：为每一次上下文变更打版本号。

我给客服助手的上下文模块建了一个简单的目录，每次改动都记录三件事：改了哪个模块、改动的动机是什么、评测前后的指标变化是多少。这个档案维护了三周之后，团队里任何一个人都能回答“当前线上环境跑的是哪版上下文，上一版为什么被回滚”，这种确定性对生产项目来说太重要了。

我在实际运行这套机制时还发现了一个额外收获：当你必须为每次修改写“改动动机”时，你会在动手前多思考一轮，很多头脑发热的乱改直接就被拦在门外了。这个机制不是70页材料里专门讲的，但如果非要说我读完它之后最值得的决定，我会把这一条排在前三。上下文工程最终沉淀下来的，是一套让输入持续进化的习惯，而不是某一次完美的配置。