前阵子我电脑上同时挂着三个项目的活：一个数据清洗脚本，一个内部文档站，还有一个图像处理的小 Demo。每个项目本身都不算难，难的是来回切换的“上下文”。切到文档站时，代码补全还在给我上一项目的变量名；跑着清洗脚本时，快捷键脚本又把文档站目录打开。当这种错位越来越频繁，我开始怀疑：工具能不能自己知道“我现在在干嘛”？于是花了大约两周时间，把一个叫 context-mode 的本地小服务从原型一路做到可用状态。这篇文章就是记录它的设计取舍、踩坑过程和直接能抄的配置。
先给没听过这个概念的朋友白话解释一下：所谓 context-mode，就是让本地工具在多个工作模式之间自动判断并切换的一套机制。它输出的不是“你要写什么代码”，而是一个可信的先验信号——现在大概处于哪个项目、哪类任务，其他工具可以拿这个信号调整自己的行为。如果你经常在三个以上项目间切换、或者自己写过类似增强工具，这篇会有用。
1. 从“手动切模式”到“让工具自己知道我在干嘛”
1.1 最初的痛点和第一版方案
当初的第一版实现非常朴素：给 shell 写了一个 context-mode 命令，手动输入context-mode set project-a或者context-mode set research，切换时顺便改当前的 shell 提示符和几个环境变量。听起来很合理，我也觉得已经解决了问题——切换前敲一下，切换后敲一下，成本并不高。
真正坚持半天就发现不对劲：我切换项目的动作往往是被一个紧急请求打断的。上午还在写文档站，同事在群里问数据清洗的任务进度，我直接开终端开始跑脚本，根本没有动机去敲那条命令；等到 AI 工具继续按“文档站”上下文给我输出时，我才意识到自己又忘了切。一次两次还可以怪自己粗心，次数多了就明白一个事实：凡是需要人工额外记忆的维护动作，在忙碌状态下一定会被牺牲掉。手动模式切换方案天然不可持续。
所以第二版的重心完全不放在“怎么定义一个模式”上，而是转向另一个问题：有没有可能让工具根据行为自动判断当前上下文，把“切模式”这个动作从人身上挪开？这就是 context-mode 后来全部设计的地基。
1.2 重新定义 context-mode 的职责边界
动手之前，我先和一位朋友聊了一下这个想法，问他会不会觉得自动切模式很容易做得很“玄”。他的提醒很关键：如果把 context-mode 定位成一个“精准知道你在干什么”的智能助手，那期望值一开始就定错了；它应该做的是提供一个弱信号源，让别的工具拿过去做进一步判断。
这句话几乎决定了整个项目的样子。我最后把它收敛成三条边界：
- context-mode 只管“当前大概在哪个上下文里”，不负责生成具体答案。它不写代码、不总结文档、不决定工程方案，只输出一个带置信度的模式列表；
- 它必须能被单点消费。任何工具（编辑器、脚本、终端提示符、AI 辅助程序）都可以直接读取同一份当前模式，避免每个工具各自维护一份“上下文”；
- 它允许自己错，但在错的时候应该最后“不清不楚”而不是给一个确定的错误答案。模式分数接近时，宁可给 unknown。
这个边界确定后，后面所有实现都清爽了：我不需要写一个端到端的智能功能，只需要把“推测上下文”这件事做好，然后暴露一个简单的只读接口就行。很多人做这类工具死在半路，正是因为想顺手把“根据上下文做什么”也一起做了，导致问题规模瞬间膨胀。
1.3 为什么做成一个本地守护进程
其实我一度想过直接把 context-mode 逻辑塞进编辑器插件或者终端初始化脚本里。但实际列了下需求后发现，消费方不止一个：终端提示符要读，编辑器插件要读，定时任务要读，AI 辅助工具也要读。如果逻辑放在插件里，终端和脚本很难拿到；如果放在 shell 配置里，编辑器又不知道怎么调用。
所以最后做成一个常驻的本地小进程，自己负责采集信号、维护记忆、跑状态推导，对外只暴露一个本地接口，返回当前模式和置信度。所有需要上下文的工具统一找它要数据。这样做还有一个附带好处：状态是集中维护的，调试的时候只要盯一份日志就能看清整个推导链路。
技术上没有用任何花哨框架，标准库加一个线程池基本就够了。通信协议用最简单结构，本地只允许回环地址访问，再加一个固定的访问令牌防止局域网里的其他程序随便读状态。命令行的辅助工具和本地服务跑在同一个进程里，状态变更会以事件流方式写入日志文件，方便后续复现排查。
2. 上下文信号的收集：目录、进程、操作历史，哪个才是关键？
2.1 三路数据来源和它们各自的脾气
context-mode 的输入信号我最终采用了三路，彼此互补：
- 当前活动目录。这一路最可靠。通过读取进程树里终端或编辑器的当前工作目录，能比较稳地知道人在哪个项目里。它的缺点是粒度粗，一个项目下可能有写文档、写代码、查数据好几类任务，目录只能定位到“项目层”，不能再往下；
- 活跃进程信息。这一路噪声最大，但信息最及时。你刚打开某个数据分析终端，进程就立刻暴露了意图。问题是浏览器、即时通讯这类通用工具会疯狂干扰，必须做过滤；
- 近期编辑过的文件。这一路粒度最细，通常能反映你“正在处理什么具体内容”。但获取方式受系统限制，编辑器不开放接口时就拿不到。我一开始想读取全局最近文件列表，后来发现不同系统的实现差异很大，就改成了由编辑器插件主动上报。
三路信号各有各的偏向域，单独拿出来都不可靠，组合起来才有意义。我最后的设计是：以活动目录为骨架，进程信息为辅助，文件访问记录为细粒度修正。默认情况下目录决定“在哪个项目”，进程和文件只负责在项目内部进行微调；只有当目录信号缺失时，才会让进程信息顶上主导位置。
2.2 状态推导引擎：加权打分而不是玄学
状态推导我一开始想得很简单：看到什么目录就映射到什么模式。跑了半天就被现实教育了——一个人完全可能开着一堆终端，人在文档站的编辑器里，但最近五分钟在看数据清洗的代码。目录只能说明“我打开了项目”，不能说明“我正在做这个项目”。
因此改为加权打分方案。对每个候选模式，综合三路信号分别给分，再乘上各自的权重系数，最后归一化选出得分最高的模式作为当前上下文。权重不是一手测出来的，我先凭经验设初值，然后跑真实工作流，根据日志手工调整。
代码骨架大概是这个思路：
def compute_scores(observations, rules): # observations: dict, 包含目录、进程、文件访问等信号 # rules: 每个模式对应的匹配规则列表 scores = {} for mode, rule_group in rules.items(): total = 0.0 dir_prefix = rule_group.get("directory", "") if dir_prefix and observations.get("cwd", "").startswith(dir_prefix): total += rule_group["weight_directory"] for proc_name in rule_group.get("processes", []): if proc_name in observations.get("procs", []): total += rule_group["weight_process"] for file_suffix in rule_group.get("file_suffixes", []): if observations.get("last_file", "").endswith(file_suffix): total += rule_group["weight_file"] scores[mode] = total return scores实际用的版本比这个复杂得多，但核心就这么点东西。为什么不用模型？因为这类场景里“可解释”远比“精度高一点”重要。某次模式推错了，我能打开日志看出是“目录分给了项目 A、进程分给了项目 B”导致的，马上可以针对规则修，而不是面对一个说不清的黑盒。另一个原因是成本：跑本地的加权规则不需要数据准备和模型部署，改一条规则一分钟生效，迭代速度完全不是一个量级。
2.3 防抖动：不要让模式在十个候选里疯狂横跳
加权打分落地后的第一个大问题是抖动。原本我每三秒跑一次推导，日志里能看到一个典型场景：我在写文档，顺手打开浏览器查资料，不到一分钟模式就变成了 research；切回编辑器写两行字，又弹回 project-a；再切到浏览器，又跳成 research。模式来回弹，下游工具根本没法稳定使用。
解决方向有两个：一个是被动平滑，比如短时间内不重新推导；另一个是主动加粘滞，让当前模式在候选接近时保留优势。我两个都用了：
- 最小持续窗口：模式至少保持 90 秒，这个时间内的观测只累计，不切换；
- 粘滞分：当前模式在计算总分时额外乘以 1.6 的加成，只有别的候选超过这个加成后才会被打败；
- 切换冷却：每次切换后强制等待 10 秒，禁止连跳。
这三个措施叠加后，抖动基本消失。这个“当前状态天然占优、其他状态需要明显优势才能翻盘”的思路，类似现实中开会换话题也要有足够理由，否则大家默认接着上一个话题讲。后续调参的核心也在这里：如果觉得切换太迟钝，先降粘滞系数；如果还在抖，再拉长最小持续窗口，不要一上来全面放宽。
3. 用“记忆窗口”补上单帧感知的短板
3.1 只看当前一眼不够，事件发生顺序很重要
第二版只基于“当前快照”做决策，后来在一个场景上露了馅：我在清理完项目 A 的一批文件后，顺手打开终端进入项目 B 跑测试，但编辑器里还开着项目 A 的主文件。当前目录指向项目 B，编辑器进程却暴露项目 A 的文件路径，两路信号打架，结果就是模式在 A 和 B 之间来回飘，哪怕加了防抖也只是让切换慢了半拍。
回头看这个例子的本质：人做判断时依赖的不是“此刻的目录”，而是“最近这段时间我到底在干什么”，也就是一段带时序的上下文。如果没有记忆窗口，只有当前帧，那么任何“正在过渡”的场景都会变成噪声。第三个迭代开始加入按时间衰减的记忆窗口。
3.2 时效衰减的滑动窗口实现
记忆窗口的做法是：给每个观测或事件设置一个初始权重和发生时间，权重随着时间的推移按指数衰减，越早的事件对当前判断的影响越小。选指数衰减不是因为深度，而是它写起来简单，调一个半衰期参数就能控制“多久以前的后续影响只剩一半”。
import time HALF_LIFE = 1800 # 30分钟半衰期，单位秒 WINDOW_SECONDS = 3600 # 只保留1小时内的记忆 def decayed_weight(initial_weight, event_time): age = time.time() - event_time if age < 0: age = 0 if age > WINDOW_SECONDS: return 0.0 return initial_weight * (0.5 ** (age / HALF_LIFE))整个记忆窗口的实现就是维护一张事件表，每次收集到新信号就插入一条记录，查询当前模式时把所有未过期记录按衰减权重累加，连同快照信号一起送入打分引擎。衰减带来的效果很符合直觉：刚才做的事权重高，半小时前做的事还有余威，两小时前的记录基本归零。
这个设计也解决了“编辑器还开着旧文件”的问题。编辑器加入一条文件访问事件后，权重会随时间自然下降，而项目 B 里持续出现的终端活动不断叠加新事件，最后 B 的累计分自然超过 A。我甚至在日志里观察到，完全不需要额外写“清理过期状态”的代码，衰减本身就完成了淘汰。
3.3 关键事件注入：提交版本、测试失败、构建输出
普通的观测是“你经过了这个目录”，还有一种信号更值钱，就是关键事件，比如：你刚完成一次版本提交、某条测试刚刚失败、某个构建任务刚刚结束。这些事件虽然也是历史记录的一种，但对当前任务的指向性比“当前目录”强太多。
我把关键事件和普通观测分开管理，普通观测进滑动窗口，关键事件除了进滑动窗口外，还会额外提升对应模式的置信度，幅度比普通信号大几倍。原因很容易理解：提交代码说明你手头正在完成这个项目的一个里程碑；测试连续失败两次，说明你很可能正在调试测试相关的问题，这时候把模式从“写文档”强行纠正到“调试”是对的。
常用规则大致是这样：
| 事件 | 影响方向 | 注入权重 | 备注 |
|---|---|---|---|
| 版本提交成功 | 提升当前项目模式 | 0.30 | 对“提交”项目最有效 |
| 测试失败 | 提升调试相关模式 | 0.25 | 每个小时内可以累计 |
| 构建完成 | 提升开发模式 | 0.20 | 单独一次影响有限 |
| 文件批量重命名/移动 | 提示整理任务 | 0.15 | 需要配合命令前缀判断 |
| 长时间无活动 | 降低所有模式置信度 | 负向 | 防止把离开后的状态当活跃状态 |
事件注入的权重表也是用日志试出来的。一开始我把提交事件的权重调到 0.6，结果发现只要随便提交一次，模式就死锁在那个项目上，哪怕后面人已经在另一个项目里干活了。后来降到 0.3，配合衰减，效果才正常。这个教训我的感受很深：关键事件不该“一锤定音”，它应该像开会时有人拍了一下桌子，大家会注意他，但不会因此让整场会议的主题直接改变。
4. 实测排坑：context-mode 在真实工作流中翻车的三个瞬间
4.1 坑一：两个项目窗口并排，焦点来回切导致模式横跳
这个坑发生在自认为已经稳定的版本上。某天下午我在两个项目间来回核对接口参数，一会儿切到编辑器左窗口，一会儿切到终端右窗口，每切一次就触发一次进程变化。日志里看到模式在 project-a 和 project-b 之间来回切换了十几次，有的切换间隔只有几百毫秒，完全打破了预设的最小窗口——后来排查发现是最小窗口的检查逻辑只限制“模式输出变更”，没有限制“内部状态更新”，内部信号一直在实时变化并重新算分，只是没有暴露成模式切换而已。这个状态本身没问题，但在某些情况下内部状态和输出模式会产生明显的滞后感。
修复方式是把防抖逻辑前移：新增外部信号不再立刻改写推导状态，而是先进入一个 pending 暂存区，只有连续观测到新信号持续超过指定秒数才让它参与打分。这样一个窗口焦点闪烁就不会导致整体状态重新洗牌了。验证手段也很简单：把同一段工作流重放了一遍，观察模式输出从头到尾只切换了三次，而且这三次都对应真正的大任务转移。
4.2 坑二：进程采集被“同名进程前缀”误导
第二个坑在进程匹配环节。我最初用简单的子串匹配判断进程属于哪个模式，某天遇到一个叫 data 的进程和一个叫 datahelper 的进程同时存在。按前缀匹配，datahelper 会被当成 data 的同类，进而被算进数据分析模式的得分里，直接导致模式偏离实际。
排查过程依靠日志格式化重放。让我把每个进程的匹配命中和得分来源都打到日志里，很快就看到 datahelper 被错误归类。这不算难查，真正让我警惕的是这种错误很隐蔽：如果两个进程名只是前缀相同，日常根本不会注意，只有模式推导出现偏差后回看日志才能发现。
修复很简单：进程匹配不再用简单的前缀包含，改为先按完整命令路径精确匹配，没有精确匹配时才允许只匹配进程名且同时要求工作目录一致。同时给匹配逻辑加上边界检查，禁止“一个进程名是另一个进程名的前缀”时自动归类。这种看起来细枝末节的规则，恰恰是这类本地工具稳定性的大头。
4.3 坑三：守护进程被系统挂起导致输出过期上下文
第三个坑更隐蔽。某天中午我离开工位，系统进入休眠，回来之后唤醒电脑开始干活。工具读取 context-mode 的输出，直接按照休眠前记录的模式行动。问题在于，休眠前的模式是“在文档站写说明”，而我已经切换到数据清洗任务，守护进程却因为休眠期间的定时器没触发而一直没有更新状态。
排查时看到的现象是：状态文件的修改时间停留在十分钟前，而我的终端活动早就变了。根本原因不是推导算法错，而是信号采集循环被系统挂起后没有“补采补救”机制。解决思路有两层：一是给守护进程加心跳机制，每次信号采集时都会检查上一次采集时间，如果发现间隔异常就强制进行一轮全量重扫描；二是给输出状态加时间戳和版本号，任何一方在读取时发现状态过期超过五分钟，就应该拿到一个 stale 标记而不是继续用旧值。
这个坑给我最大的教训是：本地工具的状态新鲜度，和正确性同等重要。一个五秒钟更新一次的工具，系统休眠五分钟后恢复，绝不能直接拿旧状态当新状态用，必须有显式的过期概念。我还在状态返回里加了一个 confidence_stale 字段，让下游工具明确知道这个上下文已经不可信了。
5. 给想直接抄作业的人：配置、参数和边界
5.1 一份可落地的配置文件示例
讲了不少原理和坑，最后给一份可以直接照着改的配置。我的配置文件采用最简单的文本格式，一个模式一个块，字段含义注释写在里面：
modes: doc-site: display: "文档站" directory_prefix: "/work/doc-site" processes: ["code-doc", "markdown-server"] file_suffixes: [".md"] weight_directory: 1.0 weight_process: 0.6 weight_file: 0.3 >
