企业官网建设流程全解析

如果你自己动手调过 AI 辅助工具，或者天天在跟大模型对话写代码，一定撞见过这种场面：同一个问题，换个说法，答案质量差了一大截；项目里的改动明明很小，AI 却答非所问；对话聊到一半开始重复前面说过的话，甚至把旧需求当成新需求来处理。大部分人第一反应是“模型不行”或者“prompt 没写对”，但我在实际项目里反复折腾之后发现，真正的分水岭往往在上下文（context）的组织上。这也是我在团队里推行 context-mode 这套管理思路的起点。

所谓 context-mode，简单说就是一套关于“在什么场景下、把哪些信息、以什么形式喂给模型”的规则集合。它解决的既不是模型能力问题，也不是单条 prompt 的措辞问题，而是更底层的信息调度问题：放进上下文窗口的内容多了，浪费 token 还引入噪音；放少了，模型像蒙着眼做判断，聪明也没地方使。这篇内容我会把五种常见的 context-mode、它们各自的适用场景、背后的 token 预算逻辑，以及我落地过程中踩过的坑一起梳理出来，给正在做 AI 应用开发或重度使用 AI 工具的朋友一个可参考的路线图。

1. 从一次翻车说起：AI 回答总是“差口气”，问题出在上下文

先说一个我印象特别深的翻车案例。当时一个前后端联调项目，我把后端一个接口的字段名从user_name改成account，代码一共改了不到十处。顺手把 diff 丢给 AI 帮我做代码审查，结果它完全不提调用方的问题，反而在审查意见里建议我把接口返回结构改成另一种格式。我一开始以为它没理解需求，追问了一句“你看到这个接口的原始定义了吗”，它才承认自己只是根据改动片段猜测的。

这件事成了一个转折点。模型没有变，prompt 也差不多，但我没有把最关键的上下文——接口定义、调用方代码、数据模型关系——交给它，甚至没告诉它这是一个分布式多模块的项目。它只能基于肉眼可见的 diff 自我发挥。从那以后我意识到，一个模型好不好用，能力只占一半，另一半是它“戴了多少副眼镜”看问题，那些眼镜，就是上下文。

1.1 context-mode 的本质：为每次请求决定“眼镜”

打个比方。你让一个经验丰富的同事帮你检查代码，你只甩给他一行报错日志，和把相关文件、调用链、需求文档一起给他，得到的建议质量当然完全不同。模型也一样，它训练的“聪明程度”是固定的，但它每一次生成时能看到的输入范围，完全由你来决定。这个输入范围在技术上就叫上下文窗口（context window），而 context-mode 就是一套系统化的方法，用来回答三个问题：

• 放什么：哪些代码片段、文档段落、历史对话值得进上下文？
• 怎么放：信息按什么顺序排列、怎么分段拼接、怎么压缩？
• 何时更新：同一段会话中，上下文怎么随对话推进而增删？

这三个问题如果不解决，AI 工具在你手里就是“开盲盒”——有时候灵光，有时候离谱。而把它们拆开之后，你会发现很多看似模型的锅，其实都是上下文策略的锅。

1.2 为什么通用聊天的经验搬不到工程场景

现在很多人的 prompt 经验是从通用聊天场景学来的，比如“把背景交代清楚”“多给几个例子”。这套经验在半正式的问答里确实管用，但在工程场景中很快会失效。聊天场景的上下文主要是对话历史，充其量加上一两段用户描述；工程场景的上下文可能是几百个文件的代码库、几十页的接口文档、一堆异步任务的运行日志。

更麻烦的是，工程场景里信息量太大，根本塞不进窗口。如果硬塞，token 超限、响应变慢、费用变高，模型还会被无关代码干扰。如果少塞，模型又抓不住关键依赖。所以 context-mode 在工程场景中不只是“建议”，而是必须设计的一层中间件：它负责在海量信息里做取舍，再把取舍后的结果组装成模型容易消化的形式。

2. 拆解 context-mode：五种我常用的上下文组织方式

我翻了各种各样的实现方案，也跟一些开源项目的作者交流过，发现“context-mode”并不是某个官方标准术语，更像是在实践中逐渐形成的一套习惯分类。下面这五种模式是我自己用下来区分度最高的，它们各有各的脾气和适用场景。

2.1 零上下文模式：干净利落的单体请求

零上下文模式就是每次请求完全独立，不携带任何历史信息，除了系统提示词之外，只放当前这一次的任务输入。它有两张王牌：一是不会受到历史脏数据干扰，二是 token 消耗最低。

一个典型场景是文本处理任务。比如丢一段日志让你正则提取错误码，或者丢一段英文让你翻译成中文。这类任务的结果不应该依赖对话历史，如果前面聊过别的话题，反而容易把翻译风格带偏。我经常用零上下文模式做数据清洗的批量脚本，每一条日志都是独立请求，互不干扰。

它的软肋也很明显：没有记忆，就没有个性化。你在上一轮里说过“所有地名保留英文”，到下一轮它就忘了。所以零上下文模式适合“一次性、有明确指令、结果可验证”的任务，凡是需要连续协商或依赖偏好的任务，就得换下面的模式。

2.2 会话上下文模式：让回答拥有短期记忆

会话上下文模式就是我们平时最常见的聊天形态，系统把每一轮的用户输入和 AI 回复按序拼接，整体放进下一次请求。这种模式最大的进步是模型能“接着聊”，但它也是最容易被人误用的。

这里的核心是控制策略。很多 AI 产品直接把全部历史一股脑塞进去，对话到第 50 轮时，历史可能占了 2 万 token，真正的新问题反而只有几百 token。模型被淹没在旧内容里，对当前问题的专注度迅速下降。正确做法是采用滑动窗口：只保留最近 N 轮完整对话，更早的内容要么丢弃，要么压缩成摘要。

另一个要注意的细节是系统提示词的位置。会话模式里，系统提示词通常负责锁定角色和长期规则，它应该放在历史之前，而且每次请求都带着同样的版本。如果系统提示词被历史对话挤到很后面，模型的注意力会被历史占据，规则约束力减弱。我实测下来，把系统提示词放在开头、角色规则里标注“这些规则优先级高于对话历史”，能明显减少角色跑偏的问题。

2.3 文档增强模式：把知识库变成模型的“外接硬盘”

文档增强模式是目前 RAG（检索增强生成）类应用的核心，也是 context-mode 里最值得花时间研究的一种。它的思路很简单：模型的知识截止到训练数据，新文档、内部资料、私有协议它统统没看过，那就先检索再生成——把用户问题变成检索请求，从知识库中捞相关片段，拼进上下文让模型回答。

我碰到的项目里，有一种最低效的做法是“把 PDF 全文塞进去”。对短文档可行，但超过一定长度后，不仅 token 爆表，模型还会被大量无关段落干扰。真正的文档增强模式要做两步：先切片，再检索。切片粒度很讲究，按固定 500 字切会拦腰截断语义，按章节标题和段落边界切相对可靠，但也要保留一定的上下文重叠。

检索出来的片段也并非越多越好。投喂 20 个相关度参差不齐的段落，模型反而分不清主次。我现在的做法是：用混合检索（关键词 + 向量）取回候选集，再做一次重排（rerank），只留最相关的 3 到 5 段。这样上下文窗口里全是“高密度相关信息”，回答质量的提升非常明显。

2.4 代码感知模式：让 AI 读得懂工程，才写得好代码

代码感知模式是我个人花精力最多的一种，也是编程类 AI 助手和通用聊天大模型拉开差距的地方。它要做的是把代码库的“结构线索”注入上下文：当前打开的文件内容、相关的符号定义、函数调用链、项目文件树、构建配置、依赖清单，甚至是最近的 git diff。

为什么这些结构线索这么重要？因为代码的正确性依赖上下文，一个函数改了签名，所有调用它的地方都得跟着改；一个类型定义在types.ts里，你在utils.ts里让 AI 写一段处理这个类型的逻辑，它必须看到定义才能不靠猜。通用聊天工具只给你一个输入框，它无法自动感知这些，而代码感知模式要做的就是替模型提前完成“翻项目”的过程。

落地上我建议分三层。第一层是文件级：当前编辑的文件必须完整给到；第二层是符号级：通过 AST 解析或语言服务器找到当前文件的 import 依赖、函数定义、类型引用，按需拉取；第三层是变更级：把 git diff 和最近提交记录带上，让模型理解这次改动的前因后果。三层拼起来，AI 才算是“戴着工程地图干活”，而不是“蒙着眼改代码”。

2.5 多代理模式：上下文隔离的协作架构

最后一种模式适合更复杂的自动化场景，也是我近期做 AI Agent 时最常采用的结构——多代理模式。它的特点是一个主控代理负责理解用户意图、拆解任务，然后创建多个子代理，每个子代理各管一路独立的上下文。

打个比方，一个大型项目里，你想让 AI 同时做“遗留代码梳理”“新需求方案设计”“测试用例生成”三件事，如果放在同一个上下文里，三类信息互相干扰，模型很容易混乱。分开之后，每个子代理只看到自己的任务描述、相关文件和输出规范，上下文干净、聚焦，主控代理再汇总各子代理的结果。

这种模式也引入了新的复杂度：上下文隔离、结果汇总、子代理通信。你需要定义清楚哪些信息是全局共享的（比如项目背景、全局约束），哪些是子代理私有的（各自的输入文件、中间结果），否则会出现子代理之间互相套话、重复劳动的问题。我的原则是尽量轻量通信，子代理只提交结论和必要的证据链接，不交换原始大文件。

3. 为什么模式切换比想象中难：令牌预算与信息密度

讲了这么多种模式，很多人第一反应是“那我全用文档增强或者代码感知不就行了？”答案是没那么简单。每一种模式都要消耗上下文窗口里的 token，而 token 不是免费的，窗口也不是无限大的。理解 token 预算和信息密度，是真正把 context-mode 用明白的前提。

3.1 上下文窗口不是无限餐桌

目前主流模型的上下文窗口已经从几万 token 扩到了几十万 token，乍看之下放什么都够了。但实际上，你往窗口里放的每一段文本，都同时占用三份资源：输入费用、计算延迟、模型的注意力。尤其是注意力，窗口拉长之后，模型对每一段内容的“关注程度”会被稀释。

我自己算过一笔账，假设窗口是 4 万 token，系统提示词占 5000，历史对话占 8000，工具定义占 4000，文档检索片段占 2 万，留给输出的空间可能只剩 3000。输出空间不足，模型就会倾向于给短答案、省略推理过程、漏掉细节。这就像在一张餐桌上堆了太多菜，真正要吃的那个主菜反而被挤到桌子角，够不着了。

所以在设计 context-mode 时，不能只看“能不能装下”，要看“装完之后还有没有余量让模型好好回答”。我习惯在每次请求前先做一次 token 预估，把预估函数写在日志里，超过阈值就触发裁剪或摘要。这个习惯帮我避免了很多“莫名其妙变蠢”的时刻。

3.2 信息密度：同样的窗口，不同的答案质量

信息密度的意思是：单位 token 里承载的“决策有用信息”有多少。同样表达一个需求，“请帮我分析这份销售数据，注意地区维度和时间趋势，尤其是华东区最近三个月的下滑情况”比“这是一些数据，你看看有没有什么问题”的信息密度高得多。

提升信息密度可以从三个方向下手。一是删冗余：文档里的客套话、背景铺垫、重复举例都去掉，只保留定义、数值、结论、边界条件。二是转格式：把大段叙述转成结构化列表或表格，模型对结构化信息的解析效率更高。三是加锚点：明确指出哪些信息是关键的、需要在回答里重点使用的。锚点可以用诸如“以下片段中，重点关注【】内的内容”这类形式，我在实践里发现这种显式标注能显著提升模型对重点片段的利用率。

3.3 位置偏差：模型的目光会“中间迷失”

另一个容易被忽视的现象是位置偏差，业内也叫“lost in the middle”。研究发现，模型对输入开头和结尾的内容更敏感，对中间部分容易“视而不见”。这意味着你辛辛苦苦放进上下文窗口的文档片段，如果恰好排在窗口中间，很可能根本没被模型认真用到。

这个偏差对我的影响很大。我在一个知识库问答项目里，把检索到的五段文档按原文顺序拼接，结果模型总是只参考第一段和最后一段，中间的检索结果被忽略，导致答案不完整。后来我改成按相关度重排，最相关的放开头，次相关的放结尾，中等相关放中间，答案完整度立刻上来了。这个细节在 RAG 项目和长文档摘要任务里尤其重要，属于低成本高回报的优化点。

4. 落地 context-mode 的工程实践

理论讲清楚了，关键还是落地。这一节我把自己在项目里实际跑通的工程做法整理出来，包括上下文裁剪、检索增强的组合方式、会话记忆的持久化。这里面没有炫技的成分，都是你在自己的代码里可以直接抄走的套路。

4.1 上下文裁剪策略：按需取用，别做全量搬运

我踩过最大的坑就是“全量塞入”。一开始做代码辅助工具时，图省事把整个仓库的文件树和所有源文件都塞进上下文，结果 token 直接爆掉，响应慢到没法用。后来我才定下按需裁剪的三步流程。

第一步是识别必要信息。对代码场景，我先用语言服务器或者简单的正则解析，提取出当前文件里 import 的模块、引用的符号、相关的类型定义，再倒查这些符号定义在哪个文件里，只把那些文件的对应片段拉进上下文，而不是把整个文件都塞进去。

第二步是分块切分。文档场景我会按 Markdown 标题、代码注释块、逻辑段落做切分，而不是按固定字符数硬切。固定切分的问题在于会把一个完整的函数定义或一个表格拦腰截断，模型拼都拼不回来。

第三步是映射合并。把切片后的内容映射成上下文片段，加上来源标记，比如“File: src/api/user.ts, Lines: 120-145”。来源标记帮我解决了两个问题：模型引用代码时能说清楚出处，我调试时也能快速定位是哪个片段影响了结果。对于裁剪程度，我的经验阈值是：高质量片段宁缺毋滥，低质片段再多也是噪音。

4.2 检索增强的组合：向量、关键词和重排的三角关系

如果只是做简单问答，把整篇文档塞进上下文也够用。但一旦文档数量上去，就必须引入检索。我在实践中发现，单纯的向量检索并不够用，关键词检索也不能丢，两者要组合混合检索。

向量检索擅长处理语义相似，但遇到精确匹配很弱，比如用户搜索“HTTP 404 状态码”，如果文档里写的是“404 Not Found 响应”，向量相似度可能排不上号，关键词却能直接命中。反过来，关键词检索容易漏掉同义表达，比如用户说“登录超时”，文档里写的是“认证会话过期”，这时候又是向量检索发挥作用的场景。混合检索就是把两者结果做加权融合，弥补彼此的盲区。

召回之后还要重排。我的做法是先让混合检索召回 Top 30 候选，再用重排模型按和问题的相关度打分，取 Top 5 拼入上下文。重排的意义在于让最相关内容尽可能排在窗口的靠前位置。如果没有重排模型，也可以用简单启发式替代，比如依据关键词命中数量、文档更新时间做加权排序，虽然粗糙，但比随机顺序好得多。

def build_context(question, doc_index, top_k=5): # 混合检索：关键词召回 + 向量召回 keyword_hits = doc_index.keyword_search(question, top=30) vector_hits = doc_index.vector_search(question, top=30) # 合并候选并去重，保留分数来源 candidates = merge_and_dedupe(keyword_hits, vector_hits) # 简单加权重排：关键词命中数 + 向量相似度 + 新鲜度 candidates.sort(key=lambda c: ( 0.5 * c.keyword_score + 0.4 * c.vector_score + 0.1 * c.freshness_score ), reverse=True) top = candidates[:top_k] context_blocks = [c.snippet_with_source() for c in top] return "\n\n".join(context_blocks)

4.3 会话记忆的持久化：摘要加滑窗的双层结构

会话上下文模式落到工程上，最大的问题是记忆的存储和更新。把每轮对话都存在内存里不现实，服务重启就丢了；全部存数据库又太笨重，每次请求还要拉回大量历史。我实践下来最顺手的是“摘要 + 最近 N 轮”的双层结构。

具体来说，系统维护两个模块。一是摘要记忆：每过 5 轮对话或上下文超过阈值，调用一次模型把之前的内容压缩成 200 字以内的纪要，纪要里保留已确认的决定、用户偏好、关键术语定义；二是滑窗缓存：只保留最近 5 轮原始对话。每次请求时，把纪要放在最前面，再接最近轮次，这样模型既有长期记忆，又不会淹没在旧对话里。

还要考虑记忆失效。我遇到过一个典型问题：用户讨论完 Python 方案后切换到 Java，摘要里还留着“用户选用 Python”的旧结论，模型继续沿用 Python 习惯回答。后来我在系统提示词里加了一条规则：当用户明确转换技术栈或项目主题时，默认旧结论不再适用，并主动更新摘要。这个简单的显式失效机制，帮我解决了一大批“跨话题污染”问题。

5. 踩坑实录与我的调优建议

前面讲的是框架和方法，但方法在真实世界跑起来总会遇到课本上没有的情况。这一节写我自己踩过比较深的几个坑，以及最后沉淀下来的几条铁律，希望帮你少走点弯路。

5.1 上下文污染：旧对话会把新问题带偏

第一次明显感觉到上下文污染，是在做客服问答机器人时。用户先问了退款流程，又突然问发货时间，模型却一直围绕退款政策回答，甚至把发货时间的问题也往退款上引。看日志才发现，上下文里保留了太长的高权重历史轮次，模型被旧话题“催眠”了。

这类问题的解法不只是清空历史，而是要对话题切换做检测。我目前的方案有两个：一是用轻量分类器或者简单的关键词差异检测，判断用户新输入和当前上下文主题是否一致，不一致就自动清空滑窗，仅保留全局纪要；二是在系统提示词里写清楚“当检测到用户提出与之前不同主题的请求时，忽略所有历史对话中的主题约束”。第一个方案治本，第二个方案兜底，两者配合后，跨话题污染率明显下降。

5.2 过期上下文：文档更新了，回答还在用旧版本

另一个高频坑是缓存导致的过期上下文。最初我做文档增强模式时，为了提高性能给热门文档片段做了缓存，结果文档更新后缓存没有同步失效，用户提问时检索到的还是老版本内容。最典型的一次是接口文档里的参数从pageSize改成了limit，缓存没刷新，模型还在按pageSize给答案。

解决思路很简单：给每个缓存片段加上两个字段，文档版本号和文档内容哈希。每次写入缓存时，先校验版本号和哈希，不一致就直接失效并重新切块入库。同时也要注意检索层面的新鲜度权重，对频繁更新的运营类文档，我把新鲜度在重排权重里的比例调高，对技术协议类文档则更看重语义相关度。调试时记住一条：当模型答案和事实“差一点”时，先怀疑上下文是不是旧的，别急着改 prompt。

5.3 我给团队定下的三条铁律

踩过这些坑之后，我给团队内部定了几条规则，都是成本极低但收益明显的硬约束。

第一条：宁缺毋滥。拿不准是否相关的信息，默认不放进去。模型的容错能力比多数人想象得差，多一段无关内容，就可能把它带偏。宁可用更少的、高相关的上下文，也不要什么都堆上去。

第二条：先裁剪，后注入。所有上下文在进入模型之前，先经过代码层面的处理，比如提取关键字段、压缩 summary、去重排序。不要依赖模型的指令去“忽略无关内容”，它做不到百分百筛选，必须在入口处就把质量控好。

第三条：可观测。每次请求记录 token 用量、上下文片段来源、重排得分和最终的模型输出摘要。可观测不只是为了排查问题，更是为了迭代 context-mode 策略。没有日志，你都不知道刚才那个好答案到底是因为上下文组织得好，还是纯属运气。

最后说两句

回头看，我在 context-mode 上花的时间一点都不冤枉。最开始只是为了让代码审查不翻车，后来逐渐发现，上下文管理是 AI 应用从“demo 能跑”走向“生产可用”的关键一步。无论你把模型换成多强的新版本，只要上下文组织混乱，强模型一样会给出弱答案；反过来，上下文组织得当，中等模型也能完成很复杂的任务。

如果让我给一个最实在的建议，那就是：把 context-mode 当成一个和模型同等重要的独立模块来设计。它不该是“临时拼几个 prompt”，而应该有独立的数据结构、缓存策略、裁剪流程和可观测日志。每次迭代模型版本时，也顺手回归一下这些上下文策略。我在实际项目里的体会是，花一周时间认真打磨上下文组织，比费劲找一个“更强提示词”要值钱得多。希望这份经验对你也有用。