企业官网建设流程全解析

前阵子接了个活，帮朋友改造一个内部系统。代码不多，几万行，可一上手我就犯了个典型的错误——一股脑把整个项目的源码全塞给了 AI 助手，让它帮我看代码结构。结果它给我的分析报告洋洋洒洒写了两千多字，前面一大半都在讲登录模块和权限框架，而我真正想改的那个订单导出功能，它只用了两行带过。那一刻我意识到，context-mode（上下文模式）这个东西，选错了是真的会翻车。它不是某个工具的隐藏设置，而是 AI 辅助开发里最容易被低估、也最值得花心思去研究的一环。这篇博文，我就想把自己踩过的坑、试出来的方法整理出来，聊聊 context-mode 到底该怎么用。

先说说这篇文章适合谁看。如果你经常用 AI 写代码、做代码审查、或者维护一个规模不小的项目，那你一定会遇到上下文不够用、AI 答非所问、改错文件这类问题。这篇文章讲的是上下文模式的完整思路，包括概念拆解、三种典型模式、实操切换流程，以及我攒下来的一些排查技巧。不管你是刚上手的新人，还是已经被“AI 乱改代码”折磨过的老手，应该都能找到能直接用的东西。

1. context-mode 不是开关，而是一套上下文管理方法论

1.1 先从一次翻车经历说起

我那个朋友的项目，是个典型的单体应用：前端 Vue、后端 Spring Boot、数据库 MySQL，模块差不多二十多个。最初我把整个仓库的代码都作为上下文丢给 AI，想让它给我梳理出“订单模块的完整调用链”。结果是，AI 确实把调用链梳理出来了，但用的还是旧版本的接口定义，因为旧代码文件在语料里的权重更高，新改过的那个文件反而被淹没了。我后来重新整理上下文，只把订单模块相关的 controller、service、mapper、SQL 脚本、前端页面这几个文件挑出来喂给它，问题立刻解决。

这就是 context-mode 的本质——它不是一键开启的某个功能开关，而是你如何决定哪些信息进入模型视野、以什么顺序进入、以及以什么粒度和它对话的一套策略。说白了，上下文模式是一个方法论，而不是一个配置项。

1.2 我在说的 context-mode 到底是什么

我做了一段时间后，习惯把 context-mode 拆成三个环节来理解：

• 上下文采集：明确当前这次对话/任务需要哪些信息，是从项目源码里拿、从文档里拿、还是从报错日志里拿。
• 上下文筛选：把不相关的、过时的、低价值的信息剔除掉，尽量留下高信噪比的片段。
• 上下文注入：把筛选后的内容以一种清晰的、适合任务的形式组织起来，比如按“先背景、再指令、后示例”的结构一起给到模型。

很多人只关心“上下文窗口有多大”，却忽略了后面两个环节。实际上，窗口再大，如果你塞了一堆噪音进去，模型的输出质量照样会断崖式下跌。

1.3 三个术语先对齐：上下文窗口、Token、系统指令

为了避免后面理解偏差，先快速对齐几个高频词：

这三者加上前文说的采集、筛选、注入，就组成了我对 context-mode 的完整认知框架。零散地看，它们都是老概念；但把它们串成一套方法之后，很多事情就有迹可循了。

2. 三种典型 context-mode 拆解：全量、局部、检索

2.1 全量模式：让 AI 看到完整项目

全量模式，就是把尽可能多的项目代码或文档作为上下文投喂给模型。典型做法是把多个文件内容拼接到一次对话里，或者用某些带有“整个仓库”编码能力的工具直接让模型访问全部代码。

什么时候全量模式是合适的？我个人体会，它最适合“全局理解型”任务：比如梳理系统架构、盘点模块依赖关系、跨模块排查性能瓶颈、做技术债务分析。这类任务的特点是，你需要模型具备对整个项目的整体视野，而不是盯着某一行代码。

但全量模式有两个很明显的副作用。一是 token 消耗大，几万行的项目可能一次就把窗口挤爆，尤其是代码里注释多、配置文件多的时候。二是注意力稀释——模型对上下文的关注不是均匀的，它会被开头、结尾、重复出现的内容、以及语法上更“显眼”的代码片段吸引。如果你的目标模块在中间某处、而且文件排得靠后，它的优先级会被自动压低。我那次翻车，说白了就是注意力稀释造成的。

所以我会给自己定一条规矩：全量模式只做“理解”和“规划”，不做“修改”。让模型基于全量上下文去产出项目地图、模块清单、改动建议，但真正动手改代码时，切到局部模式。

2.2 局部模式：挑出最相关的文件精准投喂

局部模式是日常开发里我用得最多的一种。它的核心动作只有一个——缩小上下文范围到跟当前任务直接相关的文件集合。

举个例子，我改一个支付回调接口。我通常会把这几个文件喂给 AI：

• 支付回调的 Controller 文件
• 对应 Service 接口和实现类
• 涉及的实体类与 DTO
• 相关的 Mapper 或 Repository
• 支付渠道方的回调签名校验工具类
• 如果改了数据库字段，把对应的迁移脚本也带上

喂的时候，我会在开头加一句简短的说明：“以下是本次改动涉及的源码，请基于这些代码完成：把回调校验逻辑从 MD5 升级为 HMAC-SHA256，保持接口地址和返回结构不变。”

局部模式的好处是信噪比极高，模型能集中精力处理核心逻辑，生成的代码更贴合现有风格。缺点是它依赖你去“猜”哪些文件是相关的。猜错了，模型会因为缺少关键信息而给出看似合理、实则跑偏的答案。所以局部模式很考验你对项目结构的熟悉程度。对于不熟的项目，我一般会先让模型用检索模式帮我定位相关文件，再切换到局部模式去改代码。

2.3 检索模式：让 AI 先搜索，再回答

检索模式，说白了就是不把整个代码库喂进去，而是让模型基于索引或搜索机制，先定位到相关信息再来回答。最典型的表现就是一些 AI 编程工具里的“代码库问答”功能：你问它“库存扣减的接口在哪里”，它通过检索把相关文件片段捞出来，再基于这些片段回答。

这种模式非常适合定位型任务：查某个接口的实现、找某段日志打出的位置、确认某个常量定义在哪个文件、或者排查一个跨模块的 bug。它既绕开了窗口大小的限制，又比人肉翻代码快得多。

但检索模式也有自己的坑。我遇到最多的问题是检索结果不全。比如我搜“库存扣减”，返回的是 service 层的实现，但真正导致 bug 的那段 SQL 在另一个文件里，而那个文件因为关键词匹配度不高没被检索到。这种时候，我的经验是用多个不同的关键词去搜索，或者从已知线索（报错信息、接口名、字段名）反查调用链，把漏网的文件补进来。

2.4 三种模式怎么选：一张表说清楚

我把三种模式的选择逻辑整理成下面这张表，平时基本按这个来：

好，这张表可以作为默认起点，但你真正用熟练之后会发现，实际项目里很少只用单一模式——更多时候是在一次会话中组合使用。

3. 实操记录：一个中型项目三天内的 context-mode 切换全过程

3.1 第一天的项目摸底：全量模式开道

我那个朋友的内部系统，我拿到手后没有急着写代码。第一天干的事，就是把项目完整地交给 AI 做一次“摸底”。

我在对话开始时切换成全量模式，给了这样一个指令模板（这里给出我实际用过的一版）：

请阅读附件中的所有源码（前后端、SQL、配置文件），完成以下任务： 1. 用一句话概括这个系统的核心业务。 2. 列出所有模块名称，以及每个模块的核心职责（不超过 50 字）。 3. 画出订单模块从前端请求到数据库落库的完整调用链，标注关键类名和方法名。 4. 指出项目中重复代码较重、可能需要重构的 3 个位置。 5. 给出项目使用的技术栈清单，标注各部分的版本。

跑完一轮之后，AI 确实输出了一份结构清晰的项目地图。但我也发现，它在第 4 项“重复代码较重”上给出的判断有点泛——它指出的三处，有两处其实是同类代码，算不上真正的问题。原因还是全量模式下的注意力稀释：它更关注那些在多个文件里反复出现的内容，而忽略了上下文里短的但是关键的文件。

所以我做了一次校正：全量模式产出的结论，我最多信七分，剩三分必须自己到代码里核实。尤其是架构判断、模块边界这类高风险结论，核实一下再往下走，不会亏。

3.2 第二天的功能开发：局部模式为主，检索模式打辅助

第二天的任务是给订单模块加一个“批量导出”的功能。按照我的经验，这个任务不需要 AI 看整个项目，我只喂了订单模块相关的 5 个文件：订单 Controller、订单 Service、订单 Mapper、订单实体类、前端订单列表页。

我给 AI 的指令是这样：

请基于以上文件，实现订单批量导出接口。 要求： - 后端新增 /api/orders/export 接口，支持按时间范围和状态筛选。 - 导出格式为 Excel，包含订单号、用户昵称、金额、支付时间、状态。 - 前端在列表页增加“导出”按钮，调用新接口并触发文件下载。 - 接口返回的数据量控制在单次 5000 行以内，超出时提示用户缩小范围。 - 保持现有代码风格，不要改动文件里与本次导出无关的逻辑。

这次跑得就很顺。AI 生成的代码基本可以在现有风格里无缝嵌入，接口命名也符合项目惯例。唯一的问题在第 3 条：前端下载文件时，它用了一个blob下载方式，但没处理错误状态——如果后端返回 JSON 错误信息，前端会把错误信息当成 Excel 文件下载下来。这个是我后来 review 时发现的。

踩过这个坑之后，我在局部模式的指令模板里额外加了一条：生成代码时必须包含异常分支和错误处理逻辑。这个固定要求帮我挡掉了不少后续麻烦。

3.3 第三天的重构与 Review：检索 + 全量混合

第三天做的事有两件：一是把订单模块里一段重复了三次的导出逻辑收敛成一个公共方法；二是给整个改动集做一次代码 Review。

第一件事，我先用检索模式查了“导出逻辑出现的位置”，AI 返回了三个文件路径。然后我把这三个文件和相关调用方一起切到局部模式，给了重构指令。因为范围明确，重构后的公共方法很快就写出来了，而且没有破坏原来的三处调用。

第二件事，代码 Review 我用的是“全量 + 局部”混合的方式：先把整个 diff 作为上下文给 AI，让它在全量视角下做一遍审查，重点看逻辑正确性和事务边界；然后再把改动涉及的具体 service 文件单独拉出来，做一次更细的局部检查，重点看代码规范和异常处理。

这个流程走下来，我最大的体会是：context-mode 的选择不是一次性的，而是动态的。同样一个任务，第一阶段可能需要全量视野来拆解目标，第二阶段切到局部来聚焦实现，第三阶段再回到全量来审查边界。切换得越顺，AI 的输出质量越稳定。

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

4.1 上下文越堆越多，AI 反而越笨

这个问题几乎每个用大模型写代码的人都遇到过：你为了让 AI 更精准，把越来越多的相关代码喂进去，结果它越改越乱，甚至开始重复自己说过的话。

原因其实前面已经提到过——注意力稀释。模型对上下文各个部分的注意力不是平均分配的，超过一定长度之后，它对早期内容和中间内容的理解会变差。你喂了 10 个文件，它真正“看进去”的可能只有开头和结尾那两三个文件。这可能就是为什么 AI 有时候会盯着一个不太相关的文件反复分析。

我的做法是“三七原则”：每个任务喂的上下文里，直接相关的代码占三成，任务描述、约束条件、示例输出占七成。也就是说，不是代码越多越好，而是关键信息要重复强调、加强提示，让模型知道重心在哪里。如果上下文确实很长，我会把最重要的指令放到对话的最前面和最后面，这两个位置是模型注意力最强的区域。

4.2 模式切错了但没发现，表现为不停地“漂”

有一次，我让 AI 修改一个 Kafka 消费端的重试逻辑。我切的是局部模式，只喂了消费端那个类文件。前两轮对话都正常，但到第三轮，它突然开始大改同包下另一个文件，而且是在我没要求的情况下。我一开始以为是它“自作主张”，后来排查发现，是我在第二轮对话里贴了一小段日志，日志里包含另一个类的类名，于是 AI 就顺着这个线索去“推理”，自己把上下文扩张了，结果就漂了。

这个问题的根因是：局部模式下，模型的推理路径会发生偏移，它可能从你给的信息里延伸出额外的探索。解决办法是每轮对话都明确重申边界。我现在跟 AI 写代码时会带一句固定的话：“本次改动仅限 X 文件，不要修改其他文件，如果发现必须改动其他文件，请先报告再行动。”这句话不一定 100% 管用，但确实能把漂移的概率降下一截。

4.3 成本控制：小步快跑还是攒一波大的

上下文窗口变大，token 成本也随之变高。有些人为了节省成本，刻意把上下文压得很小，结果 AI 因为看不到足够的信息反复试错，反而更费 token。也有些人每次都上全量模式，觉得这样做出来的代码最准确，但一次对话就要烧掉几千甚至上万 token，其实很多都没必要。

我的经验是中庸路线：先用检索模式确认范围，再用局部模式做正文，最后用全量模式只审不改。如果任务本身很小，比如改一个参数名、调一个函数返回值，那就完全不需要上全量模式，给一小段局部代码就够了。成本最优的解，不是“尽量少喂”，也不是“尽量多喂”，而是“喂到刚好能一次做对”。

4.4 团队协作里的 context-mode 约定

如果团队里多个人都在用 AI 辅助开发，context-mode 的作用就更明显了。我见过有些团队的 AI 生成代码风格五花八门，原因就是每个人喂的上下文不一样、看的文件不一样、给的约束也不一样。最后代码库就跟多个作者混写出来似的，风格割裂。

我的建议是维护一份轻量的“上下文清单”文档，里面固定写清楚：

• 项目的技术栈和框架版本
• 核心目录结构和每个目录的职责
• 团队统一的代码规范（命名、注释、异常处理、日志规范）
• 常被 AI 误改的高风险文件列表
• 约定好的 context-mode 使用原则（比如：改动核心支付模块必须走局部模式，禁止全量模式直接改代码）

这份文档不用很长，几百字就够，但每次喂给 AI 之前把它放在上下文里，效果立竿见影。

最后再分享一个我在实际使用中总结的小技巧：上下文模式的本质，是你要像一个好的项目管理者那样，决定给执行者看什么。给太少，它做不出；给太多，它抓不住重点；给错了，它跑偏得理直气壮。我踩过几次坑之后，现在每次跟 AI 对话前都会先花三十秒想一个问题——“如果这个任务交给一个新人来做，我会让他先看哪几个文件？”想清楚了再喂上下文，成功率会高很多。希望这篇关于 context-mode 的经验总结，能让你少走一些我走过的弯路。