最近一次让我彻底破防的经历是在一个跨了六个模块的老项目里调一个数据流问题。我给 AI 编程助手把同一个函数的调用链讲了三遍它依然自信地给我抛出了一个引用了不存在变量的答案。问题不在模型拉胯而在我喂给它的上下文太稀碎——我没有一个稳定、可复用的方式把当前代码到底处于什么位置、牵扯哪些文件、改了什么准确又克制地告诉它。从那天起我开始认真琢磨context-mode这个东西它不是某个厂商的产品而是一套把散落上下文自动打包、按需投喂的工作方式。我花了两周实现了自己的版本也踩了一堆坑今天把这套思路完整拆给你看。1. 从答非所问到上下文失效context-mode 到底在解决什么问题1.1 为什么我们反复解释AI 还是答非所问先还原一下最典型的翻车现场。你在一个用了三年、接手时就没有文档的 Django 项目里改需求于是打开 AI 助手把报错信息粘进去问这段代码为什么报错。AI 开始猜测它猜你用了 Django 2.x 的写法猜你的模型里有个status字段猜你的中间件是默认配置。但真实情况是——你的项目用 Django 4.2模型里那个字段叫state中间件里有人加了自定义逻辑好在请求进视图前改了request.user。这一连串的信息AI 怎么知道它看不到你的代码库。哪怕你把报错那段代码贴进去它看到的也只是孤立的一小段。真正有用的上下文散落在好几个地方报错函数的上游调用者、模型定义、URL 路由、数据库迁移文件甚至某一次 git commit 里写下的为什么当时这么改。这些东西不会自动跑到对话里去。所以答非所问的本质不是 AI 变笨了而是你给的上下文信噪比太低。低到什么程度可能你贴了 2000 字代码其中对解题有用的不到 200 字剩下全是干扰项。模型不是人它不会说你给的信息不够我再等等它只会基于手头这点东西强行推理然后一本正经地胡说。1.2 上下文不是越多越好信噪比与 token 经济学很多人第一反应是既然上下文不够那把整个项目都喂进去不就行了。这个思路要是在三年前还能算个方案现在就完全行不通了。这里的核心约束是模型的上下文窗口context window——当前主流模型通常以 token 为计量单位几万到几十万 token 不等听起来很大但真实代码的消耗速度远超你想象。我自己做过一个粗略的统计一个中型仓库光src目录下的 Python 文件加起来就可能有 30 万到 50 万 token这还没算配置文件、测试文件、文档、git 历史。也就是说整个仓库塞进去窗口直接爆掉即便窗口没爆模型在几十万 token 里找你正在改的那个函数相关的信息效果也会断崖式下跌。业内把这叫做中间迷失lost in the middle——长上下文里模型对开头和结尾的内容记忆更牢中间部分经常被无视。这跟人开会很像你开一个四小时的会能记住的往往只有第一小时和最后半小时。给 AI 喂一堆不相干的文件等于逼它在四小时会议纪要里找一句关键结论能找到才怪。所以真正的问题从来不是上下文不够而是上下文无效。context-mode的核心追求就是把这个天平拨回来不是最大化上下文数量而是最大化单位 token 的有效信息密度。1.3 重新定义 context-mode一份可复用的代码档案基于上面的理解我给context-mode下的定义是一套自动构建、按需裁剪、随代码状态实时更新的代码档案机制。它要做的事有三件第一采集。感知你当前的工作状态——正在编辑哪个文件、最近的 git diff 动了哪些行、项目整体结构长什么样、相关函数定义在哪个文件第几行。第二裁剪。把所有采集到的信息做相关性排序和 token 预算控制只保留对当前任务最有用的那部分。第三投递。把整理好的上下文以结构化文本的形式输出供 AI 助手、代码补全插件、或者你自己阅读时使用。这样说可能还是有点抽象。打个比方这就像你进图书馆查资料context-mode不是把整个图书馆的书都搬到你桌上而是先看一眼你的借阅单然后帮你把相关的几本书翻到具体页码折好角放在你手边。你要做的只是翻开它们。这个定义里最容易被忽略的是随代码状态实时更新。很多项目里有人写脚本给 AI 生成上下文但那是静态的——生成一次就固定了代码一改上下文就过期。而context-mode的设计目标里必须带上时间维度你今天问的和上周问同一个文件得到的上下文应该是不同的因为你手上的改动变了需要关注的重点也变了。2. 四种工作模式怎么选快照、跟随、定向与对比动手写代码之前我先把需求拆成了四种模式。这不是凭空想出来的而是对应了四类完全不同的日常场景。把模式想清楚再动手后面所有代码都会简单不少。2.1 快照模式一次性的上下文采集快照模式解决的是一次性提问场景。比如我现在要写一封周报需要概括这周改了什么或者我要给一个新同事讲讲某个模块怎么用得先自己重新熟悉一下这块代码。这种场景下我不需要实时监控只需要一个命令把指定范围的信息抓到一份文件里然后我自己看或者喂给 AI。快照模式的实现最简单输入一个路径或者一个 git 提交范围输出一份 markdown 文件。它的输出是静态的但也正是这份静态让它可以被保存、被 diff、被 review —— 你可以把今天的快照和上周的快照放一起对比看看上下文档案本身发生了什么变化这本身就是一种很好的项目文档。2.2 跟随模式随代码变动实时刷新跟随模式是我用得最多的模式它解决的场景是长时间在同一个任务里连续工作。比如我在重构一个服务今天上午改了 worker下午要改调用它的 API明天还要动测试。这个过程中我的有效上下文一直在变上午关注 worker 内部逻辑下午关注 API 层怎么调它明天关注测试怎么 mock 它。跟随模式的做法是在后台监听仓库变化文件保存、git 分支切换、git commit每次变化都重新生成一份上下文档案。这份档案不是给某个具体问题用的而是给我整个工作阶段用的——相当于一个当前状态仪表盘。它回答的是我现在在哪、动了什么、哪些东西跟我的改动相关。这里有个关键设计决策跟随模式的刷新频率绝对不能太高。如果每次文件保存都重新扫描全仓库两分钟就能把人逼疯。我的做法是 debounce——停止编辑 3 秒后才触发刷新并且只对活跃文件做全量扫描其余文件走增量缓存。2.3 定向模式只提取与当前问题相关的碎片定向模式是所有模式里最聪明的也最难做。它解决的是我有个具体问题的场景比如函数parse_order报错了或者我要改一下get_user_by_token的行为。定向模式会先定位到这个函数然后向外扩散——它的定义、它的调用方、它调用的依赖、它引用的全局变量和配置——形成一张相关性的网络。扩散范围需要收敛不然就又变成全仓库扫描了。我用的方法是两层扩散第一层从当前函数所在文件出发找到直接 import 的文件和被当前文件 import 的文件第二层从这些文件里筛出真正包含目标函数定义、调用和依赖的那几个符号把符号附近的代码块提取出来。两层之后就停止除了极少数特殊情况再往外扩的上下文基本就是噪声。2.4 对比模式diff 驱动的最小上下文对比模式是我后来加的因为我发现只要涉及改代码几乎所有问题都可以先归约到一个 diff 上。对比模式只做一件事拿到当前分支相对主干分支或者相对任意一个指定提交的 diff然后生成一份极其精简的上下文——改前是什么、改后是什么、这次改动牵扯到哪些文件里的哪些符号。这种模式生成的上下文 token 消耗最低通常几百个 token 就够了但对 AI 理解你正在做什么却最有效。我实测下来用对比模式生成的上下文问 AI帮我看下这次改动有没有问题答案质量比粘贴 2000 行代码高得多。原因也很简单diff 本身就是一次语义压缩它天然去掉了所有没变的代码留下的全是变化本身。2.5 选型决策表与我的使用习惯四种模式各有各的适用面我把它整理成一张决策表使用场景推荐模式输出量级数据新鲜度要求一次性提问/写周报快照模式中等低长时间连续重构跟随模式较大高定位具体函数问题定向模式小中代码评审/改动评估对比模式最小高在实际使用中我的习惯是每天开工先跑一次跟随模式让上下文档案热起来中途遇到具体报错就用定向模式单独提取一次代码改完要提交前跑一次对比模式生成提交说明和自审清单。这三种模式并不互斥配合着用效果最好。3. 核心实现一个轻量 context-mode 工具的落地过程模式想清楚之后实现反而没那么难了。我把整个工具拆成了三层采集层、裁剪层、输出层。每一层都很薄但组合起来就是一个完整可用的系统。3.1 技术选型为什么我选了 Python 加 git 命令技术选型上我没犯纠结。第一版工具我用的是 Python原因有三一是 Python 处理文本和 AST 的生态最成熟二是 git 操作直接调命令行就行三是后续想接 LLM 的时候Python 的 SDK 支持最全。有人可能会问为什么不用 Node 或者 Go我的回答是这个工具的核心复杂度不在性能而在文本解析和启发式规则上这两件事 Python 都更顺手。如果你未来有大规模并发的需求再迁移到 Go 也不迟但第一版最重要的是快速验证想法。整个工具的外部依赖只有两个git命令行和 Python 标准库里的ast模块。连数据库都没有状态全部落到临时目录里的 JSON 文件。这样设计的好处是部署几乎零成本扔到任何一台有 Python 的机器上都能跑。3.2 采集层的三个层次仓库地图、活动文件、变更轨迹采集层是整个工具的地基它负责回答现在这个仓库里到底有什么。我把采集范围分成三个层次第一个层次是仓库地图。这一步输出项目的目录树、主要模块的划分、关键配置文件的路径。不需要展开每个文件的全部内容只需要文件路径和大小。我的实现是递归遍历目录忽略.git、node_modules、__pycache__这些无关目录然后把结果压缩成树形文本。这块逻辑大概五十行就能写完。第二个层次是活动文件。这里的活动指的是与你当前任务相关的文件。判定标准有两个一是最近几分钟内编辑过、且还有未提交改动的文件二是被git diff --stat列出的文件。这两类文件是你当下工作的直接载体必须采集完整内容但要按文件裁剪到只保留关键符号。第三个层次是变更轨迹。这需要调用 git 命令拿到最近一段时间默认是 7 天的提交记录和当前 diff。每次提交的信息里往往藏着当时改代码的原因这些是最有价值的额外上下文——AI 看到fix: use timezone-aware datetime when parsing order time这种提交信息比看到十行抽象代码更明白你要什么。采集层我之前踩过的坑是在 monorepo 里如果按照仓库整体去开地图很容易被无关的子项目淹没。后来我加了一个.context_ignore文件支持配置忽略规则像.gitignore一样用效果立竿见影。3.3 裁剪层的核心逻辑用 AST 做相关性打分采集层拿到的原始素材往往很大直接输出是行不通的。裁剪层的工作是对素材做两轮裁剪符号级裁剪和文件级裁剪。符号级裁剪用的是 Python 的ast模块。我把每个文件解析成抽象语法树提取出其中的函数、类、全局变量以及它们各自的行号范围。这样我就有了文件里的第 100 行到 150 行是函数get_order的定义这种索引。裁剪的时候我不需要输出整个文件只需要输出目标函数附近的代码块。文件级裁剪则依赖一个简单的打分函数。我给每个文件算一个相关性分数分数由四个因子加权求和当前 diff 是否涉及该文件权重最高、该文件是否被活跃文件 import次高、该文件是否包含目标符号的调用或定义中、该文件最近的修改时间是否离得近低。打完分按 token 预算从高到低取文件预算用完了就停。打分函数的核心代码大概长这样def score_file(path: str, active_set: set, diff_set: set, imports_from: set, last_modified: float) - float: score 0.0 if path in diff_set: score 10.0 if path in active_set: score 8.0 for dep in imports_from.get(path, []): if dep in active_set or dep in diff_set: score 5.0 # 时间衰减 越久没改贡献越低 age_hours (time.time() - last_modified) / 3600.0 score 2.0 / (1.0 age_hours / 24.0) return score这个打分函数看起来简单但非常实用。调权重的时候你一定要相信直觉而不要去跑一堆指标——我一开始花了三天做一个完美的 TF-IDF 相关度计算跑出来的结果被一个简单的文件路径命中规则按在地上摩擦。后来我学乖了启发式规则优先机器学习模型永远是后话。3.4 输出层token 预算怎么估算和控制输出层负责把裁剪结果变成最终文本同时做 token 预算控制。关键问题在于你到底输出了多少 token我用的估算方式是tiktoken库它内置了 OpenAI 的分词器可以直接对文本做 token 级精确计数。计数结果用来控制递归裁剪的终止条件先算仓库地图的 token 数再依次加活动文件和变更轨迹每加一层就检查是否超过预算超了就停止继续添加。实际使用中我给自己设定了三档预算快速问答用 800 token日常开发用 2000 token深度调试用 5000 token。注意这些数字不是越大越好——我在 1.2 节说过信噪比才是关键。2000 token 的预算下我宁可只放两个完整的核心函数也不放十个文件的碎片。输出格式我选的是 markdown原因很纯粹AI 对 markdown 的解析最稳我自己看也最舒服。每个文件用一个二级标题分隔文件内用代码块包裹。文件路径必须写绝对路径或相对仓库根的路径这能帮 AI 建立文件之间的空间关系。4. 参数调优与实测对比哪些配置真正影响上下文质量context-mode里可以调的参数不少但真正对结果有大影响的就几个。这一节我给出自己的调参结论和一组实测数据你可以直接拿去当起点再按你的项目微调。4.1 上下文窗口预算默认 2000极限 5000预算设置是第一个要定的参数。我的建议是区分两种场景交互式问答和一次性大任务。交互式问答一边写代码一边问用 2000 token 比较舒服——它能完整放下 1 个核心文件加 3 个辅助文件的摘要一次性大任务比如让 AI 审查整个模块的设计可以提到 5000 token再高就开始碰到性能瓶颈和中间迷失。超过 5000 token 不是不能用而是收益递减。我有一次测试让工具生成了 12000 token 的上下文然后拿同样的问题分别用 2000、5000、12000 三个档位去问 AI结果 5000 档的回答质量最高12000 档反而开始出现前后矛盾——模型被太多不充分相关的信息干扰了。4.2 采样粒度函数级优于文件级符号级优于行级裁剪粒度决定了同一个 token 预算下你能装多少有效信息。直接丢整个文件是最浪费的按固定行数截取比如每个文件只取前 50 行也很容易砍到无关代码。我做了一轮对比实验同样是 2000 token 预算分别用整文件、按行截断、函数级提取三种方式生成上下文然后让 AI 回答同一组代码问题函数级提取的正确率比前两者高了约 40%。实现函数级提取依赖 AST 索引3.3 节的内容但有些语言没法方便地解析 AST比如纯配置文件、SQL、模板这时候我退回到块级提取——按空行把文件切成块再按块与目标符号的距离排序。4.3 淘汰机制过期上下文比没有上下文更有害这是我最想强调的一点。很多人的上下文是只增不减——今天加了几个文件明天又加几个文件最后变成一个混杂的大杂烩。context-mode必须内置淘汰机制。我的策略有三个触发条件第一时间淘汰。某个文件超过 48 小时没有被编辑、也没有出现在 diff 里它就从活跃上下文里降级为仅摘要。第二修改淘汰。文件内容和上次记录不一致时旧版本的内容直接作废新版本重新打分。第三任务切换淘汰。当你切换到另一个分支或者重置 diff 时整个档案应该重建而不是增量叠加。淘汰机制里有个细节git 分支切换这个动作特别容易被忽略。很多工具只监控文件变化不监控分支切换导致上下文档案里还留着上一个分支的改动信息被 AI 引用后就彻底跑偏。我这里花了一天加了个分支切换检测代价是每次切换分支重新生成档案耗时约 2 秒但换来的是后面再也不会出现AI 引用别人分支代码的笑话。4.4 一组真实的实测对比数据为了让你对参数效果有个直观感觉我贴一组我在一个约 200 个 Python 文件的业务项目上的实测数据参数组合上下文 token 数AI 答案正确率生成耗时全仓库扫描482000无法回答问题超窗96s最近 10 个文件整文件860052%8s2000 token 函数级裁剪198083%1.2s5000 token 符号级裁剪495088%2.1s12000 token 符号级裁剪1180086%4.6s这个表格最值得看的是后三行5000 token 的组合正确率最高12000 token 反而降了 2 个百分点。虽然差异不算巨大但足以说明加量不是万能的。2000 token 组合的正确率已经达到 83%对日常问答来说完全够用而它的生成耗时只有 1.2 秒——这意味着你可以毫无感知地在每次保存文件后刷新上下文档案。5. 把 context-mode 接进日常工作流编辑器、终端与 CI工具本身写得再好如果接不进日常流程最后还是会被遗忘。我在这块花的心思不比核心逻辑少因为我知道一个道理工具的使用成本超过三秒人就会回到老路上。5.1 编辑器集成把上下文变成按一下就看得到我在 Neovim 里做了一个最简集成一个快捷键触发命令把当前的context-mode档案输出到一个浮窗里。浮窗分左右两栏——左边是仓库地图右边是当前问题的相关代码摘要。这个浮窗被设计成只看不编辑因为它的作用是帮你建立全局感而不是替代你的编辑器缓冲。集成方式你用什么编辑器都能做只要能绑定快捷键并执行 shell 命令就能把context-mode的输出捞回来。在 VS Code 里可以做成一个侧边栏 Webview在 JetBrains 系列里可以做成一个 Tool Window。核心思想都一样把获取上下文这个动作的路径压缩到最短。这里有个体验细节输出浮窗里的文件路径必须是可点击跳转的。Neovim 里我加了一个映射光标停在路径上按回车就直接打开对应文件。这个小功能看着不起眼但实际使用频率极高——你看到一个相关文件下意识就会想跳过去看看如果还要手动输入路径这个上下文工具很快就会沦为摆设。5.2 与 AI 工具对接让模型自动吃到档案如果你日常用 AI 编程助手或者自己调 API把context-mode的输出对接进去有两条路。第一条路是粘贴式把工具生成的 markdown 档案直接贴进对话窗口。这条路简单可靠缺点是每次都要手动操作。我改进了一下在终端里做了个命令运行后直接把档案复制到系统剪贴板然后到对话窗口按粘贴就行。整个流程从以前的开文件、找代码、复制、粘贴变成了按一下快捷键。第二条路是编程式写一个小脚本自动读取档案内容并组装到发给模型 API 的 system prompt 里。这样你每次调用模型都自动带着最新的上下文。我实测下来同样一个问题不带档案的答案和带档案的答案正确率差距在 30% 到 50% 之间。做法很简单import click from context_mode import build_context click.command() click.option(--mode, defaultfollow) click.option(--budget, default2000) def ask(mode, budget): ctx build_context(modemode, token_budgetbudget) system_prompt ( You are a coding assistant. Use the following context from the current repository to answer. If the context is insufficient, say so.\n\n ctx ) # 然后正常走你的 LLM 调用流程这段代码里最容易被忽略的是 system prompt 里那句If the context is insufficient, say so——它给了模型一个承认不知道的出口。没有这句话模型宁可猜也不肯说上下文不够结果就是答非所问。5.3 团队场景提交信息生成与代码评审除了个人开发context-mode在团队协作里也有很实际的用处。最典型的是生成提交信息和代码评审意见。生成提交信息时对比模式的输出就是最好的素材来源它有完整的 diff 摘要、涉及的文件、改动前后的关键行。我把这个输出交给 AI 让它写 commit message比直接丢git diff效果好很多因为对比模式的上下文里已经包含了改动原因级别的信息来自最近提交历史的分析AI 不需要自己猜。代码评审是另一个大场景。传统做法是评审人打开 MRmerge request逐个文件点开看 diff。有了context-mode评审人可以一键生成整个 MR 的评审档案——包含每个改动文件的影响面、依赖关系、可能的破坏点。这个档案能让评审时间平均缩短至少三分之一因为你不必在无关文件之间来回跳。我们团队现在强制要求每个 MR 描述里附一份context-mode生成的摘要新人理解老代码的速度明显加快了。这已经不只是工具了事实上它变成了一种轻量级文档制度。6. 踩坑记录七个真实问题与完整排查链路工具从能用变好用全靠踩坑。这一节我按时间顺序记录我在实现和试用中遇到的七个问题每个都给出根因和解决办法尤其是我花时间最长的几个。6.1 多语言仓库的编码陷阱Latin-1 文件导致的崩溃现象在一个历史悠久的仓库里context-mode跑到一半直接抛UnicodeDecodeError崩溃。排查链路先看 traceback定位到读文件那行我用 Python 默认的 UTF-8 编码打开一切文件但仓库里有一批老文件是 Latin-1 编码的。第二层排查是确认哪些文件出问题我用了一个小脚本遍历仓库试读每个文件标出所有编码不是 UTF-8 的文件发现几乎都是十年前留下的 SQL 脚本和 Windows 换行的配置文件。根因这些文件的字节序列在 UTF-8 解码时成了非法字符。解决方法是读取时做编码回退def read_text_safely(path: str) - str: raw Path(path).read_bytes() for enc in (utf-8, latin-1, gbk): try: return raw.decode(enc) except UnicodeDecodeError: continue return raw.decode(utf-8, errorsreplace)这里我建议latin-1放第二位因为它几乎不会解码失败但不保证语义正确。如果仓库里中文注释很多gbk也应该试一次。这个坑虽然简单但不处理的话工具连启动都做不到。6.2 大文件拖垮采集速度生成上下文要 30 秒现象工具生成一份档案耗时 30 秒超过了我三秒以内的容忍线。排查链路我先分段计时发现时间几乎全花在 AST 解析上。进一步定位发现是一个 2 万多行的第三方库文件通常是打包后的生成代码拖慢了整个解析流程单个文件就吃了 80% 的时间。根因文件太大AST 解析复杂度高而且这种生成代码对上下文贡献极小。解决方法是给文件大小设一个阈值超过 2000 行的文件自动跳过 AST 解析只取文件头部的注释和函数签名索引。更进一步把这类文件默认加入忽略列表。修复后生成耗时从 30 秒降到 1.5 秒效果立竿见影。6.3 缓存失效但未识别改了文件却用到旧上下文现象我保存了一个文件然后跑context-mode输出里还是旧内容。排查链路先检查文件的修改时间戳缓存发现工具的缓存键是文件路径加修改时间。看起来没问题再去看文件读取逻辑发现我用的是 Python 的open()读文件但前提是我把缓存内容存在内存里进程没有退出。于是问题变成了进程内缓存什么时候失效——结果是我写的失效逻辑只在刷新任务触发时检查而我当时没有触发刷新任务。根因我把缓存失效和刷新任务耦合了导致文件变了但没触发刷新的窗口期里读到的全是旧数据。解决方法是每次请求上下文时都强制校验一次所有活跃文件的修改时间与缓存中记录的时间戳不一致就重新读取。这个校验的开销极小但彻底根治了脏读问题。6.4 已删除文件的幽灵引用AI 反复看到一个不存在的文件现象某个文件在重构中被删了但context-mode生成的上下文里还引用它AI 也因此不停建议我去改那个不存在的文件。排查链路先怀疑是 git 状态没更新但 git 命令返回正确文件确实已删除。再查采集层逻辑发现变更轨迹是从 git diff 里拿的而 diff 里被删除的文件确实会出现——但裁剪层在遍历时只处理了存在的文件删除文件的内容自然读不出来于是那个文件变成了一个只有路径没有内容的幽灵条目。根因采集到删除文件后没有在上下文中标记它是已删除反而只留下一个光秃秃的路径让 AI 误以为这是一个新文件。解决方法是当检测到文件被删除时在上下文中明确标注[DELETED] 文件路径该文件已在当前分支删除并且把这个标注放在变更轨迹最前面。AI 看到这个标注后就不再建议修改它了。6.5 token 估算与实际模型的差异tiktoken 低估了消耗现象我用tiktoken估算出上下文是 1900 token但实际发送给模型时报超过窗口限制。排查链路先怀疑是发送时又附加了 system prompt 等额外内容检查发现确实加了但总量不该超。再仔细看发现模型的窗口限制是输入加输出的总和而我估算时只算了输入部分没算预留的输出 token。也就是说窗口限制 4096 的情况下输入 1900输出最多只有 2196但如果模型试图生成超长回答还是会爆。根因我把输入预算和窗口上限混为了一谈。解决方法是给模型窗口留出 30% 的输出余量如果窗口是 4096那输入预算最多设在 2800。这个规则我写成了一个配置项默认值是窗口上限乘以 0.7。改完后问题彻底消失。6.6 编辑器里快捷键冲突与控制台卡顿现象按下我设置的触发热键后Neovim 卡了大约一秒还弹出了一个陌生插件的菜单。排查链路先查我的快捷键映射发现我绑的是leaderc而这个键被另一个插件占用。这解释了弹出的菜单来源卡顿则另有原因——我执行的是一个同步 shell 调用Neovim 主线程被阻塞等于整个 UI 冻结。根因绑定冲突加同步调用阻塞。解决方法是双管齐下快捷键改成一个几乎不会被占用的组合键同时把 shell 调用改成异步任务生成完成后用消息回调刷新浮窗。改完后按热键再无感知体验好了很多。这个坑提醒我任何编辑器集成都要把异步当成默认选项。所有生成上下文的操作都应该后台执行完成后通知前端刷新而不是让用户干等。6.7 意外把敏感信息打包进上下文现象有一次我生成的上下文里包含了一个包含数据库密码的连接字符串。排查链路这个其实不是 bug而是我设计上的疏漏。采集层会读取环境变量定义文件和配置文件这些文件里很可能包含密钥、token、连接串等敏感信息。当时我把.env文件列入了项目活动文件于是它被当成普通文件采集成上下文而那次我还把这个档案直接贴到了 AI 对话里。根因缺少敏感信息过滤机制。解决方法是加了一个密钥掩码过滤层在输出前对文本做正则扫描将类似password,api_key,token等模式后的值替换为[REDACTED]。另外默认忽略.env*、*secret*、*credential*这类文件。这个改进之后我敢放心地把档案直接贴给任何人了。7. 进一步的想法扩展方向与我的几点体会工具从第一版到现在迭代了两个月除了上面说的四个模式我还在实验几个延伸方向。一个是记忆持久化。现在每次生成的上下文档案用完就丢但我希望它能积累成一个项目知识库——每天的档案自动存下来按时间和分支归档。等积累到一定量就可以做类似这个文件半年前改过一次为什么改的追溯查询。这个方向本质上是把 git 历史从提交信息细化到上下文变化轨迹我觉得潜力很大。另一个是多文件坐标系统。现在的相关性打分还是纯基于文本的启发式但真实项目里文件之间的关系更像一张图——A 文件里引用了 B 文件里的类B 文件又依赖 C 模块。如果把这张图显式构建出来做相关性扩散时的精度会高很多。我已经用tree-sitter帮忙建过一版符号索引下一步计划是把它升级成真正的依赖图。最后说说我的体会。开发context-mode的过程中我最大的感受是大家往往高估了喂更多上下文的价值低估了精确筛选上下文的成本。真正有效的工作不是把整个仓库塞给模型而是设计一套机制让它每次都能拿到此刻最该看的那几段代码。这件事做起来比听起来难多了但一旦跑通AI 编程的体验就会从碰运气变成可预期。如果你也在折腾类似的东西我给三条建议。第一先定义清楚你的使用场景再写代码别一上来就追求通用快照模式起步就够了。第二参数少设几个token 预算、采样粒度、淘汰机制这三个想清楚工具就好用了一大半。第三一定给模型留一个承认上下文不够的出口不然它宁可猜也不肯告诉你信息不足。剩下的就在踩坑里慢慢磨吧。