企业官网建设流程全解析

最近在技术社区连续刷到 "context-mode" 这个词，点进热搜看了几轮讨论，发现大家聊的并不是某个产品里的固定按钮，而是同一件困扰很多人很久的事：和大模型长时间对话时，怎么让 AI 既记得住前面说过的话，又不被无用的旧信息带偏。这个问题的本质，就是上下文的组织与管理模式。

我自己每天都在用 AI 助手写代码、读文档、拆需求，踩过的坑不算少。最典型的一次：一个项目连续聊了快两个小时，模型突然开始反复建议一套和需求完全相反的方案，我回头翻聊天记录，才发现它的注意力早就被一堆旧日志和无关文件带跑了。那次之后我开始认真研究 context-mode——不是去点哪个开关，而是把"喂给模型的上下文"当成一个需要主动设计、主动维护的东西。这篇就把我这段时间摸索出来的完整玩法梳理一遍，适合同样在跟大模型打交道的开发者、分析师，以及任何需要长时间使用 AI 干活的人。

1. 先搞清楚 context-mode 到底是什么

1.1 它不是一个按钮，而是一套上下文管理思路

先澄清一个容易误解的地方：context-mode 不是某个工具里的一个模式选项，至少不全是。现在确实有一些产品把"简短回答/平衡/详细解释"这类输出风格叫模式，也有一些 AI 编程助手提供"全局上下文/当前文件上下文"的切换开关，但如果你只把这些当成 context-mode 的全部，那就把问题想简单了。

我理解的 context-mode，是对"模型在当前时刻能看到的全部信息"的显式管理方式。它由两层组成：

• 工具层的模式：产品预设的上下文策略，比如一次对话最多塞多少 token、是否自动压缩历史、是否自动拉取相关文件；
• 你自己的投喂策略：决定哪些背景信息进上下文、哪些不进，以及什么时候该开启新对话、什么时候该继续旧对话。

两层叠在一起，才构成完整的 context-mode。前者往往由产品决定，你只能适应；后者才是你可以真正掌控、也是拉开使用效果差距的地方。

打个比方：上下文窗口就像一个临时会议桌。桌子的物理大小由工具决定，但"邀请谁上桌、桌上摆哪些材料、聊到一半要不要清场换人"——这些动作完全由你说了算。context-mode 就是一套关于"谁来开会、带什么材料"的决策系统。

1.2 为什么这个词最近突然变热

这个词最近刷屏，背后有几个很现实的原因在叠加。

第一，模型的上下文窗口越做越大。从早期的几千 token，到现在的几十万甚至上百万 token，表面上看"能装下更多内容"是好事，但实际用下来大家发现：窗口大不等于记性好。东西塞多了，模型反而容易抓错重点，处理速度变慢，输出质量也不稳定。于是"怎么用才不浪费这么大的窗口"成了刚需。

第二，AI 编程助手开始参与多文件、跨模块的复杂任务。以前让模型写个函数，上下文里放一个文件就够了；现在让 Agent 改一个完整功能，涉及十几个文件、一整套业务背景，上下文的组织复杂度直接上了一个台阶。

第三，成本和质量的双重压力。很多 API 按 token 计费，上下文里每多塞一句废话，都在烧钱。更关键的是，无效信息越多，模型的有效注意力就越分散，生成结果的可靠性肉眼可见地下降。

所以 context-mode 的热，本质上是"长上下文能力普及之后，用户被迫学会做减法"的热。

2. 上下文窗口的"物理账"：模型到底能记住多少

2.1 一分钟算清你的 Token 预算

很多人对 token 没有直观概念，导致上下文要么严重浪费、要么严重不足。先把这笔账算清楚。

Token 是模型处理文本的最小单位，中文大约一个字对应 1 到 2 个 token，英文大约 4 个字符对应 1 个 token。为了心里有数，我在本地保存了这样一个简单脚本，用来快速估算一堆文本会吃掉多少 token：

def estimate_tokens(text): # 粗略估算：中文按 1.5 token/字，英文按 0.75 token/词 import re chinese_chars = len(re.findall(r'[\u4e00-\u9fff]', text)) english_words = len(re.findall(r'[a-zA-Z]+', text)) other_chars = len(text) - chinese_chars - sum(len(w) for w in re.findall(r'[a-zA-Z]+', text)) return int(chinese_chars * 1.5 + english_words * 0.75 + other_chars * 0.3)

这个估算不精确，但足够用来判断"这一段要不要进上下文"。实际以模型返回的 usage 字段为准。

不同模型的窗口差异很大，我常用的一组参考值：

看着很宽裕对吧？但别忘了，上下文里不仅要装你输入的内容，还要装模型历史上所有的输出。一次长对话积累下来，你前面说的、它前面答的，全都在占用预算。很多时候你以为自己只发了 5000 字，实际占用的上下文可能已经有两三万 token。

2.2 中间遗忘效应：长对话为什么会越聊越糊涂

这是我在实际使用中感受最深的一个现象，也是 context-mode 要解决的核心问题之一。

大量经验和研究都指向同一个结论：模型对长上下文的注意力并不是均匀分布的。开头的内容记得最牢，结尾的内容也记得比较清楚，唯独中间一大段，信息密度越高、距离越远，越容易"隐没"。我给这个现象起了个自己的名字叫"三明治遗忘效应"——上下两片面包都完完整整，中间的馅儿反而最容易丢。

想象你在读一本一百页的报告，合上书之后，你大概率记得开头的背景结论和结尾的下一步建议，但中间第三十七页到第六十二页的细节，基本是模糊的。模型也是这样，而且它自己并不会主动告诉你"中间那段我没细看"，只会顺着记忆最清晰的部分作答。

这对实际工作的影响非常直接。假设你在对话早期详细描述过一个业务约束，聊了两个小时后问模型"按照我们最开始说的那个约束来改"，它很可能给你一个没带上这个约束的答案——不是它不听话，是那段信息真的沉底了。

理解了这一点，你就会明白为什么"把信息反复放到当前消息里"比"指望它记住所有对话历史"靠谱得多。

2.3 三种上下文组织模式，切换着用

既然同一套信息，模型在不同位置和密度下的"记住程度"不一样，那就需要根据任务阶段切换不同的组织模式。我自己日常只维护三种模式：

• 全量模式：适合任务刚启动、需要模型全面理解背景时。把所有相关材料、代码、文档一次放入，让它建立整体认知；
• 摘要模式：适合任务进行到后半段。把前半程的结论、决策、关键代码片段浓缩成几百字，替换掉完整的历史记录；
• 聚焦模式：适合处理一个明确的局部问题。只保留当前文件和最近的报错日志，把一切不相关信息踢出桌面。

这三个模式对应三句话：开始时"让你看全"，中途"让你记住该记住的"，收尾时"只让你看眼前的"。

3. 实战：把 context-mode 落到 AI 编程助手里的完整路径

3.1 开新会话前的"情境打包"

很多人用 AI 编程助手有个坏习惯：开个新会话，直接甩一句"帮我改一下这个功能"，然后等模型问。模型会问的——它会从零开始猜你的业务背景，猜错了再改，一来一回，上下文里塞满了试探性对话。

我的做法是在会话开始前做一次"情境打包"，花五分钟写一份精简的项目上下文文件，比如叫context.md，放在项目根目录。内容结构很固定：

# 项目上下文 ## 当前目标 （一句话说清楚这个阶段要完成什么） ## 业务背景 （三到五句话，说清楚这个功能给谁用、解决什么问题） ## 涉及文件 - src/service/order.py - src/api/routes.py ## 已知约束 （技术选型、兼容性要求、不能改动的部分） ## 当前进度 （做到哪一步了、卡在哪）

然后第一个消息直接把这份文件贴进去，再附带一句"基于这份上下文，开始处理 XXX 问题"。这一下就把模型的起点从"猜"变成了"看图说话"，整个会话的信息质量完全不同。

我试过对比：同样一个任务，有打包和没打包，后者的有效回答时间大约快一倍，中途纠正需求的次数少得多。

3.2 对话进行中的模式切换与收敛

会话一旦拉长，就必须主动做模式切换，别等模型自己意识到问题。我的操作节奏是这样的：

当对话超过七八轮，或者涉及的文件超过三四个，我会主动叫停，执行一次"压缩-重建"。做法是让模型先把本阶段的结论汇总成一段话：

"请用 200 字总结我们当前确定的方案、已经改完的文件、还没解决的问题，然后我会开一个新会话继续。"

拿到总结后，把它连同context.md的最新版一起粘进新会话，旧会话就此归档。这个过程我一周要做四五次，胜在稳定可靠。

还有一种更轻量的收敛手段：如果模型开始跑偏，直接明确喊一句"切换到聚焦模式，只看当前报错和当前文件"，同时用/clear或者清空上下文的操作把历史对话重置掉。不要让模型在一条已经变长的历史线上硬拉回来，成本太高。

3.3 收尾时的记忆落盘

一次会话结束，不代表信息应该随之消失。每次干完一个阶段性任务，我会顺手更新context.md里的"当前进度"和"已知约束"板块，再追加一个简短的"决策记录"：

## 决策记录（2025-01-20） - 订单状态机改为四态，取消"待支付"中间态 - 缓存统一走 Redis，不引入本地内存缓存 - 与旧版接口的兼容层保留一个月

这个过程我称之为"记忆落盘"。它带来的最大好处是：哪怕下次换一个工具、换一台电脑、甚至换一个模型，只要这份文件还在，整个项目的上下文就能无缝迁移。模型会忘，文件不会。

4. 我踩过的坑：上下文被污染的四类典型现场

4.1 把整个仓库塞给 AI

最早用支持多文件引用的编程助手时，我的第一反应是"既然支持，那就全选"。结果就是一次重构请求里带了二十几个文件，模型给出的方案看起来很全面，实际每个文件的改动建议都飘在表面上，没有一个能直接落地。

后来我想明白了：模型处理上下文是有"分辨率"的。当信息量超出它的有效注意力范围，它只能对每个文件雨露均沾，给不了深度。所以我现在坚持一个原则——让模型看到的文件数永远小于它真正需要改动的文件数。如果它要改 5 个文件，我就只给它看这 5 个，最多再加一个定义数据结构的公共文件，其余的都靠摘要描述。

4.2 让模型自己"猜"需求

另一个高频事故是把需求描述得太模糊。比如"优化一下这个函数的性能"，模型不知道这个函数的调用频率、数据量级、性能瓶颈在哪，它只能基于一厢情愿的猜测做优化。结果可能改了一通，改了不该改的地方，上下文里还因此多出一堆无效的"解释性对话"。

正确做法是把需求描述成带限制条件的任务："这个函数在高峰时段每秒调用 200 次，单次耗时 800ms，目标改成 200ms 以内。不允许改数据库索引，优先优化查询逻辑。"上下文里信息密度足够高，模型一次到位，双方都省 token。

4.3 多任务混在同一个会话里

我犯过最蠢的错误，是在同一个会话里既问着订单模块的 bug，又顺手让它帮我写一段数据清洗脚本。模型倒是都能答，但两个任务的上下文互相抢占注意力：聊到后面，它给订单 bug 提方案时，措辞越来越像在做数据清洗，我真切感受到了"上下文串台"。

从那以后我定了一条铁律：一个会话只干一件事。如果要处理的任务超过一个，宁可多开几次会话，也不要混着聊。分隔开的会话，上下文干净，模型清晰，事后检索也方便。

4.4 过分相信"看过就不忘"

最后这个坑，其实是前三个问题的共同根源。很多人（包括曾经的我）默认"模型读过的信息就等于模型记住的信息"，但前面已经说了，模型对长上下文的记忆存在明显衰减。

有一次我让助手基于对话开头定义的数据结构生成一段序列化代码，它引用了一个已经在中间轮次被我否决的旧字段名。我确认过这个信息确实出现过，模型也确实"看过"，但它就是用了错的版本。从那以后我只遵循一条原则：关键信息必须在当前消息里重新出现一次，要么原样贴出，要么用一句话点名"按我们之前确定的字段 order_id 为准，不要用 orderId"。信息的位置越靠后，被执行的确定性就越高。

整理一下这四类污染的症状和处理方式：

5. 进阶：设计你自己的 context-mode 模板

5.1 模板的最小结构长什么样

用得久了，我总结出一个通用模板结构，任何场景都能套。它一共七个字段，每个字段一句话到几句话：

1. 目标：这个任务最终要交付什么；
2. 背景：为什么需要做这件事，给谁用；
3. 范围：允许动哪些文件、不允许动哪些；
4. 约束：技术限制、前置条件、兼容要求；
5. 现状：当前的代码或资料处于什么状态；
6. 验收标准：做到什么程度算完成，一定要具体；
7. 下一步：当前最需要模型先动手做的一件事。

这七个字段即使不全填，也比空着强。最重要的是"目标"和"下一步"，前者保证模型不跑偏，后者保证模型立刻有活干，而不是反过来问你一堆问题。

5.2 三个高频场景的参考写法

场景不同，字段的侧重也不同。我贴三个我经常用的模板片段，仅供参考。

代码重构场景，重点压在"范围"和"验收"：

目标：把订单服务里的状态机改成四态，去掉待支付中间态。 范围：只改 src/service/order.py，其他文件不动。 约束：数据库表结构不能变；旧接口路径保留；兼容层注释标明过期时间。 验收：现有 32 个测试全部通过；新增 2 个针对四态转换的测试。 下一步：先输出改动方案，不要直接改代码。

数据分析场景，重点压在"背景"和"约束"：

目标：分析近 30 天用户流失前的操作序列，找出 3 个最显著的行为特征。 背景：面向运营团队，指标会被用于每周流失预警。 约束：只分析已脱敏数据；时间窗口按自然日；排除测试账号。 验收：输出一份 markdown 报告，包含每个特征的统计显著性和样本量。 下一步：先检查数据字段定义，再决定分析口径。

文档写作场景，重点压在"背景"和"现状"：

目标：把上季度的项目复盘改写成对外发布的技术博客。 背景：读者是工程师群体，偏好直奔结论、带真实数据。 范围：只修改 docs/quarterly-review.md。 现状：初稿已包含数据，但结论段太啰嗦，案例部分缺少上下文。 验收：全文控制在 3000 字以内；结论前置；每个案例补充一句背景说明。 下一步：先重写开头三段，其他段落暂不处理。

5.3 模板也要定期清理和版本迭代

模板不是写一次用一年。我见过不少团队把context.md写完之后就再也不更新，三个月后里面的"当前进度"还停留在立项阶段，等于给模型喂了一份过期的地图。信息一旦过时，比没有更危险——模型会非常自信地按照错误背景工作。

我现在习惯在模板文件头部加一行版本号和更新时间，每次更新大段内容就顺手改掉：

版本: v3.2 更新时间: 2025-01-20 最近变更: 订单状态机确定为四态；移除了旧缓存方案

同时我给自己定了一个触发更新的机制：只要某个信息在对话中被模型误解超过一次，立刻回去检查模板里对应字段是不是写得太模糊；只要一次会话中"下一步"字段被模型反复追问，就说明这个字段写得不够具体。模板和真实项目的偏差，往往就是上下文质量下降的开始。

最后分享一个我坚持了小半年的习惯：每个工作日的最后一次会话结束后，花两三分钟更新项目的上下文文件，顺便看一眼明天的"下一步"。这个动作让我第二天打开任何工具、任何模型，都能在五分钟内进入昨天的工作状态。说到底，context-mode 的终点并不是某个神奇的模式开关，而是把"喂给模型的信息"从临时聊天记录，上升成一份你自己也在维护的项目资产。