1. 项目概述我为什么自己写了一个“context-mode”1.1 起因每天都在“找回现场”而不是“干活”我每天的工作基本是在几个项目之间来回切。上午在写后端接口中午要排查前端打包问题下午可能又要去看运维脚本。项目切来切去真正浪费时间的不是切换动作本身而是切换之后的那几分钟“找回现场”的过程。终端停在哪个目录、环境变量是哪个版本的 Node、Kubeconfig 指向哪个集群、上次排查到哪一行、测试命令是哪条、甚至连打开的编辑器窗口布局都要重新摆一遍。这些琐碎状态如果靠人脑去记基本不可能完整恢复。最典型的场景就是下午 3 点切回上午那个后端项目结果发现我 cd 错了目录然后在错误的仓库里运行了 10 分钟命令才发现。我最早尝试过自己手动维护一套备忘录把每个项目的目录、启动命令、注意点写下来。但备忘录是静态的项目里的各种环境状态是动态的写着写着就过期了。后来也试过 tmux 多会话保持、Docker 容器封装环境但都感觉不够“随手”。我真正想要的是一个简单的命令敲一下 context load backend然后我的终端、编辑器、环境变量、工作目录全都切到上次离开那个项目时的状态。这就有了 context-mode 这个工具。1.2 核心定义它到底做了什么我把它定义成“工作上下文的管理器”。所谓“上下文”就是一组描述当前工作环境的可恢复状态包括但不限于当前所在的工作目录已导出的关键环境变量比如 NODE_ENV、AWS_PROFILE、KUBECONFIG正在使用的 shell 类型和会话状态编辑器/IDE 当前打开的目录或工作区最近执行过的重要命令作为“接下来该做什么”的提示项目相关的自定义启动脚本临时留下的备注比如“联调环境已部署等前端修复后验证”它本质上解决的是任务切换中的“状态保存与恢复”问题。我按下保存它把这些状态快照到一个文件我按下切换它把文件里的状态重新灌回当前 shell 会话。整个过程是显式的不是后台自动偷偷进行的。1.3 适用对象这不是给所有人用的工具我认真想过谁会从 context-mode 里获得实际收益。先说结论它最适合那些在多个项目、多个环境之间高频切换的人。后端开发者微服务项目经常要接不同的环境配置切换上下文能避免环境变量错乱。前端/全栈开发者前后端分离开发时经常要在不同仓库之间穿梭context-mode 可以保留每个仓库的启动命令和编辑器布局。运维/DevOps 人员操作不同集群、不同云账号时KUBECONFIG、AWS_PROFILE 这类变量是最容易切错的context-mode 可以把这些变量的组合封装成一个“上下文”。数据分析师分析不同数据源时Python 环境、Jupyter 路径、数据目录的切换同样很烦人。如果你一天下来只在同一个目录、用同一套环境变量干活那这个工具对你的帮助有限不值得为此增加一层复杂度。2. 设计思路从状态保存到环境还原我的取舍过程2.1 设计原则为什么我坚持“显式切换”而不是“自动感知”在动手写之前我列了几个原则这些原则直接影响后面的技术选型。第一条是“显式优于隐式”。市面上有些 IDE 自带恢复会话的功能打开编辑器会自动恢复上次打开的文件。但这类自动恢复其实很危险尤其是在同时操作两个项目的时候编辑器会自动把一堆无关窗口堆到你面前。context-mode 坚持用命令手动触发只有我明确说“切换到项目 A”它才会动我的环境。理由很简单自动感知常常在“错误的时间”做“正确的事”而我需要的只是在“我要的时刻”立刻还原。第二条是“配置必须可移植”。我不希望状态只存在某个 GUI 应用的内存或缓存里那样换一台电脑就全没了。所有上下文都应该是一个纯文本文件能放进 Git能复制到另一台机器能 diff能 review。这带来的附加好处是可以做团队共享后面我专门有一小节讲这个。第三条是“层级覆盖”。全局配置只包含通用的默认值项目级上下文覆盖全局配置再往上还可以有临时会话级的覆盖。这个设计保证了在不同层面的状态能合并而不是互相打架。2.2 核心数据结构一个 JSON 文件就能表达完整工作状态既然选择了纯文本配置第一步就是设计数据格式。我用的格式是 JSON因为 jq 可以直接解析别的脚本语言也天然支持。一个典型的上下文文件长这样{ name: backend-gateway, version: 1, path: { working_dir: /home/me/work/backend-gateway, terminal_title: backend-gateway }, env: { NODE_ENV: development, PORT: 8080, KUBECONFIG: /home/me/.kube/dev-cluster.yaml }, shell: { history_tail: [ npm run dev:gateway, kubectl logs -l appgateway -n dev --tail50, curl localhost:8080/health ] }, editor: { type: vscode, workspace_path: /home/me/work/backend-gateway/backend.code-workspace }, hooks: { pre_load: bash scripts/setup_env.sh, post_load: echo Ready to go }, notes: 联调环境已部署等前端修复后验证 API 网关超时问题 }这个设计基本上能满足我 80% 的需求。每个字段都有自己的用途working_dir是重中之重的字段加载上下文后必须 cd 到这个目录。env只保存白名单里的变量不能把整份环境变量全量快照否则会带回很多垃圾。history_tail保存最近几条命令切换之后能立刻看到“我上次在干什么”。hooks提供加载前后的扩展点这个设计让我不用频繁改主程序。notes是给自己看的便签很多问题隔半天回来就忘了写下来比什么都强。2.3 为什么不用现成的 tmux、Docker、虚拟环境肯定有人问tmux不是已经能保持会话了吗Docker 不是能封装环境吗Python venv 不是能管依赖吗为什么还要造这个轮子我的回答是这些工具的粒度都不对。tmux擅长保持“长驻终端会话”但它并不能很好地绑定“当前项目”的概念。我可以在 tmux 里开 10 个窗口对应 10 个项目但窗口一多久了你根本分不清哪个窗格里在跑什么。而且 tmux 会话恢复的是窗格布局和进程不是 Node 版本、Kubeconfig 这类业务环境变量它需要你再手动切。Docker是重量级方案适合封装整个运行时但如果我只是想切一个目录和环境变量起一个容器是杀鸡用牛刀。而且 Docker 容器里的环境和宿主机隔离联调本地服务时反而要多配置一层网络。虚拟环境venv、conda只覆盖了 Python 依赖这一层但我的上下文还包括终端目录、Kubectl 配置、启动命令。它们都能补上自己那一块但没有任何一个能统管所有层。我需要的其实是一个“轻量级编排层”它不代替 tmux、Docker、venv 这些工具而是把它们的配置组合起来在切换项目的时候把合适的工具、合适的配置、合适的目录一次性铺开。3. 实操从零实现一个可用的 context-mode3.1 技术选型Bash 加 jq不写花哨的胶水代码我写过不少小工具经常面临一个选择是上 Python/Go 写一个完整 CLI还是用脚本快速实现这次我选了 Bash 加 jq原因很简单context-mode 的核心操作和 shell 是紧密耦合的它必须直接修改当前 shell 的环境变量和目录。如果写成一个 Python 子进程它是没有办法修改父 shell 环境的除非再用eval或者source机制去桥接绕一圈很别扭。用 Bash 写还有一个好处在任何 Linux/macOS 机器上都能直接跑不需要装 Python 依赖不需要编译拉下来就能用。jq 负责解析 JSON它比python3 -c json.load...快得多而且可读性好。整个项目分为两部分Bash 函数库定义context命令负责参数解析、调用子命令。Shell hook放在~/.bashrc或~/.zshrc里在 shell 启动时加载 context 函数并为特定场景注册钩子。3.2 目录结构与命令设计~/.context/ ├── config.json # 全局配置记录默认 shell、编辑器类型等 ├── contexts/ # 所有上下文文件 │ ├── backend-gateway.json │ ├── frontend-web.json │ └── ops-cluster.json └── hooks/ # 可选的自定义钩子脚本 ├── pre_load.sh └── post_load.sh命令设计上我刻意保持命令面最小化。用户只需要记住几个动作context save backend-gateway context load backend-gateway context list context rm backend-gateway context stopsave保存当前状态到指定上下文文件。load加载指定上下文文件并应用其中的配置。list列出所有已保存的上下文。rm删除一个上下文文件。stop卸载当前上下文恢复 shell 到一个干净状态。我不提供context edit这种命令因为直接编辑 JSON 文件已经足够没必要封装。任何工具一旦命令太多学习成本就会上升最后反而不如手动操作。3.3 保存与恢复的完整实现核心逻辑其实只有两个函数context_save和context_load。先看关键的保存函数context_save() { local name$1 local file$HOME/.context/contexts/${name}.json # 获取当前目录 local pwd$(pwd) # 从白名单中提取环境变量 local env_json{} for key in ${!CTX_ENV_WHITELIST[]}; do if [ -n ${!key:-} ]; then env_json$(jq -n --arg k $key --arg v ${!key} .[$k] $v) fi done # 读取当前 shell 历史最后 5 条 local history_tail if [ -n ${HISTFILE:-} ] [ -f $HISTFILE ]; then history_tail$(tail -5 $HISTFILE | jq -R . | jq -s -c .) fi # 为编辑器 workspace 路径做一个默认推断 local editor_ws if command -v code /dev/null 21 [ -f .vscode ]; then editor_ws$(pwd)/.vscode fi # 组装 JSON jq -n \ --arg name $name \ --arg dir $pwd \ --argjson env $env_json \ --argjson history $history_tail \ --arg editor_ws $editor_ws \ {name: $name, path: {working_dir: $dir}, env: $env, shell: {history_tail: $history}, editor: {type: vscode, workspace_path: $editor_ws}} \ $file echo 上下文已保存到 $file }这段代码有几个细节我特别想强调。第一环境变量不是全量保存的而是通过一个白名单数组CTX_ENV_WHITELIST来挑选。我默认会放进白名单的是NODE_ENV、KUBECONFIG、AWS_PROFILE、PYTHONPATH这类的关键变量但不会去保存HOME、PWD、SHLVL这些 shell 自己管理的变量。第二历史命令我用tail -5只取最后 5 条这样切回来的时候能看到最近的工作思路又不会让文件内容变成几千行的流水账。再看加载函数这是整个工具的胜负手因为加载必须“修改当前 shell 的环境”。我采用的机制是让脚本输出一段可执行的 shell 代码然后在主 shell 里eval这段代码这样变量修改和cd操作才能生效。context_load() { local name$1 local file$HOME/.context/contexts/${name}.json if [ ! -f $file ]; then echo 找不到上下文: $name 2 return 1 fi # 执行 pre_load 钩子 local pre_hook pre_hook$(jq -r .hooks.pre_load // empty $file) if [ -n $pre_hook ]; then eval $pre_hook fi # 生成环境变量导出语句 local env_script env_script$(jq -r .env | to_entries[] | export \(.key)\\(.value)\ $file) # 处理目录切换 local target_dir target_dir$(jq -r .path.working_dir $file) env_script$env_script cd \$target_dir\ # 输出历史命令提示 echo 上次工作记录 jq -r .shell.history_tail[] $file | while read -r cmd; do echo $cmd done # 如果有便签就显示便签 local notes notes$(jq -r .notes // empty $file) if [ -n $notes ]; then echo 备注 echo $notes fi # 执行最后的环境切换关键 eval $env_script # post_load 钩子 local post_hook post_hook$(jq -r .hooks.post_load // empty $file) if [ -n $post_hook ]; then eval $post_hook fi echo 已加载上下文: $name }这里的关键点是env_script最终通过eval执行。如果你的内存里对“子进程不能改父进程环境”这条铁律有点概念你就知道为什么必须这么做了。context_load本身是在当前 shell 会话里调用的函数所以它的eval能修改当前环境这正是 Bash 函数相对外部脚本不可替代的地方。3.4 如何接入编辑器/IDE终端环境切好了编辑器那边我也希望一起切换。目前我用的主力编辑器是 VS Code接入方式不算复杂思路是加载 context 时检测上下文文件里的editor.workspace_path字段如果存在就调用code命令打开对应的 workspace。在 VS Code 里workspace 本身保存了打开的文件列表、面板布局、调试配置。所以 context-mode 不需要自己存编辑器布局只需要存一个 workspace 文件的路径。用一句话概括编辑器状态由编辑器自己管理context-mode 只负责在合适的时候把正确的 workspace 打开。我的post_load钩子会写这样一个脚本# ~/.context/hooks/post_load.sh workspace_path$(jq -r .editor.workspace_path // empty $HOME/.context/contexts/${CTX_NAME}.json) if [ -n $workspace_path ] [ -f $workspace_path ]; then code $workspace_path fi这里使用了一个临时环境变量CTX_NAME在context_load里先导出再调用 post 钩子钩子脚本就能知道自己属于哪个上下文。初次实现版我其实没做编辑器联动后来发现每次切换完终端还要手动去开编辑器窗口实在不够“一键”所以补上了这个能力。3.5 高级功能为每个上下文绑定启动脚本上下文不只是静态配置它还应该能触发一系列操作。比如切换到前端项目时我可能希望自动执行npm install检查依赖是否过期切换到 k8s 运维环境时我希望自动验证当前 kubeconfig 是否有效切到数据分析项目时我希望自动激活对应的 conda 环境。这些逻辑我不写进 context-mode 主程序里而是通过 hooks 机制实现。JSON 文件里的hooks.pre_load和hooks.post_load就是扩展点。比如这个上下文{ name: data-analysis, path: { working_dir: /home/me/work/data }, hooks: { pre_load: conda activate myenv echo conda env ready, post_load: jupyter notebook --no-browser --port 8899 } }加载时会先激活 conda 环境然后启动 Jupyter。这里要注意进程管理问题jupyter 是在后台运行的post_load 脚本执行完就返回不能让 shell 卡在那里。4. 调试与可用性优化实际踩过的坑4.1 常见问题环境变量丢失、上下文污染排查方向是什么我自己用了三个月踩过不少坑。第一个坑是环境变量丢失。表现是用context save保存上下文时某个关键变量明明存在但加载之后变成空的了。查到最后发现问题出在保存时环境变量的读取方式上。我在 3.3 的代码里用${!key}这种间接展开形式在 Bash 里运行时没问题但如果用户使用 zsh间接展开的语法是${(P)key}Bash 写法的脚本直接用 zsh 执行就会全部失败。后来我把保存逻辑改成了用env命令把当前环境变量输出再用 jq 过滤白名单env | jq -R split() | select(.[0] as $k | $whitelist | index($k)) | {key: .[0], value: (.[1:] | join())} 不过这样改完也引入一个新问题env输出的值如果包含换行符会被切断。好在我实际需要的变量基本都是单行值所以接受了这个限制。第二个坑是上下文污染。我加载了一个上下文工作了一段时间后环境变量已经被各种脚本改得面目全非。这时候如果直接切换到另一个上下文可能把当前任务的垃圾变量带过去。我的解决方案是context_save只能保存白名单里的变量白名单外的一切改动都不会入上下文同时在context_stop里做“清场”把几个已知的变量重置为空值。4.2 中间态处理切换时旧命令还在后台跑怎么办context-mode 最容易被忽视的风险是当你从一个上下文切走的时候那个项目里可能还有前端 dev server、数据库、watch 进程在后台跑着。如果你不管它们过一会儿你可能会发现端口冲突、磁盘日志暴涨、CPU 被莫名占满。我在设计context_stop和context_load时特意加了一个“切换前检查”逻辑加载新上下文前先看一下当前上下文里是否记录了后台任务 PID。如果有就要么提示用户“有 x 个后台任务仍然在运行”要么提供参数context load -f name强制加载。这个逻辑没有做得太自动化因为我并不希望在切换项目时把我的 dev server 杀掉很多时候我切走只是暂时看一下别的仓库后台服务还得继续跑。所以“提醒”比“自动杀”更合理。4.3 性能优化不要每次加载都扫描整个文件系统第一版里我在post_load时总会执行git status目的是确认当前仓库有没有未提交的改动。但遇到稍大的仓库时git status可能要跑几秒甚至更久这明显破坏了“秒切”的体验。后来我把这类重量级检查从自动加载流程中移除改成手动跑context doctor命令按需检查上下文内所有仓库的状态。另一个性能坑是在保存历史命令的时候如果HISTFILE很大tail -5的操作本身没问题但如果你每次保存都扫描整个文件那也会浪费时间。所以保存函数里我特意用tail -5只读末尾几行不加载全量历史。4.4 兼容性细节Bash 3 和 shell 嵌套场景macOS 自带的 Bash 版本往往是 3.2很多语法比如关联数组、${!array[]}在 Bash 3 里根本不能用。为了让 ctx 工具跨平台我最终选择把配置解析全部交给 jqBash 只负责进程管理和简单的字符串拼接。这样既避开了不同 Bash 版本的语法差异也让逻辑更清晰。还有一个比较少人注意的场景如果你习惯在 tmux 里再开多个 pane每个 pane 都会独立继承 context-mode 函数。这问题不大但要注意当你在 pane A 里 load 了一个上下文pane B 不会自动跟着变因为它们是独立的 shell。所以我建议把 tmux 一个窗口绑定到一个上下文而不是所有 pane 共享一个上下文变量。5. 进阶扩展从单人工具到团队协作5.1 把 context 文件纳入 Git 管理context-mode 最有价值的一个扩展就是团队共享。如果你在一个团队里工作大家的项目结构相似把上下文文件提交到 Git 后新同事克隆仓库就能得到一份已经配好的常用环境模板减少不少入门成本。我的做法是在项目的根目录下放一个.context/目录里面放这个项目相关的上下文 JSON。然后在config.json里配置搜索路径让context load既能在全局~/.context/contexts/里找也能在当前项目目录的.context/里找。团队共享面上有一个安全注意点上下文文件里可能会包含敏感信息比如数据库连接字符串、云凭证路径。这类内容绝对不能直接进 Git 仓库。我是用环境变量占位符来处理的例如{ env: { DATABASE_URL: ${DB_URL_FROM_SECRET_STORE} } }加载时如果发现值里有${...}占位符就尝试从本机环境变量里读取真实值。这样配置文件是安全的模板机密信息留在各人的本地环境里。5.2 与自动化脚本结合自动打开浏览器、启动 dev server我作为一个经常跟本地开发环境打交道的人理想的切换流程是输入一条context load web-frontend然后终端自动进入项目目录、加载环境变量、启动 dev server、打开浏览器预览页面、打开编辑器 workspace。这个流程用 POST 钩子就可以串起来。例子#!/usr/bin/env bash # post_load.web-frontend.sh cd $CTX_WORKING_DIR # 启动 dev server如果没启动的话 if ! pgrep -f vite dev /dev/null; then npm run dev /tmp/web-frontend-dev.log 21 echo 已启动 vite dev server, PID: $! fi # 打开浏览器 sleep 2 open http://localhost:5173这种做法的风险是脚本可能在你不想启动服务的时候也启动服务。所以我会在上下文 JSON 里加一个字段auto_start: true或auto_start: false只有显式打开的上下文才执行这些操作。5.3 找回旧版本上下文用 Git 时间戳恢复状态上下文文件本身纳入 Git 管理后带来的一个额外能力就是“时光回溯”。我经常遇到一种场景上周在一堆临时分支里排过一个问题当时的环境变量、调试命令都已经变了。如果当时保存过 context而且提交过 Git那我就能随时用git log找到当时的提交把上下文文件恢复到旧版本再context load看看当时的环境。这个能力我不能说人人需要但它确实在“回忆工作现场”这个方向上做到了极致。配合同步到私有 Git 仓库我在不同电脑之间也能快速找回前几天的工作状态。5.4 我个人的使用习惯和一点建议最后说点掏心窝的话。context-mode 这类工具最大的陷阱就是“过度设计”。我第一版想加入的功能非常多比如自动感知当前 Git 分支、自动切换 Node 版本、自动同步多个设备、还有远程服务器上下文。后来砍掉了一大部分核心只留下保存、加载、list、stop。每个功能都单测过稳定运行后才慢慢往里面加 hooks 和团队共享能力。如果你也想在本地搭一个类似工具我的建议是从最小功能集开始先做context save和context load只处理工作目录和 3 个环境变量。用 JSON 存储用 jq 读写不要引入数据库。先单独用一周把每天的操作流程记录下来再根据真实需求决定加哪些 hooks。等核心流程稳定了再考虑编辑器联动、后台任务检查、团队共享这些扩展。记住工具的价值不在于功能多而在于长期使用下来“切换环境的认知负担”真的变小了。如果你写了很多功能但每天都用不上那它们就不是资产而是负债。