1. 为什么需要 context-mode从手动切换走向规则切换1.1 配置切换的痛点可能只有折腾过的人才懂每天要在三四种工作场景里来回切换白天在项目仓库里写业务代码下午翻开几个开源项目的源码做研究晚上可能还要写自己的小工具或者博客。每换一个场景终端要换主题、环境变量要改、Git 用户要换成对应的账号甚至连一些常用别名都不一样。以前我的做法是全手工开一个终端export 一堆环境变量再手动 source 某个脚本偶尔切换忘了立马就栽跟头。最惨的是一次 Git 提交用户名写错了改历史记录改到怀疑人生。这些操作本身不难难的是“记得做”以及“做得对”。人不是机器在上下文快速切换的时候特别容易忽略细节。context-mode 这个思路解决的就是这个问题把“当前处于什么场景”交给电脑去判断让电脑替你完成一系列切换动作而不是每次靠脑子记。第一次折腾完省下来的时间远超我的预期所以这篇想好好复盘一下整个设计过程和踩过的坑。1.2 context-mode 到底在做什么一句话解释context-mode 是一种“上下文感知的配置切换机制”。它把传统意义上分散在.bashrc、.zshrc、IDE 设置、环境变量脚本里的各种配置统一成由“上下文规则”驱动的自动化行为。你可以把它理解成手机上的“勿扰模式”或者游戏本上的“性能模式”——系统根据你当前的状态自动套用一套预设方案。我做的这个小工具核心概念只有三个上下文context、规则when和动作action。上下文是离散的场景比如“工作项目”“学习项目”“日常写作”规则用来描述场景的特征比如当前目录路径、Git 分支、时间范围动作则是进入或离开场景时要做的事情比如设置环境变量、切换终端主题、打印提示信息。整篇文章后面的设计、代码、实操都是围绕这三个概念展开的。2. 整体设计思路如何定义“上下文”2.1 上下文的信号源从哪里判断你正在做什么要自动判断场景就得收集“信号”。我实际用到的信号源可以分成四类路径信号最常用当前 shell 的工作目录在哪基本就能推断出你在做什么。比如~/code/order-service大概率是工作项目~/learning/rust-book大概率是学习。Git 信号当前目录是否在 Git 仓库里、当前分支名、仓库的 remote 地址。这个比路径更稳因为仓库搬了位置或者改名之后也能正确识别。环境信号已存在的环境变量、当前用户名、系统平台。适合做全局默认值或者兜底策略。外部信号时间比如工作日晚上十点后自动切到“学习模式”、网络连通性比如能否 ping 通公司内网网关、正在运行的进程比如检测到某个编辑器或编译任务则切到对应模式。每条规则不需要具备全部信号挑几个组合就行。设计上我坚持一个原则信号越容易获取越好越稳定越好。路径比分支稳定分支比时间稳定所以路径前缀作为默认推荐其他都当作增强条件。2.2 配置文件长什么样YAML 驱动的规则引擎配置文件采用 YAML放在~/.config/context-mode/config.yaml下面整个配置其实就是一个以 context 为单位的数组。下面是我早期的一份示例结构简单直白contexts: - name: office when: pwd_prefix: /home/me/work env: PROJECT_ENV: prod GIT_AUTHOR_NAME: me-work enter: - echo enter office exit: - echo exit office - name: study when: pwd_prefix: /home/me/learning env: PROJECT_ENV: dev GIT_AUTHOR_NAME: me-personal enter: - echo enter study exit: - echo exit study这份配置表达的含义非常简单如果当前路径前缀是/home/me/work就进入office模式设置两个环境变量并打印提示当路径离开这个前缀时执行 exit 钩子。这里我故意没有引入复杂的运算和动态表达式因为规则文件是要长期维护的东西越朴素越不容易出错。2.3 规则合并与冲突的处理逻辑实际用起来一定会遇到多个上下文同时命中的场景。比如路径在~/work下时间又正好是晚上十点而另一条规则写着“晚上十点后一律切到自习模式”。这种冲突怎么处理我的方案是优先级显式化每条规则可以写priority: 0~100数字大的优先。如果数字相同按声明顺序取第一条。还有一点经验是不要试图做太“智能”的合并。比如“把两条规则的环境变量 union 到一起”一旦产生重复键用户完全不知道哪条生效。宁可规则匹配成功就整体生效匹配失败就整体跳过也不要做局部覆盖。人眼很难 debug 合并出来的结果环境变量被静默覆盖的问题排查成本高到让人崩溃。2.4 生命周期钩子进入与退出同样重要多数同类工具只处理“进入”这个方向忽略“退出”。实际环境里退出同样关键你离开了工作目录可PROJECT_ENVprod还残留在当前 shell 里下一个项目直接被污染部署配置跑到开发环境这种源头污染非常隐蔽。所以 context-mode 必须支持enter和exit两套钩子切换时先执行旧上下文的 exit再执行新上下文的 enter顺序绝对不能反。这个设计类似状态机上下文切换不是简单地“赋值”而是一组有序的动作序列。我在实现里给动作序列增加了超时保护任何钩子执行超过 3 秒就报警并把这次切换记为失败避免一个卡死的命令堵住所有后续操作。3. 核心实现一个 Python 版 context-mode CLI3.1 实现语言与模块划分实现语言选了 Python理由很简单标准库够用YAML、文件读写、子进程调用都是成熟方案而且 Linux 和 macOS 基本都能直接跑。如果你嫌弃 Python 启动慢换成 Go 重写完全没问题逻辑不变。作为日常 CLIPython 大约 50ms 的启动耗时在可接受范围内没必要第一版就上编译型语言。模块划分上我拆成了三个文件loader.py负责读取配置、解析规则、校验配置合法性。matcher.py负责收集当前信号、执行规则匹配。applier.py负责执行 enter/exit 钩子、更新环境快照文件。这样划分的好处是测试方便后续想加新的信号源不用动匹配和应用逻辑。3.2 配置加载与校验的细节loader 的要点有两个一是 YAML 解析必须容错二是配置校验一定要在真正执行前完成。我吃过一次亏写规则时漏了个缩进整个配置被 YAML 解析成了空对象工具完全不报错结果我所有自动切换全部失效排查一个多小时才发现是语法问题。所以 loader 里用yaml.safe_load并立刻校验每个 context 是否包含name和when字段。这里贴一段简化版 loader 的核心逻辑import os import yaml CONFIG_PATH os.path.expanduser(~/.config/context-mode/config.yaml) def load_config(pathCONFIG_PATH): if not os.path.exists(path): return [] with open(path, r, encodingutf-8) as f: data yaml.safe_load(f) or {} contexts data.get(contexts, []) for c in contexts: if name not in c or when not in c: raise ValueError(finvalid context: {c}) return contexts校验这一步非常值得做。任何一条规则缺少必填字段我宁愿让程序立刻崩溃也不希望它悄悄跳过。静默失败对自动化工具来说是致命的用户完全没有感知只能凭空猜哪里出了问题。3.3 信号采集与匹配逻辑matcher 的职责是回答一个问题当前到底属于哪个 context。实现上就是先收集信号再按优先级从高到低逐条匹配。关键路径的伪代码如下def get_signals(): signals {} signals[pwd] os.path.realpath(os.getcwd()) # 这里可以继续补充 git 分支、时间等信号 return signals def detect_context(contexts): current get_signals() ranked sorted(contexts, keylambda x: x.get(priority, 0), reverseTrue) for ctx in ranked: when ctx.get(when, {}) pwd_prefix when.get(pwd_prefix) if pwd_prefix and not current[pwd].startswith(pwd_prefix): continue # 其他条件同理 return ctx[name] return None这个版本只支持“前缀匹配”没有用正则表达式。原因是正则让配置文件变得极难维护而大家实际配置时九成需求就是路径前缀和分支名。去掉正则反而逼着用户把规则写清楚配置文件的可读性会好很多。等你真正遇到需要正则的场景再扩展也不迟。3.4 应用与切换环境快照和钩子执行applier 需要处理的问题比较琐碎进入新上下文时设置哪些环境变量、执行哪些命令退出时清理哪些环境变量、执行哪些命令。我的做法是维护一个“当前上下文状态文件”放在~/.cache/context-mode/current.yml里面记录当前 context 名称以及它设置过的环境变量列表。每次切换时先读旧状态把旧环境变量恢复成默认值再应用新 context 的环境变量。钩子执行用subprocess.run超时 3 秒。钩子命令统一用sh -c执行而不是直接拼接到父 shell 里目的是让每条命令独立、可追溯避免互相干扰。import subprocess def run_hooks(hooks): for cmd in hooks or []: try: subprocess.run(cmd, shellTrue, checkTrue, timeout3) except subprocess.TimeoutExpired: print(fhook timeout: {cmd})3.5 与 Shell 集成让切换变得“无感”CLI 本身只能手动执行真正要“自动”还得在 shell 里挂一个钩子。我的做法是在.zshrc中加一个precmd函数每次出现新提示符之前做一次极快的路径前缀检查只有发现路径前缀和当前状态文件的 context 前缀不一致时才真正调用 CLI 做全量匹配。有个很重要的经验不要在每次回车时都跑完整的 Python 流程那样终端会明显变卡。正确思路是“轻量判断在前重量逻辑在后”——shell 侧的路径检查几乎是零成本的只有确定需要切换才启动 Python 进程。4. 实操过程从零搭建一个可用的 context-mode4.1 目录结构与安装我最后部署的目录结构是这样的~/.config/context-mode/ config.yaml # 规则配置 ~/.local/bin/context-mode # CLI 主程序 ~/.cache/context-mode/ current.yml # 当前状态快照CLI 本身做成单文件放在~/.local/bin并加入 PATH。Python 依赖只有一个 PyYAML安装命令是pip install pyyaml。如果不想依赖第三方库也可以用config.json标准库json模块直接解析只是可读性差一些。我个人强烈推荐 YAML规则文件的可读性直接决定了你后期维护的意愿。4.2 一套真实的配置文件示例下面这套配置是从实际使用中提炼出来的覆盖了工作、学习、写博客三种场景contexts: - name: dev-backend priority: 100 when: pwd_prefix: /Users/me/code/backend git_branch: main env: APP_ENV: staging LOG_LEVEL: info enter: - echo [context-mode] enter dev-backend exit: - echo [context-mode] exit dev-backend - name: blog priority: 80 when: pwd_prefix: /Users/me/blog env: APP_ENV: local LOG_LEVEL: debug enter: - echo [context-mode] enter blog exit: - echo [context-mode] exit blogdev-backend的优先级是 100blog是 80。假如某天我把博客目录移到了/Users/me/code/backend下面路径会同时命中两条规则但根据优先级dev-backend会胜出。这种显式的优先级配置比“默认第一条”更容易被理解适合规则逐渐变多之后的维护场景。4.3 命令行运行效果与调试输出运行context-mode sync之后控制台会输出类似下面的信息[context-mode] current context: dev-backend [context-mode] env changed: APP_ENVstaging [context-mode] env changed: LOG_LEVELinfo [context-mode] hook: [enter dev-backend]为了排查方便我还加了--verbose参数可以打印信号采集到的原始值以及每条规则匹配成功或失败的原因。比如“当前 pwd 是 /Users/me/blog规则 dev-backend 需要前缀 /Users/me/code/backend不匹配”。这种调试输出在初期调规则的时候价值极高能直接告诉你到底哪一步断了。4.4 自动触发的三种接入方式我实际试过三种接入方式各有各的适用场景。第一种是 Zsh 的precmd钩子也是最推荐的。它能保证每次命令执行完、出现新提示符之前检查上下文体验最无缝。配合前面说的“shell 侧前缀快速判断”性能影响几乎为零。第二种是手动运行context-mode switch name适合场景特征不明显、必须人工介入的情况。比如你临时要改别人的项目路径本来就比较乱但你就是想套用工作模式这种时候手动切换最直接。第三种是文件监听或者编辑器插件触发适合场景非常明确的场景。比如打开某个 VS Code 工作区时自动跑一条context-mode sync。联动性最好但每换一个编辑器都得维护相应的插件成本略高。5. 常见问题与排查技巧实录5.1 规则没匹配上怎么办最典型的症状是进入某个目录预期会切到对应 context结果状态文件里还写着上一个 context。九成原因在pwd_prefix写错了可能是路径末尾多了一个空格或者大小写不一致。用context-mode --verbose一看信号值立刻就能明白。另一个容易踩的坑是软链接。os.getcwd()拿到的是逻辑路径还是物理路径取决于 shell 的处理方式。我后来统一改用os.path.realpath(os.getcwd())把路径转成真实路径符号链接导致的匹配失效问题就彻底消失了。5.2 环境变量改了却看不到效果在纯 CLI 里程序设置环境变量只能影响子进程无法改变当前 shell 的环境。很多第一次接触这个思路的人会在这里卡很久context-mode sync跑完了终端里echo $APP_ENV还是旧值。解决办法是让 CLI 只负责计算目标环境变量并写入状态文件同时生成一段可被 source 的 shell 脚本由 shell 函数去 source 它。也就是说“真正改变当前 shell 环境”这一步必须发生在父 shell 里代码只是计算和输出结果。这个道理理解了整个集成链路就顺了。5.3 钩子命令总是超时如果 enter 钩子里写了sleep 100切换动作自然会卡住。我的建议是所有钩子都写短命令不要在钩子里启动长驻进程也不要等待用户输入。如果确实需要在进入 context 后启动某个服务把启动命令放到后台运行并加上日志重定向比如nohup ./start.sh /tmp/start.log 21 这样钩子能立即返回服务也在后台正常跑日志还能留作排查依据。5.4 终端卡顿性能怎么优化把完整的 Python 匹配逻辑放在每次回车时执行终端一定会卡。优化要点放在 shell 侧先把配置里所有 context 做一个“前缀表”比如code/backend对应dev-backend、blog对应blog然后 shell 函数里直接比较当前路径前缀是否命中任何一个条目没有命中立刻返回不进 Python。实际跑下来即使有几十条规则shell 侧的字符串比较也在微秒级别完全无感。只有真正发生上下文变化时才会付出一次 Python 启动的代价这是最划算的取舍。6. 进阶玩法从终端配置到更广的场景6.1 把 context-mode 扩展到编辑器与桌面应用context-mode 的“上下文判定”能力一旦抽象出来并不局限于终端环境。比如 VS Code 的工作区本身就是一种上下文但它默认是孤立的不会联动终端环境。你可以通过编辑器插件在打开工作区时调用一次context-mode sync反过来也可以用 enter 钩子在终端启动关联的编辑器。两个方向打通之后整个开发工作流会顺滑很多。6.2 基于时间的规则做一个“深夜免打扰”场景我后来试过一个很有意思的玩法增加时间条件每天晚上 11 点到早上 7 点之间无论当前在哪个目录都把终端主题调暗、把LOG_LEVEL调成warn、自动关闭桌面通知。这等于把 context-mode 从一个“目录切换工具”升级成了“个人环境管家”。不过要记住时间信号不可控所以这类规则的优先级应该放低避免覆盖掉更明确的目录信号。6.3 规则配置是核心资产记得纳入版本管理配置文件是整个 context-mode 的核心资产一定要纳入版本管理。我自己是单独建了一个私有 git 仓库每次调整规则之后提交一次。这样哪天把规则改坏了还能优雅回退。运行时产生的状态文件则不应该入库它只是临时快照。另外每隔一段时间可以跑一次context-mode --dump把全部规则和当前信号值导出检查一遍当作健康巡检。7. 一点实践经验与后续思路说到最后我个人折腾 context-mode 最深的一点体会是这个工具本身技术上毫无难度真正的难点在于把场景规则梳理清楚。刚开始我也写了一大堆复杂规则正则、多条件组合、跨规则引用全都上了结果两周后再看自己都看不懂某条规则当初为什么要这么写。后来退回到最简单的“路径前缀 优先级 enter/exit 钩子”反而用得最顺手。自动化机制最怕的是不可解释一个正则表达式写进去容易半年后你要为它付出十倍的理解成本。如果你正打算做类似的东西我建议第一版只支持路径前缀匹配先把环境变量切换和 enter/exit 钩子跑通再慢慢加入 Git 分支、时间窗口这些信号源。多信号源是“锦上添花”不是“雪中送炭”过早引入只会增加调试负担。根据我自己的使用习惯到现在为止最有用的还是路径前缀和 Git 分支这两个信号其他基本都处于“偶尔看一眼”的状态。context-mode 后续能扩展的方向还挺多比如通过 Unix socket 跟桌面端通信、输出 JSON 供其他程序调用、把钩子改成可插拔插件系统等等。但核心思路始终是一样的让计算机感知环境替人把重复的场景切换自动化。这个方向值得每一个经常切换上下文的人认真试试。
