企业官网建设流程全解析

同样一个模型，在不同人手里产出的质量能差出好几倍。有人把它用成一个记忆力差但悟性高的实习生，有人却能靠它稳定交付一整条复杂任务线。差别基本不在模型本身，而在你给它看什么、按什么顺序看、怎么组织这些内容——这个从“怎么把一句话写清楚”升级到“怎么设计模型看到的整个信息环境”的过程，就是 Context Engineering，中文我习惯叫“上下文工程”。

我最早意识到这值得当成一套系统方法论来做，是在一个 AI 小说创作项目上。写了十几章之后，角色性格开始飘，世界观前后对不上，不是模型不行，而是每一轮输入给我拼得乱七八糟：人物设定放在中途、历史原文堆了一大坨、关键伏笔根本提都没提。后来我引入结构化上下文，又加了 evaluation 智能体来做回归评估，才慢慢梳理出一套可复用的工程方法。今天这篇就把这套方法论完整拆开，从原理到落地，该给参数给参数，该给模板给模板，适合正在做 LLM 应用、智能体、AI 内容工具，或者单纯想把 AI 写作质量做稳的人。

1. Context Engineering 到底在解决什么问题

1.1 从提示词工程到上下文工程，变化在哪

提示词工程解决的是“当前这句话怎么说清楚”。你精心措辞、加例子、指定格式，让模型在这一轮回答里更听话。但真实项目很少有单轮对话，更多是长流程、多轮交互、大量背景知识注入：系统指令、历史记录、检索结果、上一轮输出、用户当前输入，全都被拼在一起喂给模型。这时候，单独优化“这一句话”已经不够了，模型真正依据的是它看到的所有输入组成的整体环境。

上下文工程就是往前多走一层：把模型能看到的全部内容当成一个系统来设计。它管的是“哪些信息进来、以什么形式进来、按什么顺序排列、哪些该重复、哪些该省略、什么时候压缩、什么时候丢弃”。这就像给员工布置任务——任务说得再清楚，如果工位上堆满无关资料、键盘上贴着过期备忘，他也做不好。上下文工程，本质上是给模型整理工位。

1.2 三个核心管理对象：输入、结构、循环

我习惯把上下文工程拆成三个对象来管。

第一是输入源。系统指令、用户输入、工具返回、检索片段、示例样本，每个来源都要明确身份：它是规则、是事实、是风格参考，还是待回答的问题。身份不清，模型就容易把背景当指令，把示例当事实。

第二是结构。同一份信息，平铺成长文本、拆成带标签的模块、压成 JSON、配上 few-shot 示例，模型的“理解成本”完全不同。结构决定注意力分配：开头信息权重高，结尾信息权重高，中间一段最容易成为盲区。

第三是循环。多轮对话里，上一轮输出会成为下一轮输入的一部分。如果不做管理，要么上下文被历史记录撑爆，要么模型越聊越脱离核心设定。循环管的是记忆的取舍——留什么、丢什么、怎么压缩。

这三个对象对应三类决策：放不放、怎么放、放多久。后面所有方法，基本都在解决这三类问题。

1.3 一个类比：把模型当临时入职的新员工

我常跟团队讲，别把模型当成“懂一切的助手”，当成“一个临时入职的新员工”更合适。他有不错的底子，但每次对话都是“当天入职”，没有长期记忆；注意力有限，你说在最后的话他记得最清楚，说在最前面的话其次，中间一大段最容易漏；他不带评判地接活，给多少信息办多少事。

所以你要给他准备的不只是一句清晰指令，而是一套工作环境：岗位职责手册（系统指令）、今日任务清单（当前目标）、参考样例（few-shot 示例）、已办记录（历史摘要/近期原文）、可查工具书（检索上下文）。想清楚每份材料的用途和摆放位置，上下文质量自然稳定。

2. 四阶段实施框架：盘点、设计、构建、验证

这套框架我把一路的实践经验收拢成了四个阶段，不复杂，但每一步都有讲究。

2.1 盘点：目标、约束、上下文预算

动手写任何提示词之前，先做三张清单。

目标是定义“什么才算成功产出”。是让模型写一章小说、抽取结构化信息、做一个分类决策，还是做一轮客服问答？定义越具体，后面所有信息都为这个目标服务。

约束是“绝对不做什么”。不要输出血腥细节、不要超出格式、不要泄露系统指令。约束要具体，且给正向替代品。光写“不要啰嗦”没用，写“每段不超过四句话，每句不超过40字”才有效。

预算是可用上下文窗口的计算。拿常见 128K 窗口举例，很多人以为 128K 全都能用来堆输入，其实要留出输出空间。我建议输入总量控制在窗口的 70% 以内，再留 20% 给输出，剩下 10% 做缓冲。模型在临近上限时，注意力分配会明显退化，这不是猜测，是在长上下文测试里反复出现过的情况。

2.2 设计：按“首因—近因”效应布局信息

心理学里的首因效应和近因效应，在 LLM 上同样存在：模型对开头和结尾的信息权重最高，中间容易被稀释。根据这个规律，信息布局优先级大致是：

• 开头：系统级指令、核心目标、最高优先级约束；
• 尾部：当前用户输入、本轮必须执行的要求、收尾强调的规则；
• 中间：知识资料、补充背景、示例。

我早期踩过一个坑：把世界观背景全铺在最前面一大段，结果模型对后面的“本章收束”执行得异常到位，却把前面角色设定给看漏了。后来把世界观拆成“核心设定”和“扩展设定”，核心设定放开头常驻，扩展设定按章节按需注入，问题立刻缓解。

2.3 构建：模板化、动态组装、版本管理

到构建阶段，准则就一句话：不要用纯手工拼长提示词，一定要模板化、代码化。

我现在常用的组装顺序例举如下：

1. 系统指令区：固定模板，定义角色、任务、规则、输出格式；
2. 全局上下文区：人物卡、状态表、核心世界观、关键清单，带版本号；
3. 任务背景区：当前章节细纲、当前需求描述、外部检索结果；
4. 示例区：按需放 1～3 个高质量 few-shot，控制数量避免占用预算；
5. 历史区：滚动摘要在前，最近一到两轮原文在后；
6. 当前输入区：用户原始输入或本轮明确要执行的动作。

模板化的直接好处是能 A/B 测试。改某一个区域，跑一组评估样例，看分数变化，用数据决定改还是不改。而不是靠“这次感觉不错”来拍板。

2.4 验证：把 evaluation 智能体变成方法论内建环节

“看起来不错”不是验收标准。模型输出有随机性，同一套上下文不同时间跑，结果可能差很多。要系统验证上下文设计，最实用的做法是引入 evaluation 智能体。

具体是：准备 12～20 个固定测试样例，喂给被测系统，拿到输出；然后把“输出 + 评分标准”一起发给评估智能体，让它按维度打分，比如任务完成度、信息一致性、格式符合度、风格匹配度，每个维度 1～5 分并附理由。这样你改完上下文，能立刻看到量化对比，而不是靠感觉。

有人觉得这就是自动化测试。对，本质一样，只是被测对象从代码变成了上下文，断言从 true/false 变成了分级评分。正因生成有随机性，才更需要这种可重复、可回归的机制。把 evaluation 智能体当作上下文工程流程的内建环节，而不是事后补测，整条链路才算闭合。

3. 实操：AI 小说创作与通用任务里的落地细节

3.1 角色一致性不靠模型自觉，靠上下文结构

AI 小说创作是我见过最能体现上下文工程价值的场景之一。短篇还好，长篇小说动辄几十章，角色一致性、世界观一致、伏笔回收全都会出问题。这些问题在工程上几乎都是同一件事：上下文管理失败。

举例，你要模型写第 12 章，只丢给它“上一章原文 + 继续写”，它角色写飘了很正常。但解决方案不是把整本小说都塞进上下文——窗口塞不下，也没必要。正确做法是按模块管理：

• 固定区：人物卡（姓名、性格标签、当前目标、说话风格）、世界观核心设定、文风指南；
• 动态区：前情滚动摘要、当前未回收伏笔清单、本章细纲；
• 近因区：最近 1～2 章原文，保证文风语气衔接；
• 当前区：本章具体要求，比如“要以第二幕视角写，表现主角的犹豫”。

这样每轮上下文可能只有五六千 token，但效果比塞入十章原文更稳。因为模型开头读到了“该角色冷静理性”，结尾读到了“本章需要犹豫”，中间有原文兜底，三个信息源共同作用，角色表现才稳定一致。

3.2 工程级 AI 小说方法论：章节级上下文管理

把这套做法再工程化一层，我是这样管理长篇小说项目的：

角色状态表：记录每个主要角色当前的定位、情绪、目标、与其他角色的关系变化。每章结束由模型或人工更新一次，相当于游戏存档。写新章节时注入最新状态表，角色就不会“失忆”或“性格漂移”。

剧情追踪表：主线、支线、已埋伏笔、已回收伏笔，用结构化清单维护。写每一章前只注入“当前需要响应的伏笔”，不用把整部小说的伏笔网都塞进去。

滚动摘要链：第 N 章的摘要由“第 N-1 章原文 + 旧摘要”共同压缩生成，保留关键事件、人物状态、情绪变化，丢弃无关日常描写。这样做保证几十章后依然记得开头埋的线。

写作规则库：高频约束写进系统区，比如“不要剧透”“每章不超过 2000 字”“不得重复形容词”；临时约束放当前区，比如“本章要埋一个关于旧怀表的伏笔”。

这套方案解决的核心矛盾，是长故事的全局一致性和上下文窗口有限之间的冲突。全局信息用结构化摘要和状态表大幅度压缩，局部信息保留原文确保文风连续，两头兼顾。

3.3 通用参数参考：上下文预算分配

这套东西不止小说能用，所有 LLM 应用都适用。下面是我常用的输入预算表，单位是 token，按 128K 窗口举例：

信息优先级也可以按“规则 > 目标 > 已确认事实 > 示例 > 扩展背景 > 寒暄”来排。一旦 token 不够，砍的顺序和这个相反：先砍寒暄，再砍扩展背景，再砍示例。结构化的核心规则永远保留。

4. 常见问题排查：上下文失效的根因与对策

4.1 症状—根因速查表

长期做 LLM 应用的人，多半都遇过下面这些症状。我整理了一张排查表，按“症状→根因→对策”的顺序走：

这张表不是万能药，但它能给排查一个起点。我在实际项目里，80% 的问题都逃不出这几类。

4.2 三个容易被忽略的隐性点

先说负向约束的表达问题。很多人习惯写“不要写废话”“不要跑题”，但模型对“不要 X”的执行力通常弱于“请写 X”。与其写“不要啰嗦”，不如写“每段不超过三句话，每句不超过 25 字”。负向约束不是不能用，但至少要附带一个可执行的替代行为。

再说“重复不是浪费”。一个关键约束在开头出现一次，在当前区结尾再出现一次，是完全合理的做法。很多工程师追求“一句话讲清楚”，可惜这句话落在中段就容易被忽略。关键信息适度重复，是应对注意力偏差的低成本手段。

最后是“上下文不是越短越好”。短和精是两回事。上下文太短时，模型缺乏判断依据，只能靠臆测补全，结果就是自由发挥、产出飘忽。精的前提，是覆盖了模型做决策所需的全部依据。

4.3 像 debug 一样调上下文

我做上下文优化的习惯，和调代码一样留变更记录。每次调整记三件事：改了哪个区域、加了还是删了什么信息、评估分数变化如何。坚持一段时间，你会形成自己的“敏感参数表”——知道哪类问题改哪个位置最有效。

另外，每一条上下文规则都应该能回答三个问题：

• 它服务于哪个目标？没有目标就不要放。
• 它放在哪个区域最合适？开头、中段还是结尾。
• 它是每轮常驻，还是按需注入？

回答不清楚的规则，大概率是噪音，直接删。

5. 评估与迭代：让方法论形成闭环

5.1 评估智能体是上下文工程的方向盘

没有评估，上下文工程很容易变成玄学调参：试几次感觉不错，上线就翻车。评估智能体作为内建环节，解决的是三件事：

第一，量化对比。每轮改动跑同一批样例，得到横向可比的分数，改没改好一目了然。 第二，归因定位。评分后让它输出理由，引用输出原文，你就能判断问题出在“规则缺失”“示例误导”“背景不足”还是“格式未约束”。 第三，回归保护。每次上线前跑一遍回归集，防止优化一个场景、劣化另一个场景。这对多场景模型尤其重要。

我见过程序员把代码测试当理所当然，却把 Prompt 当一次性草稿。Prompt 和代码一样，上线后需要维护、需要版本、需要回归。评估智能体就是这套流程的地基。

5.2 轻量评估集怎么搭

评估集不用一上来就搞一百个样例。我的建议是先搭 12～15 个，覆盖“典型任务 + 边界情况”。典型任务占六成，边界情况占四成。边界情况包括：超长输入、信息冲突、超出知识范围、空输入、多重要求同时出现。每个样例最好附带期望输出要点，供评估智能体对照。

评估智能体的评分标准本身，也要用上下文工程来设计。比如让它先输出各维度 1～5 分，再写理由并引用原文片段，最后给出修改建议，且区分“必须修改”和“可忽略”。这样评估结果就不只是一串数字，而是一份可执行的问题清单。

5.3 从单次项目到方法沉淀

一个项目跑完，你会发现很多模式能复用：规则放开头、关键约束在结尾重申、动态信息用模板字段注入、历史对话滚动压缩。把这些沉淀成团队内部的“上下文工程模板库”，按任务类型分类，下一次直接开箱用，效率能翻倍。

做上下文工程做久了，最深的体会是：模型不是玄学，它只是对输入环境高度敏感。你把环境设计好了，产出稳定是必然，不是运气。与其花时间追新模型、新参数，不如先把眼前这套上下文的设计、验证、迭代闭环跑顺。方法论本身不值钱，把方法论执行到位才值钱。