context-mode我给多任务工作流造的一套“上下文切换”方案这段时间我一直在折腾一个叫 context-mode 的东西。起因特别简单手上同时跑着好几个项目每个项目都有自己的一套环境变量、文档笔记、常用命令甚至喂给 AI 辅助写代码的背景资料也完全不同。每天在这些项目之间来回切最耗时的根本不是写代码而是“重新进入状态”。你回想一下是不是这样——上午还在 A 项目的分支上改接口下午切到 B 项目光是把环境变量、当前进度、文档位置重新捋一遍就得花十几分钟。我后来写了一套叫 context-mode 的脚本把这些跟上下文相关的信息打包存档一条命令切换实测下来效率提升非常明显。这篇文章就把这套模式彻底拆开讲讲它解决了什么问题、核心逻辑怎么设计、最终脚本长什么样、以及我踩过的那些坑。1. 内容整体设计与思路拆解1.1 先搞清楚“上下文”到底指什么在做任何方案之前第一步不是写代码而是定义清楚问题。我给自己定的问题是在多项目并行工作时阻碍效率的“上下文”到底是什么拆下来其实就三层。环境层当前在哪个目录、PATH 里追加过什么路径、Node 版本切到哪个了、Python 虚拟环境激活了没有、当前 Git 分支是哪条、开发服务器跑在哪个端口。这些属于“机器状态”不恢复的话命令一执行就报错最直观也最烦人。状态层我这件事做到哪一步了下一步要做什么刚才改到哪个文件这个需求还剩几个待确认的点这些属于“大脑状态”不恢复的话代码看着眼熟但想不起来为什么这么写。知识层这个项目的技术栈约定、架构文档、接口文档、常用命令、特有名词、甚至一些业务背景。这些属于“资料状态”要临时翻文档的话非常打断节奏。三层合在一起才是一个完整的“上下文”。缺了任何一层切换都会卡壳。我做 context-mode 的第一件事就是明确这个模型它不是简单的环境恢复工具而是把环境、状态、知识三样东西打包成一个可切换的“工作现场”。1.2 为什么是“模式”而不是“多开几个终端”有人可能会问一个项目开一个终端窗口或者开几个浏览器标签页不也能凑合吗凑合可以但有几个绕不开的痛点。多终端的问题是“空间分割记忆没有分割”。你确实在一个目录里但你的大脑不会自动切换到对应状态。更麻烦的是终端开多了之后经常会搞混——在 A 项目的窗口里执行了 B 项目的命令或者把 A 项目的环境变量带到了 B 项目的构建流程里一旦出错排查成本比省下来的时间高得多。context-mode 的核心不光是“切换”而是“显式的、可回放的切换”。每次保存现场其实是在给自己的工作做一次快照每次恢复现场等于按一张照片把桌子原样摆回来。这比手动一个个cd、export、git checkout要靠谱得多因为过程是可重复的、可审计的。1.3 两条设计原则少走弯路这套方案一开始我做得特别复杂想着要不要搞数据库、搞后端、搞一个网页管理界面。后来全推翻了沉淀下来就两条原则。第一条显式切换优于自动推测。有人觉得可以这样检测到cd到某个目录就自动加载对应的上下文。我试过最后放弃了。原因很简单同一个目录可能会做两件完全不同的事——比如在项目根目录写接口和写测试上下文逻辑并不完全一样。自动加载会误判误判比不加载更难受。所以 context-mode 的默认操作是手动save和load宁可不便捷也不要错。第二条最小信息量原则。不要试图把整个终端输出、整个文件内容都存进去。只存“恢复现场所必需的最小信息”。信息存得越多维护越麻烦还容易把敏感内容误存进去。一张图撑不起操作系统一份 JSON 也撑不起完整项目但它足以把关键状态带回来。2. 核心细节解析与实操要点2.1 捕获阶段哪些信息值得存哪些不值得我做了大概四五版之后才总结出一份相对固定的“捕获清单”这里直接分享给你。值得存的当前目录路径这个是核心中的核心没有它就等于没存档。关键环境变量不是env的全部内容而是当前 shell 比默认环境多出来的变量。比如NODE_ENV、DATABASE_URL、VITE_API_BASE这类项目专属变量。Git 分支名虽然大部分项目是持续在一条分支上开发的但场景切换时分支名往往能快速提醒你“上次是在哪个功能上”。正在运行的服务信息比如dev server跑在了5173端口、API mock跑在8080这些信息对恢复调试环境很有用。最近执行的关键命令取历史记录里的最后一条往往就是“我刚才在做什么”的最直接线索。自由格式笔记比如“接口改到一半下一步补单元测试”“注意新版 SDK 的环境变量名变了”这种文字信息最灵活也最值钱。不值得存的终端全部输出垃圾信息多于有用信息恢复后也没法直接用。临时文件内容占用空间且大部分情况不需要。敏感凭据API Key、密码、Token 一律不进存档。这点必须从一开始就做好过滤器否则后面一定会出事。捕获的技巧上有几点想提醒你。抓env的时候要过滤掉系统自带的变量比如PWD、OLDPWD、SHLVL、_这些不然每次存档都会多出一堆噪音diff 都不好看。抓 Git 分支用git branch --show-current比解析git status的输出可靠得多。抓最近命令要慎重history在非交互式 shell 里经常是空的直接用会有惊喜需要兼容。2.2 存储格式与目录结构怎么放放哪里存储这块我纠结了很久最后用的是最土但最稳的方案纯文本 JSON Git 仓库管理。目录结构长这样~/.context-mode/ ├── project-a/ │ ├── context.json │ └── notes.md └── project-b/ ├── context.json └── notes.mdcontext.json负责存环境层和状态层notes.md负责存知识层。为什么不用一个文件搞定因为阅读频率不同。context.json是机器读的notes.md是给人读的。实际操作中你会发现恢复现场时你更想看一眼笔记而机器恢复时只需要 JSON。context.json长这样{ name: project-a, path: /home/user/work/project-a, branch: feature/login, env: { NODE_ENV: development, VITE_API_BASE: http://localhost:8080 }, ports: [5173, 8080], last_command: npm run dev, updated_at: 2025-01-15 14:30:22 }这里有几个取舍值得说。为什么选 JSON 不选 YAML因为 JSON 在几乎任何环境都有原生解析能力不需要考虑缩进问题用脚本处理最省心。为什么不用数据库因为明文文件配合 Git 可以做版本管理、回溯 diff、多设备同步这些能力用数据库实现成本太高。而且 JSON 文件可以手动改出问题了还能直接手修没有黑盒。另外强烈建议把~/.context-mode这个目录做成一个 Git 仓库。这样每次保存都能看到上下文之间的差异想回滚也方便。甚至可以推到私有仓库实现多设备同步。前提是遵守上一条——保证里面没有任何敏感凭据否则推到远端就等于裸奔。2.3 恢复阶段先做什么后做什么恢复阶段有个很关键的细节操作顺序不能乱。我第一版写得很随意想到什么恢复什么结果经常出现目录切了但环境变量没生效、分支切了但依赖版本不对的情况。正确的恢复顺序是先切目录。这是一切操作的地基其他操作都依赖当前路径。再导环境变量。必须在任何命令执行之前就位因为后续命令运行时需要读取它们。再切 Git 分支。这时候你在正确的目录里环境变量也对切分支才安全。最后显示笔记摘要。这一步是给人看的把上一步的notes.md前几行打出来帮你快速唤醒记忆。还有一个非常重要的点是幂等性。也就是说同一份存档加载两次效果应该和加载一次完全一样不能出现环境变量被重复追加、PATH 被越拉越长、服务被启动两次的问题。我处理 PATH 用的是“先去掉再追加”的策略效果稳定。3. 实操过程与核心环节实现3.1 最小可用实现一个开箱即用的 context-mode 脚本下面这个脚本是基于 zsh/bash 的最小实现。不追求花哨先把 save/load/list/rm 四个核心操作跑通。你拿过去改改路径和过滤规则就能直接用。#!/usr/bin/env bash # context-mode.sh - 上下文保存与恢复脚本 # 用法: source context-mode.sh 然后使用 ctx command export CONTEXT_DIR$HOME/.context-mode mkdir -p $CONTEXT_DIR # 过滤掉系统基础变量只保留有效项目环境 filter_env() { env | grep -v -E ^(PWD|OLDPWD|SHLVL|_|HOME|SHELL|USER|LOGNAME|PATH|TERM) || true } # 保存当前上下文为指定名称 ctx_save() { local name$1 if [ -z $name ]; then echo 用法: ctx save 名字 return 1 fi local dir$CONTEXT_DIR/$name mkdir -p $dir local branch if [ -d .git ]; then branch$(git branch --show-current 2/dev/null || echo ) fi local last_cmd if [ -n $(history 2/dev/null) ]; then last_cmd$(history 1 | sed s/^ *[0-9]* *//) fi { echo { echo \name\: \$name\, echo \path\: \$PWD\, echo \branch\: \$branch\, echo \last_command\: \$last_cmd\, echo \updated_at\: \$(date %Y-%m-%d %H:%M:%S)\, echo \env\: { local first1 while IFS read -r key value; do # 过滤明显敏感变量 case $key in *TOKEN*|*PASSWORD*|*SECRET*|*API_KEY*) continue;; esac if [ $first -eq 1 ]; then first0 else echo , fi printf %s: %s $key $value done (filter_env) echo echo } echo } } $dir/context.json # 如果没有笔记文件初始化一个 if [ ! -f $dir/notes.md ]; then echo # $name 工作笔记 $dir/notes.md echo $dir/notes.md echo ## $(date %Y-%m-%d) $dir/notes.md fi echo 上下文已保存: $name } # 加载一个已保存的上下文 ctx_load() { local name$1 if [ -z $name ]; then echo 用法: ctx load 名字 return 1 fi local file$CONTEXT_DIR/$name/context.json if [ ! -f $file ]; then echo 没有找到上下文: $name ctx_list return 1 fi # 先切目录 local proj_path proj_path$(grep path $file | sed s/.*: \(.*\),*/\1/) cd $proj_path || { echo 目录不存在: $proj_path; return 1; } # 再导环境变量 - 先用 awk 解析 json 里的 env 块 local env_block env_block$(awk /env: {/,/^ }/ $file | grep : | sed s/ *//;s/: *// | tr -d ) while IFS read -r key value; do [ -z $key ] continue # 对于 PATH 使用特殊追加逻辑 if [ $key PATH ]; then continue fi export $key$value done $env_block # 再切分支 local branch branch$(grep branch $file | sed s/.*: \(.*\),*/\1/) if command -v git /dev/null 21 [ -n $branch ] [ -d .git ]; then git checkout $branch /dev/null 21 || echo 分支切换失败: $branch fi echo 已切换到上下文: $name echo 路径: $proj_path echo 最近命令: $(grep last_command $file | sed s/.*: \(.*\),*/\1/) echo --- 笔记 --- head -20 $CONTEXT_DIR/$name/notes.md } # 列出所有上下文 ctx_list() { echo 已保存的上下文: for dir in $CONTEXT_DIR/*/; do [ -d $dir ] || continue local name name$(basename $dir) local updated updated$(grep updated_at $dir/context.json 2/dev/null | sed s/.*: \(.*\),*/\1/) echo - $name (更新于 $updated) done } # 删除一个上下文 ctx_rm() { local name$1 if [ -z $name ]; then echo 用法: ctx rm 名字 return 1 fi rm -rf $CONTEXT_DIR/$name echo 已删除: $name } # 入口 ctx() { local cmd$1 shift case $cmd in save) ctx_save $ ;; load) ctx_load $ ;; list) ctx_list $ ;; rm) ctx_rm $ ;; *) echo 可用命令: ctx save 名字 | ctx load 名字 | ctx list | ctx rm 名字 ;; esac } ctx $有几个使用上的要点你必须知道。首先这个脚本要用source加载不能直接执行。原因在于export的环境变量只对当前 shell 生效如果你用bash context-mode.sh运行脚本里export的变量在脚本退出后立刻消失没有任何意义。所以正确姿势是source ~/bin/context-mode.sh还可以在.zshrc里加一行alias ctxsource ~/bin/context-mode.sh ctx注意这里的玄机——先 source再执行上下文命令保证每个命令都在当前 shell 上下文里生效。其次脚本里我故意跳过了PATH因为 PATH 的处理要格外小心不能直接覆盖否则会丢失系统路径。还需要安装jq吗不需要上面的脚本考虑到了这点用grepsedawk解析 JSON虽然丑了点但在没有jq的机器上也能跑。3.2 从零到一给项目建档的完整现场光有脚本还不够走一遍完整流程才能知道哪里会卡。假设我在/home/user/work/blog-platform这个项目上开发。第一步进入目录后我手动设置本次任务需要的环境变量cd /home/user/work/blog-platform export NODE_ENVdevelopment export API_BASEhttp://api.dev.blog-platform.local git checkout feature/rich-editor然后激活虚拟环境可选跑起来开发服务器。现在我要建一个档ctx save blog-platform看到上下文已保存: blog-platform然后在~/.context-mode/blog-platform/notes.md里写几行# blog-platform 工作笔记 ## 2025-01-15 - 富文本编辑器的 toolbar 插件做到一半卡在图片上传回调 - 下一步给 toolbar 加一个拖拽排序参考 admin 的 old-drag-drop - 注意新版 SDK 不支持 createImageBitmap用 FileReader 兜底这样环境层和状态层都存下来了。隔了一天再来直接ctx load blog-platform脚本会把目录切过去、环境变量导进来、切到feature/rich-editor分支然后把 notes 的前几行打出来。看到“富文本编辑器做到一半”的那一刻大脑就自动接上上次的进度不需要翻聊天记录或者回忆半天。3.3 把上下文变成 AI 的提示词这一步是这个方案里我觉得最值钱的扩展。现在很多人用 AI 辅助写代码但你有没有发现一个问题——每次开新对话AI 对你正在做的项目一无所知你得把背景讲一遍又一遍。而 context-mode 天然就拥有这些背景信息。我把脚本加了一个命令ctx prompt 名字专门把存档渲染成一段 “工作背景提示词”。ctx_prompt() { local name$1 local file$CONTEXT_DIR/$name/context.json [ -f $file ] || { echo 上下文不存在: $name; return 1; } echo 我正在参与的项目: $name echo 项目路径: $(grep path $file | sed s/.*: \(.*\),*/\1/) echo 当前分支: $(grep branch $file | sed s/.*: \(.*\),*/\1/) echo 最近在做的任务: $(grep last_command $file | sed s/.*: \(.*\),*/\1/) echo echo 项目关键笔记: cat $CONTEXT_DIR/$name/notes.md echo echo 请基于以上上下文回答我的问题或协助我继续任务。 }实际操作中我会把它和 AI 客户端配合使用打开对话之后先复制ctx prompt blog-platform的输出粘进去再提问。AI 对项目背景的掌握程度会明显提升。这等于给每个项目配了一个带有项目记忆的 AI 助手非常实用。你甚至可以把这段提示词输出到一个文件通过一些工具直接投喂给支持的 AI 客户端实现半自动。4. 常见问题与排查技巧实录4.1 我先踩过的坑按症状列给你这套方案我断断续续用了几个月踩过的坑不少。整理成一张速查表方便你遇到问题直接对照。症状原因解决方案切换后环境变量不生效用bash script.sh直接跑了脚本没有source用source ~/bin/context-mode.sh或 alias 上一层包 source目录切过去了Git 分支没切本地有未提交的改动git checkout 被拒绝恢复前先git status检查或者脚本里检测到失败时输出提示手动 stashPATH 越拉越长load 时直接追加 PATH同一条路径存了多份追加前先去掉已有路径确保幂等jq 命令找不到系统没装 jq装一下apt install jq或brew install jq或者像我上面一样用 awk/sed 兜底context.json 里存了 Token过滤名单没生效或者手动写入了敏感信息过滤名单加上TOKENSECRETKEY铁律是绝不往 notes.md 里写秘钥notes.md 忘了写后来想不起来没有及时记录我在脚本里增加了保存时自动打开编辑器编辑 notes 的选项强制自己写一行多设备同步出现冲突Git 仓库跨设备推送时 context.json 冲突先git merge手动解决JSON 结构简单冲突一般不多4.2 几个容易被忽略的细节细节一非交互 shell 里history是空的。我第一次做last_command时在终端里测试一切正常放到定时任务或者子脚本里跑结果发现存进去的是空字符串。原因是 bash history 默认只在交互式 shell 里记录。如果你真需要“最近命令”这个字段建议通过fc -ln -1或者读取~/.bash_history的最后一行的方式兼容处理。细节二环境变量的“先取消再设置”逻辑。有些变量之间存在引用关系比如MY_PATH$BASE/subdir和BASE/opt/app。如果恢复时先导入了MY_PATH再导入BASE最终结果就错了。这类问题排查起来很隐蔽。现在我的做法是恢复前先看一眼 JSON 里的变量列表把明显是引用其他变量的字段在脚本里单独处理加载顺序。细节三保存时为什么不做自动全量。有人希望ctx save是自动的输入save就直接把当前状态存进去。我的建议是不要因为保存时的“上下文命名”是有认知成本的一步——你起什么名字其实是在给自己定义“这是我接下来要做的任务的入口”。这个过程本身就是整理思路。4.3 顺手能做的扩展这套脚本跑顺之后可以往几个方向扩展。第一是补全。在 zsh 里加一行compdef _ctx ctx再补一个补全函数输入ctx load后直接 tab 列出所有存档名体验会好很多。第二是自动打开笔记编辑器。保存时如果检测到 notes.md 是空的直接用$EDITOR打开它强迫自己记录。很多时候上下文丢失不是因为不想记而是因为“待会再写”最后变成了“永远不写”。第三是把ctx prompt的输出和 AI 工作流串起来。我现在已经把常用项目的上下文都建好了每次和 AI 讨论项目问题之前都先喂一段上下文效果确实比裸聊好很多。第四是集成到编辑器/启动器。比如通过脚本触发ctx load后再启动对应的 IDE 窗口或者用 Alfred/Raycast 这类启动器拉起 load 命令。这些都属于锦上添花等基础玩熟了再折腾也不迟。根据我自己的经验最值得先做的是把save和load用起来哪怕一开始只有目录路径和笔记没有环境变量也能解决大多半的“从哪继续”的问题。等到用顺手了再根据实际痛点加功能。整套方案的精髓在于“给自己营造一种随时可以按下暂停键又随时可以按下播放键的工作方式”——这在多任务并行、AI 协作日益频繁的今天是特别值得打磨的一件小事。