企业官网建设流程全解析

用了半年多 AI 结对编程，我踩过最大的坑，不是模型不够聪明，而是我把整个仓库的代码一股脑倒给助手，然后怪它答非所问。直到我把“context-mode（上下文模式）”真正用起来，AI 才从“会说话的搜索引擎”变成了“真懂我项目的结对程序员”。

context-mode 这名字听起来像某个命令行工具的开关，实际上它代表的是一个思路：在 AI 编程助手里，你给模型喂哪些代码、哪些说明、哪些历史对话，以及以什么顺序和权重喂进去。它不是某个厂商的专属功能，而是所有 AI 辅助开发工具都在反复优化的一件事。谁把它玩明白了，谁才能真正享受到 AI 写代码的红利；谁忽略它，谁就会一直停留在“AI 生成一段代码，我复制粘贴再改半天”的低效循环里。

这篇文章不聊大道理，就讲清楚三件事：context-mode 背后的原理是什么、我在实际项目里怎么配置和切换它、以及遇到“AI 突然变笨”的情况该怎么排查。无论你用的是 Copilot、Cursor、Codex，还是开源方案 Continue 这类插件，理解这套逻辑之后，都能让你的 AI 助手生产力上一个台阶。

1. 先拆清楚：context-mode 到底在解决什么问题

1.1 上下文不是“越多越好”，而是“越对越好”

最直观的误区，是把 AI 助手当成一个内存无限的容器。实际上，现在的模型都有上下文窗口限制，比如 32K、64K、128K 甚至 200K token。听起来 20 万 token 很多，但一个中型项目的源码动辄几十万行，再加上 README、接口文档、配置文件、最近的 git diff，轻而易举就能把窗口塞满。

即便窗口真的够大，模型面对过量的信息时，注意力会在这些信息之间平均分配。一句话解释就是：你塞进去 10 个文件，其中有 3 个跟当前任务完全无关，模型就要花一部分“脑力”去理解这些无关文件，最后给出的代码可能就会“跑偏”。这不是玄学，是 Transformer 架构注意力机制的固有特性——关键信息会被淹没在噪声里。

context-mode 的核心，就是帮你做信息筛选和优先级排序。它像一个阅卷老师，在把试卷递给答题选手之前，先帮你划掉无关的段落、标出重点内容，确保选手只看到最该看的那些题。

1.2 context-mode 的三个档位：全自动、严格锁定、手动投喂

我用了这么久的实际体会是，上下文控制可以分成三种模式，大多数工具也是围绕这三种模式设计的：

• 自动模式（Auto）：工具自己判断哪些文件和你当前的问题相关。它的逻辑通常基于全仓库索引、语义搜索、最近打开过的文件列表等信号。好处是省心，坏处是判断不一定准——我在好几个工具里都遇到过，它自作主张地把某个老旧的工具类文件塞进上下文，然后越想越偏。
• 严格模式（Strict / Focus）：只使用你在当前对话里明确标记的内容，比如通过 @file、@folder 显式引用的代码，或者你在项目规则文件里写明白的约束。这种模式下 AI 不会自己乱抓文件，泛化能力会下降，但准确率最高，特别适合“改这个函数，千万别动其他地方”的场景。
• 手动投喂模式（Manual）：完全由你控制粘贴内容、指定文件、控制数量。多见于聊天式工具里的“添加上下文”按钮，或者你把某段代码直接复制进对话框。自由度最高，但也最容易因为怕麻烦而偷懒不喂。

我的建议很直接：默认使用自动模式干粗活，遇到任何需要精确修改的场景，立刻切到严格模式。大部分人说“AI 不听话”，其实不是 AI 的问题，是你没给它划好工作范围，它只好满仓库乱找依据。

2. 把技术细节拆开看：context-mode 的原理

2.1 上下文窗口怎么算：token 的数学题

搞懂 context-mode 的前提，是先搞懂 token。中文一个汉字大约对应 0.6~1 个 token，英文一个单词约 1.3 个 token，代码因为符号密集，平均每个字符约 0.25 个 token。听起来抽象，我给你个具体数字：一个 500 行左右的 Java 文件，大概是 2500 到 3500 token。

假设你的 AI 工具上下文窗口是 64K token，听起来能装下 20 个这样的文件，但你别忘了，系统提示词（system prompt）要占一部分，工具定义占一部分，你和 AI 的对话历史更是一点一点积累起来的。到最后真正留给“代码内容”的空间，可能也就 30K 到 40K token。

所以我会在项目里做一道简单的算术题：当前任务涉及哪些文件？总 token 数大概多少？对话历史攒了多少？如果加起来超过窗口上限，我就会主动做减法——精简对话历史，或者把那些文件里无关的注释、被注释掉的代码删掉再喂。这不是强迫症，这是确保 AI 不会因为上下文被截断而“失忆”的唯一办法。

2.2 上下文排序与截断策略：后面进来的会挤掉前面的

很多工具在处理长上下文时，不会简单地“截断尾部”，而是有一套优先级算法。一般规律是：越靠近末尾的内容权重越高，系统指令和用户最新消息在最高优先级，中间的旧对话最容易被压缩或丢弃。

这带来一个非常实际的坑：如果你在对话中段让 AI 记住一个关键前提，聊到后面它可能真的会忘掉，因为那段内容已经被压扁了。我以前总骂“AI 记忆差”，后来才意识到，是我把重要信息放在了会被截断的位置。

正确做法是：关键信息要么通过 @ 引用的方式固定在参考文件里，要么在每次提问时都重申一遍。比如我需要 AI 基于某个配置文件来写代码，我会在每一条消息里都带上“请参照 config/application.yml 的现有配置”，而不是只在最开始说一次。

2.3 为什么同样的提示词，不同工具表现不一样

经常有人问我：“同一个问题，为什么 Copilot 给的结果和 Cursor 差的这么远？” 这里面的核心差异，就在于各家 context-mode 的实现机制。

• 索引方式：有的工具会用 RAG（检索增强生成）做全仓库向量检索，把和问题语义最相关的代码块拉进来；有的只是靠正则规则匹配引用文件名。前者更智能，但有时会召回一些“语义相似但实际无关”的代码。
• 重排序策略：有些工具会对检索到的代码块做重排序，把最相关的排在最前面，不相关的直接过滤；有些则不做，把一堆“沾边”的文件全塞进窗口。
• 系统指令强度：有些工具默认会在系统提示词里写“只使用用户明确引用的文件，不要自行猜测”，有些则写“你可以访问整个代码库，积极搜索相关信息”，这直接决定了 AI 会不会“自作聪明”地到处翻代码。

所以你不用迷信某一个工具。理解了 context-mode 的原理，换个工具只是换一套参数和习惯，核心的“少喂无关代码、明确圈定范围、维护关键信息位置”这三条原则是通用的。

3. 实操：把 context-mode 用起来的具体套路

3.1 第一步：用项目规则文件固定“长期上下文”

很多项目的 AI 辅助编程用不好，不是因为工具不行，而是因为项目缺少一份 AI 能读的“使用说明书”。我的做法是在仓库根目录维护一份简明扼要的项目说明，名字各家工具约定不同，有的叫AGENTS.md，有的叫CLAUDE.md，也兼容通用的CONTEXT.md，本质上都是给 AI 看项目背景的规则文件。

内容固定包含这几块：

• 项目技术栈：比如“Spring Boot 3 + MyBatis-Plus + MySQL 8”，一句话让 AI 不用猜。
• 代码风格约定：比如“Controller 不写业务逻辑，一律走 Service；DTO 不用 Lombok；日期时间统一用 Instant”。
• 目录地图：告诉 AI 哪些目录是核心业务、哪些是自动生成、哪些不要动。
• 常见命令：本地启动命令、测试命令、构建命令。

这份文件最大的价值，是它像一份“系统提示词”一样，每次 AI 工具被启动时会自动加载进上下文，等于你每次对话都带上了一份精确定位的项目说明书，而不是靠 AI 自己去猜你的代码结构。

3.2 第二步：在对话里使用显式引用圈定范围

这一步是很多新手最常忽略的。直接在输入框里写“把用户服务改一下”是典型的下策——因为“用户服务”是个模糊概念，AI 可能去翻 10 个相关文件。更好的写法是：

我建议的格式是三个要素齐备：

1. 目标文件：用 @ 或 # 符号显式带上文件路径；
2. 约束条件：说明允许改动哪段、禁止涉及哪些范围；
3. 预期产出：你要的结果类型，比如“重构方法签名并更新所有调用处”。

我举一个实际工作中的例子。以前我让 AI 帮我给一个支付回调接口加日志，它生成了一大堆新代码，还顺手改了我配置文件里的初始化逻辑。后来我改成这样写：

给PaymentCallbackController.java中的handleCallback方法增加结构化日志，要求使用LoggerFactory.getLogger，不要改动该方法的签名和返回值逻辑，也不要修改任何其它文件。

同样的需求，只多了一句“不要修改任何其它文件”，AI 的输出就老实了很多。这不是什么魔法，而是你主动封死了 AI 发散思维的空间。

3.3 第三步：该切严格模式时别犹豫

我在做两类任务时一定会切到严格模式：

• 重构 / 高风险修改：动老代码的时候，最怕 AI 顺手“优化”掉一些看起来冗余但其实有依赖的逻辑。严格模式下它只看你喂给它的文件和规则文件，不会去“参考”别的代码，反而更安全。
• 精确提问：比如“这个查询为什么会慢？”如果你以自动模式提问，它可能会把整个数据访问层翻一遍；换成严格模式并手动粘贴那条 SQL 和对应 Mapper 方法，得到的原因通常会直击要害。

关于严格模式，一个常见担忧是“它会不会因为看不到上下文而给出错误答案？”我的经验是：严格模式下你确实要承担“主动投喂”的责任，但投喂的粒度可以很精细——你可以只粘贴方法体、只粘贴报错堆栈、只粘贴一条 SQL，这比自动模式抓来的半屏无关代码高效得多。

3.4 一套可复用的 context-mode 提示词模板

直接用这三套，是我在不同项目里反复验证过比较稳定的风格：

• 任务限定模板：请修改 [文件路径] 中的 [方法/函数名]，实现 [具体需求]。要求：基于 [参考文件路径] 的现有风格完成，不改变 [某接口签名]，不修改 [禁止文件列表]。完成后列出所有受影响文件。
• 问题定位模板：我在 [场景描述] 遇到问题：[错误信息或现象]。相关代码在 [文件路径:行号范围]。请只基于这些代码分析可能原因，不要推测与这些代码无关的因素。
• 代码审查模板：请以严格模式审查 [文件路径] 的 [提交/代码块]，重点关注 [并发安全 / 性能 / 边界条件] 三个维度。只报告有实际风险的问题，忽略代码风格问题。

模板不是死板的，关键在于每次提问前先问自己一句：“我有没有给 AI 足够的锚点，又有没有给它划好边界？”答案是“给了”的时候，你的 context-mode 就算用对了。

4. 踩坑记录与排查指南

4.1 典型症状和对应解法

用 context-mode 时间长了，你会发现自己能靠“症状”快速判断是上下文的问题，还是模型本身的问题。我整理了一张排查表：

这张表的价值在于，大多数情况下“AI 变笨”都不是模型能力衰减，而是上下文管理出了问题。你可以把这张表打印出来贴在显示器边上，出了问题先照着查一遍运气成分会小很多。

4.2 上下文“污染”的三种典型路径

“污染”是我起的名字，指的是无关或有误导性的信息进入了上下文，导致 AI 的判断被带偏。根据我的实操经验，污染通常来自三条路径：

• 历史对话残留：你上一个问题聊的是 A 模块，接着问 B 模块的问题，AI 还带着一堆 A 模块的记忆。如果你不新开一个会话，A 模块的上下文就会持续干扰 B 模块的回答。所以我的习惯是：换任务，必开会话。宁可重新描述一遍项目背景，也不让旧话题干扰新任务。
• 自动检索误召回：自动模式下的语义搜索不是百分百准确的。尤其当你的代码库里有多个同名的类或方法时，召回结果经常会张冠李戴。应对办法是：注意观察工具界面展示的“引用文件列表”，如果出现了你没想到的文件，立刻手动移除。
• 规则文件本身打架：项目里如果有多个规则文件（比如根目录一份、子目录又有一份），且内容互相矛盾——AI 有时会选择后加载的那份，有时选择文件里篇幅更大的那份。这不是 AI 智障，是规则文件让 AI 产生了困惑。正确做法是保证规则文件唯一权威，子目录只补充细节、不推翻根规则。

4.3 一个容易忽略的小窍门：让上下文“过期”

这是我用了很久才悟到的一个技巧。AI 编程助手保持上下文的方式，和人的工作记忆很像——你不停往里面塞东西，它会慢慢“选择性遗忘”。与其让 AI 带着旧上下文“负重前行”，不如主动帮它清理。

具体做法是：完成一个功能后，我会故意发一条消息给 AI，类似“现在请忽略刚才的所有讨论，我们切换到新任务”，或者干脆新建会话，然后把前一个任务的结论（比如“XX模块已经改造完成，入口在 XXService.java”）作为一条精简背景重新喂进去。

这个小动作看起来多此一举，实际上对后面的准确率提升非常明显。因为你会被迫去总结上一个任务的成果，而 AI 也能轻装上阵，不用在长长的对话历史里翻找你要的新任务相关的旧信息。这也算是 context-mode 在“会话维度”上的最佳实践。

我后来为什么离不开 context-mode

说句实在话，像我这种业务代码多、老项目占大头、还经常需要在几个模块之间来回跳的开发者，之前总觉得“给 AI 喂上下文”是浪费时间——有那个功夫我自己都写完了。可真把 context-mode 玩溜之后，我发现那些“浪费的时间”正是 AI 输出质量的分水岭。

现在我开一个新任务的标准动作只有三步：看一眼项目规则文件需不需要更新、判断该用自动还是严格模式、把最新代码的关键文件 @ 进对话。整个过程不超过一分钟，省掉的却是后面改 bug 的半个小时。这不是玄学，是你和 AI 之间的沟通精度变高了——你说的话它能听懂，它给的代码你能直接用，这才是结对编程该有的样子。