企业官网建设流程全解析

最近 “context-mode” 这个词在技术社区的热度涨得很快，我判断主要原因是各家 AI 编程助手和 Agent 框架都在拿“上下文模式”当卖点。但说句实在话，不管你是用 Copilot、Cursor、Claude，还是直接调大模型 API，context-mode 都从来不是一个产品独有的开关，它本质上是一整套关于“给模型喂什么、喂多少、以什么顺序喂”的取舍逻辑。

我自己最早把 context-mode 当成一个简单的参数，觉得不过就是“上下文长度选长选短”而已。直到自己动手写 Agent、做代码库问答的时候，才真正意识到：它可能是决定 AI 输出质量的最关键变量，也是最容易被低估的一环。这篇文章想用我踩过的真实开发经历，把 context-mode 的原理、常见形态、选型方法、落地实现以及各种翻车现场摊开讲一遍。无论你是刚接触 AI 应用开发的新人，还是在调优上下文的老手，应该都能从中找到可以直接抄作业的部分。

1. 先拆掉一个误解：上下文不是“聊天记录”，是模型的工作范围

1.1 Context 与 Context-Mode 到底有什么区别

很多人把“上下文”理解成对话历史，这是最常见的第一层误解。实际上，语言模型理解的上下文远不止聊天记录：系统提示词（System Prompt）、用户输入、检索到的知识片段、工具调用返回的结果、被引用的代码文件，全部都会被拼进 Prompt，然后才形成模型看到的“上下文”。

模型的 context window 决定了它一次最多能读多少 token。过去主流模型的窗口只有 2k、4k，现在普遍是 128k、200k 甚至更大。窗口变大确实带来很多便利，但成本问题和注意力问题并不会因为窗口变大而消失：输入的 token 每一分钱都是要花钱的，而且模型在超长上下文里并不会一视同仁地处理每一个 token。

这时候就引出了 context-mode 的真正含义：它不是“上下文长度”的调节器，而是管理整个 context window 的策略集合。什么时候把哪些内容塞进上下文、哪些内容不塞、塞进去之后放在什么位置、按什么顺序组织，这些规则合在一起，才叫上下文模式。

我常用一个比方：context window 相当于你的办公桌，大小固定；context-mode 则决定了你把哪些报告摊在桌面上、把哪些收进抽屉里。桌面摆满杂物的后果，和上下文被无关信息塞满的后果是一样的——你真想找的那支笔反而找不到了。

1.2 同一个需求，不同 context-mode 输出的答案完全可能是两份

举个我实际遇到的场景。我有一个小型服务端项目，想让 AI 检查登录接口的鉴权逻辑并修复越权风险。

第一次我用了全局上下文模式，把整个服务端的源代码目录全部塞进去。结果 AI 确实给出了一个非常宏观的修复建议，但也顺带改了路由中间件里一段和鉴权无关的日志逻辑，因为它“看到”那部分代码也有点问题。那次改动差点在 code review 阶段引发事故。

第二次我改用局部上下文模式，只把login.py和auth.py两个文件注入进去。AI 的修复非常精准，改动范围也很小，但后来我发现它漏掉了一个关键点：某个上游服务调用这个登录接口时，依赖了一个旧版本返回字段，而局部的两个文件里根本没有这个信息，所以 AI 的输出和调用方完全不兼容。

这两个结果都没有对错之分，问题在于我选择模式时没有认真想过任务的性质。这也是我这篇文章想强调的第一个观点：没有最好的 context-mode，只有是否匹配当前任务的 context-mode。

2. 三种最常见的上下文模式：全局、局部、记忆

既然要做选型，就得先把常用上下文模式的形态和适用边界理清楚。我平时在开发和设计 AI 应用时，基本只围绕三种模式来思考。

2.1 全局上下文模式：一次全量装载，用成本换视野

全局上下文模式，顾名思义，就是尽量把当前工作区里所有相关信息一次性注入 Prompt。在代码工具里，它通常表现为“整个仓库作为上下文”；在文档问答场景里，就是“把整本手册作为上下文”；在对话场景里，往往是“把全部历史消息原样带上”。

这种模式最大的优点是信息完整性。你不需要提前猜模型到底需要什么，也不依赖检索质量，只要上下文窗口放得下，模型理论上就能看到所有东西。它特别适合架构评审、跨模块重构、全局检索式问答这类任务——这些任务的核心价值正是在于“看到全貌”。

但它的代价也很直观。第一是 token 成本非线性上升，无论你问的是一个小问题还是一个大问题，只要全量装载，费用就按照完整内容计算；第二是模型在超长上下文中会出现明显的注意力退化，这个问题在业界被叫做“Lost in the Middle”，即模型对长文本中段内容的记忆明显弱于开头和结尾。全量加载 200k token 的文章，真正关键的句子可能只有 500 token，但模型反而可能忽略它。

所以我的经验判断是：全局模式适合“问题边界不清楚、需要探索全局”的任务，而不适合“目标明确、改动点清晰”的任务。后者用全局模式，只会白白花钱，还分散注意力。

2.2 局部上下文模式：最小必要信息，专注当下任务

局部上下文模式，是和我最初想法最接近的一种模式：只给模型完成任务所需的最小信息集。

在代码场景里，它通常通过对代码库做切片、按文件路径过滤、或者借助检索（RAG）命中与任务相关的片段来实现。在文档问答里，它就是把长文档切成块，只把命中查询的 top-k 片段拼进 Prompt。

局部模式的好处非常明显：快、便宜、输出聚焦。同样一次调用的输入 token，全局模式可能要到 100k，局部模式可能只需要 5k 到 8k，首 token 延迟也会明显下降。更重要的是，模型看到的内容越聚焦，越不容易跑偏去修改不该改的东西。

但局部模式有一个致命短板：它过度依赖“检索命中质量”和“切片完整性”。如果检索阶段没有把真正重要的上下文捞出来，模型大概率会在缺少信息的情况下开始编造答案，而且它自己不会意识到信息缺失。行业里管这个叫沉默失败（Silent Failure）：模型不会主动说“我缺少背景信息”，它只会自信地写出一个看似合理但其实是幻觉的答案。

所以局部模式的使用要配套一个动作：对输入信息做依赖展开。至少要把任务关联文件的一层依赖关系（比如 import 引用、接口调用方、配置来源）也纳入上下文，而不是机械地只给目标文件。这个问题我后面会专门展开。

2.3 持久化记忆上下文模式：跨会话保持“长期状态”

前面两种模式解决的是一个会话内部的问题，但 AI 应用往往需要跨会话保持一致性。今天你让 AI 按 A 方案设计模块，明天新开会话，AI 可能完全不记得这个约定，于是重新设计成 B 方案。这种断裂感，就是持久化上下文缺失的表现。

持久化记忆上下文模式，把稳定的项目事实、历史决策、偏好约定、进度状态存放在一个独立的记忆层里，比如AGENTS.md、context/memory.md、项目知识库，甚至是向量数据库。每次新会话开始时，只把记忆层里的高价值信息注入 Prompt，而不是把历史的每条消息都搬出来。

这就像人的长期记忆：你不会把昨天每句话都记得清清楚楚，但你会记得讨论后得出的结论。持久化上下文要记录的也是结论，而不是过程流水账。

它的优势是可以让多轮任务不断档，Agent 能保持风格一致、技术选型一致。但它的风险也很隐蔽：记忆层一旦被写入错误或过期的信息，会造成远比“没有记忆”更严重的误导。因为模型对记忆内容有很高的信任度，你写进记忆里的就算是个错误决策，它也会当作既定事实来执行。所以我一直坚持一个原则：记忆层里只放稳定事实，不放临时想法和未经验证的方案。

这三种模式在实际系统里不是互斥的。成熟的做法通常是叠加使用：全局模式做底层的“全量视野兜底”，局部模式负责实时的精准检索，记忆模式维护跨会话的一致状态。关键是搞清楚每层到底放什么内容。

下面用一张表把三种模式的主要差异列出来，方便选型时快速对照：

3. 怎么选 context-mode：任务矩阵、token 账本与注入顺序

3.1 用“任务矩阵”做选型，而不是凭感觉

踩过几次坑后，我总结了一套选型判断标准，每次接到任务先过四个问题，再决定用哪种模式。

第一是任务半径：改动或查询涉及多少个文件/模块？如果答案是 1 到 3 个文件，局部模式基本够用；如果涉及多个模块的联动关系，就要考虑全局模式或者“局部 + 依赖展开”。

第二是探索需求：这个问题是不是需要模型在未知区域里找答案？比如“帮我梳理这个项目的鉴权流程”，这类任务信息分布在整个项目，某个局部文件给不出完整答案，全局模式才是首选。

第三是输入确定性：任务输入是否明确？越明确的任务越适合局部模式，因为你知道该往 Prompt 里放什么；输入越模糊，越需要全局视野来补全缺失信息。

第四是成本敏感度：全局模式输入 token 是局部模式的几十倍，如果任务是你每天要跑几十次的常规操作，成本差异会非常可观。

基于这四个维度，我手里的速查表大致长这样：

最稳的策略永远是：局部优先，有需要再升级到全局。先拿最小信息集去跑，发现答案明显缺少背景，再逐步放大范围。这样比一上来就全局全量循环省钱省时。

3.2 token 成本与延迟，是一笔需要心里有数的账

聊选型不谈成本是耍流氓。全局模式的输入 token 可以是局部模式的二十倍以上。假设一个中大型项目全量扫描需要 100k token，而局部模式只需要 5k token，一次调用的输入成本就差了 20 倍。

如果是一个团队每天跑 100 次 AI 任务，每次都走全局模式，成本很快就会变成一个必须汇报的数字。但更隐蔽的成本是延迟：首 token 生成时间大体上随输入 token 数量上升，长上下文意味着更长的等待。开发场景里，等待时间越长，开发者切换上下文的概率就越高，实际效率反而是下降的。

不过，我并不是说为了省钱就无脑局部。还有一笔更贵的账叫返工成本：如果因为上下文缺失导致 AI 产出了不兼容的代码，review 发现问题再重跑一次，浪费的是人的时间，比 token 贵一个量级。所以选型不光是省 token，更是在“省的 token”和“可能导致的返工”之间做平衡。

我的经验是：对自动化流水线里的任务（比如批量文档总结、自动生成测试），倾向局部模式，因为成本是持续性的；对架构评审、重构设计这类低频但关键的任务，不要抠 token，该全局就全局。

3.3 注入顺序：上下文放在哪个位置，直接影响模型会不会用它

很多人忽略了一个细节：上下文不是一股脑拼进 Prompt 就行，顺序本身就是一种指示信号。

行业里有一个比较公认的现象：模型对 Prompt 开头和结尾的信息敏感度最高，中间部分容易被忽略。你希望模型优先遵守的指令，应该放在开头或者结尾的显眼位置；你希望它作为参考的辅助信息，可以放在中段。

我实际拼 Prompt 的通用结构大致是：

1. System Prompt：定义角色和行为边界，放在最前面。
2. 任务说明：把本次要完成的事情写得清清楚楚，紧跟系统提示词。
3. 动态上下文：检索到的代码片段或知识块，按相关性从高到低排列。
4. 历史摘要：如果是多轮任务，放经过压缩的会话摘要。
5. 用户当前输入：作为最后一段，明确本次触发任务的具体请求。

这个结构的作用是把“指令”和“参考资料”分开，避免模型把参考信息当成指令执行。很多 context-mode 的问题，其实不是信息数量不够，而是信息堆在一起，模型分不清哪些是背景、哪些是必须遵守的硬性要求。

另外我还有一个建议：对于最关键的那一条要求，可以在开头和结尾各出现一次，用不同措辞强调一遍。适度的重复能显著提升模型遵循的概率，但不要无限制重复，否则会显得像在灌水，反而稀释注意力。

4. 从零落地 context-mode 管理：我当前在用的最小方案

前面聊了不少原理，落到工程上到底怎么做一个 context-mode 管理的最小实现？这部分我把自己项目里正在用的方案简化后分享出来，它不依赖任何特定框架，只用到文件系统和一段 Prompt 组装逻辑，完全可以直接抄走改。

4.1 用文件目录来承载上下文状态

很多人一上来就想着上向量数据库，但其实只有上下文管理的话，文件系统往往是最合适的起点。文件天然可以版本化、可以人工审查、可以被 CI 检查，这三个特性非常重要，因为上下文内容出错了，你能追溯、能回滚、能发现是谁改的。

我习惯在项目根目录维护一个context/目录，结构大概这样：

context/ ├── system.md # 固定系统提示词，定义 AI 的角色边界 ├── memory.md # 长期记忆，记录项目决策、约定、进度 ├── global.md # 全局上下文入口，存放稳静态的项目总览 └── sessions/ ├── 2025-06-01.md # 按日期归档的会话摘要 └── 2025-06-02.md

每次生成 Prompt 的时候，程序读取这些文件，再按当前任务的 mode 决定装载哪些文件、跳过哪些文件。这套设计最大的优点是透明：你随时可以打开context/memory.md看看里面到底写进了什么，比起让数据库里看不懂的向量去决定上下文，这种可审计性在工程上非常重要。

还有一个配置文件，用来表达每次任务希望以什么上下文模式运行：

{ "mode": "local", "include": [ "src/auth/login.py", "src/auth/permission.py" ], "maxTokens": 8000, "memoryRefs": [ "AGENTS.md", "context/memory.md" ] }

这个配置文件你可以理解为“任务上下文订单”：告诉加载器这次只关心哪些文件、要不要带记忆、上限是多少 token。团队协作时它最有价值，因为每个人都能明确知道一次调用到底喂了什么给模型。

4.2 一条注入管线的 Python 骨架

核心的加载逻辑可以抽象成一个小函数，我给出简化版本：

# context_manager.py from pathlib import Path def read_file(path: str) -> str: return Path(path).read_text(encoding="utf-8") def retrieve(task: str, index, top_k: int = 10): """从检索索引中命中与任务相关的切片，返回 top_k 个片段。""" return index.search(task, top_k=top_k) def build_context(task: str, mode: str, index=None, config: dict = None) -> str: system = read_file(config.get("system_path", "context/system.md")) if mode == "global": # 全局模式：读取全量文件，再统一截断 chunks = [read_file(p) for p in config.get("include", [])] elif mode == "local": # 局部模式：先检索，再加一层依赖展开的文件，去重后使用 chunks = retrieve(task, index, top_k=config.get("top_k", 10)) chunks += [read_file(p) for p in config.get("include", [])] chunks = dedupe(chunks) elif mode == "memory": # 记忆模式：固定记忆 + 检索的局部片段 memory = read_file("context/memory.md") chunks = [memory] + retrieve(task, index, top_k=config.get("top_k", 5)) else: raise ValueError(f"Unknown mode: {mode}") # 按顺序组装：系统指令 -> 任务说明 -> 动态上下文 -> 当前输入 return assemble_prompt( system=system, task=task, context_chunks=chunks, max_tokens=config.get("maxTokens", 8000) )

这里面的dedupe和assemble_prompt是两个基础工具函数，一个负责按路径或者哈希去重，一个负责把各个片段按前面说的顺序拼接，并在超出maxTokens时做截断。截断的策略我建议优先级反过来：优先保证系统指令和用户当前输入不被截掉，然后保证高相关性的检索片段，最后才是通用背景。

这套代码最关键的设计决策是：模式是运行参数，不是硬编码逻辑。同一个调用入口，传入不同 mode，就能让同一个业务在不同上下文规模下运行。这方便你做 A/B 测试：跑同一批任务，对比不同模式下的输出质量和成本，然后再去定团队规范。

4.3 历史太长时，用滚动摘要代替原始日志

多轮对话和长期 Agent 任务里，还有一个所有团队都会撞上的问题：历史消息全量拼接，会飞速吃满上下文窗口。一个两小时的深度调试会话，原始消息可能就有 50k token，而且其中大部分是重复的试错过程。

我的做法是滚动摘要：每轮关键任务结束后，让模型自己总结这一段的核心要点，写入sessions/目录，下次继续对话时，只注入摘要，不注入原始日志。

摘要模板我固定为四块：

## 目标 （这次会话要解决什么问题） ## 决策 （讨论后确定的方案、选型、结论，一字不漏记录下来） ## 变更 （改了哪些文件，动了哪些逻辑） ## 遗留 （未解决的问题、下一步计划、风险点）

这里有一个关键动作：原始日志仍然要归档，只是不注入 Prompt。摘要负责给模型提供连续记忆，原始日志留给人类做审计和回溯。不要因为摘要够用就直接丢弃原始数据，否则将来想追溯一个错误决策的推导过程时，你会非常痛苦。

滚动摘要本质上是持久化记忆上下文的一种实现，它把“记忆”从抽象概念变成了可维护的工程资产。配合 4.1 里的文件目录，你已经拥有了一套不依赖外部服务的 context-mode 管理方案。

5. 踩过三次 context-mode 的坑之后，我的处理经验

原理和代码都聊完了，这节我讲讲自己实实在在翻过的车。技术文档里很少会写这些细节，但它们恰恰是最影响实际效果的。

5.1 坑一：全局上下文把模型“喂撑了”，关键逻辑反而被忽略

有一次我需要让 AI 修改一个服务模块里的小函数，因为担心它缺少背景，我把整个模块目录 2000 多行代码全部注入了上下文。结果是灾难性的：AI 给出了一个在结构上非常“完整”的重构方案，但它把注意力放到了中间一段样板代码上，真正需要修改的核心逻辑反而没有被处理，而且它还顺手“优化”了一个和任务毫无关系的日志模块。

这就是前面提到的 Lost in the Middle 现象。信息越多，模型越容易迷失在中间段，尤其是当关键信息恰好埋在长文本中部的时候。

我的处理方式很直接：给所有进入上下文的内容做一个相关性排序，然后把最关键的待修改代码块放在 Prompt 末尾的“请修改以下区域”部分，让关键信息处于注意力高地。现在除非任务明确要求全局审视，否则我都会先做一次检索定位，把相关文件缩小到 3 个以内再送入 Prompt。

5.2 坑二：局部模式漏掉了“看不见的依赖”，产出接口不兼容

这个坑是我印象最深的一次。我用局部模式让 AI 重构一个 service 类，只把 service 本身和它对应的模型文件放进了上下文。AI 给出的新接口清爽了很多，看起来完全没毛病。结果代码一进 CI，调用方直接编译失败。

原因在于旧接口被另外三个服务模块引用，而这三个模块根本不在上下文里。AI 没有它们的信息，自然不可能知道接口变更会造成什么影响。局部模式在省 token 的同时，把“依赖关系”也一起省掉了，这是最典型的沉默失败。

现在的做法是：凡是涉及到接口、函数签名、数据结构的修改，我会先做一步依赖展开，把调用方的一层关系也扫描进上下文，至少得让模型知道“还有谁在用这个接口”。这项操作在代码库场景里并不复杂，用 import 解析器抓一下引用关系就行；但如果连依赖展开都不做，那局部模式只适合完全不涉及对外接口的纯内部逻辑修改。

5.3 坑三：持久化记忆被写脏，过期决策持续误导后续任务

有一次我们团队在context/memory.md里记录了一个中间方案的决策，本来只是临时选项，后来正式方案被否决，最终选了一条完全不同的路线。但那条被否决的临时决策没有被及时清理，结果之后一周内，所有依赖记忆上下文的 AI 任务都在按那条错误决策执行，甚至生成的新代码也在向错误方向靠近。

这次事故让我明白了三件事。第一，记忆内容必须带状态字段：proposal（提议）、accepted（已接受）、deprecated（已废弃），每次注入前过滤掉 deprecated 内容。第二，记忆文件必须有人工 review 机制，不能完全依赖模型自己维护。第三，记忆只记录“结论”，不记录“讨论过程”。讨论过程里的临时想法是最容易过期、最容易误导人的内容，它们应该留在 issue 或聊天记录里，而不是进入记忆层。

5.4 我最后沉淀下来的实践公式

折腾了这么多，最后沉淀下来一句话，也是我现在设计所有 AI 应用时都会默念的一个公式：

有效上下文 = 任务必要信息 + 稳定项目事实 - 过期噪音

任务必要信息由局部模式负责，稳定项目事实由记忆模式负责，过期噪音靠定期清理和状态过滤来消除。全局模式更像是一个补充选项，只在确实需要全貌时才启动。把这三个部分协调好，context-mode 就不再是一个让人迷惑的开关，而是让 AI 输出真正可控的系统能力。

最后分享一个小习惯：我现在每次拿到一个需求，会先问自己一句——这个任务到底需要模型看见哪些文件？如果答案不超过五个，就坚决用局部模式；如果答案变成了“整个系统”，再考虑全局模式也不迟。这个简单的习惯让我每天的 token 开销比之前省了一大半，产出的结果也更稳定。毕竟模式划分再精细，也代替不了动手前先想清楚任务边界这件事。