企业官网建设流程全解析

1. 拆解 context-mode：AI 编程工具的上下文到底是什么

1.1 从一次典型翻车现场说起

先讲一个我最近遇到的真实场景。项目里有一个支付金额计算模块，逻辑分布在price.ts、discount.ts和order.ts三个文件里，外层还有个缓存服务。我让 AI 助手帮我加一个“满减后取整”的规则，它洋洋洒洒写了一百多行，结果一跑测试，满减被取整取没了，订单金额直接差了一分钱。

问题不在 AI 的代码能力，而在于它根本没看到discount.ts里对精度处理的逻辑——它只“看”了我粘贴给它的price.ts。这就是 context-mode（上下文模式）要解决的痛点：AI 编程工具能参考哪些代码、按什么策略参考、参考多少，直接决定了产出质量。

很多人把 context-mode 当成一个“打开就行”的开关，实际上它的每个模式、每个参数背后都是对 Token 预算、相关性和成本的三方权衡。这篇文章我就站在实际使用的角度，把 context-mode 的机制、配置、踩坑和进阶玩法一次说清楚。

1.2 它适合谁、能解决什么问题

如果你属于下面任一类型，这篇文章应该能帮你省下不少时间：

• 用 Cursor、Windsurf、Continue 这类 AI 辅助编程工具，但觉得 AI 经常“答非所问”；
• 项目代码量中等偏上（几万行到几十万行），AI 检索经常漏文件；
• 经常遇到“上下文溢出”，聊到一半 AI 开始重复或者遗忘前面的要求；
• 团队里多人共用一套 AI 工具，想统一上下文管理规范。

context-mode 表面上只是“让 AI 多读几个文件”，实际上它牵涉到 AI 如何理解你的代码库、如何控制成本、如何在一个长时间会话里保持一致性。理解透这一层，你再回去用那些工具，会有种“原来开关在这里”的豁然感。

2. 三种常见的 context-mode 类型与选型逻辑

2.1 自动模式、手动模式与混合模式的差异

目前主流 AI 编程工具里，context-mode 通常分成三类，名字可能不同，但内核基本一致：

选型逻辑其实很直白：改动范围越小，越适合自动模式；改动范围越大，越要往手动和混合模式靠。

举个例子，改一个 CSS 类名、修一个空指针判空，自动模式完全够用，还能省下每次手动@文件的时间。但如果你要做一次订单模块的促销逻辑重构，自动模式大概率漏掉price.ts和order.ts之间的调用关系，这时候手动把相关文件全拖进去才是正确姿势。

2.2 为什么不是“上下文越多越好”

这是我在带新人时最常纠正的一个误区。很多人在手动模式下恨不得把整个项目的核心文件全塞进去，觉得这样 AI 一定看得全面。但实际结果是：AI 的输出质量先升后降，Token 成本倒是实打实上去了。

原因有三层。

第一，模型的注意力是有限资源。GPT 级别的大模型虽然在长上下文上有专门优化，但当你塞进几万行代码时，它对中段内容的“记忆”会明显变淡。你精心放在提示词末尾的“不要修改支付精度”反而可能被淹没。

第二，无关代码会引入噪声。如果你要让 AI 改前端页面的展示逻辑，结果把后端数据迁移脚本也放进上下文，AI 很可能在重构时把两个本不相关的领域“缝合”到一起，产生一些看似合理实则荒谬的代码。

第三，费用和速度。每次请求的输入 token 都按量计费，上下文翻倍，成本接近翻倍，响应时间也会拉长。团队用共享账号时，一次贪心的全量注入可能直接把一天的额度烧掉大半。

我自己的经验是：一个需求涉及的直接文件控制在 3~8 个，间接依赖用“提及”而不是“全文注入”。后面我会讲具体操作。

3. 核心机制拆解：检索、注入与权重

3.1 自动模式下 AI 是怎么“找文件”的

理解自动模式的检索机制，是配置好 context-mode 的基础。大部分工具不是真的把你整个仓库都读进模型，而是先通过检索算法“猜”哪些文件和你当前任务相关，然后把它们塞进上下文窗口。

主流的检索手段可以归为三类：

• 基于编辑历史的近邻推荐：你最近动过哪些文件、当前打开哪个文件、复制粘贴了什么内容，工具会认为这些和当前任务最相关；
• 基于符号与索引的关键词匹配：工具会为代码库建索引（变量名、函数名、类名、注释关键词），你用自然语言描述需求时，它会提取关键词去索引里找命中率最高的文件；
• 基于嵌入向量的语义检索：把代码片段和你的自然语言描述都转成向量，算相似度，这一层能发现很多你没有主动提到、但语义上确实相关的文件。

很多工具会把以上三种加权融合。所以你会看到同一个工具，有时候你提“订单金额”它就能找到price.ts，有时候你提了它也无动于衷——那大概率是关键词匹配那层出了问题，比如项目里函数命名不规范、注释缺失、或者索引还没建好。

3.2 手动注入时的“优先级权”是怎么回事

手动模式也不是你把文件加进去就平等对待的。以 Cursor 为例，你用@引用的文件，在提示词拼接时会被放在一个优先位置，紧接着才是自动检索的文件。模型对提示词的开头和结尾注意力最强，所以@注入的文件实际影响力远大于自动检索的文件。

基于这个机制，我给团队定过一套手动注入规则：

1. 要改动的目标文件必须手动@，不能指望自动模式找到它；
2. 关键约束所在的文件必须手动@，比如精度处理、权限校验、状态机定义；
3. 调用链更深的文件（A 调用 B，B 调用 C）优先注入 B，因为 B 是直接接口，C 的影响已经被 B 封装了。

这么做的逻辑是，把有限的注意力预算花在最能约束 AI 输出的地方，而不是雨露均沾。你与其让 AI 同时看十个文件，不如挑出三个“规则制定者”让它重点参考。

3.3 上下文面板：被忽略的实时监控工具

绝大多数 AI 编程工具都有一个“上下文面板”或类似入口，它能显示当前会话已经注入了哪些文件、每个文件大概占了多少 token。这个面板是我排查问题时的第一站。

有一次 Autopilot 模式（自动模式 + 自动操作）莫名其妙在改一个无关的测试文件，我打开上下文面板一看，果然它把那个测试文件作为相关文件自动注入了，而真正的业务文件排在后面。原因是我上个会话里频繁打开那个测试文件，编辑历史权重把它顶到了前面。

解决办法很简单：手动@目标文件，把它的优先级拉高，再在面板里临时降低无关文件的权重。处理完再看输出，直接就正常了。养成每次发关键请求前扫一眼上下文面板的习惯，能避免至少一半的“AI 犯傻”问题。

4. 实操配置：从默认值到精细化调优

4.1 第一步：确认工具的上下文模式入口

不同工具的配置入口不太一样，但基本都藏在设置或命令面板里。以较常见的几类工具为例：

• Cursor：设置面板里的Features部分，可以切换Automatic/Manual/Mixed；在对话框里也能临时用@切换文件级引用。
• Windsurf：类似地，配置项里有Context Configuration，可以设置最大上下文文件数、是否开启代码库索引。
• Continue：属于开源方案，在config.json里通过contextProviders控制，可以组合文件、文件夹、代码大纲、终端输出等来源。

实操要点是：先搞清楚你当前用的是哪个模式，再谈调优。我见过不少人是默认设置一路用到底，AI 表现不稳定就怪工具不行，其实根本原因是自动模式的召回策略和项目结构不匹配。

4.2 第二步：针对项目结构的三个调优参数

确认入口之后，我建议优先调这三个参数：

最大参考文件数。默认值一般在 5~20 之间。如果你的项目是微服务风格，每个服务独立目录、单文件职责单一，可以把数字调大一些（比如 15），因为单文件内容短、总体 token 可控。如果你的项目是大仓 monorepo，文件大且互相依赖复杂，建议调回 5~8，强制自己手动@关键文件。

是否开启语义检索。很多工具允许你关闭关键词匹配或向量检索。我的建议是：项目规范、命名整洁时全开；项目里充满a1、tmp、test2这种变量名时，关键词匹配的噪声很大，反而应该关掉关键词那层，只保留编辑历史和手动@。

索引刷新频率。如果你经常新增文件，而 AI 总是“找不到”新建模块，多半是索引没刷新。把索引刷新改成自动或文件变更时触发，能缓解这个问题。但注意，频繁刷新会占 CPU 和磁盘 IO，大项目改完代码卡顿几秒是正常现象。

4.3 第三步：用会话隔离对抗上下文污染

context-mode 的配置再多，也挡不住上下文污染的“慢性侵蚀”。所谓上下文污染，就是你在同一个会话里聊了 A 功能又聊 B 功能，AI 把 A 的残留信息带进了 B 的生成。

手动模式下更容易出现这个问题，因为你可能会把上一轮相关的文件一直留在上下文里。我的处理办法：

1. 每次开启新任务，先新建会话，不要在一个会话里连续做不同需求；
2. 如果必须在同一会话里切换，先手动移除上下文面板里的旧文件；
3. 对长时间会话，定期“总结前文”并开新会话：让 AI 把当前进度和结论浓缩成一段文字，再在新会话里粘贴，这样既保留关键信息，又清空冗余 token。

这个习惯一开始会觉得很麻烦，但两三次之后你就会发现，AI 在“干净”上下文下的表现稳定得多。

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

5.1 “AI 找不到我新写的文件”怎么办

这是频率最高的一个问题。排查顺序很重要：

1. 先确认文件是否已保存，未保存的文件很多工具的索引抓不到；
2. 打开上下文面板，看目标文件是否在注入列表里；
3. 如果不在，手动@试一次，能正常引用说明索引没坏；
4. 手动@也找不到，大概率是索引陈旧，去触发一次全量索引重建。

遇到过最极端的案例：一个同事在项目里新增了refundService.ts，AI 连续三次都给出“该文件不存在”的回复，最后发现是因为他把文件放在了.gitignore覆盖的目录下，索引默认跳过该目录。这个坑比较隐蔽，如果你的新文件老是“不存在”，可以检查一下是否被忽略规则拦住了。

5.2 上下文塞满了但输出还是不对

这类问题要拆成两部分看：Token 是否真的够用，以及关键信息是否在有效位置。

首先，打开上下文面板看实际的 usage 数字。如果已经被塞到接近上限，比如 90% 以上，那 AI 的注意力会被严重稀释。这时候应该删掉一些不那么关键的文件，而不是继续追加。

其次，判断关键约束是否被放在了“注意力高位”。模型对话中，开头的 system prompt 和用户消息、以及最后几条消息权重最高。如果你的关键需求写在中间，后面又跟了好几条补充说明，AI 很可能只记住最后几条。

我的处理技巧是：把最关键的一句话在提问时重写一遍。比如你已经说了“不要改动金额精度处理”，在不方便开新会话时，就在最后一条消息里再次强调“记住，price.ts第 80 行的精度处理逻辑禁止改动”。实测下来，这个重复强调对输出质量的提升非常明显。

5.3 自动模式经常漏文件，是否该彻底放弃自动模式

不建议。自动模式的“漏”很多时候不是它能力不行，而是项目自身的可检索性太差。

我有个老项目，模块间依赖靠动态加载字符串拼接路径，全仓库找不到一个明确的 import 关系。自动模式漏文件属于必然结果。这种情况下，我会做两件事：

1. 把关键入口文件手动@进上下文，补偿自动检索的盲区；
2. 给项目的核心模块写一个AGENTS.md或CLAUDE.md说明文件，里面用自然语言描述模块职责、依赖关系、常见修改入口。很多工具支持在检索时优先读取这类文档，相当于给 AI 画了一张项目导航图。

补完这两步之后，自动模式的准确率会明显回升。顺带说一句，这个AGENTS.md不只是为了 AI 友好，团队新人看了也很有帮助，属于一举两得。

5.4 Token 成本飙升的排查清单

最后整理一份我自己常用的成本排查清单，按优先级排序：

• 是否有大文件被自动注入（比如动辄几千行的配置文件、生成的 lock 文件）；
• 是否有上次会话的残留文件还在上下文里；
• 是否反复粘贴同一段代码（直接粘贴的内容也会占 token，且没有去重机制）；
• 是否在循环调试中频繁重发相近问题（与其让 AI 猜，不如手动检查一遍代码再重发）；
• 是否开启了“代码库全局检索”模式，却只改一个小 bug（这是典型的杀鸡用牛刀）。

如果你的团队对成本敏感，我建议每周抽出一点时间看一眼工具的费用面板，找出 token 消耗最高的会话，往往能发现上面某一项被踩中了。

6. 进阶玩法组合：context-mode + 代码索引 + 记忆文件

6.1 让“加工过”的代码片段成为你的上下文弹药

普通上下文注入是把原始文件喂给 AI。进阶玩法是：先自己把文件里的核心逻辑浓缩成一段带注释的摘要，再把摘要注入进去。

举个实际例子，我处理过一个老项目的userAuth.ts，这个文件有 4200 多行，塞进去太贵，不塞 AI 又不懂鉴权流程。我的做法是抽出一个 80 行的精简版本，包含登录、token 校验、角色判断的函数签名和关键注释，再用@把它引用进上下文。

效果是：AI 理解了鉴权约束，出错的概率下降，token 消耗从几万降到几千。这个“人工摘要”的思路，本质上把模型当成人来沟通——你给一个同事讲代码时，也不会直接甩一个几千行的文件让他自己看完，对吧。

6.2 跨会话保持一致的“外部记忆”写法

AI 编程工具有一个天然的短板：会话隔离。你今天让 AI 遵守“金额字段统一用分存储”，明天它换了个新会话就忘了。在 context-mode 下，可以让这个问题变得可控。

做法是在项目根目录维护一个context.md（名字可以自定义），把项目级规则、命名约定、已知坑位都写进去。每次开启新会话时，把这份文件@进上下文，相当于给 AI 装了一份“入职培训手册”。

我自己的context.md大概包含这几类内容：

• 项目技术栈和目录结构说明；
• 金额、时间、ID 等关键字段的统一格式约定；
• 哪些模块有特殊的边界条件（比如并发控制、精度处理）；
• 过往 AI 在本项目里犯过的典型错误记录。

这个文件会随项目迭代更新，它也是团队知识沉淀的一部分。配合手动注入，能大幅降低跨会话的“失忆”问题。坚持用下来，你会发现 AI 的回复风格都稳定了不少。

6.3 不同任务类型下的模式搭配建议

最后，给出一套我实际验证过比较顺手的模式搭配，可以直接作为起点：

这套搭配的逻辑是按照“改动范围”和“约束数量”两个维度来选的。改动范围越大、约束越多，就越要往手动模式倾斜。你自己用的时候，不必照搬，关键是要理解这个维度思维。

7. 我自己实际使用的总结与体会

用 context-mode 调优到现在，最深的体会是：这个功能不像一个开关，更像一个“提示词工程 + 代码检索 + 成本管理”的复合工具。它的核心不是“让 AI 多看文件”，而是“在有限的注意力里，把最重要的代码放到它能看到的位置”。

踩过几次坑之后，我现在的工作流基本固定下来了：一次会话只做一件事，关键文件手动@，非关键文件看上下文面板的占用再决定要不要加，每次新项目先写一份context.md作为基准。这套流程并不复杂，但确实让 AI 的产出质量稳定了一个台阶。如果你也是重度用户，不妨从这周开始，把这三个动作加到自己的日常流程里试试，大概率会感受到明显的变化。