"context-mode"这个词，我是在一次被AI工具坑到怀疑人生之后才开始认真研究的。当时我用某款AI编码助手改一个老项目的日志模块，明明只是改个输出格式，它却自作主张重构了整个异常处理逻辑，还引用了一个根本不存在的新依赖包。问题出在哪？出在我给了它一个巨大的粘贴板，里面混了二十多个不相关的文件，而我以为它真的"看懂了"。
后来我花了很长时间梳理AI辅助开发的上下文管理问题，发现大多数人对context-mode的理解还停留在"给AI多贴点代码就行"的层面。实际上，上下文模式是一个决定了AI回答质量上限的系统工程。这篇我就把这段时间的实测经验和踩坑记录完整整理出来，围绕context-mode的核心玩法、边界控制、落地架构和真实项目里的取舍逻辑，给想把这套东西真正用起来的朋友一份可以直接照做的参考。
1. 为什么说context-mode是AI辅助开发的真正分水岭
先下个结论：同样的模型，同一段代码，不同的上下文管理方式，产出的质量差距可以达到"能用"和"完全不能用"两个极端。
我接触过不少团队，大家用的都是市面上主流的AI编程助手，但体验天差地别。有人觉得AI是神，有人觉得AI是人工智障。我观察下来的结果很有意思——觉得AI好用的人，几乎都在有意无意地管理上下文；觉得AI是智障的人，几乎都是"甩一个大文件包进去然后祈祷"的操作方式。
1.1 context-mode的本质：给AI划定"该看什么"的边界
上下文模式，简单说就是决定AI在生成回答时能"看到"哪些信息的一种工作状态。这跟人的工作方式很像——你让一个资深工程师帮你 review 代码，你得先告诉他项目背景是什么、这次改动的范围在哪、你关心哪几个模块，而不是直接把整个仓库的git历史甩到他脸上。
AI也是同样的道理。大语言模型的能力边界是固定的（至少在同一个模型版本内是固定的），但它的输出质量上限高度依赖输入上下文的质量。context-mode就是为了解决"怎么把最有用的信息塞进有限的上下文窗口"这个问题。
我自己的定义是：context-mode不是某个按钮或某个开关，而是一整套关于信息筛选、组织、注入和更新的方法论。好的上下文模式，能让AI站在正确的位置上看问题；坏的上下文模式，就是让AI站在一堆噪声里瞎猜。
1.2 大多数人的失败路径：把上下文当成粘贴板
我刚接触AI辅助开发时的典型操作是这样的：把需求描述写到最前面，然后从项目里复制三五个相关文件整个粘进去，再加一句"帮我实现这个功能"。前几次确实能出活，因为项目刚起步，代码量小，模型能抓住主线。
但项目过了2万行之后，这套玩法立刻失效。失效的表现有几种：
- AI反复使用一个已经在其他地方定义过的名字，导致命名冲突
- AI生成的代码风格跟项目现有风格严重不一致
- 改A模块的时候，AI悄悄动了B模块的公共函数，但没告诉你
- 最关键的是，AI会一本正经地编造不存在的API和配置项
这些都是典型的上下文失控症状。模型没有足够的信息来判断"什么是对的"，于是只能用它的先验知识去填空。这个"填空"在语法上大概率是对的，但在你的项目里大概率是错的。
1.3 我把context-mode拆成了三个子问题
为了不让自己陷入"玄学调优"，我把上下文模式拆解成三个可以独立优化的子问题：
- 信息的时效性：AI看到的代码是不是当前最新版本？如果你的上下文里包含了已经废弃的函数，AI一定会去调它。
- 信息的精确度：AI看到的内容和当前任务的相关性有多高？相关性越低，噪声越大，回答质量越差。
- 信息的结构化程度：AI看到的内容是以什么形式组织的？一段被截断的半截代码、一段孤立的报错日志、一句含糊的需求描述，这些信息模型处理起来效率极低。
后面所有章节，本质上都是在解决这三个子问题。你也别指望有一个万能开关能一键搞定这三件事，真正core的功夫都在细节里。
2. 一次真实事故复盘：context-mode失效是怎样一步步发生的
在讲我的解决方案之前，先用一次真实事故完整走一遍排查链路。这也是我建议所有读者理解context-mode的第一课：先学会诊断，再谈优化。
2.1 事故起因：一个简单的页面跳转修复
当时有个内部管理系统，某个列表页点击"编辑"按钮后，跳转到详情页时参数丢失。这是个典型的常规bug。我图省事，直接把列表页的完整代码和详情页的完整代码都粘给了AI，然后在最前面写了需求描述："点击编辑，跳转时带上当前行的id和status。"
AI给我的方案是这样的：在列表页的编辑函数里拼接URL，用encodeURIComponent包装参数，然后在详情页的onLoad里解析。从语法上看，这套方案完全正确，标准的Web开发套路。
问题出在执行的时候。详情页onLoad里原本已经有了一段旧的参数解析逻辑，是用来处理其他入口跳转传参的。AI可能没太注意那一段逻辑是干什么的（因为它在上下文里贴了完整文件，但文件太长，模型的注意力被稀释了），直接新增了一段解析代码，结果新旧两段逻辑产生了冲突，参数被后面那行代码覆盖了。
2.2 排查过程：从输出结果倒推上下文缺陷
我第一反应是AI生成代码有bug，于是又把报错信息粘回去让它自修复。它想了半天，给我的答案是"需要清除一下页面缓存"。这个回答离目标越来越远了。
后来我停下来，手动对比了AI手里可能掌握的上下文和它实际需要的最小上下文，发现问题出在三个地方：
- 我给的是完整文件，但完整文件里大部分代码跟本次任务无关。详情页有300多行，真正跟参数解析相关的只有20行。模型被迫处理了280行噪声，注意力分散了。
- 我没有告诉AI这个页面还存在"其他入口跳转"这件事。它不知道已有的参数解析逻辑是不能动的存量逻辑。这不是它的错，是我没把"边界约束"写进上下文。
- 我贴进去的代码复制自开发分支，而实际出问题的是测试分支，两者在跳转逻辑上有细微差异。模型看到的根本不是真实代码。
2.3 这次事故给我的三个教训
教训一：上下文不是越多越好，是"越准越好"。把无关代码贴进去，等于请一个记忆力超强的实习生来帮你改代码，但你让他同时看了30个模块的需求，他当然会记混。
教训二：不要假设AI能自动区分"存量逻辑"和"新增逻辑"。在人类团队里，你给新同事说"这个函数别动"，他听得懂。AI没有这种默契，你必须把这种约束显式写进上下文里。比如在需求后加一行："注意：现有handleQueryParam函数是给其他入口用的，保持其原有逻辑不变，只在这段函数之后追加新的参数合并逻辑。"
教训三：上下文必须和实际代码同步，否则AI就是空转。从那以后我给自己定了一条死规矩：凡是喂给AI的代码，必须是从当前工作分支现场复制的，不允许用记忆版本、旧版本，更不能凭印象描述。
2.4 我把排查经验总结成了一张诊断表
如果你也遇到AI输出质量下降，先别急着骂模型，按下表逐项检查：
| 症状表现 | 可能的上下文问题 | 优先级 |
|---|---|---|
| AI引用不存在的函数 | 关键接口定义没有包含在上下文中 | 高 |
| 生成的风格和项目不一致 | 没有提供样例代码或风格约定 | 中 |
| 修改了无关模块的公共逻辑 | 上下文范围过大，边界约束缺失 | 高 |
| 反复跳不出同一个错误 | 报错上下文缺少前置代码 | 中 |
| 回答越来越泛、越来越官方 | 上下文被大量无关内容填满，模型在猜 | 高 |
这张表我后来打印出来贴在显示器边上。每次AI效果变差，我先跑一遍这张表，80%的问题都能在30秒内定位。
3. 三种常见的context-mode形态：从对话内到文件外
解决了诊断问题，我们来聊聊实际使用中三种最常见的context-mode形态。它们不是互斥的关系，而是可以组合使用的，理解清楚各自的能力边界和适用场景，才不会被工具的"一键魔法"迷惑。
3.1 对话内模式：最轻量但最考验"提问结构"
对话内的上下文模式，就是你现在在聊天窗口里跟AI对话的方式。你贴代码、提需求、它回答。看上去简单，但这里有一个很多人忽略的细节：对话内的上下文是累积的。
什么意思？你的每一轮对话都会占据上下文窗口。第一轮你贴了500行代码，第二轮报错信息又用掉1000个token，第三轮修正需求又写了几百字，到第四轮的时候，模型实际上能记住的"重点信息"已经被稀释得差不多了。
我做过一次对比实验。同一个任务，第一种方式是一次性把完整信息和需求全部放在首条消息里，第二种方式是分四轮逐步追加信息。结果是，第一种方式的输出质量明显高于第二种，尤其在后半段代码中，第一种方式的风格一致性更稳定。
这不是玄学，这是transformer注意力机制的直接体现。首条消息的内容在整个生成过程中会被反复参考，而追加在后面的信息，虽然模型也能看到，但对最终输出的影响力会随距离衰减。
实操建议：能用一条消息说清楚的事情，不要拆成三条。如果任务复杂，先用一个简短开头把"任务目标+边界约束+关键文件清单"钉死，然后再贴详细内容。
3.2 语义检索模式：用检索代替死记硬背
第二种形态是把上下文交给检索系统管理。典型工具是各种支持"引用文件"或"代码库索引"的AI编程插件。它会先对你的项目做一次向量化索引，然后在生成回答时自动检索相关代码片段作为上下文。
这种方式的好处是显而易见的：不用手动贴代码，AI自己去找。坏处也很明显：检索质量直接决定输出质量，而检索质量并不总是可靠。
我在一个中型项目上验证过，检索模式在单一职责模块上表现很好，比如"帮我改一下用户登录逻辑"，它能精准抽到认证相关的文件。但一旦任务涉及跨模块流转，比如"登录之后把用户信息同步到订单模块并触发消息推送"，检索结果就开始出现拼凑感，经常抓到一些关系不大的片段。
这说明语义检索适合"点状任务"，不适合"链路型任务"。链路型任务的信息是分散在多个模块里的，而且它们之间的逻辑关系，仅靠向量相似度是捕捉不到的。你需要在上下文中显式地描述这条链路。
3.3 外部化模式：把上下文沉淀成项目资产
第三种形态是我目前最推荐的：把上下文做成独立的项目文件，比如CONTEXT.md、AGENTS.md、docs/decisions/这类结构。这些文件本身不是代码，但AI在生成时会自动读取它们，等同于把上下文从"对话里的临时记忆"变成了"项目的持久化记忆"。
这个模式优势极其明显。团队里任何一个人用AI干活，都能自动继承项目级上下文，不用每次重新讲一遍背景。哪怕过了三个月才回来改这个项目，直接让AI读CONTEXT.md，它瞬间就能恢复全部关键信息。
我在一个长期维护的项目里建过一个CONTEXT.md，内容包括：
- 项目技术栈和版本约束（明确说"禁止引入未经审批的第三方依赖"）
- 核心业务概念定义（比如"什么是活动价、什么是渠道价，两者不允许混用"）
- 模块边界（哪个目录属于服务端渲染，哪个目录属于客户端逻辑，不能串）
- 编码风格约定（缩进风格、命名惯例、错误处理偏好、测试偏好）
- 已知的坑（哪些历史遗留代码是不建议动的）
这个文件大概600行，但只要它存在，AI在这个项目里的表现就稳定在一个很高的基准线上。我已经把这个方式固化成了所有新项目的标准操作。
4. 一套可落地的context-mode三层架构
有了这些基础，我来分享一套我在真实项目中验证过的上下文架构。核心思路是把上下文分成三个层次，各司其职、互不干扰。这套架构也不绑定任何特定工具，你看完可以根据自己的环境灵活落地。
4.1 第一层：全局骨架——常驻的项目级上下文
全局骨架解决的是"AI对项目一无所知"的问题。它的信息密度不需要很高，但覆盖面要广。具体到落地，一个CONTEXT.md文件就够了。我需要强调一下，这份文件不是写给AI看的说明书，它是给所有未来要用AI处理这个项目的人和AI一起看的地基。放什么内容是有讲究的：
- 项目的启动命令和测试命令，这是AI跑验证的前提
- 核心目录结构的说明，每个目录是干什么的，谁可以依赖谁
- 关键依赖清单，以及为什么要用这些依赖
- 不允许做的事情列表，比如不要改生成的SQL迁移文件、不要动公共枚举类
我见过很多人把CONTEXT.md写得非常详细，动辄两千行。我的建议是没有必要，写得太长反而稀释重点。控制在300到600行之间，只保留那些"不知道就一定会出错"的信息。
4.2 第二层：任务快照——按需注入的临时上下文
任务快照解决的是"当前这个具体任务需要什么额外信息"的问题。每次开工前花两分钟整理一个简短的任务描述，包含：
- 你正在改哪个文件、哪个函数
- 这个函数在项目里承担什么职责
- 你期望的改动范围是什么，禁止波及哪些模块
- 如果有相关的前置约束（比如已有旧的传参逻辑），明确写出来
任务快照的最大误区是贪多。我见过有人把整个模块的文档、几十个接口定义全塞进去，结果AI被信息淹没。一个合格的任务快照应该控制在800个token以内，够用就好。
为什么这么强调task快照的独立性？因为对话内的上下文是会累积污染的。如果你上午已经跟AI聊了几轮其他任务，到下午再开一个新任务时，上午的内容还残留在上下文窗口里，AI很可能会把两个任务的上下文混着用。我的习惯是：每切换一个任务，就开一个全新的对话（或会话隧道），hosting任务快照作为首条消息。
4.3 第三层：约束条件——控制AI行为的隐性上下文
第三层最容易被忽略，但它是决定AI输出风格和准确率的关键。约束条件不是"告诉AI做什么"，而是"告诉AI不做什么、注意什么"。
我有几个固定的约束模板，属于缝在上下文里的标配：
- "不要修改与本任务无关的函数。如果确实需要修改其他模块，请先说明理由再动手。"
- "不要使用项目中尚未引入的第三方库。如果确有必要新增依赖，请明确写出库名和版本，交由人工评估。"
- "保持现有代码的编码风格，尤其是命名习惯和注释习惯。"
- "如果问题的答案存在多种可能，先列出你的假设，再给出方案。"
这些约束看起来很简单，但实际效果非常显著。它们把AI从一个"偶尔自作聪明的代码生成器"变成了"一个受过基本职业训练、懂得边界感的协作者"。
4.4 三层架构的组合使用流程
平时干活时，我的标准操作顺序是这样的：
- 打开项目，让AI先读
CONTEXT.md（第一层） - 在每轮任务开始前，粘贴一份新的任务快照（第二层）
- 在任务快照末尾附带本次任务的约束清单（第三层）
- 让AI先复述一遍它认为要做什么、它对每一条约束的理解，确认理解一致后再生成代码
最后一步特别有用。让AI复述需求，本质上是在强制它把上下文里的信息重新编码一遍，这能显著降低"模型跳过关键信息直接输出"的概率。代价是多花十几秒，收益是少返工几小时。
5. 实测对比：同样的功能，三种上下文策略的不同结果
理论讲再多，不如跑一次实测。我挑了一个真实的业务功能——"给用户中心新增一个导出CSV报表的按钮"——用三种不同的上下文策略分别让AI实现，对比一下结果差异。这个例子很能说明问题。
5.1 策略A：裸奔式（没有上下文管理）
操作方式：直接在聊天窗口输入"帮我给用户中心加一个导出CSV按钮"。
结果：AI生成了一个完整功能，代码写得花团锦簇，用了papaparse这个库（项目里没引入过），还把按钮样式改成了它认为"更好看"的方案，完全偏离了项目现有的UI风格。更要命的是，它把导出接口的地址写成了一个凭空杜撰的/api/user/export-csv，后端根本没有这个路由。
结论：在完全没有上下文的情况下，AI的输出等于"一个不太了解你们项目的陌生工程师的凭空发挥"。它之所以敢这么干，是因为它脑子里存了大量"通用做法"，而它不知道哪些通用做法在你项目里是不成立的。
5.2 策略B：半桶水式（贴相关文件）
操作方式：把用户中心的列表页、用户API定义文件、路由配置一起粘进去，然后提出需求。
结果：比A好了很多，AI找到了正确的API地址（因为API定义文件里有），也没有再乱加依赖。但问题在于，它还是修改了几个不该动的公共组件——具体来说是给按钮加了一个loading状态时，把全局的Button组件默认行为改掉了。这殃及了其他页面，因为那个Button组件是全局共享的。
根源：我虽然贴了相关文件，但没有明确划出"本次改动边界"。模型认为改全局组件是一种合理的提高复用性的方式，但它不了解这个项目对全局组件有多么保守的修改策略。
5.3 策略C：三层架构式（全局骨架+任务快照+约束）
操作方式：
- 先让AI读取
CONTEXT.md，内容明确写了"用户中心的列表页属于前端模块，可独立改动但不得修改components/ui下的公共组件" - 首轮任务快照里写了：新增导出按钮，放在列表页右上角操作区，样式参考同页面的"刷新"按钮；导出接口为
GET /api/users/export，参数与列表筛选参数一致；导出逻辑放在独立的exportUtils.ts中，不要污染页面组件 - 附加约束：不得引入新第三方库，使用原生
Blob方案实现导出
结果：AI生成的功能一次通过code review。样式跟现有按钮一致，没有动任何公共组件，导出的CSV也能正常打开。唯一的微小瑕疵是文件名没有加日期前缀，我在任务快照里没提，它也没想到。加一行代码解决。
5.4 实测结果的量化感受
我不能说每种场景都能有如此悬殊的差距，但在跨模块、有存量逻辑约束、涉及UI和接口联动的任务上，策略C比策略A的返工率低了至少一半。我自己统计过，过去用裸聊方式做三个功能大概有一个要推翻重做，用三层架构后，大概五个功能才可能出现一次大返工。
如果你觉得这个数据太理想，我建议你直接在自己的项目里试试，拿一个小功能分别用三种策略跑一遍。你会很快意识到，context-mode不是一个"提升AI能力"的东西，它是一个"降低AI犯蠢概率"的东西。
6. 上下文管理中的隐藏陷阱和我的实测应对
讲完三层架构，再聊几个我在实战中反复踩到、但很少被系统性谈论的坑。这些坑不解决，上面所有方案都会在某些时刻失效。
6.1 黏性陷阱：上下文窗口的隐性占用
这是所有人都会遇到的问题，只是很多人没有意识到。你用对话方式工作一小时后，第一轮贴的几十行代码、讨论过的方案、中间产生的错误样例，全都还占着上下文窗口。等任务推进到收尾阶段，模型对前期关键信息的记忆已经变得模糊，甚至开始遗忘你最早提出的边界约束。
我的应对手段很朴素但好用：一个人工断点机制。每当一个子任务完成，我不会继续在同一个会话里开新任务，而是开一个新会话，然后在新会话里重新粘贴精炼过的任务快照和约束。这相当于人脑的"清除短期记忆，保留长期笔记"。
6.2 过期陷阱：上下文中的代码版本已经过时
项目在飞速演化时，上下文里的信息会快速过期。你今天早上粘贴的一个函数，下午就可能在另一个分支上被重构了。如果AI基于过期代码继续生成，那它生成的所有后续代码都有安全隐患。
我在用外部化模式时，给CONTEXT.md设置了一个强制更新时机：每次涉及公共接口变更、依赖变更或目录结构调整，必须在当日结束前更新这个文件。这个习惯救了我不止一次。有一回同事改了用户实体的字段命名规范，由于我当天更新了CONTEXT.md，后续AI生成的所有代码都自然采用了新命名，没有出现混用。
6.3 检索陷阱：语义检索带来的"看起来相关"片段
前面提到语义检索模式，这里展开说一个深入的问题：语义检索会返回"语义相近"的代码片段，但不保证是"功能正确"的代码片段。这是两个完全不同的概念。
比如你问"怎么获取当前登录用户的角色"的相邻代码，检索系统可能返回一个在另一个无关模块里同样调用了getUserInfo的片段。语义上它跟你的问题相关（都涉及获取用户信息），但实际上跟你的业务逻辑毫无关系。AI如果拿这段回去垫上下文，就会生成方向上完全跑偏的代码。
应对策略是：如果使用支持检索的工具，一定也要同时提供精准的文件路径提示，不要让AI完全依赖检索。比如在任务快照里明确写"相关代码在src/modules/user/service.ts中，只需要参考其中的getUserRole函数"。这等于在检索之上加了一个人工路标。
6.4 幻觉陷阱：AI对于不存在的功能的"顺滑编造"
AI在上下文信息不足时，最恶劣的表现不是"说我不会"，而是"告诉你一个根本不存在的实现方式"。比如一个项目里根本没有的消息队列组件，AI能给你写出完整的调用示例。
这个问题单靠上下文管理也解决不了，因为诱发它的原因是模型训练数据里的通用知识太丰富，它总能用记忆中的"常见做法"补全空白。最有效的应对就是：约束它，把"如果你不确定项目里是否有这个功能或API，必须明确说不确定，而不是假设存在"写进约束清单。配合全局骨架里的依赖清单，大多数编造行为能被拦截在生成之前。
7. 在不同场景下的context-mode侧重点
聊完了通用方法，说一说在不同场景下，什么该加强、什么可以适当舍弃。不能一套方案走天下，不同场景的上下文管理重点差别很大。
7.1 新项目初始化：上下文先行
新项目开工时，是最容易建立好上下文体系的时机，因为代码还少、约束还没固化。很多人新项目直接用AI一顿猛输出，结果代码风格五花八门，后患无穷。
我的建议是：动手写第一行业务代码之前，先把根目录下的AGENTS.md或CONTEXT.md建起来。不用长，几十行就够，核心是写清楚"这个项目打算用什么技术栈、目录怎么分、编码风格倾向什么、哪些东西是后续新增时要遵守的"。这个成本极低，收益是巨大的——每个后续的AI交互都在这个地基上生长。
7.2 存量系统改造：上下文考古
在老项目上使用context-mode，最难的是存量逻辑的梳理。老项目往往缺少文档、命名混乱、存在大量历史包袱，AI很容易在"合理理解"和"现实代码"之间产生冲突。
我在这种场景下的固定做法是：让AI先"考古"，再改代码。具体就是先不发修改指令，而是问它"请根据代码库分析，当前登录校验的逻辑链路是什么，从请求进入开始到用户身份确认结束，列出每一个涉及的文件和函数，并指出其中哪些可能是历史遗留的无用代码"。等它把链路画出来（也就是把上下文建起来），我再开始提修改需求。这样做的返工率远低于直接让它改。
7.3 技术文档生成：上下文的输出端复用
context-mode不仅用于生成代码，也用于生成文档。而且文档生成对上下文管理的要求更高，因为胡说八道的文档比没有文档危害更大。
我在让AI生成技术文档时，会特别指定三个上下文锚点：一是实际代码文件名和路径（它必须基于代码，不能凭记忆写），二是文档的目标读者（比如是新入职的前端还是长期维护者），三是文档的边界（比如只要讲清楚当前模块，不要扯历史演进）。没有这三个锚点，AI生成的文档优美但假大空，有了这三个锚点，它就更接近一份可直接交接的技术文档。
8. 从context-mode延伸出去：我养成的几个工作习惯
这些习惯单独看都不算什么高深技术，但组合在一起，它们让我对AI工具的掌控感提升了一个量级。
8.1 每个项目一个"sources文件夹"
我在项目根目录下维护了一个.ai/文件夹，里面存放给AI用的辅助材料，包括CONTEXT.md、STYLE.md（编码风格）、ARCHITECTURE.md（架构说明）、known-traps.md（已知陷阱）。这个文件夹本身不参与业务打包，但它是我所有AI相关操作的起点。新项目我会第一时间创建这个文件夹，并在项目交接时把它同步给下一个人。
8.2 让AI先复述再动手
这个习惯可以说是最能提升效率的一个：在所有重要任务开始前，先让AI用自己的话复述"你准备怎么做、你的步骤是什么、你有哪些疑问"。这一步用来确认它真的理解了我的上下文。实测中，这个要求能让"理解错了但不说"的概率大幅下降。AI假装懂的时候很多，让它复述就藏不住。
8.3 每次输出都要"引用来源"
凡是AI给出的关键结论（比如"这个接口在authController.ts的第47行被调用"、"这个配置在application.yml里"），我会要求它在回答里说明信息来源。如果它编造，这个要求本身就会让它犹豫；如果它说"根据代码库检索"，我至少能快速定位去验证。这个习惯能有效压缩幻觉的生存空间。
8.4 定期换血：对对话历史保持零执念
我见过很多同事，AI会话已经扯了十几个小时，依然舍不得开新会，因为觉得"聊了这么久，它应该都记得"。恰恰相反，上下文窗口有限，它记得越久，忘得越多。我对长期会话的态度是：任务一完成，立即归档会话内容到笔记里，然后清零开新会话。归档碎片化、上下文按需注入，配合外部的持久化文件（CONTEXT.md），这三板斧才是context-mode真正好用的根基。
