企业官网建设流程全解析

先别急着划走。如果你最近在用 Cursor、Claude Code、Codex 这类 AI 辅助编程工具，对 context-mode 这个词肯定不陌生。它不是什么藏着掖着的高级黑科技，本质上就是一个决定"AI 到底能记住多少、按什么方式记住"的配置项。可就这么个不起眼的设置，我见过太多人栽在上面：上下文开太大，一次请求几百 K Token，成本和响应时间一起起飞；开太小，模型转头就忘了你十分钟前提的需求，反复改都改不对。这篇文章就从实际使用出发，把 context-mode 的前因后果、参数逻辑、实操配置和踩坑记录一次性说透。

如果你是刚接触 AI 编程的新手，看完至少能明白为什么别人调的 AI"记性好"、自己调的 AI"像个金鱼"；如果你是老手，后面几个关于摘要压缩和优先级排序的细节，应该也能帮上忙。核心思路很简单：不是所有信息都值得进模型，关键是让对的信息留在窗口里，把错的信息挡在门外。

1. 先从根上理解：Context Mode 到底在管理什么

1.1 上下文不是"越多越好"，而是"越准越好"

先说清楚"上下文"三个字到底指什么。在 LLM 的场景里，上下文就是模型生成回答时能够参考的全部信息，包括：系统提示词、对话历史、你贴进来的代码片段、读取的项目文件、工具返回的结果，以及这些内容本身的顺序和格式。

很多人有个直觉：上下文越多，模型理解越全面，回答越准确。这个直觉只对了一半。早期我用默认的全量上下文模式跑一个中小型项目，把整个工程的目录树、十几个关键文件一股脑塞进去，以为这样 AI 能"看到全局"。实际效果是：响应延迟从 3 秒飙到 20 秒，单轮成本翻了几倍，而且模型反而开始"注意力涣散"——明明让它改 A 模块，它却把 B 模块里的一个相似函数也一起改了。

原因是 Transformer 架构的注意力机制虽然在长序列上已经很强，但信息密度和信噪比依然会影响生成质量。塞进去 100 个文件，其中 90 个与当前任务无关，这些无关信息会稀释模型对真正重要代码的关注度，甚至引发"上下文中毒"——某些文件里的旧注释、废弃接口，反而把模型的判断带偏。所以 context-mode 的核心理念不是"管理容量"，而是"管理注意力"。容量是物理上限，注意力是质量上限。一个好的 context-mode，应该在容量约束内，尽可能把模型的注意力集中到与当前任务最相关的信息上。

1.2 三种主流工作模式，先把框架搭起来

目前主流的 AI 工具里，context-mode 通常会暴露成几个可选的模式，叫法不完全一样，但万变不离其宗。我按自己的理解把它归成三类：全量模式（Full Context）、平衡模式（Balanced）、紧凑模式（Compact/Sliding Window）。

全量模式，就是把能放的东西都放进上下文：完整对话历史、所有已打开的文件、整个项目的索引摘要。优点是信息覆盖率最高，适合长线任务、跨文件重构这种"一步错步步错"的场景；缺点是 Token 消耗猛、响应慢、信噪比低。我实测过，一个 5 万行代码的中型项目，如果开全量模式，一轮对话能把 200K 的窗口吃进去大半，成本肉眼可见地跳。

平衡模式，是当前大多数工具的默认选择。它会对上下文做一次轻量筛选：对话历史保留最近 N 轮，文件按"是否被当前消息引用"判断去留，项目结构信息压缩成摘要。说白了，工具内部会维护一个"相关性打分"，把最可能相关的内容保住，把明显无关的裁掉。它的好处是省 Token、速度快，坏处是偶尔判断失误，把该留的文件裁了，导致模型"失忆"。

紧凑模式，通常用滑动窗口实现：只保留最近 M 条消息或最近 M 个文件，更早的内容要么被丢弃，要么被一个自动生成的摘要替代。这是一种彻底的"短期记忆"策略，适合高频短对话、代码答疑、单文件改动这类任务。优点是速度极快、成本极低；缺点是模型几乎没有"长期记忆"，跨文件、跨会话的复杂任务容易崩。三种模式没有绝对的好坏，只有合适不合适，后面我会用真实场景说明怎么选。

2. 关键参数与取舍逻辑：模式不是拍脑袋选的

2.1 窗口上限：先算清楚你的"物理记忆"有多大

不管你用哪种模式，第一个要搞清楚的是模型上下文窗口的硬上限。拿目前主流的模型来说，常见的窗口有 8K、32K、64K、128K、200K，高端一些的有 1M 级别。这里的单位是 Token，不是字符，更不是文件数。一个英文单词大约 1 到 1.3 个 Token，一个中文字符大约 1 到 2 个 Token，一段普通的代码每行大约 3 到 8 个 Token。很多人以为"200K 窗口等于 200K 字符"，实际上是 200K Token，也就是说一个 200K 窗口大概只能装 15 万到 18 万个英文字符，中文则只有 10 万到 13 万字左右。

我平时会做一个很粗暴的估算：把项目里要喂给模型的核心文件字数加总，除以 0.7，得到大概的 Token 数，再乘 1.5 作为冗余系数。比如核心文件加起来 6 万字符，Token 大约是 8.5 万，冗余后按 13 万算，那 128K 的窗口勉强够，200K 的窗口比较从容。这个估算不精确，但足够帮你在选模式前判断会不会撞墙。

窗口上限决定了你迟早会触碰边界，只是时间早晚的问题。所以选模式之前，一定要先回答一个问题：我的任务到底需要多少上下文？大多数情况下，答案远比你想象的小。我见过一个重构任务，开发者在配置里贴了 40 个文件，但实际改动只涉及 6 个文件，剩下 34 个纯粹是"以防万一"。context-mode 的价值就在这种时候体现——它能把那 34 个文件挡在窗口外面。

2.2 优先级排序：窗口满了，谁能留下谁该走

当上下文总需求超过窗口上限时，工具必须做取舍，这就涉及优先级排序。发展到现在，主流的排序规则大致可以概括成四层金字塔。

第一层是系统提示词和用户的当前消息，这层永远保留，没有任何商量余地。第二层是工具调用结果和最近一两轮对话，因为它们是模型接下来推理的直接依据。第三层是被当前消息明确"引用"或"提及"的文件内容，比如你说"修改 src/utils/date.ts 里的 format 函数"，这个文件就会被标记为高优先级。第四层才是剩余的历史消息、旧文件和项目信息，它们通常会被压缩或丢弃。

理解这层金字塔很重要，因为很多"AI 突然变笨"的现象，根源就在这层排序上。比如你在一段超长对话的中途，让模型"像我们刚才讨论的那样改一下订单模块"，此时"刚才"的讨论可能已经在第三层之外、甚至被摘要压缩了，模型只能根据一个不完整的摘要猜，猜错就怪不了它。所以有一句经验之谈：每次发消息，尽量把最关键的信息放在当前消息里，而不是指望模型从历史里翻。你可以重复一下关键文件路径、核心需求、约束条件，这会让 context-mode 的排序机制自动把你的重点提到最高优先级。

2.3 摘要压缩：怎么做到"丢了细节，留住灵魂"

紧凑模式和平衡模式都会用到摘要压缩。最简单的实现是线性截断，窗口满了就把最早的消息直接扔掉。但主流的做法已经演进到 Map-Reduce 式或迭代式摘要：把早期的对话分成若干段，每段用小模型生成独立摘要，再把这些摘要按顺序合并成整体摘要，必要时再做一次压缩。

这种做法的好处是，即使 20 轮前的细节被丢弃，关键需求、已确认的决策、历史报错信息还能以浓缩的形式保留下来。但问题也随之而来：摘要是一个有损压缩过程。小模型在总结时，可能会丢掉一些"当时觉得不重要、后面却至关重要"的细节，比如某个特殊的边界条件、某个用户指定的命名风格、某条埋得很深的业务规则。

我自己踩过一个典型的坑：让 AI 开发一个批量导入功能，早期对话里明确说过"导入失败时，单条错误不能中断整个批次，要收集所有错误后统一反馈"。这句话在原始对话里出现过，但因为后续又聊了十几轮别的细节，它被推进了历史区，最终被摘要压缩成"导入失败时需要反馈错误"。结果模型生成的代码，遇到第一条错误就直接中断——完全不是我想要的行为。这件事让我养成了一个习惯：任何"不能违背的硬约束"，我都会在系统提示词里单独写一遍，或者在当前消息里反复强调。摘要可以作为背景信息的存储器，但绝不能当合同来用。

3. 实操：从三个真实场景看 Context Mode 怎么落地

3.1 场景一：长对话开发调试，选平衡模式

先说我自己最常用的场景：连续几小时在同一个会话里调试一个功能。早上从"帮我写个接口"开始，中间经历了"参数校验不对""数据库报唯一约束冲突""前端传参格式要调整"，到下午可能还在这个会话里改 bug。

这种场景，我强烈建议平衡模式。原因有二：第一，任务跨度长，全量模式会把早期大量探索性的、已经过时的讨论也留在窗口里，白白占用 Token 还干扰判断；第二，紧凑模式又太激进，可能把关键的历史决策丢掉。平衡模式结合了两者的思路：保留足够多的近期上下文，同时把远期内容压缩成摘要。

实际操作中，我会配合几条配套动作。每完成一个小里程碑（比如接口调通、bug 修复），在会话里发一条简短总结："已完成 X，当前状态是 Y，下一步是 Z"。这条总结会把该阶段的关键信息钉进近期上下文，即使之后被压缩，摘要也能准确保留。不要在一个会话里塞多个不相干的任务，早上的需求做完了，下午要做另一个完全不相关的功能，建议新开会话。跨任务混在同一会话里，是 context 污染最严重的操作。还要定期检查工具面板里的 Token 占用，如果发现 128K 的窗口已经用了 100K 以上，而任务还远远没结束，果断开一个新会话，把必要的上下文手动整理过去。实测下来，平衡模式加定期总结加任务分会话，能把长对话场景的失败率从 30% 降到 5% 以下。

3.2 场景二：多文件项目重构，用全量模式但必须圈定范围

和长对话调试相反，跨文件重构是少数真正需要全量模式的场景。比如你要把一个单体模块拆成多个 service，或者调整整个项目的目录结构，此时模型需要同时理解十几个文件之间的依赖关系，任何"只见树木不见森林"的模式都容易造成结构性错误。

全量模式的价值在于，它能一次性把相关文件都放到模型面前，让模型在做牵一发而动全身的决策时，能看到所有"被牵动的地方"。我做过一次 30 个文件的目录迁移，用全量模式让 AI 辅助完成依赖更新，一次通过的准确率明显高于平衡模式。但全量模式必须配合"手动圈定范围"。我见过有人把整个 monorepo 的根目录拖进上下文，结果工具直接开始读取 node_modules 和构建缓存，窗口瞬间爆炸。正确的做法是：在配置里显式指定要包含的目录和文件，排除 node_modules、dist、.git 这些无关内容。很多工具的 context-mode 都支持 include/exclude 规则，用好了，全量模式也能保持高信噪比。

还有一个经验：全量模式下，把任务拆成阶段进行。比如先让 AI"只分析依赖关系，不要改代码"，再让 AI"基于分析结果生成改动清单"，最后再"按清单逐文件修改"。这样每一阶段模型读的都是同一批文件，但注意力聚焦点不同，不容易被上一阶段的输出带偏。这个"先分析、再计划、后执行"的分层方法，对任何复杂任务都通用，本质上是把一个大窗口任务拆成了三个小任务，每个小任务的上下文需求都大幅下降。

3.3 场景三：文档问答和碎片任务，紧凑模式就够用了

第三种场景是高频短对话：问我某个 API 怎么用、这个报错什么意思、帮我格式化一段代码。这种任务的特征是"单轮独立"，上下文几乎不需要记忆。此时用紧凑模式（滑动窗口）是最高效的选择。

紧凑模式会把窗口限制在最近几轮对话内，旧的对话全部清掉。可能有人担心：那我上一轮刚贴的错误信息，这一轮它不就忘了吗？实际上不会，滑动窗口保留的"最近几轮"通常足够覆盖一个简单问答的完整生命周期。只有当你在一轮的回复里又追问五六个子问题，才可能把最初的错误信息挤出去。用紧凑模式，我测过一组任务的平均响应时间，比全量模式快 2 到 3 倍，Token 消耗减少 60% 以上。对文档问答这种场景，这省下来的时间和成本就是纯赚。

不过要提醒一点：如果某个碎片任务做着做着变复杂了，比如从"这个报错什么意思"变成了"帮我全面排查整个服务的内存泄漏"，一定要手动切换到平衡或全量模式。工具的自动模式检测不一定能及时发现任务复杂度上升，靠人眼判断最靠谱。我一直把 context-mode 的切换当成开车换挡：平路用五档（紧凑），爬坡换二档（全量），别指望一个档位走完全程。

4. 常见问题与排查技巧实录

4.1 模型"忘记"需求，先别骂它，先查上下文

几乎每个用 AI 编程工具的人都发过这样的火：十分钟前让它"用 A 方案"，十分钟后它回答的全是 B 方案，跟完全失忆一样。我排查这类问题有一套固定流程。

第一步，检查当前模式。如果用的是紧凑模式，大概率是滑动窗口把早期需求挤掉了。第二步，查看工具面板里的上下文占用和内容列表，确认需求对应的对话轮次是否还在窗口内。第三步，检查摘要历史，看关键需求是否被压缩成了残缺信息。找到了原因，修复就很简单：把需求重新在当前消息里完整复述一遍，或者把关键约束写进系统提示词。这里我给一个小技巧：如果你频繁遇到"失忆"，可以在每次对话开头加一段"任务备忘"，格式很简单——项目名称、当前任务、已完成部分、关键约束、下一步。这段备忘会作为当前消息的高优先级内容进入上下文，相当于给模型贴了个便签。

4.2 Token 消耗异常，通常不是模型的问题，是模式的问题

有次我在跑一个数据清洗脚本的调试任务，打开 Token 统计一看，平均每轮对话消耗超过 8 万 Token，而任务本身只需要几千。一查才发现，工具开了全量模式，把整个数据集目录下的几十个 CSV 预览文件全读进了上下文。每个 CSV 的头部和样本行都完整展开，数据量瞬间失控。解决办法很简单：在 context-mode 的排除规则里，把数据文件、日志文件、二进制文件全部排除。

再补充一个提醒：凡是 .csv、.log、.jsonl、.png、.pdf 这类不适合直接做上下文的文件，要么不要放进 include 范围，要么在配置里用 exclude 明确排除。我后来还在工作区里建了一个 .contextignore 文件，把常见的重文件类型和构建工具目录都列进去，之后 Token 消耗直降 70%。另外，输出侧的 Token 也要算。有些模型输出一个完整文件时，Token 消耗甚至超过输入。如果你的工具支持"只输出 diff"或"只输出修改部分"，一定要开，这能省下一大截成本。

4.3 摘要压缩把关键约束丢了，那就别让它丢

前面说过摘要是有损的，但有没有办法减少损失？有。我总结了两条。

第一条，高频关键信息要"多点冗余"。重要的约束，在系统提示词里写一次，在任务备忘里写一次，在当前的指令里再写一次。同一信息在上下文里出现多次，就算被压缩，也不太可能全部丢光。冗余是应对有损压缩最简单粗暴但有效的手段。第二条，选择合适的摘要触发阈值。大多数工具的 context-mode 允许你设置一个触发压缩的阈值，比如"当窗口占用超过 80% 时开始摘要旧内容"。很多人默认用这个值，但我实测发现，80% 触发往往不够主动，因为从触发到真正生成摘要，中间还有好几轮对话，窗口很容易直接冲满 100%，导致模型强制丢弃而不是优雅压缩。我建议把阈值调到 60% 到 70%，代价是摘要会更频繁地触发，换来的却是"模型始终有足够空间处理新信息"，从整体稳定性看是划算的。

4.4 排查问题速查表

这张表是我自己贴在工位边上的速查卡，每次排查问题先对着看一遍，能省下不少时间。别小看这些看起来"低级"的问题，它们占了日常 AI 编程事故的大半。

5. 写在最后的一个实操体会

用 context-mode 这几年，我最大的感受是：它考验的其实是你对"信息"的理解。你以为自己在管理 AI 的记忆，实际上是在管理一堆信息的优先级、时效性和信噪比。好的上下文，不在多，而在准；再强的大模型，也需要你帮它筛选该看什么、不该看什么。

最后再分享一个小技巧：每次开新会话，都花十秒钟在第一条消息里写清楚"你要做什么、你已知什么、你希望 AI 输出什么"。这个动作的成本几乎为零，但对所有模式的效果提升都肉眼可见。把信息结构想清楚了，context-mode 无论选哪个，都不会差到哪里去；反过来，信息本身一团糟，再花哨的模式配置也救不回来。