你有没有过这种经历：上午还在写技术文档，下午就要切到另一个项目的代码环境，第二天的选题会又需要一套完全不同的资料目录和提示词。我之前的做法是每次手动改环境变量、切路径、换别名，偶尔还会因为漏了一个export导致脚本跑错，一查就是半小时。后来我干脆给自己写了个叫context-mode的轻量级工具，解决的问题很简单：用一个命令把整套工作环境切到目标状态，想切回来也一条命令。这篇文章就聊聊我为什么做这个东西、核心设计怎么定的、实现时踩了哪些坑，以及它到底适合什么人用。
1. 痛定思痛：为什么我非要做一个"上下文模式"工具
1.1 多任务并行的混乱日常
我手头同时会有写文档、做开发、处理运维反馈这三类事情，每类事情需要的终端环境差异很大。写文档时希望打开某个资料目录、加载几个写作相关的别名、提示符上标注当前项目；做开发时要切到代码仓库、设置调试用的环境变量；处理运维反馈则要连上一堆远程主机、加载运维脚本路径。
以前是怎么处理的？打开终端后手动cd到对应目录，手动export几个变量，再alias几个命令。这套组合拳每个上午重复三四次，每次都要敲十几行命令。更麻烦的是，如果同时开两个终端，很容易搞混哪个终端是哪个项目，在写文档的终端里执行了代码编译命令，结果 PATH 不对，报错后又要从头排查。
我尝试过写死到.bashrc里，结果更痛苦，因为三套配置互相污染，写文档时多了一个开发用的环境变量，某些文本处理命令的行为就变了。这种状态切换的痛点，本质上不是“缺变量”，而是“缺一个能整体切换上下文的机制”。
1.2 上下文模式跟普通配置管理的区别
普通配置文件解决的是“静态参数”，比如settings.json里把端口、路径写死。可实际工作中需要的是“一套完整状态”：当前目录、PATH、环境变量、别名、提示符，甚至进入和退出时的钩子动作。
我用一个生活里的类比来想这件事：手机上的“驾驶模式”“睡眠模式”不是一个开关控制音量，而是一套组合动作，比如驾驶模式打开导航、连接车载蓝牙、开启免打扰。上下文模式就是终端里的“场景模式”，一条命令执行后，整个 Shell 的状态都变成你预先定义好的样子。
这也是我不想用 Docker 或者虚拟机的另一个原因——它们太重了，也不适合解决“上下文记忆”问题。我要的是一个能在当前终端里立即生效、立即失效的轻量方案。
2. context-mode 的核心设计与配置格式
2.1 一个上下文到底包含什么
我最初设想一个上下文包四类内容：环境变量、路径、别名、提示符。后来发现还需要钩子脚本，用来处理“进入时启动服务”和“退出时关掉服务”这类动作。
环境变量和路径是最基础的，比如进入写作模式要设PROJECT_STYLE=tech_blog，进入开发模式要把$HOME/work/code/bin加到 PATH。别名同样重要，例如写文档时gst代表“快速查看今日进度”，开发时gst代表“git status”，两者语义完全不同。
提示符是对抗混乱的关键武器。上下文切换后，终端提示符会变成[docs]或[code]，这样哪怕同时开三个终端，我只看提示符就知道当前处于什么状态，不会再出现“在写作终端里敲编译命令”的尴尬。
钩子脚本则是进阶能力。比如进入运维上下文时自动加载最新的运维脚本列表，退出时自动清空临时生成的认证令牌。这些动作如果用命令行手动做，十有八九会忘。
2.2 配置目录结构与加载优先级
context-mode 的配置全部放在~/.context-mode/contexts/目录下，每个上下文一个子目录，里面至少有两个文件：enter.sh定义进入时的动作，exit.sh定义退出时的动作，另外加一个可选的metadata.conf用来写描述信息和版本号。
~/.context-mode/ contexts/ docs/ enter.sh exit.sh metadata.conf code/ enter.sh exit.sh default.env加载优先级上，我做了两层：第一层是全局default.env，所有上下文都会先加载它，通常放一些中立的配置，比如EDITOR、LANG。第二层是上下文自己的enter.sh，里面可以覆盖全局变量。这样做的好处是，公共配置只写一遍，各上下文只需要维护差异项。
2.3 切换命令的语义：cm use <context>
我设计了一个cm函数作为入口，核心用法只有两个：
cm use <context>：切换到指定上下文cm exit：退出当前上下文，恢复切换前的状态
这两个命令背后是“单一模式”逻辑——同一时间只能处在一种上下文里。虽然也可以设计成栈式嵌套（进入 A 再进入 B，退出 B 回到 A），但经过几天试用后我放弃了嵌套。原因很简单：嵌套的“祖先状态”很难可视化，也容易忘记自己在第几层。我需要的不是分层切换，而是像遥控器一样，直接选一个场景频道，不需要管之前的频道。
3. 实现细节与爬坑实录
3.1 如何在 Shell 里安全地切换环境
第一版工具我犯了一个很经典的错误：把切换逻辑写成了一个独立脚本文件，在脚本里通过cd和export设置环境。发现脚本运行结束后，终端里的当前目录和环境变量完全没变。
这不是脚本写错，而是 Unix 进程模型决定的：子进程里的环境变量修改不会影响父进程。想要改变当前 Shell 的状态，必须用source命令加载脚本，或者把逻辑封装成 Shell 函数。所以最终我把cm做成了一个函数，定义在.bashrc或.zshrc里，函数内部用source去加载上下文目录下的enter.sh。
这里有个安全细节：既然要执行任意上下文里的脚本，就不能直接无脑source，万一脚本里有语法错误，可能会导致当前终端会话崩溃。我的做法是在source之前先跑一次bash -n enter.sh做语法检查，只有通过检查才会真正加载。
3.2 环境变量残留与清理策略
单靠source还不够，因为切换上下文后，旧的上下文变量可能还留在环境里。比如从code上下文切到docs，enter.sh里没有取消CODE_ROOT这个变量，但code上下文之前设置了它，于是docs环境里莫名其妙多了一个CODE_ROOT。
我做了一个快照机制：每次cm use成功之前，先把当前所有以项目自定义前缀开头的环境变量（比如CM_、CTX_开头的）记录到一个临时文件里。切换进新的上下文后，如果发现新上下文没有定义某个旧变量，就自动unset。退出时更简单，直接按快照恢复。
这个机制有几个边界条件需要注意。如果上下文脚本里修改的是PATH这种公共变量，不能整体unset，否则系统命令都找不到了。所以我在恢复PATH时不是覆盖整个值，而是把快照里的PATH完整替换回去，因为PATH本来就是上下文管理核心的一部分。
还要处理“忘了退出”的问题。如果我打开一个新终端，直接cm use docs，此时没有上下文快照，退出时会发现记录文件不存在。这种情况我就让cm exit打印一句提示，然后什么都不做，避免报错打断工作流。
3.3 与现有环境的冲突处理
实际使用中最头疼的还不是自管理的变量，而是和系统已有的配置冲突。我遇到过两个具体的坑，都值得拿出来说。
第一个坑是PATH重复累积。在enter.sh里写export PATH="/some/bin:$PATH"，每进入一次上下文就多一遍前缀，退出后再进入又加一次。虽然不影响功能，但echo $PATH会越来越长，看着都烦。后来我在 enter 脚本里加了一个防卫逻辑：先用case ":$PATH:" in *":/some/bin:"*) ;; *) export PATH="/some/bin:$PATH" ;; esac判断是否已经包含，包含就不重复添加。
第二个坑是别名覆盖。某天我发现在我自己的docs上下文里定义了alias ll='ls -lh'，但全局.bashrc里也定义了同名别名，导致进入上下文后ll的行为没变。排查后发现是因为source enter.sh执行的顺序在.bashrc之后，理论上应该覆盖成功，但我在enter.sh里用了alias ll="..."，在非交互式 Shell 里别名默认不展开，所以没有生效。解决方法是明确使用shopt -s expand_aliases开启别名展开，并且在加载上下文后强制hash -r刷新命令缓存。
3.4 测试方法：模拟一次完整的切换
为了让这个工具不炸，我给它写了一套极简的验证流程。在干净的临时目录里构建两个测试上下文：test-a和test-b，各自定义三个变量和两个别名。然后在一台新开的终端里反复执行：
cm use test-a- 检查变量是否为
test-a的值 cm use test-b- 检查
test-a的变量是否被清理，test-b的变量是否生效 cm exit- 检查环境是否回到初始状态
我还把PS1变化也纳入测试，因为提示符是“状态可视化”的第一道关。这些测试我用脚本封装成了test_context_mode.sh，每次改动核心逻辑后跑一遍，五分钟就能全部跑完。有了自动化测试，后面我再改配置、加功能的时候，心里有底多了。
4. 实测收益与适合的人群
4.1 一个典型的工作日：三模态切换
我用一个实际例子来说明收益。早上九点，我打开终端，首先cm use docs，这时路径自动进入文档目录，提示符变成[docs]，并且notes命令被别名到了文档笔记文件夹。我在这个状态下写了两个小时的方案稿。
十一点切去开发，执行cm use code。文档上下文的环境变量被清掉，路径跳转到代码仓库，提示符变成[code]，便捷命令dbg被绑定为带调试参数的启动命令。我改了一会儿代码。
下午有运维会议，我又cm use ops。此时PATH加入了运维脚本目录，提示符变成[ops]，另外我设置了一个专属别名hosts='cat ~/.context-mode/data/hosts.txt'，快速查看服务器清单。
整个过程中没有手动export过一次，也没有cd过几次，因为enter.sh里已经写好了cd动作。就算中途被叫走去开其他事，回来只看一眼提示符就知道自己正在做什么，这个“零成本状态回忆”是最大收益。
4.2 不适合用 context-mode 的场景
并不是所有场景都适合这套东西。我总结了三种不建议硬套的用法：
第一，如果你长期只在一个项目里工作，上下文切换频率极低，那没必要引入额外的配置目录和加载逻辑，直接在.bashrc里写死反而更省心。
第二，如果你的环境切换需要隔离依赖，比如两个项目的 Python 包版本冲突，这已经超出环境变量管理范畴，应该用专门的隔离工具，context-mode 只管“状态”，不管“依赖隔离”。
第三，如果你的团队有多个人合作，共享上下文配置时容易产生“哪个版本覆盖哪个版本”的分歧。我目前的建议是：上下文配置可以纳入版本管理，每个人拉下来后复制成个人覆盖文件（比如~/.context-mode/contexts/code/enter.local.sh），全局配置只放不敏感的环境变量和目录设置，避免互相踩脚。
4.3 可扩展的三个方向
这个工具虽然叫 context-mode，但扩展空间其实不小，我个人正在考虑三个方向：
第一个方向是自动切换。根据当前所在目录自动推断该用哪个上下文，例如在~/work/docs下打开终端就自动cm use docs。实现思路是在 Shell 的 PROMPT_COMMAND 钩子里做轻量级判断，但要注意性能，不能每次敲命令都去扫目录。
第二个方向是可视化面板。把所有上下文列成一个菜单，用方向键选择切换。这个适合不熟命令行的人，不过优先级不高。
第三个方向是结合 AI 写作工具。把不同的“写作风格模板”也看成上下文，进入某个上下文后，自动加载对应的提示词前缀和语气设定，让 AI 出来的内容风格更一致。我已经在部分场景里试验过，效果不错，可能会在后续单独写一篇分享。
5. 常见问题与排查手册
5.1 切换后某些命令还是老样子
这种情况十有八九是别名或函数的问题。我遇到过git这个命令被全局函数包了一层，导致上下文里定义的别名不生效。排查思路是先确认上下文是否正确加载，可以用cm status查看当前上下文和最近加载时间；再检查命令的真实位置，用type git看它是函数、别名还是外部命令。
如果type显示为函数，而你期望的是别名，需要在enter.sh里对这个函数做 unset，或者用unalias。函数和别名的优先级关系很容易坑人，我的经验是：在上下文里尽量少跟全局函数较劲，要么约定全局函数统一不定义某类命令，要么在 enter 脚本里显式处理。
5.2 退出后遗留了临时变量
如果你发现cm exit后环境里还有一个/tmp/xxx变量，多半是因为exit.sh里没有清理干净。我在快照恢复逻辑里做了通配匹配，但前提是变量名前缀一致。
一个容易忽略的点是：如果上下文脚本里创建了文件，比如临时目录或锁文件，这不算环境变量，快照恢复不会处理。所以我的约定是：先创建临时文件的一律在exit.sh里加一句rm -f /tmp/xxx，不能指望自动清理。
5.3 切换时提示 "enter.sh not found"
这个提示大概率是元数据里上下文名写错了。metadata.conf里记录的context_name与目录名不一致时，我会特意打印一条警告。更常见的情况是你在~/.context-mode/contexts/下建了子目录但没有放enter.sh，比如只放了一个README.md。解决方式很简单：要么补上enter.sh，要么在配置里标注为“super-context”，这样工具会跳过它。
6. 一点后续想法
我在实际使用中发现，context-mode 最大的价值不是“切换环境”，而是“降低切换的认知成本”。以前我切换任务是靠大脑记住“现在该做什么”，现在我把这套状态外置到了配置里，大脑只需要说“我要做文档”，剩下的交给命令。
最后分享一个小技巧：把cm use绑定为终端快捷键。比如我在终端里按Ctrl+o弹出一个上下文列表，配合模糊搜索，基本两秒就能切到目标状态。这个小改动让我用它的频率直接翻了一倍。如果你也有类似的切换烦恼，建议从最小配置开始，先定义两个上下文用一周，感受一下再决定要不要扩展成全家桶。
