企业官网建设流程全解析

做AI辅助开发这么久，我踩过最大的坑不是模型不够聪明，而是它"忘了"。明明上午刚跟它敲定过的接口规范，下午换个文件再问，它能一本正经地给出完全相反的方案。后来我才意识到，不是模型出了问题，是我从来没好好管过它到底能"看到"什么——这就是我今天想聊的 context-mode，一个我用了大半年、几乎重构了我所有AI协作方式的东西。

简单说，context-mode 不是某个产品的某个按钮，而是一套"给AI喂上下文"的方法论和工程实践。它解决的是大模型上下文窗口有限、多轮对话遗忘、以及知识过时这三件最让人头疼的事。无论你是在用代码助手写业务逻辑，还是在用对话式AI整理文档、分析数据，这套思路都适用。这篇文章我会把整套东西从设计原理到落地配置完整拆一遍，最后附上我实战中踩过的坑和排查方法，希望能让你少走几个月的弯路。

1. 先搞清楚 context-mode 到底在解决什么问题

1.1 上下文窗口的物理限制

现在我们用的主流大模型，上下文窗口从几万 token 到上百万 token 不等，听起来很大对吧？但你要意识到，一个中型项目的代码库动辄就是几十万行，把所有代码塞进上下文不仅不现实，而且会带来两个致命问题：一是 token 成本直线上升，二是信息密度急剧下降。模型在面对海量输入时，注意力会被稀释，真正关键的信息反而容易被淹没。

我做过一个很直观的测试：把一份包含六千行代码的文件完整贴给模型，让它找出某个函数的所有调用点。结果它给了我三个虚假的调用位置，事后人工核对，有两个根本不存在的。但同样的任务，我只把相关的接口定义、函数签名和十几处关键调用片段整理成上下文喂给它，准确率几乎是百分之百。这个实验让我彻底明白了一个道理：给AI的上下文不是越多越好，而是越"对"越好。

1.2 遗忘曲线与多轮对话

大模型的"遗忘"和人类不太一样。人类是随着时间推移慢慢淡忘，而大模型是在每一轮对话中，都会把较早的信息压缩、丢弃或者干脆"记混"。你回想一下是不是经常遇到这种情况：第一轮你和AI确认了项目使用 Vue 3 组合式 API，写到第五轮它开始给你生成 Options API 的代码；你明确说过数据库表叫order_info，它后面却开始用orders这个表名。

这背后的机制是，模型在生成回复时，需要把整个对话历史重新处理一遍。当历史超过一定长度，早期的细节就会在注意力机制中被边缘化，表现就是"选择性遗忘"。context-mode 的核心思路，就是对抗这种遗忘——不是靠模型自觉，而是靠我们主动把关键信息固化下来，在每一轮交互中都显式注入。

2. 整体设计思路：把上下文当工程来做

2.1 上下文的三个层次

我在实践中把上下文分成了三个层次，每一层有不同的更新频率和管理方式。

第一层是全局静态上下文，也就是项目最基本的"元信息"：技术栈、目录结构、代码规范、命名约定。这一层几乎不会变，写一次可以长期复用。第二层是迭代动态上下文，指当前这个需求、这个迭代内的决策记录：本次要改哪些文件、接口怎么设计的、有哪些约束条件。这一层每个迭代更新一次。第三层是即时会话上下文，也就是当前这个AI会话里的临时信息：正在调试的报错信息、刚跑出来的测试结果、某一段具体代码。

这三层分开管理的好处很明显。全局静态上下文可以被所有会话复用，不用每次重新敲一遍；迭代动态上下文能保证AI始终围绕当前目标工作，不会跑偏；即时会话上下文则保持了灵活性，让临时信息可以快速进出。很多人在用AI开发时觉得效果不稳定，很大程度就是因为这三层信息混在一起，既没有分层，也没有更新机制。

2.2 为什么不是简单拼接文本

你可能会想，这不就是弄几个文本文件，用的时候拼在一起发给AI吗？表面上看确实如此，但实际操作中有几个容易被忽略的细节。

首先是格式问题。AI 对结构化的信息理解效率远高于纯文本。同样是技术栈说明，"技术栈：Vue 3 + TypeScript + Vite + Pinia"和一段二百字的项目介绍，前者被模型精确提取并使用的概率高得多。你给AI的信息越结构化，它的输出就越稳定。

其次是冗余问题。拼接文本最容易出现的状况是信息重复。比如全局上下文里已经写了"项目使用 pnpm 作为包管理器"，迭代上下文里又写了"请用 pnpm 安装依赖"，这不会让AI更重视这条信息，反而占用了宝贵的上下文空间。我见过有人一个上下文文件写到五千字，里面大量内容是重复的，这是在白白浪费 token。

最后是时效性问题。文本拼接是静态的，但项目是动态的。代码改了一版，接口换了个参数，如果上下文文件没有同步更新，AI 就会被过时信息误导，而且它自己根本不知道。所以 context-mode 不是搭一个模板就完事，它需要一套维护机制，这也是我后面要重点讲的。

3. 实操：搭建一套可复用的 context-mode 工作流

3.1 定义上下文模板

我现在的做法是在项目根目录建一个.context/文件夹，里面按层级放几个 Markdown 文件，我直接给你看模板。

# .context/global.md — 全局静态上下文 ## 项目概述 - 项目名称：order-service - 项目类型：订单中台服务的后端 API - 技术栈：Java 17 + Spring Boot 3 + MyBatis-Plus + MySQL 8 + Redis - 构建工具：Maven - 代码风格：阿里巴巴编码规范，方法注释必须写完整 Javadoc ## 目录结构 - `src/main/java/com/example/order/`：业务代码 - `controller/`：HTTP 接口层 - `service/`：业务逻辑层 - `mapper/`：数据访问层 - `src/main/resources/db/`：数据库变更脚本 ## 关键约定 - 所有接口返回格式统一为 `{ code, message, data }` - 分页参数统一使用 `pageNum` 和 `pageSize` - 订单状态枚举：`CREATED, PAID, SHIPPED, COMPLETED, CANCELLED`

# .context/iteration.md — 迭代动态上下文（每个迭代更新） ## 当前迭代目标 - 实现订单取消功能，支持用户主动取消和超时自动取消 ## 相关文件 - `OrderController.java`：新增取消接口 - `OrderService.java`：新增取消逻辑 - `OrderStatusHandler.java`：新增状态流转处理 ## 已确认的决策 - 取消原因用字符串字段 `cancelReason` 存储，不单独建表 - 超时取消由定时任务触发，扫描 `CREATE_TIME` 超过30分钟且状态为 `CREATED` 的订单 - 取消后需回滚库存，通过消息队列发送 `InventoryRollbackEvent` ## 当前待确认问题 - 已支付的订单是否允许用户主动取消？—— 待产品确认，默认不允许

这两个文件配合起来，我基本不用在对话里反复解释项目背景。每次开新会话，第一步就是把这两个文件的内容丢给AI，然后说"基于以上上下文，我们开始讨论本次迭代的任务"。效果立竿见影，AI 从一开始就知道自己在什么项目里、要干什么事。

3.2 注入策略与 token 预算

有了模板还不够，还得解决"怎么注入"和"注入多少"的问题。我给自己定了一个 token 预算规则：全局上下文控制在 800 token 以内，迭代上下文控制在 1200 token 以内，两者加起来不超过 2000 token。剩下的窗口留给对话本身和代码输出。

为什么是 2000 token 这个数字？以 128K 窗口的模型为例，2000 token 只占 1.5% 左右，几乎不影响模型的正常发挥，但对回答质量的提升却是巨大的。很多人喜欢把整个项目的 README、设计文档、接口文档全塞进去，动辄一两万 token，看似信息丰富，实际上模型根本分不清主次。

注入的方式也有讲究。我测试过几种不同的做法，效果差异明显。

第一种是对话开头一次性注入。在首条消息里把两个文件内容贴进去，之后正常对话。这种方式的优点是简单，缺点是如果会话很长，后续几轮里这些信息也会被稀释。

第二种是关键节点重复注入。在每轮重要交互（比如要求生成代码、修改方案）之前，都把核心上下文重新发一遍。这样能有效对抗遗忘，但代价是 token 使用量会高一些。

第三种是分段按需注入。只注入当前任务需要的部分。比如这次只要改OrderService.java，就只把相关接口签名和业务规则发过去，其他不相关的上下文一律不发。

我实际使用下来，推荐的做法是"开头完整注入 + 关键节点重复注入核心决策"。开头注入让AI建立整体认知，当对话超过十轮、明显感觉到AI开始遗忘时，就把iteration.md里的"已确认的决策"重新发一遍，这条经验非常管用。

3.3 与 AI 工具联动的落地方式

如果你用的是带项目级 AI 功能的编辑器（比如 Cursor、Continue 这类），可以把.context/文件夹里的文件配置成自动加载的规则文件，这样AI会自动读取，省去手动粘贴的步骤。

以 Continue 为例，它支持在.continuerules文件里写项目级规则。这些规则本质上就是我在global.md里维护的内容——技术栈、目录结构、代码约定。但我会把规则文件和上下文文件分开：规则文件里只放"必须遵守的行为约束"，上下文文件里放"需要知道的事实信息"。为什么分开？因为行为约束需要AI每次都严格遵守，而事实信息只需要它理解即可，两者的强制程度不同。

还有一个很实用的联动方式：把上下文文件纳入版本管理。.context/目录跟着代码一起提交到 Git，这样每次迭代改了哪些决策，看 Git 历史就能追溯。更重要的是，新成员加入项目时，只需要读一遍.context/里的文件，就能快速建立对项目的认知，这已经超越 AI 协作的范畴，变成了团队知识管理的一部分。

4. 实战配置：一个完整案例的逐行拆解

4.1 场景设定与配置目标

我用一个具体的例子来演示整个流程。假设我们现在要给一个电商订单系统开发"订单导出"功能，需求是：按条件筛选订单，生成 Excel 文件，超过 5 万条时改为异步导出，通过消息通知用户下载。我们来看看 context-mode 怎么辅助完成这个需求。

配置目标很明确：让AI在完全不问任何背景问题的前提下，直接产出符合项目规范、能通过 Code Review 的代码。我衡量一套 context 配置是否成功的标准就一句话——AI 主动提问的次数越少，上下文质量越高。

4.2 配置文件的建立过程

第一步，确认全局上下文是否覆盖了本次需求的所有基础信息。查看global.md，里面已经写了技术栈是 Java 17 + Spring Boot 3，接口返回格式是{ code, message, data }，这个需求不涉及新的技术组件，全局上下文不需要动。

第二步，更新迭代上下文。我新建一个iteration.md，针对本次导出需求补充以下内容。

# 迭代上下文：订单导出功能 ## 需求说明 - 支持按订单状态、创建时间范围、订单号模糊查询 - 导出字段包括：订单号、用户ID、商品名称、数量、金额、状态、创建时间 - 数据量 ≤ 5万条时同步导出 Excel，> 5万条时异步导出 - 导出文件名格式：order_export_yyyyMMdd_HHmmss.xlsx ## 涉及文件 - `OrderExportController.java`（新增）：导出接口 - `OrderExportService.java`（新增）：导出业务逻辑 - `OrderExportTask.java`（新增）：异步任务 - `OrderExportMapper.xml`（新增）：分页查询导出数据 ## 技术决策 - 使用 EasyExcel 生成 Excel，不引入 POI 原生 API - 异步导出使用 Spring 自带的 `@Async` + 线程池，不引入消息队列 - 导出进度状态存数据库表 `order_export_record`，字段含 `id, user_id, status, file_path, create_time` ## 约束 - 接口鉴权用现有的 `@RequiresAuth` 注解 - 导出金额字段单位为分（Integer），避免浮点误差

第三步，评估 token 占用。这个文件大概 600 到 700 token，加上全局上下文的 800 token，总共不到 1500 token，符合预算。

4.3 实际对话与效果验证

配置好之后，我打开一个全新的会话，把两个文件直接发给AI，提示词只有一句："基于以上上下文，开始开发订单导出功能。请先给出实现方案。"

这次返回的方案质量非常高。AI 不仅准确理解了需求，还主动指出了两个点：一是"超过 5 万条时改异步"这个阈值应该做成可配置的，建议放到application.yml；二是异步导出完成后，应该同时提供"下载地址"和"文件清理策略"，避免磁盘被占满。这两个点都是合理的补充，说明它确实读懂了业务背景和项目约束。

对比一下没有逐步维护上下文的"裸聊"模式：AI 会先问十几个问题——"你们用的什么框架？""分页组件是哪家的？""异步任务用什么中间件？""权限注解是什么？"——每一个问题都在消耗你的时间，而且这些问题在上下文里早就写了。

4.4 参数选择背后的计算逻辑

关于"为什么阈值定在 5 万条"，我补充一个简单的计算，帮你理解这类参数是怎么来的。假设单条订单记录在 Excel 里占用 80 字节（考虑到中文字段），5 万条大概是 4MB 的文件体积，同步生成在普通服务器上的耗时大约 2 到 3 秒，勉强可以接受。如果到 10 万条，文件 8MB，生成时间 6 秒以上，用户体验明显变差，而且大文件在 HTTP 响应里传输也容易超时。

所以我设置的是：同步导出的上限参考值 = 单条数据体积 × 预估条数 × 3（安全系数），控制在 5 秒响应时间内。这个公式不复杂，但它把产品需求变成了可量化的工程参数，这也是 context-mode 追求的效果——让AI基于明确的参数工作，而不是"大概""差不多"。

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

5.1 上下文污染：AI 被历史错误信息带偏

最典型的问题表现是：第一轮AI给了一个方案，你发现有问题，让它改。改完之后，它在后面的回答里又把第一轮的方案当成"最终版本"来引用。这是因为整段对话历史都在模型的处理范围内，被否定的方案并没有"删除"，只是优先级降低了。

我的排查方法很简单粗暴：当AI开始引用旧方案时，立刻把需求重述一遍，并附上当前迭代上下文中的"已确认的决策"部分，明确说"以下为唯一有效决策，之前的讨论作废"。实测下来，这种方式比单纯说"不对，重新来"有效得多，因为冲突信息被剪除了。

另一个容易忽视的污染源是代码编辑器自动补全的隐含上下文。如果你用的IDE集成了代码库级别的AI索引，它可能会把一些与当前任务无关的代码片段混入上下文。遇到AI突然提到一个跟当前需求无关的类或方法，先检查是不是编辑器插件在作怪，把无关文件从索引里排除。

5.2 上下文过时：配置文件没跟上代码变更

维护不及时导致的过时，是所有问题里最常见也最隐蔽的。有一次我改了数据库表结构，把order_info表的status字段从 varchar 改成 int，但忘记了更新iteration.md里的字段说明。结果AI沿着旧的上下文生成了一段把字符串"PAID"直接赋给 int 字段的代码，编译直接报错。

这类问题的根源在于上下文和代码是两份独立维护的资产，人的精力有限，顾此失彼。我后来想了一个相对省力的办法：每次代码合并到主干之前，把iteration.md的"变更记录"部分和本次提交的 diff 对照着过一遍。什么事情变了，就顺手更新到上下文文件里。这个习惯我坚持了三个月，基本杜绝了过时问题。

还有一个技巧：在上下文文件顶部加一行"最后更新时间"，每次修改后更新它。当你把上下文发给AI时，它至少知道这份资料的时效。虽然模型不会主动据此判断，但对你自己的维护节奏是个提醒。

5.3 token 超限与输出质量下降

上下文窗口是有限资源，但很多人没有意识到模型的输出长度也在消耗这个窗口。当你让AI生成一个很长的文件时，之前的上下文会被"挤"到窗口边缘，影响后续轮次的理解力。我遇到过最极端的情况：让AI生成了一个 3000 行的代码文件，然后问它"这个文件里有没有处理空指针？"，它回答有，实际代码里根本没有——因为生成过程中，早期指令已经被挤出有效注意力范围了。

应对策略很明确：大文件生成后，新开一个会话，只把生成的代码文件路径和新指令发过去，不要跟生成过程在同一个会话里讨论后续问题。对于超大代码文件，建议拆成多个会话、每个会话负责一个模块，最后用一次"全局审查"会话汇总检查接口一致性。

5.4 问题速查表

6. 进阶技巧：把 context-mode 变成自动化流程

6.1 用脚本自动生成迭代上下文

手动维护上下文文件还是太累，尤其是每次迭代开始时的初始化工作。我后来写了一个简单的 Shell 脚本，自动从 Git 分支信息、项目配置和最近提交记录中提取关键信息，生成迭代上下文的初稿。

#!/bin/bash # gen_context.sh — 生成迭代上下文初稿 BRANCH=$(git branch --show-current) LAST_COMMIT=$(git log -1 --pretty=%s) PROJECT=$(basename $(pwd)) DATE=$(date +%Y-%m-%d) cat > .context/iteration.md <<EOF # 迭代上下文：${PROJECT} (${DATE}) ## 当前分支 - 分支名：${BRANCH} - 最近提交：${LAST_COMMIT} ## 待补充 - 当前迭代目标：（手动填写） - 涉及文件：（手动填写） - 已确认决策：（手动填写） EOF echo "已生成 .context/iteration.md，请补充详细内容"

这个脚本只做"骨架生成"，真正的内容还是需要人来填，但它解决了从零开始的阻力。每次新建迭代分支后跑一下，五分钟内就能把上下文初始化好。

6.2 与团队协作的知识沉淀

context-mode 最有价值的地方，可能是它让隐性知识变成了显性资产。以前团队里"为什么要这么设计""这个表为什么加这个字段"这类问题，散落在各个人的脑子里和聊天记录里。现在有很大一部分被沉淀进了上下文文件，新成员上手项目的速度明显加快。

我这里再分享一个小技巧：把踩过的坑也写进上下文文件。格式很简单，在某个决策下面加一行"注意：不要使用 XX 方式，因为会导致 XX 问题"。AI 在后续生成中会主动避开这些坑，团队成员也不会再犯同样的错误。

比如我在订单导出这个迭代里就写过："注意：导出金额字段不要用 Double，会丢失精度，统一用 Integer 存分"。有了这一行，AI 每次生成金额相关代码时都会遵循这个约束，比我每次口头提醒可靠得多。

7. 我踩过最深的三个坑，提前帮你避开

第一个坑是上下文中混入了过多个人偏好。我一开始写全局上下文时，把自己喜欢的代码习惯全塞进去了，比如"变量名要用动词开头""函数长度不超过三十行"。这些约束本身没问题，但写得太多、太细，模型反而变得畏手畏脚，生成的代码过于碎片化。后来我精简到只保留项目级的硬性规范，个人风格的部分交给AI自然模仿就好。

第二个坑是把上下文文件当成了万能钥匙。有一次遇到一个极其复杂的历史遗留Bug，我精心维护了半天的上下文，AI 还是束手无策。后来才明白，context-mode 解决的是"AI 在不了解背景的情况下瞎猜"的问题，而不是"AI 什么都能解决"的问题。遇到需要大量推理和探索的任务，还是得靠人的判断力来引导，上下文只是基础，不是捷径。

第三个坑是忘了上下文也会误导AI。信息是双刃剑，过时的、不准确的上下文比没有上下文还要糟糕。我见过有人在上下文里写"项目使用 Redis 缓存订单数据"，但实际上缓存早就被移除了。AI 基于这个错误信息生成了大量跟缓存相关的代码，删起来比写还费劲。所以维护上下文时，最重要的原则是：宁可字段少，不可信息错。

做了半年多 context-mode 的实践，我最大的感受是：和 AI 协作，本质上是一种沟通能力。你沟通得越清晰、越有结构，AI 的回报就越稳定。而 context-mode 就是一套把"清晰沟通"固化成工程规范的方法，它不依赖某个模型、某个工具，任何时候都适用。如果你也在为 AI 遗忘、答非所问、代码风格漂移这些问题头疼，不妨从今天开始，在你的项目里建一个.context/目录，把第一条全局上下文写进去。一个月后你再回头看，会发现和 AI 的协作默契度完全不一样了。