企业官网建设流程全解析

在 AI 辅助编码这件事上，我一直觉得自己算是个“挺有耐心”的人，直到有一次让它帮忙改一个历史遗留模块，对话没超过五轮，它就开始把前面已经确认过的接口签名给忘了，还一本正经地给我编了一个不存在的函数。那一瞬间我意识到，问题不出在模型笨，而出在我根本没把“context-mode”当回事。

“context-mode”听起来像某个工具里的隐藏开关，实际上它是几乎所有现代 AI 编程助手和大型语言模型应用里最核心的一种运行机制：决定模型这一轮生成时能看到什么、记住什么、以什么为依据。你可以把它理解成给 AI 布置的“作战地图”——地图画得越精确，AI 就越不会跑偏。

这篇文章我想从项目实践的角度，把这个概念彻底拆开讲：它到底是什么、底层怎么工作、实际操作中怎么把它用好，以及我踩过的那些坑。无论你是刚开始用 AI 写代码，还是已经被“AI 瞎改代码”折磨到崩溃，这篇内容都能让你少走不少弯路。

1. context-mode 是什么：它解决的是“记忆与依据”的问题

1.1 从一次失败对话说起

先回忆一下那个经典场景。你打开编辑器，找到 AI 助手，输入了一句非常自然的需求：

“请把用户模块的登录逻辑改一下，改成支持手机号验证码登录，同时保留原有的密码登录能力。”

然后 AI 回给你一坨逻辑完全不通的代码，甚至把项目里根本不存在的类名都用上了。为什么？因为它根本不知道你的项目长什么样，不知道“用户模块”在哪个目录、用的什么框架、有没有现成的验证码服务。它只是在“没有上下文”的状态下凭空生成。

这时候如果你开启或正确配置了 context-mode，AI 就会先去扫描项目结构，定位与“用户模块”相关的文件，读取核心函数签名、数据模型、既有实现方式，再结合你当前正在编辑的文件内容，最后才生成代码。整个过程相当于一个“先侦察、后作战”的动作，而不是闭眼乱答。

在真实工具里，context-mode 通常表现为：自动抓取当前打开文件、读取项目索引、让用户手动追加“上下文文件”或用 @ 符号引用某个文件/片段。这些动作的共同目标只有一个——把“和当前任务有关的信息”塞进模型输入窗口。

1.2 context-mode 能解决什么，不能解决什么

搞清楚边界非常关键。context-mode 非常适合以下场景：

• 跨文件改动：比如你要修改“登录逻辑”，同时它依赖“用户表结构”和“Token 工具类”，上下文模式可以把这些依赖文件都纳入考虑范围。
• 长对话维持一致性：比如你已经聊了半小时需求，AI 还能记得项目初始化时的技术栈约定，靠的也是上下文模式。
• 代码审查和重构：让 AI 不仅看当前文件，还能对比关联文件，指出潜在影响面。

但它不是万能的。我见过不少人以为开了 context-mode 就等于 AI 全知全能，结果它还是会在一些冷门第三方库的用法上犯错。为什么？因为上下文模式解决的是“项目内信息可见性”，解决不了“训练知识之外的世界知识”。模型没见过那个新发布的 npm 包，你给它再多项目文件也没用。

所以正确的期待是：context-mode 是放大器，不是无中生有的魔术师。它把你自己项目里已经存在的信息、你之前聊过的内容、规则文件中的约定，全部变成 AI 可用的素材。素材越好，结果越好；素材为空，结果全凭运气。

2. 底层逻辑：窗口、检索与规则文件如何协作

2.1 窗口是硬约束：一切上下文都有容量上限

要理解 context-mode，首先必须知道“上下文窗口（context window）”这个概念。每个模型在生成回答时，能接收的输入 token 数量是有限的，通常用几千到几百万 token 来标定。这就好比一个人同时只能记住 10 张 A4 纸上写的内容，你硬塞给他 100 张纸，他也只能看到最后拿出来的那部分。

这个约束带来了一个很现实的问题：项目越庞大，全部代码越不可能一次性塞进模型。于是 context-mode 本质上变成了一个“信息筛选器”——在有限的窗口内，尽可能保留与当前任务相关性最高的内容。

我记得有一次处理一个微服务仓库，整个项目光是源码就有 30 万行。如果试图让 AI “读一下整个项目”，先不说耗时，输入窗口几乎肯定会被撑爆，而且大部分被塞进去的内容跟本次任务毫无关系，反而干扰判断。所以主流的 AI 编程工具都采用“按需注入”的方式：你问什么，它就把相关文件动态检索、拼接进上下文。

2.2 自动检索与手动引用是两条并行路径

目前主流助手里的 context-mode 主要分两种工作路径。

一种是我称之为“被动索引”的路径。工具会在后台为项目构建向量索引或代码语义索引，当你的问题涉及某个关键词时，它自动检索出若干个相关文件片段，填充进上下文。这个路径的好处是省事，你什么都不用做；坏处是“自动”这两个字往往会骗人，因为检索策略有时无法理解复杂的业务逻辑，会把一些文件名匹配相似但毫不相关的模块拉进来。

另一种是“主动指定”路径，也就是你在输入框里通过 @ 符号、文件选择器或规则声明的方式，手动把某个文件、某段代码、某个说明文档加入上下文。这条路径更可靠，因为 AI 能看到你明确指定的内容，不会自行脑补。缺点是需要你有一点“指挥意识”，知道哪些文件值得被拉进来。

我自己的习惯是：重大改动优先主动指定，简单修改依赖自动检索。尤其当你正在改一个核心模块时，哪怕自动检索功能已经建议了文件列表，我也会手动再确认一遍，把关键的 service 层和 model 层加上。

2.3 规则文件是 context-mode 里的“常驻记忆”

除了动态注入，context-mode 还有一个非常重要的组成部分：规则文件，常见叫法包括 AGENTS.md、CLAUDE.md、.cursorrules、或者其他项目级说明文档。这类文件之所以关键，是因为它不依赖你每次提问时手动添加，而是作为“常驻上下文”的一部分，比如让 AI 在每次交互时都自动读取并遵守其中的规定。

我的理解是，这个文件相当于给 AI 立了一套“项目宪法”：技术栈是什么、目录结构怎么组织、测试要不要写、命名规范是什么、有哪些绝对不能踩的雷区。以前没有 context-mode 的时候，这些约定写在 README 里只能给人看；现在它能同时给人看和给 AI 看，这个改变非常本质。

比如说我在一个 TypeScript 项目里写过这样的规则：所有错误处理必须返回 Result 对象，禁止抛异常；API 路由文件只能在 src/routes 目录下新增；数据库查询必须走 repository 层。写上这些后，AI 生成的代码质量直线上升，因为它不再是“搜到什么算什么”，而是先读到这些硬规定，再结合具体任务生成。

3. 实操：把自己的项目调教成高可用 context-mode

3.1 第一步：先写一份高质量的项目规则文件

规则文件是成本最低、收益最明显的上下文优化手段。无论你用的是什么工具，建议先检查项目根目录有没有类似 AGENTS.md / CLAUDE.md 的文件。没有的话，新建一个，然后按下面这个模板去填充：

# 项目代码 AI 协作约定 ## 技术栈 - 后端：Node.js + Express + TypeScript - 前端：React 18 + Vite - ORM：Prisma ## 目录结构 - src/services：业务逻辑层 - src/repositories：数据访问层 - src/routes：路由定义，禁止在 route 中写业务逻辑 - src/utils：通用工具函数 ## 硬性规范 1. 错误处理必须返回 { success: boolean, error?: string, data?: T } 结构 2. 禁止使用 any 类型 3. 新增数据库字段必须先写 migration 文件 4. 所有 API 必须有 JWT 鉴权，白名单接口需在 auth whitelist 中声明 ## 测试要求 - 核心 service 方法必须附带单元测试 - 测试文件与被测文件保持同级，命名格式为 *.test.ts ## 常见任务提示 - 新增用户相关接口时，先查看 src/services/user.service.ts 中现有校验逻辑 - 修改数据模型时，同步检查 prisma/schema.prisma

这份文件的真正价值不在于写得长，而在于写得“可执行”。我见过很多团队写了一大堆愿景式废话，什么“保证代码质量”“遵循最佳实践”，AI 看了等于没看。一定要像上面这样，明确、具体、可验证，最好带上路径和关键词。

写完规则文件后，重启 AI 助手，或者在对话中手动重新加载一下项目上下文。之后你随便问一个涉及项目结构的问题，观察它是否引用了规则文件中的内容。如果没生效，检查一下工具是否支持该文件名，以及文件是否放在工作区根目录。

3.2 第二步：针对具体任务动态追加上下文

规则文件是下限，动态追加是上限。实际开发中，很多任务是临时性的、局部性的，这时候就要用“主动指定”的方式临时补充上下文。

举一个我实际操作过的例子。有一次我需要把一个老旧的用户注册接口改成“邮箱验证后激活”模式。我先让 AI 查看规则文件了解项目约束，然后执行了这样几步：

1. 明确指定读取文件：@src/routes/auth.ts、@src/services/user.service.ts、@src/models/user.model.ts，让 AI 先看这几个核心文件。
2. 在对话中粘贴关键代码片段：把当前注册接口的十几行核心实现贴进去，并标注“这是当前逻辑，保留接口入参格式”。
3. 补充外部约束：把第三方邮件服务的接口文档关键段落手动贴进去，因为模型不一定知道你们公司用的邮件服务最新 API。

这套流程走完，AI 生成的改动几乎可以直接用，只在细节上修了一两个字段名。相比之下，如果不手动加上下文，让它“看着办”，结果就是重写一遍注册逻辑，完全不兼容现有用户表。

3.3 第三步：拆分任务，别一次塞太多

很多人有一个错觉：既然 context-mode 能加载上下文，那把能想到的文件全部加上总没错吧？实际上这是最典型的翻车姿势。上下文窗口有限，把太多无关文件塞进去会挤占有效空间，导致模型注意力被分散。

我自己有一个“三个文件原则”：单次对话中，除非任务确实牵扯很广，否则尽量把核心关注的文件控制在三个以内，其他文件通过搜索或让 AI 读取索引来了解。这样既保证关键信息充分，又避免上下文污染。

如果确实需要处理跨多个模块的大任务，正确做法是拆成多个连续子任务。比如“先分析影响面，再看数据层，最后写实现”，每个子任务重新调整上下文，比一口气让 AI 读完十几个文件要稳定得多。

3.4 实操中值得留意的工具差异

目前市面上 AI 编程工具对 context-mode 的实现各有侧重。有一些是编辑器插件形态，强调“自动跟随当前文件”，你打开哪个文件它就优先参考哪个；有一些是终端对话形态，更依赖规则文件和 @ 引用；还有一些是网页聊天形态，需要手动上传文档或开启联网检索。

这意味着同一个规则文件在不同工具里效果可能不一样。我的建议是：工具可以换，但规则文件一定要沉淀在你自己的项目里。哪怕换个编辑器、换个 AI 服务，只要规则文件还在，AI 对项目的理解就不会断档。这也是我坚持把所有约定写进代码仓库而不是写在聊天窗口里的原因。

4. 常见问题与排查技巧：为什么 AI 好像“没上下文”了

4.1 症状一：AI 总是忘记前面聊过的话

这是一个高频问题。你明明在第 3 轮规定了“不要修改配置文件”，第 4 轮它又去动配置了。很多人以为这是模型笨，其实大概率是上下文被截断或丢失了。

常见原因有两个。一是对话太长，超出了窗口长度，工具自动丢弃了最早的消息。解决办法是及时开启新对话，而不是在一个会话里无限堆积需求，把关键信息写进规则文件里更为稳妥。

二是在一些工具中，如果你切换了分支、改了文件名或者移动了文件位置，索引缓存没有刷新，AI 还在按旧路径找文件。这种情况一般重启工具或手动同步索引就能解决。我踩过一次坑：重命名一个 service 文件后，AI 反复引用旧路径，查到半天才发现是索引缓存过期。

4.2 症状二：上下文内容太多导致回复变慢或质量下降

当你发现 AI 的回复开始东拉西扯、废话变多，或者响应时间明显变长，大概率是上下文里塞了太多“背景噪音”。比如你手动追加了一个几百行的配置文件，而实际任务只需要其中三个参数，这些多余内容就会干扰判断。

排查方法是：精简上下文，只保留完成任务所必需的最小信息子集。这就像做菜，盐放多了可以补救，但食材下锅前你非要倒半瓶酱油，那这道菜基本废了。项目级规则文件里也要注意，不要堆积过期内容，定期清理和更新。

4.3 症状三：AI 明明读了文件，却理解错误

这可能是 context-mode 里最隐蔽的坑。有些工具自动检索时，只是把命中了关键词的文件片段截断了，比如只读了函数签名，没读到函数实现；或者只读了某个类名，没读到构造函数参数。AI 就在这种“半上下文”状态下开始推理，结果自然是错的。

遇到这种情况，不要急着骂模型。先检查 AI 回复中引用的代码片段，看看它到底看到了什么。如果它是基于不完整的信息在推理，那就手动补充完整文件或关键片段。我常用的验证方法是让它“复述一遍你对这个文件的理解”，它能准确说出来，才算真的读懂了。

4.4 补充一套排查思路

当你觉得 AI 表现异常时，按这个顺序排查几乎能覆盖大多数情况：

1. 确认规则文件存在且被工具识别；
2. 确认当前对话是否是新开、是否被截断；
3. 确认手动引用的文件路径是否正确、内容是否为最新版本；
4. 确认工具索引是否过期，必要时重建索引；
5. 确认上下文数量是否过多，尝试清空重试；
6. 如果问题依旧，尝试把需求拆得更细。

这套排查动作，我几乎每周都会用上。尤其是在大型仓库里，索引过期和文件路径错误出现的频率比你想象中高得多。

5. 从实战中总结的一些经验

说几个比较个人的体会。第一，context-mode 不是“开没开”的问题，而是“用得好不好”的问题。默认开关通常能解决 50% 的问题，剩下 50% 需要你自己动手去配置、去维护、去调优。

第二，规则文件的维护应该纳入代码评审流程。我见过太多项目一开始写了一份很好的 AGENTS.md，后来代码结构改了，文件却没人更新，AI 开始按旧规范生成新代码，闹出不少笑话。把它当成活文档，跟代码一起变更、一起评审，效果会好很多。

第三，不要在同一个会话里让 AI 做太多不同类型的事。每切换一次主题，就应该主动想一下：当前的上下文还适不适配这个新任务？如果不适配，就新开会话，重新构建上下文。这个习惯哪怕不给 AI 用，对你自己理清思路也有好处。

最后再分享一个我很喜欢的技巧：在规则文件里加一个“如果接收到的任务含糊不清，先列出你的理解并等待确认”的指令。这能让 AI 在上下文不充分时停下来反问，而不是硬着头皮写一堆程序正义但业务错误的代码。实测下来，这个“主动确认”机制能大幅减少返工，也是把 context-mode 用到极致的点睛之笔。