你有没有遇到过这种场景正在写一篇技术文章脑子里塞满了思路顺手切过去修了个 bug又有人让你帮忙看看一份文档。等再切回来的时候之前整理好的思路已经乱成一团。我试过很多办法开多个文档、用笔记软件、把内容粘来粘去最后都败给了“上下文切换”这件事。所以我自己写了一个小工具名字就叫context-mode。它的定位很直接在终端里用一条命令把当前正在进行的任务上下文保存下来随时切换随时恢复。这篇博文把我从设计到落地整个过程完整拆开包括数据格式、命令设计、关键代码、常见坑和排查方法。适合每天要同时处理多个任务、经常和 AI 对话、写长文档或者长期跟维护一堆工程分支的人读看完可以直接抄去自己用。1. context-mode 到底要解决什么问题1.1 上下文混乱的典型场景我先把你可能遇到的场景摆出来看看是不是似曾相识早上在写一份季度总结写到一半被叫去处理线上告警等你回来刚才想好的一段表达怎么也想不起来。正在基于一个开源项目做二次开发刚理清了调用链结果又去回复了几个用户问题再回到代码里之前的上下文已经丢了。长期维护一个项目经常要在“调试接口”“写文档”“梳理架构”几个状态之间反复横跳每个状态下你关注的代码区域、依赖项、关键命令都不一样。这些场景的共同点不是“信息不存在”而是“信息堆在一起没法快速分离”。文本编辑器里的多个 Tab 能帮一点忙但真正有价值的上下文不只是文件内容还包括你当时整理出的结论、待验证的想法、临时收集的参考资料、甚至一段正在调试用的命令。1.2 设计目标像抽屉一样管理你的工作状态我在做 context-mode 的时候给自己定了几个硬性目标足够轻一条命令完成保存/切换不能在工具使用本身上花精力。存储格式可读所有数据就是纯文本和 JSON随时可以用编辑器打开改。完全离线可用不依赖任何外部服务敏感信息留在自己电脑里。可脚本化能放进 Git hook、cron 任务、编辑器快捷键里配合使用。你可以把它理解成一个“给大脑用的抽屉柜”。每个抽屉是一个命名好的上下文里面有这段工作需要的全部背景信息。你工作时只拉开一个抽屉做完一个任务就把抽屉推回去拉开另一个。抽屉里的内容不会因为你中途去干别的事而自动消失。1.3 为什么不做成 GUI 或者编辑器插件这不是技术能力问题而是刻意选择。GUI 工具在“记录”这个动作上天然比命令行重你得打开窗口、找到输入框、填写表单、点保存。而终端里的命令可以在你思考的间隙直接敲完甚至可以通过别名做到两个键触发。编辑器插件也是个方案但它只能解决“写入”的问题不能解决“把上下文带到任何地方”的问题。context-mode 是独立的命令行工具我可以在终端里用可以在脚本里调用也可以让 AI 编程助手读取同一份上下文文件。这种可组合性是绑定在单一编辑器里做不到的。下图是整个工具的简化工作流我用文字描述一下你通过cm save 名称把当前工作上下文存入本地存储后续通过cm load 名称把它读出来注入终端、剪贴板或指定文件cm list让你随时看到自己有哪些抽屉当你不再需要某个上下文时用cm rm清理。2. 整体架构与核心功能设计2.1 命令体系与数据模型context-mode 项目名中带着 “mode” 这个词就是希望它像一个“模式开关”一样工作。命令集合设计如下命令作用示例cm save name -s 内容保存一个新的上下文cm save weekly-report -s Q3目标...; cm save debug-login -f ./tmp/notes.mdcm append name -s 补充内容往已有上下文追加内容cm append weekly-report -s 补充数据新增用户3000cm load name加载上下文到终端/剪贴板cm load debug-logincm list列出所有上下文条目cm listcm rm name删除一个上下文cm rm old-notescm clip name将上下文内容复制到剪贴板cm clip weekly-reportcm export/cm import导出/导入全部数据cm export ./backup.json存储结构放在了~/.context-mode/目录下主文件是store.json。单个条目的结构这样设计{ id: 20250918-214530, name: weekly-report, tags: [report, q3], content: 季度目标... 当前进展... 待确认..., created_at: 2025-09-18T21:45:3008:00, last_used: 2025-09-19T09:12:0008:00 }字段不多但都是有用的设计name是给人看的也是命令里要用的关键参数我限定为小写字母、数字和连字符避免空格带来的转义问题。content是真正承载上下文的地方纯文本长度不限。tags可选项方便按标签过滤。last_used用来支持“最近使用的上下文”这个功能我经常用cm list --recent快速找回上午的工作状态。2.2 上下文注入与模板机制只保存一段文本文档还不够实际使用时我更希望“加载上下文”这个动作能同时完成几件具体的事。context-mode 里做了一个“注入模板”机制每个上下文保存时除了content还可以附带模式类型比如coding、writing、review、mail。举个例子我保存一个code-fix类型的上下文然后加载时工具会把内容包装成这样的结构【当前任务】 修复登录模块在 session 过期后跳转异常的问题 【已知信息】 - 异常发生在 LoginService.checkSession() - 前端接口在 401 时未统一处理 - 复现步骤登录后等待 30 分钟点击任意菜单触发 【待验证】 - 服务端是否返回新的 refreshToken - 前端路由守卫是否需要补充白名单 【建议动作】 1. 先在后端接口加日志确认过期时间点 2. 再检查前端 axios 拦截器对 401 的处理这个结构其实就是给 LLM 或给未来的自己看的“提示词”。实际里我会把这段包装后的内容直接复制到 AI 对话框或者文档开头省去每次重新整理背景信息的功夫。2.3 安全性与隐私设计一个和上下文管理相关的工具最容易被人担心的是隐私。context-mode 默认所有数据都存在本地没有网络请求。我使用的场景里有时会涉及一些内部系统的日志、密钥片段、客户信息这些内容不适合放到第三方平台这也是我坚持本地优先的原因。为了让这个原则更容易落地我还做了两个小功能每个条目支持设置sensitive: true标注为敏感的内容在cm list里只显示名称不显示内容预览。支持cm export --redact导出脱敏版本。脱敏规则很简单就是把疑似邮箱、手机号、密钥片段用***替换。这个功能在你想把上下文分享给同事参考时特别好用。3. 从零搭建 context-mode 的实操过程3.1 环境准备与安装context-mode 我尽量做到零依赖但为了让 JSON 解析更可靠我选择依赖jq。如果你经常在命令行操作大概率已经装了没装的话用系统自带包管理器装一下就行。完整依赖清单Bash 4.0 或 Zshjq 1.6解析 store.json 用fzf可选推荐用于交互式选择上下文安装脚本我写在项目里了逻辑不复杂检测系统中的依赖创建数据目录然后把主脚本下载到/usr/local/bin/cm并加上可执行权限。完成之后在 shell 配置里加一行别名alias cmcontext-mode装完先验证一下$ cm --version context-mode 1.0.0如果命令提示找不到大概率是/usr/local/bin不在 PATH 里。用echo $PATH看一下加进去就行。3.2 核心代码实现整个工具的核心是四个函数保存、加载、列表、删除。我现在把关键实现贴出来并逐段解释为什么这么写。# 保存上下文 cm_save() { local name$1 local content$2 local store$HOME/.context-mode/store.json local id id$(date %Y%m%d-%H%M%S) local entry entry$(jq -n \ --arg id $id \ --arg name $name \ --arg content $content \ --arg created $(date -Iseconds) \ {id: $id, name: $name, content: $content, created_at: $created}) if [[ -f $store ]]; then jq --argjson entry $entry . [$entry] $store $store.tmp mv $store.tmp $store else mkdir -p $HOME/.context-mode echo [$entry] $store fi echo saved: $name }这里用jq而不是直接用echo拼 JSON是因为用户输入的内容里可能包含引号、换行、反斜杠。手动拼字符串很容易破坏 JSON 结构而jq -n --arg会自动处理转义。实测下来用jq后从来没有因为特殊字符出过问题。加载函数要更细心一点因为要考虑到“加载到什么位置”的问题cm_load() { local name$1 local store$HOME/.context-mode/store.json local target${2:-screen} local content content$(jq -r --arg name $name .[] | select(.name $name) | .content $store) if [[ -z $content ]]; then echo no context found: $name return 1 fi case $target in screen) echo $content ;; clip) printf %s $content | pbcopy || printf %s $content | xclip -selection clipboard ;; file) printf %s\n $content $2. echo written to $2. ;; esac # 更新时间戳 jq --arg name $name \ (.[] | select(.name $name) | .last_used) | now \ $store $store.tmp mv $store.tmp $store }target参数让同一个命令具备了三种输出方式。screen模式适合直接在终端里查看clip模式适合准备粘贴到编辑器或 AI 对话框file模式适合把上下文输出到一个临时文件配合其他工具进一步处理。列表函数我用表格输出方便人眼扫cm_list() { local store$HOME/.context-mode/store.json jq -r .[] | \(.name)\t\(.last_used // never)\t\(.content[0:40]) $store \ | column -t -s $\t }输出效果差不多是这样name last_used content_preview weekly-report 2025-09-19T09:12:00 季度目标... debug-login 2025-09-18T21:45:30 LoginService...3.3 在日常工作流里的实际演示光看代码不够直观我拿三个真实工作场景演示一下 context-mode 能怎么改变节奏。场景一写一篇技术文章我把所有参考资料、核心论点、示例代码片段先收集起来保存为一个上下文。写文章时用cm load article --target clip把背景说明复制到 AI 对话框让 AI 按我的信息生成初稿。中途被打断去改 bug改完回来再cm load article思路完整恢复。晚上文章写完了cm rm article清理这个临时上下文。场景二处理客户反馈收到客户反馈后我把问题描述、相关日志、排查思路存进cm save support-customerA。第二天客户又追加了一条反馈用cm append support-customerA -s 客户补充重启后问题仍然存在。排查到解决办法后把结论追加进去形成完整处理记录。事后cm export --redact ./result.json导出脱敏版分享给团队。场景三跨天恢复“昨天的研究”每天下班前我用cm save research-vector-db把当天看过的资料、当前结论、下一步计划存下来。第二天上班直接cm load research-vector-db30 秒内进入昨天的工作节奏。周五汇总时用cm list --tags research把所有研究类上下文列出来写周报时引用的都是真实过程记录。我用下来最大的感受是context-mode 让我从“记忆负担”里解放了出来。以前我总得靠脑力维护一个“现在进行到哪了”的指针现在这个指针变成了公开的、可随时查看的状态。3.4 配置与自定义扩展每个工具只有用到一定深度才会顺手context-mode 提供了两个自定义维度第一模板自定义。默认模板有coding、writing、review等但每个人的工作习惯不同。模板文件放在~/.context-mode/templates/下你可以创建自己的模板比如--type support定义客服场景的结构。加载时指定--type support就能按这个模板渲染。第二指令钩子。context-mode 支持在加载和保存时触发自定义命令。比如我想在加载一个coding类型上下文时自动把项目目录切换到 context 里记录的工作目录我可以写一段钩子脚本# ~/.context-mode/hooks/after_load.sh case $CM_NAME in project-*) cd $(jq -r --arg n $CM_NAME .[] | select(.name $n) | .content \ | grep -oP 工作目录[:]\s*\K[^\n]) ;; esac这个例子稍微有点硬编码但思路是值得借鉴的工具本身保持简单把奇技淫巧留给 shell 环境去增强。4. 高频问题与排查技巧实录4.1 常见问题速查表我在实际使用和给同事推荐的过程中收集了不少问题。挑典型的整理成表格问题现象可能原因解决办法cm: command not foundPATH 中没有包含安装目录export PATH/usr/local/bin:$PATH中文内容显示成\uXXXX终端或 jq 输出默认转义非 ASCII 字符JSON 存储本身没问题查看时加-r参数即可保存时被 shell 展开变量在双引号里写了$HOME等变量cm save name -s 价格是 $5要在内容包含$时加引号用\$转义加载的内容尾部被截断有些实现用echo输出多行文本统一改成printf %s不要用echo两个终端同时保存导致数据丢失并发写入 store.json用flock给写入操作加锁误删了重要上下文没有自动备份在 rm 时自动把内容压缩到~/.context-mode/trash/第四条的“截断问题”尤其隐蔽。echo在有些环境下会对以-开头的内容处理异常而且echo默认在尾部追加换行多行内容时行为不一致。所有涉及内容输出的地方我最终都换成了printf这个问题再也没有出现过。4.2 我踩过的三个坑第一个坑在管道里 alias 失效。早期我给cm设置了 alias但在脚本里写cm list | grep project时发现 alias 不会被展开命令直接报错。后来我把脚本里的调用全部改成完整函数名context-mode只在交互式 shell 里保留 alias。第二个坑JSON 里保存带$符号的内容。有一次保存 shell 片段时没有注意转义导致变量被提前展开成一串空值。比如你写$PATHshell 会自作主张把它替换成环境变量值等到你用的时候内容已经不是你想存的了。现在的处理方式是所有保存操作都用--raw参数明确告诉工具“不要做任何展开”。第三个坑同一目录自动关联导致误加载。早期我做过一个“进入目录自动加载同名上下文”的功能看起来方便实际特别容易翻车。经常是进到项目目录工具自动加载了旧的上下文把当前还没整理好的新想法覆盖了。后来我彻底去掉了自动加载改成手动cm load一切以显式操作为准。4.3 让 context-mode 更好用的小技巧最后分享几个我用着非常顺手的小配置按推荐程度排序绑定快捷键。在 Zsh 里我加了两个键位Ctrlg保存当前上下文Ctrll加载最近使用的上下文。配合起来基本是零思考成本。定时快照。我写了一个 cron 任务每小时把 store.json 复制一份到~/.context-mode/snapshots/只保留最近 30 份。这样就算误删了内容也能从快照里捞回来。和 AI 工具联动。写代码时我会把cm load task --target clip的输出直接粘贴到 AI 助手的上下文里。这样 AI 不用再问“项目背景是什么”这种基础问题直接就能进入具体实现。不同项目用不同的 tag 前缀比如tag: project-xxx然后用cm list --tag project-xxx做项目级视图。时间一长这其实就是个轻量版的项目知识库。5. 后续还能怎么扩展写到这代码已经完整工作流也能跑了。但任何工具用久了都会看到更多可能性我给自己列了几个后续想做的方向支持把某个上下文直接渲染成 Markdown 文件作为周报素材。给cm list增加按标签过滤和模糊搜索已经做了基础版。把 store.json 的同步交给用户自选方案。我把备份目录纳入私有 Git 仓库每次cm save后顺手 commit 一下多台机器之间靠着 Git push/pull 就能同步。等数据量大了之后可以考虑在cm list里加入内容索引这样搜索效率更高。有意思的是第一版 context-mode 只有 80 行 shell现在已经扩展到了 300 多行。功能变多了但设计原则还是那几条本地存储、纯文本优先、命令简洁。我个人在实际操作中的体会是工具越大越容易成为负担context-mode 的价值恰恰在于它只做一件事让你在任何时刻都能清晰地知道“当前在干什么、之前干到了哪里”。如果你也有多任务并行和上下文丢失的困扰我建议从最小版本开始先跑通 save 和 load 两条命令用上一周再按自己的习惯加模板、加钩子。工具是次要的把工作过程显性化记录下来的意识比任何工具都重要。