企业官网建设流程全解析

1. context-mode 是什么：先搞清楚上下文从哪来、往哪去

1.1 一个真实翻车场景

前几天帮同事排查一个前端构建问题，他用的 AI 编程助手一直答非所问。我看了一下他的操作：把整个项目目录直接丢进了对话窗口，AI 一开始还能正常回复，等到对话超过二十轮之后，它开始频繁把node_modules里的代码当成业务代码来分析，给出的"修复建议"全是往webpack.config.js里加各种插件，最后甚至建议他删除package-lock.json来"解决依赖冲突"。

问题出在哪？不是工具不够聪明，而是他完全没开启上下文管理能力。AI 助手在一个会话里能"记住"的内容总量是有限的，专业叫法是上下文窗口，窗口被大量无关文件占满之后，真正重要的业务代码反而挤不进去。这类工具普遍提供一种叫 context-mode 的工作模式，直白翻译是"上下文模式"，本质是解决一个问题：在有限的上下文空间里，把最有价值的信息喂给模型。

1.2 官方定义与我的理解

context-mode 不是一个厂商独有的名词，而是一类"内容组织策略"的总称。在很多 AI 编程助手（Cursor、Copilot Chat、Cline 这类工具）、甚至一些支持语义检索的编辑器里，它代表一种可切换的工作状态：

• Auto Context（自动上下文模式）：由工具自动分析当前打开的编辑器标签页、最近修改的文件、当前光标附近代码，动态决定把哪些内容放进上下文。
• Manual Context（手动上下文模式）：你明确指定哪些文件、哪些代码块、哪些文档需要被模型看到，其他内容一概不进上下文。
• Agent/Whole Repo Context（代理或全仓模式）：允许 AI 在更大范围内自主检索代码库，按需拉取文件片段，而不是一次性全量塞入。

我把它理解为"内容过滤漏斗"：代码库那么大、对话记录那么长，模型的内存有限，context-mode 决定的是漏斗开口大小和过滤策略。

1.3 为什么这个功能决定了 AI 编程工具好不好用

我自己的项目里跑过一组对比。同一个改动需求"给订单模块增加一个取消原因字段"，分两种方式操作：第一种不设置任何上下文策略，直接问 AI"帮我改订单模块"；第二种手工将OrderService.java、OrderController.java、OrderMapper.xml、order_detail.sql四个相关文件加入上下文，再补一句需求说明。

结果差别非常大。第一种方式下，AI 有大概一半概率去修改错误的文件（比如改了Order.java实体类的注释，或者新增了一个不存在的接口方法），因为它在整个代码库里自行猜测。第二种方式下，AI 几乎一次就给出了可用改动，因为它确实知道订单模块的"完整链路"长什么样。

这个实验说明一个核心观点：模型能力固然重要，但喂给模型的上下文质量，直接决定输出质量。context-mode 就是那个"喂食策略"。这也是为什么你现在打开任何一款主流 AI 编程工具，都会看到类似"添加上下文""自动索引""代码库检索"的功能，它们全都是 context-mode 在不同产品中的呈现。

2. 三种主流 context-mode 的原理与选型判断

2.1 Auto Context：省心但需要"驯"的工具

自动模式是最常见的默认选项。它背后的逻辑不复杂：编辑器插件实时监听你的打开文件、光标位置、选中区域、最近 git diff，然后把这些信息压缩成一小段代码摘要，随每次提问一起发给 AI 模型。

这套机制的好处是零成本起步。刚接触工具的人不需要理解任何概念，打开就能用。但它有一个我一直提醒朋友注意的毛病：自动模式对"你正在改哪块代码"的判断，依赖编辑器的活动状态。如果你开着 A 文件却在写 B 文件的改动描述，自动上下文大概率会把 A 文件的相关信息带上，AI 就被带偏了。

我踩过最典型的一次坑：在utils/date.ts里补了一个格式化函数，然后打开pages/list.vue准备调用它。我在对话框里输入"帮我把日期格式改成 YYYY-MM-DD"，自动模式下 AI 直接修改了list.vue里的硬编码日期字符串，改了七八处，还改坏了一处接口返回字段。而我的真实意图是调用刚写好的date.ts工具函数。原因就是自动上下文把当前打开文件list.vue当作主要关联文件。

所以，自动模式适合两种人：一是项目结构简单、文件间耦合度低的小项目；二是对话轮次少、需求描述足够具体的场景。如果你在大型项目里做跨模块改动，纯靠自动模式非常容易被无关文件带偏。

2.2 Manual Context：主动权最大的"精装模式"

手动模式接近传统程序员写代码的思维方式：我知道哪个文件与此相关，我就把它指定给你。在 Cursor 里按Ctrl+Enter（Windows）/Cmd+Enter（Mac）可以手动添加当前文件，也可以直接用@符号引用具体文件、目录或者 Documentation 页面。

手动模式的核心优势是可预期性。每轮对话你完全清楚模型看到了哪些内容，模型不会突然"灵机一动"去翻一个它不该看的文件。排查问题时，手动模式尤其好用：把报错日志、对应的源文件、配置文件按顺序摆好，AI 的分析路径基本能跟着你的思路走。

缺点也明显：费手、费脑。一次涉及十来个文件的跨端改动（比如后端接口、前端页面、数据库脚本三端联动），手动一个个添加上下文非常繁琐，而且很容易漏。我见过有人改了 5 个文件但只手动加了 3 个，AI 完全没意识到还有 2 个配套改动，最后生成的代码根本无法编译。

2.3 Whole Repo/Agent 模式：给 AI 一个"检索权限"

全仓模式是近两年各家工具发力的重点。它的实现方式不再是"把文件塞进上下文"，而是在代码库上建立索引，由 AI 根据问题意图自主搜索相关文件，然后只把搜索结果中的片段作为上下文。

理论上这是最强大的模式——你只需要问"订单改价后怎么同步库存"，AI 自己去找OrderController、InventoryService、StockLogMapper等文件。实际体验也还行，尤其是在大项目中，"找文件"的成本远大于"改文件"的成本，全仓模式确实省力。

但它有两个硬伤至今没有完美解决。第一是索引一致性：如果你的编辑器和 AI 使用独立的索引服务，改完代码之后索引没刷新，检索出来的还是旧代码。第二是上下文窗口碎片化：全仓模式下 AI 会优先检索到匹配度最高的片段，但这些片段之间的依赖关系它不一定理解。比如它搜到一个函数定义，却没搜到调用它的地方，给出的重构建议就只覆盖了定义本身。

2.4 选型判断：没有最好，只有最合适

我给团队做了一个简单的选型对比表，照着选基本不会错：

我的习惯是混着用：日常写代码默认 Auto，遇到需要跨文件链路追踪的时候切成 Manual，探索陌生模块时打开全仓检索。没有一种模式是银弹，理解每种模式的"盲区"才能真正发挥它们的价值。

3. 实操：把 context-mode 调成顺手的样子

3.1 配置关键参数与文件

先确认你用的工具是否支持 context-mode。Cursor 和 Cline 应该是最直观的两个参考，Copilot 近年来也加了#引用语法和自动上下文。代码工具大同小异，我以 Cursor 为例讲参数含义，其他工具照着对应找。

第一步是设置上下文来源的白名单。在 Cursor 设置里找Features -> Codebase Indexing，打开代码库索引。这里面有一个隐藏细节：索引范围默认是当前工作区，如果你的项目是 monorepo（比如packages/admin、packages/server、packages/shared三个子包），建议在.cursorignore文件里排除node_modules、dist、build等目录，避免索引垃圾过多。

.cursorignore文件内容示例：

node_modules/ dist/ build/ coverage/ .git/ .temp/ *.min.js *.map

第二步是设定上下文注入策略。在Settings -> AI Rules中可以写入一段"系统提示词"，告诉 AI 在回答前先确认它看到了哪些文件。我常年使用的一段规则是：

在回答任何问题之前，先列出你参考了哪些文件。 如果不确定某项改动的完整影响范围，请先说明你缺失的信息。 不要修改与用户明确指出的文件无关的代码。

这段规则的作用不是魔法，而是将"上下文边界"变成显式约束，逼迫 AI 在上下文不完整时主动暴露盲区，而不是假装懂。实测下来，误改无关代码的次数明显下降。

第三步是 token 预算控制。没有 UI 界面显示的方案，只能通过控制同一会话里的轮次来间接控制。我给自己定的红线是：单次任务超过 8 轮对话没搞定，果断新开会话，把前几轮的关键结论手动整理成一段背景描述，传给新会话。这比在旧会话里一层层"纠正"高效得多。

3.2 四个黄金实操动作

下面四个操作是我每天高频使用的，分别解决不同场景下的上下文问题。

动作一：对话冷凝（Conversation Condensation）当一个会话聊到快 20 轮，AI 开始"忘记"需求开头的内容时，不要恋战。把需求、已确认方案、当前进度整理成三五行文字，开新会话粘贴进去，再继续。这比让 AI 回忆旧对话内容要可靠得多。

动作二：文件分段注入如果单个文件超过 500 行，不要整个丢进上下文。很多工具支持选择指定代码块或函数后添加（在 Cursor 里选中代码 ->Ctrl+Shift+L添加到上下文）。我一般只把函数的签名、注释、关键逻辑段加进去，其余部分靠模型在对话中自行推理。

动作三：用 TODO 注释做上下文锚点这是一个偏技巧的做法。在做大规模重构时，我会在关键位置写// [AI-REF] 此处是订单状态机核心逻辑，注意与 RefundService 的联动，然后把这一行注释粘贴进上下文。这个"锚点"能大幅降低全仓模式下检索的偏差概率，AI 能精确找到目标位置。

动作四：多会话分工同时打开两三个会话，每个会话只干一件事：一个负责搜索与定位，一个负责方案设计，一个负责代码实现。注意会话之间不要互相污染，一个会话一个问题域。我在看陌生代码库时，先开一个"侦察兵"会话让它汇报文件结构和关键类职责，再开"施工队"会话动手改，远比让一个会话从头干到尾清晰。

参数层面还有一个容易被忽略的点：模型选择影响所需上下文量。更长的上下文窗口（以百万 token 为单位的模型）虽然能容纳更多文件，但不意味着你应该把所有文件都塞进去。上下文越长，模型对远端内容的"关注力"会递减，这是注意力机制的固有特性。

3.3 一个完整的实操案例：给订单模块加取消原因

为了把上面的动作串起来，我模拟一个真实需求。

背景：现有mall-api项目，Java Spring Boot 后端 + Vue 前端。需求是在用户发起订单取消时，弹窗要求选择取消原因，后端持久化到order表的cancel_reason字段。

我的操作流程：

1. 新建会话，粘贴需求说明，使用@OrderController@OrderService@OrderMapper显式引用后端三个文件，用@cancelOrder.vue引用前端弹窗组件。
2. 在系统提示词里附加一句"请先输出你计划修改的文件清单，确认后再动代码"。
3. AI 第一次回复了一个计划：改后端接口接收参数、改 service 层逻辑、改 mapper 的 SQL、改前端弹窗、改订单详情展示。我看了下清单发现它漏了OrderLog（需要记录取消日志），用一句"还需要同步记录操作日志"补充进上下文。
4. 让 AI 按清单逐文件实施。每改完一个文件，我检查一次 diff，再让它继续。
5. 大约 6 轮对话后完成改动，我本地跑了一遍编译和烟囱测试，通过。

对比另一天偷懒直接放全仓模式让 AI 自己来，它把改价逻辑也顺带动了（因为订单模块确实有改价接口），害我多花 20 分钟撤销。所以你看，手动模式在复杂需求里多花两分钟，能在后续省两小时。

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

4.1 上下文污染：AI 总在改没让改的文件

这是最频繁的问题。现象是你在问 A 模块，AI 回复的其他模块的代码方案。原因大多是自动上下文把当前打开的几个文件全部注入了。排查步骤：先看 AI 引用清单（大部分工具会显示"已参考文件"），确认它是否引用了不该出现的文件；其次看最近 diff，改动了哪些文件；最后检查是否有.cursorignore之类的排除配置没生效。

修复手段：切换手动模式，重新指定相关文件；如果 AI 已经在一堆无关文件里"狂奔"，别逐个纠正，直接新开一个会话，用"动作二：文件分段注入"把关键文件重新喂给它。

4.2 改动不同步：AI 拿到的代码是旧的

碰到过最头疼的一次：我改了OrderService.java里一个方法，AI 在下一轮对话中分析时用的还是旧方法签名。原因是索引没有及时刷新。处理方式：

• 在工具里手动触发"重新索引"（Cursor 里Cmd+Shift+P输入reindex）。
• 检查监控目录，确认没有把源码目录排除在索引之外。
• 更重要的一条：当你在对话过程中发现 AI 引用了旧代码，先做一次"保存所有文件+重建索引"，再进行下一轮对话。旧上下文一旦被模型记住，后续纠错成本极高，不如重置对话。

4.3 Token 耗尽：聊着聊着 AI 变笨了

上下文窗口到达上限后，最古老的信息会优先被"遗忘"。如果 AI 连最开始的需求都开始搞错，说明第一个窗口已经满了。应急做法是把最初需求压缩成一段摘要，手动粘到当前对话末尾，让 AI"从这一段继续"。长期做法是养成"8 轮换新会话"的习惯。

另外补充一个容易被忽略的细节：让 AI 阅读超大文件会显著消耗 token。如果必须让它理解一个 2000 行的配置文件，先让它只列出结构大纲（section 标题和关键配置项），再按需展开指定片段，比一次性读完整文件省至少一半 token。

4.4 多项目切换混乱：A 项目的上下文跑到了 B 项目

开了两个窗口同时处理两个项目，AI 的回答偶尔串线。这是 context-mode 最常见的使用误区：工具按窗口/工作区隔离上下文，但如果你在同一个窗口里切换项目目录，索引和上下文都还残留旧内容。我的建议是严格一项目一窗口，切换项目就切换窗口，不要图省事在一个窗口里来回切。

如果已经串线，同样用新会话解决。不要在旧会话里解释"你应该看另一个项目"，模型的注意力分配机制很难处理这种"修正引导"。

4.5 快速排查口诀

我给自己总结了一段口诀，遇到问题先照口诀过：

先看引用清单，再查排除列表，不行重建索引，最后重开会话。

这四步能解决 80% 的 context-mode 问题。剩下 20%，通常是需求本身描述模糊导致模型猜错，那就不是上下文的问题，而是提示词的问题了。这时候把需求再写具体一点、加上验收标准，效果立竿见影。

5. 一点长期使用的体会

用 context-mode 一段时间后，最大的变化不是写代码变快了，而是我对自己项目结构的理解更清晰了。因为要让上下文可控，你必须明确知道改动涉及哪些文件、哪些接口、哪些数据表——这本来就是一个合格开发者在动手前应该做的梳理。工具把你逼着把这件事做了。

还有一个体会：上下文管理的能力会迁移。现在我看任何 AI 工具，第一关注点不是它用了什么模型，而是它怎么管理上下文。模型每年在迭代，但"让正确的内容进入上下文"这个工程问题永远存在，谁把这个问题解决得更好，谁的输出质量就更高。

如果你准备开始用 context-mode，从最简单的 Auto 模式起步，一周后切换成手动模式，强迫自己用几周，再回到自动模式。你会发现自己的判断力完全不一样了——那时候你真正理解了 AI 编程助手是怎么"想"的。