企业官网建设流程全解析

用 AI 编程助手写代码的人，大概率都遇到过这个场景：你让它改某个模块里的一个函数，它却兴致勃勃地把另一个模块的代码也重写了一遍，或者扒出一个已经废弃的旧实现当作最新逻辑。我一开始以为是模型能力不行，后来排查了大半天才发现，问题根本不在模型，而在我没管好工具里的context-mode——上下文模式。

这个功能几乎成了当前主流 AI 编程工具的标配，但说实话，真正把它用明白的人不多。它本质上回答了一个问题：每次你提问的时候，模型到底能“看到”哪些代码、哪些文件、哪些历史对话？把这件事搞明白，AI 编程的体验会从“抽卡”变成“稳定复现”；搞不明白，再强的模型也会被一堆无关信息带沟里去。这篇文章我就从我自己的实操经验出发，拆一拆 context-mode 到底是个什么机制，不同的模式各有什么脾气，以及我总结出来的切换规则和排错套路。

1. “context-mode”拆开看，藏的其实是 AI 编程的命门

1.1 模型没有记忆，每次回答都是一次“重新入场”

先说一个很多人忽略的事实：大模型本身是没有记忆的。它不会像人一样记得你三天前让它写过什么，它每一次回答都只基于当前输入窗口里塞进去的内容。所谓“上下文”，就是你这一次提问时塞给它的全部信息总和——包括当前打开的文件、选中代码、项目文件索引、历史聊天记录，甚至各种自动检索到的相关文件。

这就是 context-mode 的由来。mode（模式）决定了“塞哪些信息”的策略，而不同策略直接决定了回答质量的上下限。你可以把模型想象成一个临时上岗的厨师：

• 你只给他一个鸡蛋、一把葱，他能立刻做个蛋炒饭；
• 你告诉他“厨房里所有食材都可以用”，他反而可能拿西瓜皮给你炒牛肉；
• 最怕的是，你递给他一本三个月前的旧菜单，他照着做了，端上桌你才发现食材早就换了。

我遇到过最典型的翻车现场，是让 AI 重构某个老项目的数据层。它自动检索全局上下文时，抓到了两个同名文件——一个是正在用的新版，一个是_deprecated目录下的旧版。因为旧版文件里的函数名更新，AI 直接采纳了旧版逻辑，生成了根本跑不通的代码。后来我把上下文切换成“仅当前文件”模式重新问，它给出的方案立刻就对味了。同一个模型，同一次任务，就是上下文选择的问题。

1.2 context-mode 争夺的其实是“有限的注意力”

任何一个 AI 编程工具的上下文窗口都是有限的。这个窗口就像一块白板，你塞进去的文件越多、历史对话越长，白板上的空间就越拥挤。模型在这块白板里找线索，跟人在垃圾堆里找钥匙是一个道理——不是找不到，而是容易被无关信息干扰，而且找的过程会消耗大量“注意力”。

我习惯用一个简单的比喻来解释：上下文窗口就是舞台，模型是演员，你的指令是剧本，自动带入的文件是道具。

• 道具准备得精准，演员看一眼就能入戏；
• 道具塞满整个舞台，演员反而不知道该看哪里；
• 更麻烦的是，舞台上只要有一个“穿帮”的旧道具（比如过时的依赖版本、废弃接口），演员就会照着那个错误的道具演完整出戏。

所以context-mode 的核心价值，不是“让模型看到更多”，而是“让模型看对”。这也是为什么我后来给自己定了一条规矩：每次让 AI 动手之前，先花 10 秒钟想清楚它这次需要看什么，然后再决定用哪种上下文模式。这一步想清楚了，后面能省下大量来回扯皮的纠错时间。

1.3 先理解上下文模式的两条底层原则

在往下展开具体模式之前，有两个底层原则我觉得必须刻在脑子里：

第一，信息不是越多越好，而是相关度越高越好。很多人以为全局模式最强大，实际用下来它反而是噪音最多的模式。它给你“自动带来参考文件”的能力，但也把一堆弱相关文件塞进窗口，把有价值的信号淹没了。

第二，每种上下文模式都有自己的“成本”。有的模式消耗的 token 少但能力弱，有的模式能力强但容易被无关文件干扰。你可以在不同模式之间切换，但切换的代价是你需要重新描述需求、重新给上下文。

理解这两条之后，再看下文对各种模式的分析，就会通透很多。

2. 主流工具里的几种 context-mode，分别是什么脾气

虽然各家产品对这种功能有各自的名称和交互方式，但扒开底层来看，无非是下面这几种模式在来回切换。我把它们的特征整理成了一张表，方便对照。

2.1 对话模式：适合“想清楚”，不适合“动手改”

对话模式是最朴素的一种：模型只依据当前聊天窗口里的历史记录和你的最新输入来回答，不会主动去翻你项目里的任何文件。好处是干净、噪音少、响应快，而且 token 消耗极低；坏处是它对项目本身一无所知。

我一般把它用在两个场景：一是任务开始前的方案讨论，比如先问“这个模块的改动会不会影响外部调用方的契约”；二是给模型发一段异常堆栈让它帮忙分析，不掺任何额外的代码噪音。

但对话模式有个致命缺陷——它记不住早期对话里的约定。有一次我让 AI 帮忙梳理一个模块的重构方案，前五分钟敲定了“保留parseData接口，内部实现改成流式解析”，聊到后面又加了不少新需求。等聊了 40 分钟，我让它总结一下最终方案时，它给出的方案里完全没了“保留接口”这条约定。原因就是上下文窗口里的早期消息被截断了。后来我学乖了：凡是重要的决定，聊完立刻用文件模式单独确认一遍，绝不只放在对话里。

2.2 文件模式：把“焦点”压缩到一个文件，稳但受限

文件模式是利用率最高的模式。它的上下文就是当前正在编辑的文件——通常还会包含你选中的代码段。模型在这块小天地里工作，不会乱跑，响应快，也基本不会出现张冠李戴的问题。

这个模式的优点是稳定、可预期。你让它改当前文件里的一个函数，它就把那个函数周围的代码琢磨一遍，给出一个范围收得非常小的 diff。对绝大多数增删改查类任务，文件模式就是最舒服的模式。代价是视野受限：一旦这个函数的逻辑依赖其他文件里的工具函数、常量定义或接口类型，模型就看不见了。它会怎么办？要么靠文件名和自己的“经验”瞎猜，要么直接用你选中的那几行代码硬写。猜对了是运气，猜错了你还得花时间纠错。

所以我的经验是，用文件模式的前提是“这次改动能独立成立”。如果发现要改的地方牵扯到其他文件里的类型或工具函数，别硬撑，立刻切手动指定模式，把相关文件一起喂进去。

2.3 全局项目模式：强大的检索，也是最大的噪音源

全局项目模式听起来很酷——“我让 AI 自动去找出所有相关文件”。实际操作下来，这个模式是把双刃剑。它背后通常有个项目索引，模型会根据你的问题语义主动召回相关文件作为上下文。这个召回的准确性，直接决定输出质量。

我见过最离谱的情况是，项目里同时存在utils.ts（新版工具函数）和legacy/utils.ts（旧版），模型在全局模式下引用了一大堆 legacy 目录下的函数，最后生成的代码不仅风格和现代代码库格格不入，甚至调用了根本不存在的依赖。事后排查发现，它召回了旧版文件，因为旧版文件里的注释写得特别“像答案”。

全局模式真正好用的场景只有三个：跨文件重构、查找调用链、给完全不了解项目结构的人做“项目体检”。在这些场景里，检索带来的广度红利大于噪音成本。但如果你已经明确了改动范围，全局模式就是纯亏——它不光慢，还容易引错路。

2.4 手动指定模式：把主动权抓回自己手里

手动指定模式，就是显式告诉模型“这次看这几个文件、这段代码、这个目录”。这是我最推荐的模式，没有之一。因为它的逻辑最简单——你自己最清楚这次任务需要什么信息，与其让模型的语义检索猜，不如你直接把答案摆到它面前。

实际操作中，手动指定通常有几种形态：

• 指定文件：把依赖的常量定义、接口类型、工具函数文件加入上下文；
• 指定代码片段：只选中某个函数实现，多于一行的引用都不带；
• 指定文件夹适用于跨目录的大型改动，但要小心，文件夹里的无关文件也会被塞进窗口。

这个模式的“成本”在操作端——你需要多花几秒钟去拖拽或输入文件路径。但这点成本换来的是极高的精准度。我可以负责任地说，我把日常改成“绝大多数任务走手动指定”之后，AI 一次通过率提高了至少一半。

3. 实战中我是怎么切 context-mode 的：一套可复用的判断流程

模式本身不复杂，难的是在真实开发过程中快速判断“现在该用哪种模式”。我总结了三条铁律，按顺序执行，基本不会翻车。

3.1 先判断任务边界，再选模式

拿到一个任务，我先问自己一个问题：这次改动会不会碰当前文件之外的东西？

• 如果只是改当前文件里的一个函数、一个常量、一段逻辑，那我直接文件模式，干净利落；
• 如果要引入新依赖、新工具函数，或者要改接口签名，那必须手动指定，把相关的文件一起拉进来；
• 如果想查清楚一个功能牵扯了哪些文件，或者要做全局重命名，我才切全局模式。

这个判断过程一般不超过 10 秒，但它能把一大半无意义的 AI 输出掐死在发生之前。顺便说一句，很多人习惯不管三七二十一直接全局模式，问出来的东西看着有道理，其实都是“听起来合理的废话”，因为模型找不到确切依据，只能编。

3.2 算一笔 token 账：全局模式什么时候是亏本的

很多人不看 token 消耗，觉得“反正包月/包年”。但 token 成本不只是钱的问题——窗口越宽，模型的注意力就越分散，回答质量越差。我有个很直观的经历：同样是让 AI 给一个 50 个文件的项目写查询接口，手动指定模式下它能精准复用现有工具函数；全局模式下它反而自己造了一堆轮子，因为检索出的文件太杂，它看不出哪些是核心工具，哪些只是边角料。

我给自己定过一个“成本倒挂”的判断标准：如果项目里相关的代码超过 10 个文件，全局模式至少会加载 3 倍以上的无关文件。这时候模型的有效注意力严重下降，不是不能跑，但你要花更多轮对话去纠偏。所以我的结论是，全局模式的“好用”主要体现在探索型任务，生产型改动一律手动圈范围。

3.3 最容易被忽视的毒药：会话历史污染

很多人在不同任务之间不清理历史对话，这是 context-mode 使用里最隐蔽的坑。上下文模式只会决定“当前能看哪些代码文件”，但历史对话本身也是上下文的一部分。你聊得越久，早期对话里的过时结论、废弃方案、修改前的代码，就会一次次地污染后面所有轮次的判断。

我踩过一个真实案例：上午让 AI 把一个表结构 A 改成了结构 B，下午又让它基于“当前代码”加一个统计接口。因为对话历史里全是上午改之前的旧代码片段，模型基于旧表结构生成了一整套 SQL 和数据模型。我直到被 QA 拦下来才意识到，问题不在模型，而在我的会话没清空。

从那以后，我的默认习惯是：每切换一个任务，新建独立会话。就算不建新会话，也会先发一条“忽略之前所有讨论，基于当前项目状态重新开始”，把历史污染的边界切开。

3.4 完整链路排查：AI 答错时，我按这个顺序查

如果 AI 的返回明显有问题，我不急着重新编提示词，而是先做一轮排查，按下面这个优先级来：

1. 先看它引用了什么文件。大多数工具的对话里会展示用到的上下文文件列表。一眼扫过去，就能发现是不是引用错了文件——这就是最常犯的错。
2. 再问一句“你看到的代码是什么”。让模型复述它认为的现状，你立刻能识别它对项目的理解停留在哪个版本。
3. 定位是“缺信息”还是“信息过量”。缺信息就手动把关键文件补进去；信息过量就把模式收窄，切换到文件模式或手动指定。
4. 清空会话，重开一轮。如果以上都没用，果断新开会话，把上下文恢复干净。

这条排查链路我用了很长时间，几乎每次都能在十分钟内定位问题根源。与其反复重问，不如先花时间把 AI 的“视野”调对。

4. 上下文自动截断与忽略规则：文档里不会写的细节

4.1 长文件被“看不见地腰斩”，是最隐蔽的坑

我在这里要说一个最容易被忽视的技术细节——长文件的截断问题。很多工具引入文件时，并不会真的把整个文件完整塞进上下文窗口。当文件行数超过某个阈值，它可能会只截取前 N 行，或者把中间大段内容折叠成一段摘要，然后在补全函数定义或注释的时候，依赖窗口外的部分去猜测。

出现这种情况时，AI 输出的“幻觉率”会急剧飙升。我曾让某工具改一个 3000 行的核心服务文件，它在文件模式下的每次修改都显得很有把握，但每次生成的代码都基于对后半段文件内容的胡乱猜测，和真实逻辑严重冲突。后来我才发现，工具只索引了文件的前半段，后半段的某个关键类定义根本没进上下文。

所以对于超长文件，我的策略是：先让模型列出文件里的函数签名和行号分布，再用行号区间做定点引用。比如先问“这个文件里有哪几个公共函数，行号分别在哪”，然后让 AI 基于“第 100-150 行那段函数”去精确修改。这相当于把一个大文件人为切成了可控的小块，模型的准确度会显著提升。

4.2 .gitignore 之外的“隐形忽略文件”

另一个容易被忽略的机制是自动忽略规则。很多工具会把某些目录排除在项目索引之外——比如.git、node_modules、构建产物目录，这些大家都知道。但有些工具还会忽略.gitignore里列出的文件、被二进制化的大文件、超过体积阈值的日志文件，等等。

问题在于：这些忽略规则不会在界面上明确告诉你。你可能会发现全局模式下 AI 死活找不到某个文件，或者引用了一个已经被忽略的路径，而你自己完全摸不着头脑。

排查办法很简单：全局模式下先让它“列出项目根目录下的所有一级目录”，再看它漏了哪个。如果漏了，你再手动把它加进上下文，就解决了。这个坑我在一个 monorepo 项目里踩过多次——子包的README.md和核心实现文件被索引规则忽略，AI 每次出方案都缺一块，直到我手动 @ 了文件才好。

4.3 自动摘要，是把双刃剑

很多工具在做全局检索时，不会把整个匹配到的文件都放进上下文，而是先跑一遍摘要，再把摘要喂给模型。这样做的好处是节省 token，坏处是摘要过程本身会丢失关键细节。

比如你让 AI 找一个“处理错误码映射的函数”，摘要只提取了函数名和注释，但函数内部对某个特殊错误码的特殊处理逻辑，摘要里根本不会有。模型基于摘要回答，看似有理，实则残缺。

这类问题很难直接看到，因为“摘要”是工具内部的隐层逻辑。我应对的经验是：一旦发现 AI 引用了某个文件但给出的细节很“泛空”，立刻切手动指定模式，强制把那个文件的完整内容拉入上下文。这个操作能治大多数“看起来对、用起来错”的返回。

5. 把 context-mode 真正用顺手的进阶操作

5.1 用“项目引路牌”文件，给全局模式立规矩

全局模式容易乱，但我们可以主动“规划”它的检索重点。我习惯在一个项目里维护一个专门的上下文导航文件（如project-context.md），里面写清楚：

• 项目的顶层目录结构长什么样；
• 每个业务模块的核心入口文件是哪个；
• 项目的常用命名规范、错误处理约定；
• 哪些目录是历史遗留，不要让 AI 参考。

这个文件平时不影响代码运行，但全局模式下它会成为模型最优先读取的项目说明。有了它，AI 的自动检索就多了一个“锚点”，即使模式切成了全局，也不容易跑偏。我在两个中型项目里试过，加了这个文件之后，全局模式的回答准确率提升非常明显，而且跨文件任务的探索过程也不再漫无目的。

5.2 把“需求描述”做成可复用的上下文块

真正的高手会在自己的常用工具里维护一套“复用型上下文片段”。举个例子：

• 一段描述“本项目的错误处理规范，外部调用必须统一抛出业务异常，禁止裸 throw Error”；
• 一段描述“本项目数据库访问统一走仓储层，不要在业务代码里直接写 SQL”；
• 一段描述“测试环境与生产环境的差异说明，以及联调时的账号约定”。

这些片段在任务开始前手动粘进上下文，相当于给模型发了一份“项目章程”。它不一定每条都能严格执行，但能极大减少模型因为不了解约定而产生的返工。我自己的实操是：把这类约定碎片化，放在某个固定文档里，需要时复制粘贴，而不是每次重新长篇大论地解释。

5.3 定期“瘦身”上下文：只喂结论，不喂过程

很多人有个坏习惯，喜欢把排查问题的完整过程原封不动丢给模型——包括试过的错误方案、报错日志、实验记录。其实模型不需要那么多过程信息，它需要的是结论和现状。

我现在每次让 AI 接手代码前，都会先手动做一个“上下文清理”：

• 把无关的报错讨论删除；
• 只保留当前文件的核心逻辑片段；
• 把“我试过 A 方案但不行，因为 X”改写成“现在不能使用 A 方案，约束是 X”。

别小看这个动作，它让模型的分析路径短了很多，回答也更贴合实际。

写在最后的小经验

这套上下文管理的方法，我在不同项目里反反复复调过很多次，最后得到的结论其实非常简单：与其追求工具的自动能力，不如把“喂什么给模型”这件事变成你自己的主动决策。AI 编程的下限由模型决定，但上限很大程度上由 context-mode 的使用水平决定。我现在的工作流很简单——每开一个任务，先想清楚边界，再选择上下文模式，改到一半如果发现 AI 答得不对劲，第一时间检查上下文而不是怀疑模型。如果你也被 AI 编程的“抽风时刻”折磨过，不妨试着把注意力从提示词技巧转移到上下文管理上，你会少很多返工。