企业官网建设流程全解析

写代码这些年，我越来越觉得“让 AI 看懂项目”这件事，比“让 AI 写代码”本身难得多。明明同一个 AI 助手，有时候它像极了解你的老搭档，一句话就能给你改出完全可用的函数；有时候又像个没头苍蝇，反复给你贴一些无关接口的片段，最后还得你自己删了重写。差别往往不在模型强不强，而在一个容易被忽略的东西上——context-mode，也就是“上下文模式”。

我真正意识到这个问题的严重性，是在一次接手老项目维护的时候。那个项目里文件之间的关系绕来绕去，AI 默认拿到的那点上下文，根本拼不出完整逻辑，于是它对代码的“阅读理解”全面跑偏。后来我把项目的 context-mode 手动调整了一下，把真正关键的入口文件、类型定义和数据层文件显式喂进去，效果立刻就不一样了。这篇文章就把我对 context-mode 的理解、实操经验以及踩过的坑完整梳理一遍，希望能帮你少走点弯路。

1. context-mode 到底在解决什么问题

1.1 为什么所有 AI 编程工具都在强调“上下文模式”

先说一个底层事实：现在的 AI 编程助手，本质上都是在做“上下文预测”。模型拿到你给的代码片段、文件内容、对话历史，然后推断你下一步想干什么。模型的能力再强，如果你没把它需要参考的代码给它，它就只能凭空猜，而程序员最恨的就是这种“看似合理的瞎猜”。

你可以把 context-mode 理解成“给 AI 喂资料的规则”。它决定了 AI 在回答你问题时，能看到哪些文件、哪些代码、哪些历史记录，以及按照什么优先级去理解这些东西。很多工具在界面里默认开启的是“自动上下文”，也就是让 AI 自己从你当前打开的文件、最近的编辑记录、项目结构里挑选信息。但在复杂项目里，自动模式经常挑错重点——它可能把一大堆组件样式文件塞进来，却漏掉了最核心的类型定义。

所以 context-mode 的本质，是把“喂什么”这件事的控制权，部分交还给用户。你不再完全依赖工具的黑盒判断，而是可以主动告诉 AI：看这个文件，参考这个约定，忽略那个目录。理解这一点之后，你就不会再觉得上下文模式只是个锦上添花的开关了，它其实是决定 AI 输出质量的上限因素之一。

1.2 三种主流 context-mode 的取舍逻辑

虽然各家工具的叫法不太一样，但主流的上下文模式基本可以归成三类，我这里用比较容易理解的方式拆一下：

• 自动模式：工具根据你当前的操作行为，自动收集相关文件。比如你打开了一个组件文件，AI 就会把这个文件和它引用的子组件、公共方法自动纳入上下文。优点是省心，缺点是工具对“相关”的判定不一定准。
• 手动模式：你通过特定的符号（比如@或#）显式指定文件、目录或符号，作为 AI 的参考资料。优点是你拥有绝对控制权，缺点是操作成本增加，而且很多人不知道哪些文件值得手动指定。
• 排除模式：也叫“忽略模式”，相当于给 AI 划一块禁区。你可以声明某些目录、文件类型或者特定代码块永远不进入上下文，比如自动生成的代码、加密算法、密钥文件等。这个模式对保护代码卫生和隐私非常关键，但常常被忽略。

这三类模式不是互斥的，实际用的时候更多是组合。比如我会把全局规则设成“自动模式 + 排除 node_modules”，然后在关键会话里单独用手动模式补充精确引用。理解了取舍逻辑，后面配置起来才有方向感。

2. 核心细节解析与实操要点

2.1 自动检测模式的工作原理与陷阱

自动模式的背后，其实是工具在帮你做一个“检索 + 排序”的动作。它通常会把项目里的文件按某种规则扫描一遍，比如最近打开的文件、与当前光标位置相关的 import、被频繁引用的公共模块等，然后按照一个模型打分，把分数最高的若干片段塞进上下文窗口。

这里面有个关键的量化指标：上下文窗口是有限的。以常见的模型为例，几万 token 的窗口听起来很大，但代码的 token 消耗速度远超你的直觉。一个中等复杂度的文件可能就有几千 token，加上系统提示词、对话历史、工具返回结果，窗口很快见底。自动模式在窗口拥挤时，会悄悄丢弃一些“它认为不重要”的内容——问题就出在这里，它认为不重要的，很可能正是你在意的。

我遇到过一个典型的坑：当时我想让 AI 理解一个跨模块的状态管理设计，自动模式下它会优先保留当前编辑文件的全部内容，然后保留一些 import 片段，但状态管理的核心 store 文件，却因为引用距离远、优先级低，被挤出了上下文。结果 AI 给我建议的“优化方案”，是在完全不了解 store 结构的情况下编出来的，看似合理，实际上根本接不上项目现状。所以自动模式适合小项目、单文件逻辑清晰的场景；一旦涉及跨模块、历史包袱重的代码，别指望自动模式能替你判断。

2.2 手动引用与符号绑定的使用技巧

手动引用，简单说就是你在提问时，用特定符号把目标文件“钉”在上下文里。很多工具都支持这种交互，比如在输入框里输入@然后选择文件，或者输入#加文件名来引用某个具体文件。

但这里有个细节值得展开：手动引用的本质是“一次性的上下文注入”。你这次引用后，AI 会读取该文件内容作为参考，但下一次对话如果没有再次引用，AI 可能会忘记。很多人误以为只要在会话开头引用过一次，整个会话里 AI 就都记得，其实不一定。工具的行为各不相同，有的会把引用保留在当前会话中，有的只把它当作单轮请求的一部分。

所以我的习惯是：在关键问题时，哪怕文件已经在屏幕上，我也会重新手动引用一次。尤其是在连续追问的场景下，每次追问前把最核心的文件再显式指定一遍，能显著降低 AI“失忆”的概率。另外，手动引用还有一层好处——它同时向 AI 传递了“这次对话的重点”。你只引用了user.ts和api.ts，AI 就能自然推断出你关心的是用户系统和接口层，而不是 UI 组件，回答时会自动向这个方向倾斜。

2.3 排除规则与代码卫生

排除规则是我个人觉得最被低估的模式。你以为你只是让 AI 忽略node_modules而已，但在真实开发里，很多场景比这个微妙得多。

举个例子：如果一个项目里同时有src目录和dist目录，dist里是构建后的压缩代码，不带排除规则，自动扫描时很可能把它当成普通代码喂给 AI。这不仅浪费上下文窗口，还可能让 AI 被压缩后的代码风格带的“走火入魔”。同理，package-lock.json、yarn.lock、各种生成的 API 文档、.d.ts文件，都不该进入 AI 的参考范围。

配置排除规则时，有几个细节需要特别注意：

• 排除逻辑应当是继承式的：如果你排除了dist，那dist/models就不该再出现，否则规则就乱了。
• 规则要有优先级：比如你排除了**/*.md，但允许docs/api.md进入上下文，工具得有办法表达这种例外。
• 排除规则不只影响文件扫描，还影响语义理解：当 AI 意识到某些代码是自动生成的，它对你的意图判断会更准确。

这些规则配置好后，能让 AI 面对的代码“更干净”，也更接近一个老工程师眼中应该关注的部分。

3. 实操过程与核心环节实现

3.1 场景设计：给一个老项目做技术重构

光讲概念没用，我拿一个最近实际处理过的场景来完整走一遍。假设你要把一个 Vue 2 的项目重构为组合式 API 风格，项目结构大概长这样：

src/ api/ components/ Header.vue UserCard.vue ... store/ index.js modules/ user.js order.js utils/ request.js

这种项目文件之间依赖很重，自动模式经常会把相关模块遗漏。你想让 AI 帮你把UserCard.vue里的逻辑拆出来，改成 Vue 3 的<script setup>风格，同时保持对外 API 不变，这是个很典型的 context-mode 应用场景。

先说我的目标：让 AI 在理解UserCard.vue的基础上，同时知道 store 的 user 模块是怎么暴露状态的，以及 request.js 提供了哪些方法。只要这三个信息对齐，AI 的重构建议就基本不会跑偏。

3.2 自动模式的实操记录

我先把自动模式开着，简单输入：

帮我看看 UserCard.vue，把里面跟用户信息加载相关的逻辑整理一下。

自动模式下，AI 确实读到了UserCard.vue，同时因为UserCard.vue里 import 了user.js模块，它也顺带把user.js的一部分内容拉进来了。但问题来了——自动模式只拉取了被直接引用的 export 片段，没有覆盖request.js里的请求封装逻辑。它看到的是user.js里调用了request.get('/user/info')，但不知道这个request的鉴权逻辑、错误处理逻辑是什么样的。

结果 AI 的建议是：把请求逻辑直接放到组件里，用fetch重写一遍。听起来很干净，但完全忽略了项目现有request.js里统一的 token 注入和错误码处理。这个方案拿给组里任何一个人看，都会被否定。这就是自动模式在“直接引用链”之外的信息盲区。

3.3 手动模式实操记录

于是我在第二次尝试时，切到手动的 context-mode，主动把所有关键文件都引上：

帮我参考 @UserCard.vue、@store/modules/user.js、@utils/request.js， 把 UserCard 里用户信息加载的逻辑整理一下，保持原有接口和错误处理方式不变。

这个操作里，@就触发工具的文件选择器，我逐个选中三个目标文件。提交后 AI 的回答质量明显上了一个台阶。它不再建议我用fetch重写，而是基于request.js的既有封装，提出了把加载逻辑抽到一个useUserInfo组合式函数里的方案。这个方案既能兼容原 store 的用法，又不破坏现有的请求层统一异常处理。而且，因为这个方案是在完整理解request.js的前提下生成的，最终落地时我基本没改什么。

从这个对比里你应该能看出，手动模式不是让你“多干活”，而是让你在关键节点上给 AI 提供“精确制导”。有些习惯好的开发者会说“反正 AI 会自动读”，但实测下来，显式引用的稳定性和准确度都显著更高。

3.4 参数与配置参考

这里我也整理一份偏实用的配置建议，方便大家照着设置。注意不同的工具字段会有点差异，但思路是通用的。

如果你用的是支持全局规则的工具，我强烈建议你把“禁止把密钥文件和本地配置带入上下文”写成默认规则，既保护隐私，又防止 AI 在不该出现的地方自作聪明。这些配置虽然看着琐碎，但实际影响很大。

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

4.1 AI 一直答非所问的排查顺序

遇到 AI 回答跟问题不贴边，我的第一反应不是怀疑模型，而是先看这个会话的上下文列表。多数工具里能看到当前上下文引用了哪些文件、多少 token、历史有多长。排查顺序基本是固定的：

• 看引用文件对不对：如果 AI 引错文件，比如引了一个同名测试文件，那答非所问就很好理解了。
• 看引用内容新旧程度：有时候 AI 拿到的文件是旧版本，而你改的最新代码不在上下文里，这也会导致回答滞后。
• 看对话历史是否已被截断：如果历史过长，早期的关键指令会被截掉，后面所有回答都会偏离你的真实意图。

我遇到过一次很典型的问题：我在一个长会话里，前面讨论了 A 模块的 5 个子问题，后面切换到 B 模块时，没有做任何清理，结果 AI 一直以为还在改 A 模块，给出的方案跟当前问题风马牛不相及。解决办法很简单：新任务就开新会话，B 模块的问题不要在 A 模块的上下文里问。这比任何提示词都管用。

4.2 上下文过载导致的“越改越乱”

另外一个高频问题是上下文过载。表现形式很典型：AI 开始“忘事”，前面刚说好的命名约定，后面就不遵守了；或者你改了一处代码，AI 建议的下一处修改却基于旧结构，出现循环混乱。本质原因是上下文窗口里塞了太多“低价值信息”，把关键约定挤了出去。

处理这段过载，我有几个实操办法：

• 清空会话，重新组织上下文：把当前需要的核心文件重新引用一次，新的会话历史变短，关键信息占比更高。
• 把大任务拆成小任务：一个会话只做一件事，比如“只重构 UserCard 的加载逻辑”，而不是“重构并顺带优化所有子组件”。
• 用规则文件固化“不可变约定”：把团队规范、命名约定、禁止事项写进全局规则里，就算历史被截断，规则文件也会被优先保留。

这一招在长时间作战时特别重要。以前我总觉得 AI 对话越多它越懂我，后来发现，对话越多它越容易把早期的关键约定忘掉。主动清空重来，看似浪费，实则高效。

4.3 隐私与隔离的注意事项

聊到上下文，就不能不提隐私。context-mode 手动引用一个文件时，文件内容会被发送到模型服务端，这一点几乎没法避免。所以你在引用文件之前，应该先想一遍：这个文件里有没有不该出去的东西？

实际开发中出过问题的场景很多。比如某个 Java 项目里，application.yml带着内网数据库地址和账号，被开发者随手@进去喂给了 AI；再比如有些仓库里有企业内部规范文件，里面写了公司架构和人员信息，被 AI 记进上下文后，后续所有生成代码都可能带上无关内容。处理办法很简单：

• 全局忽略所有配置文件（.env、application.yml、config.local.ts等）。
• 引用文件前肉眼扫一遍敏感字段，不放心就手动打码。
• 涉及商业秘密或合规要求高的项目，尽量用企业内部私有化部署的工具。

我见过有团队把密钥变量误写进上下文，AI 生成代码时把变量名当成了常量，结果引起了一次配置混乱。虽然没造成安全事故，但给所有人提了个醒：把“不告之机密”写进 context-mode 的默认规则，是每个团队都应该做的事。

4.4 几个容易被忽略的小细节

最后再补充几个我在日常使用中踩过的小坑，这些细节网上很少有人提，但确实影响体验：

• 手动引用和自动扫描是会叠加的：如果你在开自动模式的同时又手动引用了文件，那 AI 拿到的东西可能是两拨内容拼起来的。叠加之后，上下文窗口更容易满，反而影响效果。我一般会先把自动模式关掉，再手动精确引用，这样可控性最强。
• 模型版本会影响上下文模式的行为：同样的配置，新模型和老模型对上下文的利用效率不一样，甚至可能表现为“同样的引用方式，回答质量差别很大”。遇到这种差异时，先别急着骂工具，看看模型版本是不是变了。
• 快捷键和交互方式值得专门学一下：很多人只会在输入框里打字，不知道工具的@文件选择器还能搜符号、搜类名。把交互方式学透，能省下大量指向时间。
• 会话历史是另一种上下文：context-mode 只解决“让 AI 看到哪些文件”的问题，但会话里你自己说过的话，同样是上下文的一部分。所以提问时，尽量把需求说全，不要指望 AI 能像老同事一样从你的沉默里猜出意图。

写在后面

跟 context-mode 打了这么久交道，我个人体会最深的一点是：它其实不是什么高深技术，而是把“喂信息”这个动作从被动变主动。大部分人对 AI 编程工具的使用体验不佳，不是模型不够好，而是他们从未有意识地去管理 AI 能看到的东西。你把上下文管好，AI 的判断力自然会提升一个档次。

最后再分享一个小技巧：我会在每个新项目的开头，花十分钟把排除规则和全局规则先配好，让“清理上下文”变成项目初始化的一部分。这十分钟看起来是额外成本，但后续 AI 生成代码的返工率会明显下降，这个投入怎么算都值。