企业官网建设流程全解析

1. 这个叫 context-mode 的东西，解决的到底是什么问题

先聊点实在的。如果你最近在折腾 AI 编程工具，或者花时间调过 Cursor、Copilot、Claude Code 这类带对话式编辑能力的编辑器，你大概率会在设置界面、快捷键列表、或者某些深度玩家的配置文件里看到一个词：context-mode。

我第一次遇到 context-mode 是在一个深夜调 AI 辅助重构的现场。当时我选了一大段核心逻辑，敲了一行复杂指令想让 AI 按新接口重写，结果它完全无视我选中的代码，直接从整个项目范围理解任务，给我返回了一份“参考意义大于实用意义”的修改方案。那一刻我意识到，大部分所谓“AI 不听话”的抱怨，根子不在模型能力，而在上下文模式没调对。

context-mode 说白了就是：AI 工具在接收你的指令时，到底把哪些内容当作“当前背景信息”来参考。它决定了 AI 的“视野范围”——是全项目、当前文件、某个文件夹，还是你手动圈选的几段代码。这个机制并不是某个工具的独门绝技，而是近两年几乎所有 AI 辅助编程产品的共同底座，只是不同工具给出了不同的切换方式和暴露程度。

这个模式对三类人特别有价值。第一类是深度依赖 AI 写业务代码的开发者，模式切换直接影响生成质量；第二类是团队里负责制定 AI 编码规范的技术负责人，理解了它才能在配置文件里做出正确取舍；第三类是刚开始接触 AI 编程工具的初学者，明白这个概念可以少走很多弯路——很多奇怪的“AI 抽风”其实只是模式选错了。

我接下来要讲的，是 context-mode 在主流工具中的实际表现、背后的原理，以及我在生产环境里踩过的坑和总结出的操作经验。不堆术语，尽量说人话。

2. 为什么需要模式这个东西：没有边界的上下文，等于没有上下文

在讲解具体操作之前，我想先花点篇幅说一说 context-mode 存在的原因，因为这决定了你后续所有选择的方向。别急着跳过去，这部分的认知价值比快捷键列表高得多。

2.1 不设边界的 AI 会把你的项目“读爆”

很多人第一次用 AI 编程工具时都有过一个朴素想法：我把整个项目都喂给它，它不就能帮我改任何地方了吗？理论上没错，但实际上有两个硬约束。

第一个是 token 限制。模型的输入窗口是有限的，即使是 200K 上下文窗口的大模型，也无法容纳一个中大型工程的全部代码。强行塞入会触发截断，而截断往往发生在关键位置——模型看到的项目是不完整的，它的理解就是残缺的。

第二个是注意力稀释。我自己做过一个实验：把一段 bug 修复任务同时放到“仅当前文件”和“整个工作区”两种模式下执行，前者一次就能定位到问题函数，后者却给了三套方案，其中两套扯到了毫不相关的模块。原因在于模型需要对所有输入内容分配注意力权重，无关信息越多，关键上下文的相关性权重就越低，这在直觉上有一个很形象的类比：你让人在一堆杂物里找钥匙，和他的桌上只有一把钥匙时找钥匙，效率完全不是一回事。

context-mode 存在的第一个理由，就是给 AI 划定一个合理的观察范围，避免信息过载导致的质量崩溃。

2.2 相关性不是“距离”决定的，是任务决定的

另一个更深层的原因是，AI 需要知道它“为什么”要关注某段代码。一段代码和当前任务的相关性，无法单纯靠它在磁盘上的路径、文件大小或者与当前文件的物理距离来判断。

举个例子。你在修复一个支付回调的 bug，相关逻辑可能分散在三个文件里：控制器入口、服务层校验逻辑、数据库模型定义。这三个文件在目录结构上相距很远，但如果 context-mode 只提供“单文件模式”，AI 就看不到校验逻辑；如果只提供“全项目模式”，AI 又会把日志工具、路由配置这些不相干的东西也读进来。

好的 context-mode 实现，其实是在做一层“任务感知的相关性筛选”。它通过你选中的代码、当前打开的文件、最近编辑过的内容、你在指令中引用的符号这些信号，来推测哪些内容对这个任务真正有用。

注意：这个“推测”意味着 context-mode 不是一个单纯的开关，而是一个动态的过滤机制。理解这一点很关键。很多人设置好模式之后就再也不管了，但同一个模式在不同任务下的表现差异巨大，原因就在这里——过滤机制需要信号输入，而你的操作方式就是信号源。

2.3 成本问题：模式选对了，钱包才能省

还有一个非常现实的问题：钱。使用 API 方式接入 AI 编程工具的话，上下文越长，单次调用费用越高。如果每次都把全项目塞进去，基本上一次对话就是几十万 token 的消耗，一次任务纠结几轮，一天下来费用相当可观。

订阅制工具虽然不直接按 token 收费，但上下文过长会导致响应时间拉长、限流概率增大，在实时协作场景下非常影响体验。把 context-mode 调好，本质上就是在控制每次请求的信息量，让有限的预算花在刀刃上。

这三个原因（上下文窗口限制、注意力稀释、成本控制）叠加在一起，你就能理解为什么 context-mode 不是“锦上添花”的功能，而是 AI 编程工具在工程实践中必须解决的问题。

3. 主流的 context-mode 分类：从单文件到全局，中间隔着三层

不同工具对 context-mode 的实现方式各有差异，但归纳下来，可以分成四个层级。理解这四个层级，你在任何工具里都能快速找到对应的调节方式。

3.1 单文件模式

这是最基础的 context-mode，AI 的视野范围仅限于当前打开的文件再加你输入的指令。适合做局部重构、格式化、单文件 bug 修复这类边界明确的任务。

在 Cursor 中对应的是没有额外加 @ 引用、且在设置里关闭了 embeddings 检索的状态；在 Copilot 中则表现为一般的 Chat 会话只读当前文件或选中内容。

优点是响应快、token 消耗低、结果稳定可预期。缺点也很明显：当函数定义在另一个文件时，AI 极容易“编造”一个不符合实际的函数签名。

我在用单文件模式时踩过最大的坑，是让 AI 修改一个模块的接口，但它看不到接口调用方的代码，结果改完内部实现之后，调用方全部红色报错。这就是典型的模式适用范围判断失误。

3.2 相关文件模式

相关文件模式是当前 AI 编程工具中最主流的默认选项。它的工作逻辑是：AI 根据当前任务的文本提示，在项目里检索与语境最相关的若干个文件，自动纳入上下文。

在 Cursor 中，这表现为打开 Auto-index 之后的自动检索；在 JetBrains 的 AI Assistant 里，也有类似的“Related Files”机制；在 Continue 这类开源扩展中，则是通过 embedding 相似度检索 Top K 文件实现。

这个模式对“修改跨文件逻辑”的任务效果很好。比如你要改一个接口的参数结构，AI 通过相关性检索可以自动找到所有使用这个接口的调用方，一并纳入考虑，从而给出更完整的修改方案。

但相关文件模式不是没有缺陷。检索质量高度依赖 embedding 质量，而 embedding 对“语义相同但措辞不同”的代码匹配效果并不算好。举个例子，如果你的代码里方法名字是doSave，但你对话中使用的是“把数据持久化”，检索系统未必能把这两者关联起来。

这时候就需要你手动补充信号：在指令中明确提方法名、类名，或者干脆用 @ 符号显式引用文件。手动指定优先级通常高于自动检索。

3.3 目录/文件组模式

这个模式让你显式指定 AI 的视野范围。在 Cursor 里可以用/或者 @ 符号引用文件夹；在 Claude Code 里可以通过明确的方式设置调用范围；在开源工具 Continue 里则可以通过.prompt文件配置固定的上下文集合。

目录模式适合做“有明确边界的跨文件任务”。比如你要重写某个模块，你已经明确知道这个模块涉及controller、service、repository三个目录，那你划定范围之后，AI 就会把这三个目录下的内容作为背景信息，而不会把网撒到整个项目里。

这里的一个实操经验是：目录范围宁小勿大。我在做模块重写时，通常会先手动观察目标目录树的规模，如果超过 20 个文件，再按子目录拆分任务，而不是一次性全选进去。一次引入太多文件，AI 的注意力会被摊薄，反馈质量的下降非常明显。

3.4 全项目模式

全项目模式就是让 AI 对整个代码库建立索引并基于全部内容响应。适合做架构分析、跨模块依赖梳理、新需求影响面评估这类“需要全局视野”的工作。

但请注意，全项目模式是四个模式里最“贵”的。响应慢、token 消耗大，而且经常出现检索结果被不相关内容污染的情况。我的建议是：把它当成侦察工具，而不是常规编辑工具。用全项目模式向 AI 提问“这个改动会影响哪些模块”，得到结果后再切换到相关文件或目录模式做具体修改。

为了更直观，我这里整理了一个对照表：

4. 实操要点：以主流编辑器为例，把 context-mode 调到顺手状态

理论上限是四个层级，具体到工具里的操作则各有微妙之处。我用过的工具集中在 Cursor、VS Code 的 Copilot 以及一些开源方案上，下面从实操角度讲一讲怎么把它们调顺。

4.1 Cursor 里的上下文设置：@ 是一切信号的源头

Cursor 的 context-mode 控制非常依赖 @ 符号的引用系统。你可以 @ 一个文件、一个文件夹、一个文档，甚至是代码库中某个具体的符号，这些显式引用的优先级永远高于自动检索。

实操建议：

• 在 Chat 模式下，如果你想让 AI 只基于指定文件回答，务必用 @ 明确引用并加入必要的说明。不要只把文件名丢进提示词，文件名的语义含量太低了，AI 未必会给出你期望的重视程度。
• 在 Composer（现在叫 Agent 模式）下使用代码编辑功能时，Cursor 会同时考虑当前文件和引用文件。这时候注意看页面底部的上下文列表，它会向你展示当前 Prompt 包含了哪些内容。我经常在里面发现一些“意外”的文件——某次 Auto-index 把一个测试文件当成相关文件塞了进来，这直接导致 AI 被对立面的测试逻辑给带偏了。
• 模型设置里有 Rules 字段（旧版叫 User Rules），可以在里面写入固定指令，例如“你不必查看除了用户 @ 引用以及明确说明范围以外的任何文件”，这对收紧模式边界非常有效。

有一个小技巧：在 Cursor 中，命令面板可以快速查看当前会话的上下文清单。每次生成结果质量出现明显下降时，我第一件事不是换提示词，而是查这个清单，看看哪些不该进来的文件混进来了。

4.2 VS Code + Copilot：相关文件是默认，也是最容易翻车的地方

VS Code 的 Copilot Chat 在绝大多数情况下会启用相关文件自动带入的机制，但在大型项目中，它会产生“相关性爆炸”。

比如你打开了一个工具函数文件，然后在 Chat 里问“这个函数的性能瓶颈在哪里”，Copilot 会尝试把工具函数的调用方也检索进来，结果检索命中几十个文件。这些文件未必对回答有实质帮助，却把上下文塞得很满。

我的应对方式：

• 对话前先在编辑器里打开真正相关的文件，让“已打开文件”的信号尽量集中在目标代码上。
• 提示词中使用明确的范围词，例如“仅基于当前文件分析”，配合具体行号、具体函数名，可以有效绊住检索系统扩散的脚步。
• 需要跨文件时，我会直接在提示词中粘贴关键代码片段，而不是依赖自动检索。代码片段加注释，转述意图，这个“手抄”模式在 Copilot 里比依赖自动引用稳定得多。

必须要承认的是，Copilot 在这方面的控制力度比 Cursor 粗糙一些，对使用者自身的上下文纪律要求更高。

4.3 轻量级团队协作场景：把 context-mode 固化进配置文件

如果你在做团队级应用，让每个成员各自理解 context-mode 是不太现实的。更靠谱的方式是在项目根目录放入规范文档，把这些模式规则固化成团队的执行公约。

我的团队文档里写的是三段式约定：

1. 单文件改动（行级改动、函数级重构）：只允许使用单文件模式，不引入任何其他文件。
2. 跨文件小规模改动（涉及 2-5 个文件的接口调整）：默认使用相关文件模式或手动指定文件组，并要求 AI 输出影响文件清单后再动手。
3. 大面积重构（涉及模块级改动）：必须先在文档里写清楚改前方案，列出涉及文件，之后才允许在指定目录模式下执行。

这个约定实施之后，AI 生成垃圾代码的概率显著下降。核心原因在于：它倒逼团队成员在调用 AI 之前先想清楚任务边界——想清楚边界之后，模式自然就对了。

4.4 场景化选择建议

我把场景和模式选择做成了一张速查表，可以贴在工位旁边：

5. 踩坑实录：我在 context-mode 上载过的几个跟头

这一部分是我最想分享的。理论谁都会讲，但实战场上的教训才真正值钱。

5.1 全项目模式下做局部修改，结果是灾难

有一次我在一个有几万行代码的项目里，开着全项目模式让 AI 改一个路由文件里的响应格式。AI 花了很长时间“思考”，最后给了一段把路由和数据库模型缠绕在一起的新代码——它把不该触发的一堆业务逻辑也重写了。那次改动的 Review 花了四个小时，最后全盘回滚。

教训：局部任务永远不要全项目模式。你以为它会更“谨慎”，实际上它是把相关性权重分配到了很多无关代码上，导致它对“局部”发生了什么产生了错误理解。

5.2 @ 引用了文件，但 AI 是把整个项目都读进去了

有一次我在 Cursor 里明确 @ 引用了一个文件，指令中说“只改这个文件”，结果 AI 还是在我没提到的文件里加了一份导出。查上下文清单后发现，Auto-index 自动检索到的文件也在清单里，而且权重并不低。

从那之后，我在关键任务中都关掉了自动索引，或者至少在指令里明确注明禁用检索。上下文清单检查变成了我的肌肉记忆。

5.3 拥抱“增量上下文”而不是“重置上下文”

很多人在一次任务里反复让 AI 生成修改，但从来不清理对话。累积到一定轮次后，AI 对最初的代码状态产生了错误记忆——因为后续轮次里出现了大量被修改后的代码片段，而最初的 baseline 它已经记不清了。

我的做法是：每次大的改动阶段结束后，新建会话，重新导入关键文件，重新设置 context-mode。保持对话的“任务聚焦”，避免上下文污染。这在 context-mode 的使用中属于最容易被忽略、但影响最大的一个习惯。

5.4 不要盲目信赖“自动检测相关文件”

自动检测相关文件在一些小型 demo 项目里表现很好，因为文件少、语义关联清晰。但在微服务架构多仓库工程里，自动检测经常把依赖中同名符号所在的文件给错配进来。遇到语义混淆的情况，我宁可手动引用文件、手动划定范围，也不要依赖自动检测的“智能”。

我分享一下排查思路：当 AI 输出里出现了你完全没有提到、也不在预期范围内的文件路径时，马上停止接受它的方案。先回到上下文清单里找出这个文件是什么时候被引入的，然后清理掉再继续。不要觉得这个环节浪费时间，我实测下来，这是我避免无效代码产生的最有效手段。

5.5 处理“AI 记忆漂移”的规程

所谓记忆漂移，是指 AI 在长对话过程中对原始代码状态的记忆发生偏差，到了后半程它会把之前修改过但后来废弃的代码当作现存的真实状态。

我现在的规程是：任务中涉及三处以上文件的改动时，每完成一处的修改，就要求 AI 重新读取当前最新状态的文件，必要时重新启用单文件模式核对。不要假定它会“知道”文件已经被改成了什么样子。

这个冲动源于一次惨痛经历：我让 AI 重构一个服务类，它自己改了内部实现，但在生成下一个文件的时候却用了旧版接口，整个重构功能的运行直接崩掉。

6. 用四条铁律守住 context-mode 的底线

写到这里，我想再把经验压实成四条“铁律”。这四个约束也是我在实际带团队时反复强调的内容，大概率可以直接照搬到你现在的工作流里。

6.1 显式永远比隐式可靠

对 AI 工具而言，“显式引用”的效果远好于“模型自动猜”。需要某个文件作为背景时，就用 @ 或者直接粘贴关键代码，不要指望 Auto-index 能完整猜测你的意图。自动检索在给“提示”时有效，但绝不能替代你主动指定的上下文。

6.2 上下文的范围要跟着任务的粒度走

任务范围越小，上下文范围就应该越小。修单文件 bug 的时候开全项目模式，与让一个只看全局的架构师来改你桌子上的一个错别字，效果是一样的——他一定会在确保“全局一致性”的大前提下做一些无关改动。

6.3 每一次生成结果，先检查上下文清单，再检查代码

这个习惯越早养成越好。我见过太多人把时间花在反复修改提示词上，却始终不检查 AI 实际看到的上下文是什么。绝大多数生成质量问题的根源不在提示词的水平，而在输入上下文是否干净、边界是否清晰。查清单比调提示词快得多，也准得多。

6.4 任务阶段切换时，强制刷新会话

只要是“从分析阶段跨入实施阶段”、“从 A 模块切换到 B 模块”、“从生成代码切换为审查代码”，一律新建会话并重新校准 context-mode。这能规避掉大量的记忆漂移和上下文污染问题。多花一分钟刷新会话，比多花几小时审错代码省得多。

7. 顺手分享一个我自己在设计 context-mode 工作流时用的检查清单

介于篇幅原因，我在最后把这个检查清单留在这里。它不是文档里的理论条目，而是我自己在处理生产环境问题时逐条打勾的习惯，你可以按需剪裁使用：

• [ ] 当前任务的明确范围是什么？涉及哪些文件？
• [ ] 有没有关掉自动检索，或者至少查过上下文清单里混入了什么文件？
• [ ] 如果涉及跨文件，是否手动引用了必要的文件？
• [ ] 本次任务需要用到的关键函数名、类名是否已经在提示词中显式出现？
• [ ] 对话轮次是否已经超过 10 轮？是否需要刷新会话？
• [ ] 在生成修改方案之前，是否让 AI 先输出了影响文件清单？
• [ ] AI 返回结果时，是否检查了它引用的文件与你的预期一致？

这些检查每次花不到三分钟，但能省下的是每天几小时无效返工的时间。开发工具越往前进化，我们对“信息边界”的掌控就越重要。context-mode 本质上是在人类可控性与模型自由度之间找到的那个平衡点，掌握好它的手感，你的 AI 协作效率会有一个实打实的跃升。