企业官网建设流程全解析

你有没有遇到过这种情况：同一个AI编程会话，头两个需求处理得极其漂亮，第三个就开始答非所问，第四个直接在不相干的文件里加了一堆代码？我排查过不少这样的现场，问题几乎都不在模型身上，而是出在 context-mode（上下文模式）上。当上下文模式和当前任务不匹配时，模型就像一位记性极好但注意力混乱的资深工程师——什么都见过，却不知道你此刻真正想要什么。

这篇文章不讲基础操作，就聊我在实际项目里如何管理 context-mode：为什么它会导致"越改越乱"的故障曲线，三种形态各自怎么用，我自己的一套从开局到收尾的工作流，以及两个让我印象深刻的翻车案例。适合已经把AI辅助编程跑起来、却频繁遇到"改着改着就失控"问题的开发者。看完之后你至少能回答一个问题：什么时候该让AI自己决定看什么，什么时候该强行接管。

1. context-mode 为什么值得单独研究：上下文污染的放大效应

1.1 从一次失效的改版看 context-mode 的底层逻辑

有一次我在维护一个支付对账服务，任务是给核心模块加上新的错误码映射。会话从一开始就一切正常：模型读懂了现有结构，新增了常量，补了单测，连续三轮输出都干净利落。

然后我加了句"顺手把旧版错误码也兼容一下"。问题在这之后爆发了。会话里已经积累了十几轮关于接口格式、异常路径、时间字段的讨论，自动上下文检索一遍遍把旧的对账逻辑代码拉进来。AI 给出的"兼容方案"没有在入口层做映射，反而钻进了一个早已废弃的幂等表模块里，写了一层旧码转换逻辑，把本来收敛的改动重新撑大了三倍。code review 直接被拒，同事留言：这句话为什么会出现在支付核心模块？

现在回头看，根因就是 context-mode 一直停在"累积式"默认档位上。模型在长上下文里做判断时，最新指令的权重确实最高，但旧代码片段、旧讨论目标仍然占着大量的注意力。当"旧版兼容"这个短语和"旧版幂等逻辑"被同时激活，模型就把这两件事强行归类到了一起。

你可以这么理解：团队开会，你前面讲了新项目方案，中间回顾了一段历史问题，最后补一句"顺便把昨天那个问题也解决一下"。一个正常的人类leader都会困惑，AI也一样。上下文里塞进来的东西不是越多越好，而是要区分"背景知识""历史记录"和"当前目标"。

1.2 "删除即遗忘"与"编辑即覆盖"：模式切换的典型机制

要跳出这个坑，得先搞清楚工具提供的基础操作会如何影响模型判断。我现在把常见操作列成一个对照表，方便你选。

这里有一个很微妙的点：很多人习惯用"再跟模型强调一遍"来纠正方向，这是效果最差的补救方式。因为追加消息不会改变模型已经看到过的旧样例，它只会让尾部指令与旧历史形成紧张关系。模型两头一摇摆，改错方向就是大概率事件。

真正高效的动作是"删除"或"编辑"。你把那个无关文件从上下文里摘掉，模型的推理空间立刻变小；你把一段被AI引用过的旧实现替换成新版本，它就失去了构造错误分支的素材。这个思维方式，比单纯记快捷键重要一百倍。从那以后，我把 mode 切换当成和 git 分支一样频繁的操作，而不是任务结束后的一次收拾。

2. 实操中的三种 context-mode 形态与最优使用场景

2.1 auto 模式：适合起步但别让它陪你走完全程

我见过很多开发者的默认状态：打开工具什么都不管，预期总是"它能自己找到需要的代码"。auto 模式的好处确实在这里——它的机制是结合向量检索、最近打开文件、文件树优先级，自动决定把哪些片段塞进上下文。你只需要描述问题，剩下的交给工具筛选。

但它最大的坑也在这里：向量检索衡量的是"文本相似度"，不是"业务相关性"。两段代码都处理"订单超时"，但一个在订单服务，一个在物流服务，长得像不代表它们应该被放进同一个修改任务里。auto 模式跑久了，对话历史也会像滚雪球一样参与检索，最后模型看到的是一堆"相似但无用"的代码。

所以我的经验是：auto 模式适合三类任务——快速浏览陌生项目、定位 bug 大致范围、生成多个候选方案。一旦任务进入"确认要改谁、只改谁"的执行阶段，就应该主动切走，不要让 auto 陪你从方案讨论一路走到代码落地。

2.2 手动上下文模式：把注意力预算花在刀刃上

手动 context-mode 的核心是：由你决定模型能看什么。在 Claude Code 里是 @文件路径 的引用方式，在 Cursor 里是关闭自动上下文后用 @ 手动挂载，在 GitHub Copilot 里是 #file:path。不管入口长什么样，本质都一样——你在给模型划重点。

我习惯把模型一次会话能有效处理的代码量称为"注意力预算"。手动模式不是把预算浪费在它自己猜出来的片段上，而是精准分配给你确认过的文件。举个例子：修一个登录接口的问题，我会挂三个文件——token_store.go、auth_service.go、auth_test.go。其他看起来有关联但实际不参与逻辑链的文件，全部不挂。模型看不到它们，反而更专注。

手动模式还有个容易被忽略的细节：如果你改了本地代码，记得把最新版本重新挂载一次。很多工具挂载的是会话开始时的快照，你本地改了它看不到。这点不处理好，会出现"模型一本正经地修改旧代码"的诡异情况。

2.3 临时上下文与快捷指令：高频场景的固化

手动模式再好，每次手写一遍约束也烦。这就是指令模板和项目说明文件的用武之地。我会把最高频的操作固化成交给模型的固定指令，例如：

/fix 只做最小改动，不顺手重构，不使用本会话之外的文件 /review 只关注逻辑正确性和边界条件，忽略格式和小众性能问题 /refactor 保持接口签名不变，尽量保持测试不变，一次性输出完整结果

这些指令本质上是在"上下文入口处"设置了一个稳定的行为基线。模型每次收到指令就等于被重新注入了这些规则，比你在对话里想起来再强调要可靠得多。

更进一步的方案是把项目级约束写进一个会被自动加载的说明文件。比如在项目根目录维护一份上下文备忘，内容类似：

# 项目上下文备忘 - 数据库查询必须经过 repository 层封装，禁止出现裸 SQL - 错误码统一引用 errors/errcode.go 中的常量 - 修改消息队列消费者时，必须同步更新 docs/consumer.md - 全项目禁止新增对已废弃 config 包的引用

这样一来，当你开启手动模式并指定关键文件时，模型一开始就带着这些规则出场。它不是被你提醒着遵守，而是从上下文起步阶段就认为这是默认行为。

3. 我的 context-mode 日常工作流：从开局到收尾的完整拆解

3.1 开局三件事：清空会话、锁定目标、建立检查点

有了上面的理论，落地实操时我只做三件事。

第一件，清空会话。这个清空不是简单点"新建对话"，而是要确认上一轮加载的文件引用、临时指令、检索片段都没了。有时候我还会重启一下编辑器插件，因为某些工具的上下文面板是跟着窗口状态走的。任务切换是最容易发生上下文污染的时间点，旧任务的一句话可能在新任务里复活成修改方向。

第二件，锁定目标。我不会只丢一句"帮我改一下库存校验"，而是写成像需求描述那样的目标句，比如："把订单模块的库存校验提前到支付动作之前，不改变任何已有外部接口签名，保持幂等表结构不变。"这句目标句会粘贴在整个会话的最前面，它就是我给模型设下的"北极星"。后面无论聊多远，它都有一条清晰的判断基准。

第三件，建立检查点。开干之前我会先看一眼当前 git status，记录 baseline diff 行数；如果涉及核心模块，甚至先打一个轻量 tag。改到一半发现方向不对，靠检查点回退的时间成本，远比在混乱会话里跟模型来回较劲低。

3.2 修改进行中：如何分批注入上下文并验证

很多人的操作习惯是"把相关文件一次性全部挂载，越多越安心"。我的习惯恰恰相反：先挂一个入口文件，让模型列出它认为依赖哪些文件；我看完清单后，再分批挂载真正需要的部分。每次挂载不超过三个文件。

这个批次感很重要。模型在收到第 1 个文件时，会对问题建立初步框架；收到第 2、3 个文件时，是在往框架里填细节。如果一上来就给它塞 8 个文件，它反而容易抓不住哪个才是主线。

每一步修改完成后，我都会立刻跑一次最小验证——单测、lint、或者至少让模型回答"你刚才改动的文件里，有哪几个是我没有挂载过的？"如果它说出了我没挂过的文件，说明上下文里存在隐藏来源，我会立刻切掉自动检索，重新聚焦。

另外还有一个坑：粘贴报错时，不要复制整屏堆栈。我通常只贴最上面的错误类型和最近一帧调用位置，再附上最近几次改动的 diff。报错全文几百行塞进去，很快就把有限的有效上下文占满，模型开始"认真地答偏"。

3.3 收尾动作：压缩、定稿与沉淀

任务临近完成，我不会马上关掉会话，而是做三步收尾。

第一步，压缩前确认关键约束已经被写进持久化文件。如果有一个约束只存在于对话里，我会先补进项目上下文备忘，再执行 compact。否则压缩一过，摘要器很可能把这条"你辛苦强调了三遍"的规则丢掉。

第二步，压缩后让模型"根据当前代码状态生成变更说明"，而不是让它回忆聊天过程。这样既验证了模型在压缩后是否能从代码本身读出改动，也顺便生成了适合放进 commit message 的摘要。如果模型连改了什么都说不对，那说明上下文状态已经被破坏，果断开新会话重来。

第三步，把这次任务的"上下文配方"沉淀下来。比如"处理消息队列问题时必挂 producer.go、consumer.go、schema/event.proto"。积累几周之后，这些配方会变成你个人的模式手册；下次同类任务开局直接照着配方走，效率完全是另一个级别。

4. 两个翻车案例复盘：context-mode 失效时的完整排查链路

4.1 案例一：全局检索把私货塞进了无关文件

这个案例发生在一次订单状态机修复中。我当时的会话刚跑了一轮检索，一切看起来正常。第一次生成的方案里，它修改了一个叫 fulfillment_status.go 的文件——那根本不是当前模块的代码。我第一反应是它搞错了路径，可代码写得相当流畅，说明不是随机幻觉，而是真读到了那个文件。

排查链路一步步走：

1. 打开上下文面板，查看当前挂载的片段列表。果然，除了订单模块自身，还有一段来自 fulfillment 模块的"相似状态机"代码。
2. 查这个片段是怎么进来的。结果显示它来自自动上下文检索，原因是文本特征和当前代码高度相似。
3. 把会话切到手动模式，移除所有非订单模块的引用，只保留 order_state_machine.go 和对应的测试文件。
4. 重新让模型生成，这次没有再碰 fulfillment 模块，生成的改动全部收敛在预期范围内。

注意：如果模型开始引用你没挂载过的文件，优先检查自动检索和压缩后的摘要来源，而不是继续在对话里纠正它。

事后复盘，那个检索片段本身不是错误，错误在于我让 auto 模式参与了"执行阶段"的决策。自动检索对"哪里长得像"的判断很准，对"哪里真正该改"的判断却未必准。它适合在你刚开始不了解项目时帮你找候选，不适合在精确手术时替你决定下刀位置。

4.2 案例二：被压缩掉的专家约束与返工代价

另一个更隐蔽的翻车发生在数据库层改造中。会话开始时我明确交代过一条硬性约束："本项目禁止用 ORM 之外的查询构造器，所有 SQL 必须经过 repository 层统一封装。"模型前半段执行得很好，每次涉及查询都会走封装函数。

会话进行到中后段，我点了上下文压缩（compact）。当时觉得对话已经太长，压缩能帮模型聚焦。结果问题立刻冒出来：在新增一个明细查询时，模型直接生成了裸 SQL 构造，完全绕过了封装层。我指出后它道歉，但下一轮又在别处犯同样的错——因为产生这个错误的上下文状态，已经和开始时的约束状态彻底断开了。

排查链路：

1. 对比压缩前后的对话摘要。发现摘要器只保留了"数据库层改造、新增明细查询"等事实性信息，把我自定义的项目约束当成聊天噪音丢掉了。
2. 找到问题本质：关键约束放在"一次性对话消息"里，而不是"每次加载的持久化上下文"里，压缩一过就变成不定期消失的规则。
3. 修复动作：把那条硬性约束写进项目上下文备忘文件，并重新开了一个干净会话。手动指定 repository 层和入口文件后，模型从第一轮就遵守约束，后续没有再跑偏。

这件事给我的教训很大：任何你希望模型"始终记住"的东西，都不应该只存在于聊天记录里。上下文压缩技术再强，也是对历史做有损压缩，你最重要的约束如果不在压缩掉的 raw history 里，就会随它一起消失。正确的做法，是把规则前置到模型每次读取都必经的入口位置。

5. 建立自己的 context-mode 检查清单：一套可抄作业的评估维度

5.1 会话开始前的 5 个问题

我现在每次开一个偏执行的会话，开工前都会自己过一遍这五个问题：

1. 这个任务的核心文件是哪几个？如果超过四个，我会拆任务，而不是硬塞给模型。
2. 哪些文件只需要只读权限？只读文件可以不挂载或标注为参考，避免模型顺手修改。
3. 有哪些约束是模型必须自始至终遵守的？写到持久化上下文文件，而不是留在聊天里。
4. 有没有需要主动排除的目录或文件？比如旧的生成器代码、文档里的历史方案，明确排除比靠模型自觉更稳。
5. 用什么方式验证结果？单测、lint、还是编译通过？没有验证手段的任务，我会在会话开头就让模型确认"你准备如何证明改动有效"。

这 5 个问题各花不到十秒，但能省掉后面大量返工。它们背后的逻辑很简单：context-mode 的核心矛盾是模型注意力有限，而我们总想一次性塞太多东西。开工前做减法，就是给后续会话节省注意力预算。

5.2 运行中的 3 个信号

任务跑到一半，我会留意三个危险信号，任何一个出现，都意味着上下文模式已经跑偏：

信号一：模型开始引用我从没挂载过的文件，而且这个文件和任务没有直接逻辑关系。这说明自动检索或历史上下文里还藏着"私货"。

信号二：生成的代码开始复用我在前面已经明确废弃的方案，比如重新引入旧的查询方式、旧模块名。这说明旧代码片段仍在上下文中占据权重。

信号三：同一个约束我需要重复强调三次以上。这说明当前会话的注意力分配已经失衡，追加消息已经不太管用。

这三个信号本质上是在回答同一个问题：模型此刻看到的上下文，还是不是你希望它看到的那个上下文？如果不是，最省力的做法不是继续在混乱会话里纠正，而是开一个干净的手动会话，把正确的内容重新放进去。

5.3 收尾后的小动作

任务收尾后，我会做两个很小但很管用的动作。一个是把"这次成功用到的上下文配方"存下来，通常是三五个文件路径，对应一类任务；另一个是把"这次踩坑的点"浓缩成一句提示语，比如"不要在长会话里讨论两个以上的变更点""测试覆盖以外的旧实现不要挂进上下文"。这些句子不需要优美，只要下次开工时能提醒到我就够。

积累到一定量，它们会成为你个人甚至团队内部的 context-mode 操作手册。我团队里的新人，现在开工前会先翻这份手册，而不是对着工具默认设置发愣。这也是我写这篇文章希望达到的效果——上下文管理不应该靠感觉，而应该是一门可以沉淀、可以交接的工程动作。

我刚用这套方法时也不适应，总觉得手动挂载文件比 AI 自动找慢。跑了两个迭代之后，最大的感受其实是返工少了：以前一个功能来回改四五版，现在基本一两次过，总时间反而省一大截。如果你也想把 context-mode 变成可掌控的习惯，建议别贪多，每次只改一个环节，比如先从"任务开始时强制开手动模式"做起。最后分享一个很实用的小技巧：每当你准备向会话里粘贴超过十行外部代码时，直接新建一个手动模式会话，把这段代码作为唯一输入起点。这个动作帮我避开了大半上下文污染，大概率对你也会有用。