“context-mode”这个标题单独丢过来的时候我第一反应是这八成又是哪个AI辅助编程工具里的一个功能开关。但真当我坐下来准备写点东西时越想越觉得不对——context-mode这个词如果只当它是一个“模式开关”那格局就小了。它背后真正值钱的东西是一整套“如何把项目上下文打包、隔离、投喂给大模型”的方法论。过去半年多我自己就在折腾这么个玩意儿。起因很简单DeepSeek、Claude、GPT这类模型用多了之后我发现最大的麻烦根本不是模型能力不够而是上下文太容易串味。今天改完A项目的代码明天切到B项目接着问AI问题模型还带着A项目的记忆在回答B项目的问题那种“驴唇不对马嘴”的感觉相信用过AI编程助手的人都懂。后来我干脆自己写了一套“context-mode”的管理方案——不准确说是一套全新的上下文组织流程。它不是什么神秘黑科技就是一个把“当前项目”“当前任务”“当前对话历史”“当前代码状态”打包成结构化提示词的方法体系。我用纯脚本加配置文件的方案跑了几个月解决了很多实际问题。今天这篇文章就把这套思路从头到尾拆开讲包括会话隔离怎么做、上下文包怎么拼、Token预算怎么算、快照切换怎么搞以及我踩过的坑。先说清楚一件事这篇文章适合谁。如果你是那种每天要用AI辅助写代码、改Bug、读源码的开发者这篇文章能帮你把AI从“看起来懂你”变得“真正懂你”。如果你是刚好在做一个类似的工具比如给AI coding agent做上下文管理模块那这些设计思路可以直接参考落地。哪怕你只是用ChatGPT之类的网页版这套“显式封装上下文”的思路也能让你日常提问的质量上一个台阶——说白了很多人问不出好答案不是因为AI笨而是因为你给AI的上下文太乱。1. 我为什么要专门做一套context-mode被上下文串味逼出来的方案先讲个真实的场景。我有三个项目在同时推进一个基于Gin的Go后端服务一个Vue3TypeScript的前端控制台还有一个Python写的离线数据处理脚本。每天早上一打开终端我习惯性地会把这三个目录里的代码都“喂”给AI助手——注意是同时喂。最开始用网页版的时候我每个问题都要手动圈定代码范围但AI跨对话的记忆总是把我搞得很难受上午问Go项目的路由怎么改下午问Vue项目传参问题结果模型给出的建议里居然带着Go项目的变量名风格追问几句才发现它把两个项目的上下文混在一起了。后来我去仔细研究了一些开源AI编程工具的实现发现它们普遍在谈一个概念context window上下文窗口。说白了大模型能同时“看到”的文本量是有限的比如8K、16K、32K甚至200K token。你喂进去的历史对话、代码片段、系统提示词一起占用这个窗口。窗口之外的内容模型就是“失忆”状态。所以问题根本不是“AI记不记得你之前说了什么”而是“在有限的窗口里你有没有把最该让它看到的东西放进去”。我做的第一版试验其实特别糙。我写了两个脚本一个叫collect_context.sh负责把当前项目的结构、git状态、最近修改的文件列表抓出来另一个叫pack_context.py负责把这些数据按固定模板拼成一段超长的文本然后塞给AI。跑了两周效果确实比手动复制粘贴强但问题也暴露得很明显——它把所有项目的信息都塞在一个包里AI依然分不清主次。于是我开始正经做第二版也就是后来被我叫作“context-mode”的东西。核心思路只有一句话上下文必须按会话隔离会话必须按任务组织任务必须能被随时切换和回溯。这句话听起来简单但落地的时候涉及的东西远比想象中多。下面我按模块一个个讲清楚。2. context-mode的第一个核心设计按项目任务双重维度做会话隔离如果不做任何隔离你所有的对话都挤在一个大池子里等到对话长了早期的关键信息会被自动挤出上下文窗口模型就开始“胡言乱语”。我见过有人为了省事把几个项目的代码全部拼接在一段对话里问AI结果AI把A项目的接口路径当成B项目的来推荐让人哭笑不得。所以第一步就是要让每个任务拥有一个完全独立的上下文空间。2.1 会话的物理存储结构我采用的是最朴素的目录方案每个项目一个根目录每个任务一个子目录任务下面是独立的会话文件。看起来就像这样~/.context-mode/ projects/ gin-backend/ tasks/ fix-login-timeout/ session.log metadata.json add-order-export/ session.log metadata.json project-state.yaml global-context.md vue-console/ tasks/ ...每个session.log存储当前任务的所有对话历史metadata.json记录任务创建时间、目标描述、关联代码文件、当前上下文包的版本号。而project-state.yaml和global-context.md是项目级的公共上下文——只要在这个项目里开新任务这些内容会自动被加载进去。你可能觉得目录结构有什么好说的但其实这里面有个关键决策为什么不用数据库我的考虑是文本文件可以被任何工具读取和修改方便我用shell脚本直接处理也方便拿到别的机器上备份和恢复。如果你以后想做一个更大规模的产品当然可以用SQLite但自己用的话纯文本文件的可调试性、可版本管理性远胜数据库。2.2 会话切换的语义有了一堆会话文件之后问题就变成当你从Go项目切到Vue项目时系统怎么知道该加载哪一套上下文这里我参考了桌面端AI助手常见的“Worktree工作树”概念但做了简化。我没有搞复杂的进程管理而是维护一个current.json文件里面记录当前激活的项目ID和任务ID。每次切换时更新这个文件每次发消息时脚本根据这个文件加载相应的上下文包。就这么简单。{ current_project: gin-backend, current_task: fix-login-timeout, current_version: 2025-06-12-14-30 }这看起来只是个小变量但它解决了一个实际问题你在终端里连续开多个会话窗口每个窗口里的AI助手不会互相“串门”。因为你给每个shell窗口指定了不同的current状态各自的上下文完全隔离。这也直接解决了我最开始被串味问题逼疯的痛点。3. 上下文自动采集不只是堆代码而是把结构化信息变成模型看得懂的文本隔离做好了下一步就是怎么把项目信息变成“上下文”。这一步是整个context-mode最核心、也最容易被低估的环节。很多人的做法是把所有代码文件一股脑拼进提示词。对于小项目可能还好但一旦项目上了规模几十个文件、几万行代码全部塞进去不但超Token预算而且真正有用的信息会被淹没。模型的注意力是有限的你给的信息越多它对关键信息的敏感度反而越低——这跟人一样让你看一份全是废话的长篇报告你也很难抓住重点。3.1 代码上下文的分层粒度我设计的采集逻辑分成四层每次打包时根据任务类型选择不同的组合第一层项目画像。包括项目名称、技术栈、目录结构仅两层、README的核心摘要、当前Git分支和最近的commit信息。这一层告诉模型“你在跟一个什么样的项目打交道”。第二层任务目标与约束。比如“修复登录超时问题要求覆盖Redis连接重置的场景保持接口兼容性”、“新增导出功能参考已有下载模块的代码风格”。这一层是模型做决策的主心骨。第三层相关代码实体。根据任务描述和目标文件路径自动匹配涉及的函数、结构体、组件、接口定义等。我用一个简单的正则加符号索引来抓取关键定义粒度是“函数级”不是“文件级”。第四层最新修改片段。把最近改动的文件差异git diff / git show提取出来让模型知道“刚发生了什么”。这一层对调试特别有用。每一层对应一个标记打包的时候可以用--layer project、--layer task、--layer code、--layer diff这样的参数控制也可以缩写成-L task,code。默认组合是task,code因为绝大多数代码生成和修改场景只需要这两层。如果你让AI读一个完全陌生的开源项目那用project,code更合适。3.2 一个最基础的上下文包长什么样我直接贴一个简化版的模板你就明白为什么模型在拿到这个包之后回答问题的准确率会明显提升[系统提示] 你的角色是在{golang}后端项目中辅助开发的资深工程师。项目根目录/home/user/work/gin-backend。 当前任务目标修复用户在登录接口超过5秒仍未收到响应时的超时问题。要求 - 不改变现有接口签名 - 兼容已有前端轮询逻辑 - 排查Redis会话缓存超时重置逻辑 [项目结构] gin-backend/ cmd/ internal/ api/ service/ cache/ pkg/ go.mod [相关代码实体] 函数: LoginHandler (internal/api/user.go:42) - 接收参数: ctx, req - 调用: AuthService.Login(ctx, req) - 依赖: RedisClient.Get(ctx, key) 函数: AuthService.Login (internal/service/auth.go:108) - 流程: 校验密码 - 生成session - 写入Redis - 返回token - 依赖: UserRepo.GetByUsername, RedisClient.SetEX [最近变更] commit 7d3f02a: 重构Redis缓存层引入连接池配置 diff --git a/internal/cache/redis.go b/internal/cache/redis.go -80,7 80,7 c.connPool redis.Pool{ MaxIdle: 30, - MaxActive: 50, MaxActive: 20, }你看模型拿到的不是一个巨大的代码仓库而是一个“精确制导”的信息包。它知道当前项目是什么、你要它做什么、相关代码在哪、最近改了什么。剩下的事就是它在一个相对干净的上下文里做推理。3.3 必要的信息冗余别省但要有序这里说一个我实践后的平衡策略。有人可能觉得既然要精炼那是不是只给函数签名和注释就行了我试过结果并不好——模型在不知道函数内部实现的情况下给出的建议经常是“正确的废话”。所以我的建议是核心代码实体的函数体只保留关键路径比如分支、循环、外部调用省略具体的长日志、注释、格式排版等。简单说保留能理解逻辑的“骨架”砍掉干扰注意力的“脂肪”。这个取舍你可以通过调整--context-depth参数控制默认是2含义是“展示函数体内部的直接逻辑不递归展开被调函数”。4. Token预算管理上下文不是越多越好而是“够用就好”搞定了内容还得搞定数量。我早期犯过一个特别蠢的错误——打包上下文时贪多求全动辄堆上万行代码结果经常把Token窗口挤爆或者模型看到后半部分内容时前半部分关键信息已经衰减了“长上下文”变成“长而不实”。4.1 Token计算的两个经验公式日常聊天用的Token计算器和API的真实计费窗口略有差异但对于咱们自己打包上下文有两个经验公式特别实用中文内容1个汉字大约1到1.5个Token不同模型分词器有差异英文内容1个英文单词大约1.2到1.5个Token纯代码的话一个符号算0.5到0.8个Token比较稳妥。拿上面那个Go项目举例那一整个上下文包实际体量估计在2600到3400个Token。我通常把单次上下文包的体积控制在8K Token以内这明显低于主流模型的16K或32K窗口给后续的对话留出足够空间——因为对话本身也会持续消耗Token。4.2 分层预算分配表我在config.yaml里维护了一张预算分配表每次打包时动态计算。你可以直接参考层默认占比最大Token上限作用系统提示与任务目标10%1K让模型明确做什么、不做什么项目画像10%1K提供技术栈和目录结构等背景相关代码实体60%5K核心逻辑上下文最近变更diff20%2K让模型知道最新进展与潜在问题来源这个占比不是拍脑袋定的。我在实际使用中发现如果“相关代码实体”占比太低模型容易瞎编API如果“项目画像”占比太高模型容易陷入堆术语的陷阱给不出具体能跑的代码。60%/20%这个组合是我改了四五轮之后比较稳的比例。4.3 超预算时的降级策略有时候任务就是很大比如“给整个项目的所有接口补上统一错误处理”涉及的代码文件可能超过20个5K的代码层上限根本不够。这时我不会强行扩大总包而是启用“分批问答”模式第一步把项目画像和任务目标发给模型让它自己列出需要修改的文件清单第二步从清单里挑出最关键的3到5个文件打包成代码层上下文让模型给出改法和示例第三步按文件逐个修改并在每次修改后将当前diff追加到上下文。这样做的好处是每次对话的Token消耗可控且模型注意力始终集中在当前正在处理的文件上。代价是要多跟模型交互几轮但代码质量明显提升几乎不会出现“改了这个文件忘了那个文件也需要同步修改”的漏网之鱼。5. 上下文快照、版本回滚与多任务切换做到随时反悔有了会话隔离和上下文打包下一步自然就是“快照”。为什么需要快照因为人总会改主意。比如你让AI按方案A重写了某个模块跑了两个小时后发现方案A有严重性能隐患想退回方案B——如果没有快照你只能凭记忆把代码改回去或者依赖Git的History慢慢翻。这个体验非常糟糕。我在context-mode里设计了快照逻辑每次执行一次重要变更包括代码建议应用、大段上下文切换、任务状态更新之前都会自动把当前的上下文包和一个代码文件快照存下来。存储方式沿袭了我一贯的极简风格就是一个带时间戳的目录tasks/ fix-login-timeout/ snapshots/ 2025-06-12-14-30-task.md 2025-06-12-14-30-code-state.tar.gz 2025-06-12-15-02-task.md 2025-06-12-15-02-code-state.tar.gztask.md存的是“当时模型看到的所有上下文”code-state.tar.gz存的是“当时重点代码文件的当前状态”。回滚的时候把这两个文件恢复出来再让AI重新加载它就能完全回到当时的思路和上下文里继续往下干活而不是像某些工具那样只能“重头再来”。这套快照机制还有个意外收获我可以对比不同快照之间的上下文变化反推出“我什么时候给AI加了什么信息导致它的回答风格发生了变化”。这种可追溯性在调试“AI为什么突然乱改代码”这类问题时价值无可替代。5.1 多任务并行时的切换成本在没有上下文隔离和快照之前从A任务切到B任务再切回来至少要重新复述一遍需求、贴一遍代码浪费大概5到10分钟。有了这套方案之后切换成本几乎变成了零改一下cur\n\nrent.json加载对应任务的上下文包AI马上就能接着上次的状态继续干活。有一次我上午在修后端登录超时下午临时被叫去改前端一个弹窗样式晚上又切回来继续修后端。整个过程没有任何精神内耗——因为每个任务的上下文都被原原本本地保存着我甚至不需要自己去回忆“我之前让AI改到哪一步了”直接看session.log的最后几条记录就能无缝接上。6. 我在实际跑context-mode时踩过的坑以及现在的使用习惯如果你打算照着这个思路造一套自己的方案下面这几个坑我建议你提前避开都是我花钱买来的教训。6.1 坑一把所有文件无脑打包让模型陷入“选择困难”我最开始图省事用了find . -name *.go | xargs cat这种方式打包代码结果模型经常给出互相冲突的建议——因为它同时看到了多个版本的函数定义和过时的调用方式根本分不清哪个是最新的。后来我引入了三层过滤先按git的最近修改时间筛选文件再按文件扩展名核心语言文件优先比如.go、.py、.ts最后用关键词匹配代码实体比如任务描述里的函数名、类名、表名。这三层过滤下来有效信息占比大幅提升。如果你也遇到模型回答“上下文无关的泛泛而谈”很大概率就是因为你把垃圾信息打包进去了。6.2 坑二忽略了系统提示词本身的维护不少人建好了context包却忽略了最前面的系统提示词。我一开始写的是“你是一个AI助手请帮我解决以下问题”这几乎等于什么都没说。后来我改成“你是一个有5年Gin开发经验的Go工程师请基于当前任务描述给出可实施的修改方案并在方案中标注具体的文件路径和行号”回答质量立刻提升了一个档次。原理很简单系统提示词决定了模型进入的“角色状态”和“输出格式期望”。它不占多少Token但影响整段对话的方向。我现在的系统提示词模板包含四个要素角色、目标、约束、输出格式。这四个要素缺一不可。6.3 坑三对话历史越来越长早期的关键信息还是会被挤出去即便上下文包控制在8K以内对话轮次多了之后总Token还是会逼近窗口上限。我试过两种解法第一种是“压缩历史”定期用模型对前面的对话做一个摘要把摘要放进上下文代替完整的历史第二种是“关键信息提取”如果任务目标一直没有变就确保任务目标始终存在于上下文头部的固定位置即使中间对话被截断它也不会被挤掉。我目前用的是第二种。养成这个习惯之后模型“忘记任务目标”的问题几乎彻底消失了。7. 一点额外的心得context-mode背后的思维模型可以迁移到所有AI使用场景最后再说几句题外话。虽然这套东西一开始是为了解决编程场景的上下文混乱问题但它背后的思维模型——把上下文显式组织成结构化信息分层、为不同任务隔离不同会话、为信息设置优先级和预算、保留快照支持回溯——放在任何AI使用场景里都成立。比如我写文档的时候会把“文章主题、目标读者、已有素材、参考文章的写作风格、禁忌措辞”这些分别打包再交给AI帮我润色。效果远比直接甩一堆素材给它要好得多。再比如我做数据分析和AI agent流水线的时候也会把每一阶段使用的数据集描述、列名、统计口径单独存成一个上下文文件避免阶段之间的信息污染。如果你刚好在开发类似的AI辅助工具我建议你把“context-mode”当作一等对象来设计——不是给它留一个开关而是给它建立完整的生命周期会话的创建、上下文的采集、预算的分配、快照的存储、回滚的恢复。这五个环节做扎实了你的工具才算真正具备了“记忆力”。我在开发这套方案之前总以为AI不够聪明是痛点现在才想明白聪明的部分AI做得很好记性和纪律性的部分真的得靠人在外面帮它补上。
