企业官网建设流程全解析

做开发这些年，我发现很多人在用 AI 辅助编程工具时都会碰到一个很典型的现象：同一个模型，同一个代码库，有时候回答精准得像是读过你整个项目，有时候却答非所问，甚至一本正经地胡说八道。差别往往不在模型本身，而在于你有没有刻意管理 AI 的“记忆视野”。这就是我想聊的 context-mode，也就是“上下文模式”。它解决的核心问题只有一个：在 AI 的能力边界之内，决定到底把哪些代码、哪些文档、哪些对话历史喂进模型，让它在有限的注意力里做出最优判断。

这个标题听起来像是个简单开关，但真正用好的话，它其实是一个贯穿开发全流程的工程能力。这篇文章我会从概念拆解、核心参数、实操案例到问题排查，完整讲透 context-mode。不管你是刚接触 AI 编程辅助，还是已经在团队里把它当日常工具，应该都能从里面找到一些能直接用起来的东西。

1. 理解 context-mode：从“AI 失忆”到“AI 聚焦”

1.1 先看最常见的“模式困惑”

我先说一个场景。你让 AI 帮你重构一个模块的命名规范，明明刚在对话里贴过这个文件，但改到第三个函数的时候，它突然用回了旧变量名。你以为它是“忘了”，但严格来说，它并不是真的遗忘——而是它的上下文窗口里，早期对话信息已经被后续内容挤掉了。

现在的 AI 编程工具普遍有一个 Context Window，也就是上下文窗口的概念，通常以 token 为单位。用一个粗略的类比来说，这就像 AI 的“工作台”。工作台越大，能同时摊开看的东西越多，但超过工作台尺寸的资料，就只能放在远处的“资料柜”里。AI 面对庞大的代码库时，不可能把整个仓库都端上工作台，它只能靠索引、检索和你手动指定的文件来判断该取哪些资料。context-mode 的本质，就是帮你管理这个“工作台”的陈列策略。

如果你不主动管理，工具通常只会给一个“自动模式”：它会在你打开的文件、最近修改的文件、对话历史里各取一部分，拼成一份“工作台材料”。大部分时候够用，但一旦遇到大仓库、跨模块重构、或者复杂的多步任务，这种“自动拼装”就很容易出现信息偏移——该在的资源不在，不该在的却占了大量 token。

1.2 工作台思维：给 AI 配一个“临时桌”而不是“整层图书馆”

我自己在实际使用中，最喜欢把 context-mode 理解为两个级别的控制：

第一级是全量模式，相当于把整个仓库的检索结果都作为候选，让 AI 在全局范围里找答案。适合用来“认识项目”：比如刚接手一个老项目，需要 AI 帮你梳理模块依赖，或者定位一个 bug 可能在哪个文件。这个模式覆盖广，但代价是每次查询都消耗更多的 token，而且回答速度会变慢，偶尔还会因为候选文件太多，AI 反而不知道该选哪个。

第二级是聚焦模式，相当于你手动把几个关键文件“钉”在工作台上，AI 只基于这些内容来思考。适合用来“动手术”：比如你已经定位到 bug 在某个 service 文件里，就不需要再让它翻遍整个仓库。只要把那一个文件、相关的接口定义、还有一条出错日志喂给它，它往往能给出比全量模式更精准的答案。

这两种模式不是哪个更高级，而是要配合用。很多新人一上来就喜欢把整个仓库塞进上下文，觉得这样 AI“懂得最多”，结果反而容易出现前后不一致的回答。原因很简单：信息太多，AI 会平均分配注意力，而对当前任务真正重要的细节，反而淹没在了海量代码里。

1.3 为什么“上下文管理”正在成为硬需求

过去协作文档时代讲究“电梯陈述”，现在和 AI 协作讲究“上下文预算管理”。这是 context-mode 最有价值的地方。

模型输入是有硬上限的。以常见的多模态编程模型为例，上下文窗口可能从 16k、32k 到 128k token 不等。听上去很大，但换算成真实代码，128k token 大概也就 4 万到 5 万行的体量，看起来够用，可一旦对话历史长一点、需求文档和接口文档再占一部分，留给实际代码的空间就非常有限了。上下文模式就是在这种约束下，通过“筛选→压缩→加权”的手段，在有限的窗口里装下对当前任务最有用的东西。

我经常用一个比喻来解释：context-mode 就像一个项目管理里的“需求澄清会”。你不把几十 G 的需求文档全扔给开发，而是在会上把当前迭代最关键的三条需求讲清楚，再配一个变更记录。AI 的上下文模式做的就是这件事——在每轮任务开始前，先想清楚“这一轮该给它看什么”。

2. 核心设计与参数拆解：模式不是越多越好，关键是可切换

2.1 context-mode 通常包含哪些模式

先说结论，目前主流 AI 编程工具中常见的 context-mode 设计，通常包含三类核心模式：全量检索模式、聚焦文件模式、增量会话模式。每个工具叫法不同，比如有的叫 Global / Repo / Fast / Focused / Agent 模式，但底层逻辑大差不差。

这三个模式本质上是三种不同的“信息密度策略”。全量模式是广而浅，聚焦文件模式是窄而深，增量会话模式则介于两者之间，强调在同一段对话里保持一致性。

2.2 核心参数到底看什么

理解模式还不够，你还得会调参数。不同工具里参数名字可能不一样，但核心无非是几类：

第一个是max_tokens，或者叫context_limit，它决定 AI 单次能“看到”多少内容。如果你用的是聚焦文件模式，这个值可以设置得偏小，够包住目标文件即可。如果用全量检索模式，建议给足空间，否则检索结果还没塞进去，就被截断了。

第二个是检索深度，有的工具叫retrieval_top_k，有的叫“引用数量”。它决定在全局模式里一次召回多少个文件片段。我见过不少人的误区是把这个值调到最大，觉得 AI 能看更多文件。但实测下来，召回片段过多时，AI 经常出现“信息过载”，它反而会平均对待所有内容，把核心代码和无关配置一视同仁。我自己的经验是控制在 5 到 10 个片段最合适，超过 15 个以后诊断率明显下降。

第三个是“固定参考文件”。这类参数常表现为 pin 或 always_include。一个好的 context-mode 设计，应该允许用户把少数几个文件固定在工作台上，不管此刻是全量模式还是聚焦文件模式，这几个文件永远在上下文中。典型做法就是 AGENTS.md、README 或者是项目的架构说明文件。

2.3 一份可复用的 context-mode 配置示例

我在实际项目里，习惯在仓库根目录维护一份工具配置，把不同模式的规则固化下来。这里给你一份伪配置，你可以按自己用的工具改改看：

# context-mode 配置说明 ## 模式选择 - 默认：focused # 高效，适合日常改动 - 跨模块任务：global - 多轮重构：incremental ## 核心参数 max_context_tokens: 32000 retrieval_top_k: 8 pinned_files: - docs/AGENTS.md - README.md - packages/core/src/constants.ts ## 切换规则 - 任务目标包含两个以上模块：使用 global 模式 - 任务目标仅涉及单文件或单模块：使用 focused 模式 - 任务需要连续修改 3 个以上文件：切换 incremental 模式

这套配置背后有一个逻辑：把“模式选择”从靠感觉变成靠规则。当团队里每个人都按这套规则走，AI 的输出质量会变得稳定很多。你不需要每次都要想“该用哪个模式”，而是看任务类型自动落位。

2.4 模式切换的时机判断

模式切换不是玄学，它是可以流程化的。我总结了一个很实用的判断标准：看任务的时间跨度。

如果这个任务在半小时内能完成，比如修一个 bug、写一个单元测试、加一个接口，用聚焦文件模式就够了。把相关那个文件钉住，把报错日志贴进去，run 一次，能解决就解决，解决不了再放开检索范围。

如果任务要跨半天以上，比如需要在一个大功能里同时调整后端接口、前端调用、类型定义和测试用例，那就要用增量会话模式。每轮只做一件事，但始终保持对话连续，不让 AI 丢掉前面已经确定好的接口签名。

如果任务是要摸清一个不熟悉的仓库，比如接手遗留系统，或者排查一个只在特定环境下出现的 bug，那就打开全量检索模式，让 AI 去仓库里找线索。

我踩过最大的坑，就是在聚焦模式下问了超过上下文范围的问题。它明明看不到那个文件，但它不会告诉你“我没看到”，而是会根据已有的零散信息“猜”一个答案。所以在切换模式之前，你得先确认：这个任务需要的信息，是不是已经放在 AI 的工作台上了。

3. 实操：在真实开发流程里把 context-mode 用在刀刃上

3.1 场景一：新项目起飞，用全量检索模式快速建立项目地图

接手一个不熟悉的项目时，传统的做法是先把代码跑起来，再看 README，再看核心模块，整个流程下来半天就没了。用 context-mode 的话，第一步可以直接切成 global 模式，然后让 AI 基于仓库全局信息回答几个问题。

我通常第一波会问三件事：

• 这个项目的整体架构是怎样的？入口在哪、依赖关系如何？
• 核心业务链路从哪个函数开始，到哪个接口结束？
• 如果我要加一个新功能，应该从哪个模块入手？

切到全量检索模式后，AI 会利用仓库索引去寻找线索。但这里有个注意点：它检索的是“文本相似度”，不是“业务语义”。如果项目里有些文件命名不清晰，比如所有工具类都叫 utils.ts，那 AI 很可能找到全是雷同名字的文件，而错过真正的核心逻辑。所以这时候，你要手动把关键文件的路径加入 pinned_files，让它优先看这些。

我在一个电商后端项目里，就是这么梳理出来的。整个仓库有 400 多个文件，打开 global 模式后问了一句“订单履约流程怎么走的”，三分钟内，AI 顺着订单状态机的代码、仓储服务的调用关系，把整条链路列出来了。如果是以前人肉翻代码，这个工作量至少要半天。但前提是我把orders/和inventory/两个核心目录的说明文件固定进了上下文。没有这个动作，它的回答会停留在“表面相似”的文件上。

3.2 场景二：修改单点 Bug 或微小重构，聚焦文件模式是精确手术刀

修 Bug 是 context-mode 最典型的精确使用场景。先说操作流程，五个步骤：

第一步，把异常堆栈和 bug 触发的具体操作步骤贴进对话。 第二步，切到 focused 模式，把候选文件（通常是报错堆栈里出现的那个文件）钉进工作台。 第三步，让 AI 解释这个文件的核心逻辑，确认它“真的看懂了”。 第四步，给出修复建议，并限定它只能基于当前文件上下文提出方案。 第五步，让 AI 写出修改后的完整函数，而不是只给片段。

这套流程看起来简单，但里面有个很关键的细节：第三步千万不要跳过。你让 AI 解释文件逻辑，其实是在做一次“上下文完整性测试”。如果它能准确说出这个文件的输入输出、边界处理、隐含依赖，说明它已经把手头的信息吃透了。这时候再让它改代码，准确率会高很多。如果它解释得驴唇不对马嘴，那就说明工作台上的材料不够，你得补充相关类型定义或调用方代码，再继续。

我自己用聚焦模式时，还有个习惯：把相关文件路径直接写在问题里。我会说“请基于 service/user.ts 和 types/user.d.ts 这两个文件做分析”，这种显式指定比依赖工具自动加载要可靠得多。因为自动加载可能只加载了其中一个文件的部分片段，而你手动指定的文件会以更完整的形式进入上下文。

3.3 场景三：跨模块长链路重构，增量模式做好“记忆接力”

跨模块重构是最容易出现“AI 失忆”的场景。比如你要把一个支付模块从老接口迁移到新接口，中间要改 controller、service、model、test 四个层次，没有一个人能在一次对话里让 AI 全部改完还保持一致的，这时候 incrementa 模式的价值就出来了。

我的做法是分段推进，把重构拆成三个迭代：

第一迭代，先把目标接口定义、现有模块的调用关系全部放上工作台，让 AI 输出一份迁移预案，包含新旧接口的字段映射、影响范围清单。切到 global 模式完成这一步。

第二迭代，把预案作为“上文”，切换到 focused 模式，逐个文件修改。每改完一个文件，就把 AI 的摘要更新到对话里，此时打开 incremental 模式，让新对话继承前一轮结论。

第三迭代，完成后切回 global，让 AI 重新检查一遍上下文里是否还有引用旧接口的地方。

这套流程的精髓在于：不要在一个模式里做所有事。每轮任务结束的时候，不需要 AI 把所有细节都留在脑子里——你只需要让它输出一份“当前状态摘要”，比如“controller 层已改完，service 层还有 3 处依赖旧接口”。下一步再把这个摘要作为新上下文的锚点。这就是增量模式的真正用法：让它成为一个可以连续承接的“交接棒”，而不是声音越来越小的电话线。

3.4 场景四：测试生成与接口对接，用上下文模式维持“一致性”

写单元测试是很多人喜欢用 AI 的地方，但也是“上下文失控”的重灾区。

如果你直接对 AI 说“给这个项目写测试”，它可能会生成一堆能通过编译但与业务语义完全无关的测试用例。原因是它不知道接口的真实约束和边界条件。我的做法是，先切到 global 模式，提出一个目标：“给 paymentService.createOrder 写单元测试，覆盖金额边界、并发重复请求、库存不足三个场景。”然后让它自己把相关的 entity、repository、错误码定义都找出来。这一步是让 AI 建立“测试对象”的全局认知。

确认它找到了正确文件后，再切到 focused 模式，把目标文件的完整代码、依赖服务的接口定义、以及一份测试规范文件（比如项目里的测试命名规范）一起钉进上下文。之后才开始生成测试代码。

这样生成的测试，覆盖率和准确率都会明显高不少。关键就在于我们通过模式切换，把“探索信息”和“精准输出”这两个阶段分开了。探索阶段允许 AI 广撒网，输出阶段要求它只看关键材料。

3.5 常规项目里的十分钟上手路径

如果你是第一次接触 context-mode，不用急着配一堆参数。我给你一条十分钟就能走通的路径：

打开你的 AI 编程工具，看设置里是否有“模式”或“上下文选项”。没有的话，就用对话式指令：在每次提问前显式声明“本次只基于以下文件回答”，然后附上路径。先养成这个习惯，后面再慢慢研究工具自带的模式。

做完一件事之后，对比一下前后回答质量：如果切到 focused 模式后，回答反而更精准，说明你之前用全局模式依赖太重了。如果切到 focused 模式后，AI 开始胡诌，说明这个任务本来就需要更多信息。多做几次这种对比，你对 context-mode 的理解会比看十篇文章都深刻。

工具始终会变，但“管理工作台信息”这个心智模型是不过时的。

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

4.1 症状速查表

4.2 典型问题一：上下文中混入了“过时信息”

这是我遇到的概率最高的问题。AI 给你推荐了一个方案，但这个方案基于的是它检索到的一版很旧的接口签名。你在反馈里说“我这里已经没有这个参数了”，它会道歉，然后换一个方案。但如果它检索到的旧文件仍然在上下文中，它会反复把旧签名当作“事实依据”。

解决方式很直接：用git log查这个文件的改动时间，如果最近确实有大重构，先手动把新版本文件的内容贴给 AI，同时告诉它旧的已废弃。这比让它反复在仓库里“自我翻找”要快得多。

我还有一个习惯，就是定期清理“钉住文件”。有些文件我当初把它设置为 always_include，后来发现它已经不再被项目引用了，但它还在每次对话中占据固定 token 额度。这其实就是一种看不见的上下文浪费。每两周我会做一次全量模式的询问：“当前项目中哪些改进了？”把已废弃的固定引用清掉，这台 AI 工具就又“轻”了不少。

4.3 典型问题二：聚焦模式下 AI 开始“一本正经胡说八道”

很多人切到聚焦模式后，发现 AI 反而开始编造不存在的东西。这不完全是模型的问题，而是聚焦模式下，它看不到全局，自然不知道全局里有哪些约束。如果你问它“这个模块有没有并发锁”，而你没把并发相关的代码放上工作台，它就说“似乎没有”。

这时你要做的是承认聚焦模式的信息边界。不要在聚焦模式下问“全局判断类”的问题。如果你需要它判断“某某功能是否安全”，必须把安全校验相关的代码也放进上下文，或者干脆切回 global 模式。

这个原则被我记成了口头禅：聚焦模式下问“怎么改”，全量模式下问“为什么”、“在哪里”。

4.4 典型问题三：模式切换后，之前的“约定”被丢掉了

增量会话模式的坑在于：工具可能会在你切换模式时清空会话缓冲，导致 AI 完全忘了之前已经确定好的方案。我在一次重构里就吃过这个亏：上一轮确定了“控制器只接收 DTO，不直接依赖实体”，下一轮切换模式后，AI 又大摇大摆地写回了实体参数。

规避方式有两个：

第一，不要依赖 AI 的“记忆”，把重要约定直接写进项目说明文件。我在每个项目根目录都会放一个AGENTS.md，里面不仅写明技术栈，还会写明“本项目禁止在 controller 层直接引用 ORM 实体”。不管上下文怎么切，只要这个文件被 pinned 进工作台，这些约定就不会丢。 第二，切换模式时，先让 AI 对着约定文件做一次“确认”，比如问一句“我们上一轮确定的原则是什么”，它答对再继续。这本身也是对我的上下文管理是否到位的一次校验。

4.5 独门技巧：上下文“瘦身阶梯”

最后分享一个我自己一直在用的方法，叫“瘦身阶梯”。当 AI 的回答质量下降时，不要马上加大上下文，而是按照一定顺序做“减脂”：

第一阶，先从对话里移除历史样例代码，只保留当前出错信息。 第二阶，把 pinned_files 里不相关的内容去掉，只留当前模块。 第三阶，如果仍然混乱，直接把会话归零，开启一个全新上下文，只带上必要摘要和问题本身。

为什么“减脂”反而比“加料”更有效？因为模型在上下文里搜索正确答案的能力，和人类在工作台上找东西类似。一个堆满杂物的桌面，就算有正确答案你也看不到。上下文越小，注意力越集中。很多看似“模型不够聪明”的翻车，其实都是我们自己往它的工作台上堆了太多无关资料。

5. 从“个人技巧”到“团队工程”：让 context-mode 成为可沉淀的资产

5.1 把模式说明写进仓库，而不是留在聊天记录里

我在团队里推行过一套做法，把 context-mode 的使用说明直接固化到仓库目录。不是一张口头说明，而是一份真实可用的规则文件。这样的好处是，新人一到项目里，打开工具加载这个配置，就自动获得了团队沉淀下来的上下文策略。

这份规则文件里写明几类关键内容：

• 项目采用哪些 context-mode 组合
• 默认 pinned 哪些文件
• 什么情况下需要切换模式
• 项目中哪些目录禁止 AI 引用（比如生成代码目录、构建产物目录）

这样做之后，团队协作里就少了一个最烦人的问题：同一个 AI 工具，不同人用出来效果天差地别。核心玩法不是模型不同，而是上下文管理的方式不同。

5.2 建立观察与复盘机制：多问一句“它看了什么”

使用 context-mode 到了进阶阶段，不是看你怎么回答，而是看你怎么提问。

我推荐每周做一次“上下文管理复盘”。打开 AI 工具的日志，或者根据输出内容回顾一下：这一周里，多少次是因为上下文不足导致的偏题？多少次是因为上下文过载导致的回答空泛？针对这两类问题，分别调整配置。

也可以从另一角度做观察：那一句让 AI 突然“开窍”的话，是不是你把正确的文件路径贴给了它？如果是，说明你的检索策略有效。把一个有效的“检索动作”记录下来，沉淀为团队的使用经验，比记一百句“咒语”都实用。

不少团队已经这样做了：他们把“喂给 AI 的文件清单”称作“项目雷达”——这份清单代表着一套知识结构：哪些文档对项目至关重要，哪些代码是核心链路的关键编排，哪些旧模块正在被替换。context-mode 其实也承载着这种知识表达。

5.3 统一多工具之间的理解：别被界面的“模式按钮”框住

市面上 AI 编程工具各有各的叫法，有的按钮叫 Agent，有的叫 Ask，有的叫 Edit，有的把它藏在快捷键里。但底层暴露出来的逻辑都一样：你决定在一个多大的视野范围内让模型思考。所以我建议你不要依赖某一个工具的界面，而是把 context-mode 理解成一个自问自答的问题：

“本次任务在多大范围内搜索信息最合理？”

这个问题的答案，决定你选哪个模式、钉住哪些文件、设置多大的检索范围。界面和按钮会变，但这个问题永不过时。你带着这个心智模型去用任何工具，都能很快定位到对应的设置项。

5.4 最后分享一个关于“喂什么”的经验

说到最后，context-mode 不是万能的。它的作用在于帮你管理模型的视野，但它没法替代高质量的项目文档。任何模式调优都替代不了一个事实：如果仓库里根本没有清晰的架构说明、接口文档和模块边界描述，AI 就算把整个仓库都装进上下文，也只能看到一个“堆满代码但缺乏语义”的世界。

所以我的建议是，一边调试 context-mode 的参数，一边花点时间把项目里的说明文档建起来。比如每周留 30 分钟，把新碰到的核心概念写进 README，把接口变更记录写进 CHANGELOG，把容易踩坑的逻辑写进 AGENTS.md。这些内容看起来简单，它本身就是在为 AI 准备更有价值的知识供给。当文档信息密度上来以后，context-mode 里的“context”才能真正做实，模式切换的精准度也会明显提升。

我在实际使用中有个很深的体会：context-mode 不是让 AI 替代你思考，而是让你决定它该思考什么。它更像是一个取景框，框住的是当前任务的世界边界。你可以随时拉近、拉远、调整画幅，但没有哪个焦距是永远正确的。多问自己一句“这个任务需要多大范围的视野”，比任何参数调优都管用。把这个问题问顺了，再复杂的大仓库、再长的重构链路，你也能跟 AI 配合得很稳。