context-mode：用显式上下文对象终结多任务切换的思维混乱

我同时推进三四个小项目的时候最难受的不是写代码而是每次切任务都要重新捡起上下文。窗口可以切标签页可以开问题在于脑子里那个“我现在到底在做什么”的状态没人帮我记住。后来我给自己写了一个小工具核心就一件事把上下文变成一个显式的、可以随时存取、随时恢复的对象。这个设计我叫它 context-mode。这篇文章会把它的设计逻辑、落地步骤和真实踩坑都写出来给同样被多任务上下文搞得焦头烂额的人一个能直接复用的参考。1. 为什么我要自己造一个 context-mode而不是继续忍下去1.1 单画布容不下所有任务的记忆成本我做技术类工作的时间不短手头同时转的项目通常有三四个。写代码要换仓库写文档要换目录查资料要开新浏览器窗口聊天工具里还有一整套待办。表面上看这些窗口都在桌面上想找哪个点哪个就行。真正的问题出在“思维状态”上你写完一段需求分析接着去调接口再回头改文档这三次切换其实各有一整套前置记忆。比如问题背景、已经试过的方案、刚看到的关键线索。这些记忆全部藏在人脑里没人替你持久化。我试过用“多开几个窗口”“多建几个文件夹”“多建几个标签组”来解决结果都不理想。窗口开多了还是乱文件夹归类还是难标签组必须手动整理而且要命的是一旦我关掉浏览器或者电脑重启这些临时积累的线索就全没了。这不是工具数量的问题而是缺少一个抽象的“上下文容器”一个能统一记录任务相关状态并且能在你切换时完整取回的东西。1.2 把“上下文”当成一等公民而不是背景噪音大多数工具把上下文当成隐性的东西工作目录、当前分支、打开的文档、剪贴板里的临时片段都是散落在各个角落的状态。我用 context-mode 的思路是反过来把这些东西显式打包成一个独立对象。这个对象有自己的名字、自己的保存时间、自己的归属项目像一个“快照容器”。用起来就像这样我打开编辑器、终端、资料页把状态整理好然后执行一次保存。这条上下文被标记为“需求评审准备”。几个小时后我想接着做只要执行一次恢复编辑器会打开当时的文件列表终端会切到当时的工作目录浏览器会打开当时的资料页我之前贴的临时备注也会回到待办区。整个过程不是靠记忆而是靠一条命令。1.3 它到底适合谁用这东西不是大厂框架也不是分布式方案它就是个人效率层。最适合三类人。第一类是同时参与多条产品线或多份合同的开发者分支和目录太多经常搞混自己在哪个业务上下文里。第二类是内容创作者写作、配图、素材、审校来回切换思路断了很难接上。第三类是运营和客服这类“会话密集”岗位每天处理大量相似问题不同客户的信息必须隔离清楚。如果你只是单线程做事任务本来就简单这工具帮不上什么忙。但只要你有跨任务的切换需求这套模式就能省下大量“重新进入状态”的时间。2. 核心设计拆解一个显式上下文对象到底要装什么2.1 上下文的三层结构在动笔写代码之前先要把“上下文”这件事拆清楚。我在实际设计中把上下文分成三层每一层的有效期和恢复策略都不一样。层级包含内容例子失效条件任务上下文任务名称、目标、当前阶段“给用户中心做权限改造”任务结束或被放弃数据上下文文件、目录、数据库连接、环境变量项目代码路径、本地数据库库名数据被移动或删除界面上下文打开的标签页、窗口位置、临时输入浏览器资料页、编辑器分屏布局人工清理或应用退出三层分开管理的原因很简单它们的变化频率完全不同。任务上下文可能一周才变一次数据上下文可能一天变几次界面上下文则可能十分钟就变一次。如果全部塞进同一个快照那恢复的时候要不就是太僵硬把不该重开的重开了要不就是太松散该恢复的位置没恢复。我的做法是快照整体保存但恢复时按层拆分执行。界面上下文负责快速还原现场数据上下文负责保证路径和配置正确任务上下文则只作为备注和校验信息。这样既保留了“一键恢复”的爽快感又不会因为界面状态的频繁变动把体验搞得迟钝。2.2 两级状态机和一条上下文栈设计选择时我对比过好多方案最后选了“开关状态 上下文栈”这个两级结构。第一级是一个开关表示“当前是否处于某条上下文的管理之下”。开关打开时我会约束自己的操作范围尽量只触碰当前上下文相关的窗口和文件开关关闭时一切回到普通工作状态。第二级是上下文栈用来记录切换的历史顺序。栈而不是树这个选择很关键。树结构适合表达“一个任务下分成多个子任务”但它引入的复杂度很高因为你还要决定父子节点之间怎么继承上下文。栈就简单得多你只需要记住“我从哪来现在在哪接下来回哪”。人一天的工作路径其实是线性的虽然逻辑上任务有嵌套但实际操作永远是串行的。栈的入栈和出栈天然对应“切走”和“切回”插入成本低心智负担小。栈还需要裁减。如果不裁切了一百次之后栈就会变得很深。我设置了三类裁减规则。第一固定某个上下文为“常驻”它可以被临时压栈但永远不被清理。第二最近最少使用的上下文会被标记为“可回收”当栈深度超过 20 条时自动清理最底层。第三两个连续且相邻的上下文如果内容高度相似合并成一条只保留最新的保存时间。2.3 上下文标识符和时间戳看着简单其实很重要每条上下文需要一个标识符。我一开始直接用任务名比如“权限改造”很快发现不行同一个任务可能被反复保存名字是一样但不同时期的状态完全不一样。后来改成“名称 序号 时间戳”的结构类似task: auth-refactor / seq: 12 / 2025-01-18T14:30。序号用来区分同一任务的多次快照时间戳用来做生命期管理。保存时机同样是核心问题。我发现两套不同的保存策略各有各的适用场景。手动保存适合关键阶段比如我刚完成一个功能自测想留个备份点那我来一次“保存”。自动保存适合持续记录我固定在三个时机自动落盘一是空闲五分钟二是标签页切换完成三秒后三是收到系统锁屏信号。自动保存的粒度不需要太细否则很容易把临时状态都存下来等到恢复时反而分不清哪条是有意义的。2.4 为什么最终用了混合存储而不是一张 SQLite 大表刚开始我打算用 SQLite 存所有上下文后来发现恢复时候会有一个绕不开的延迟把数据库里的快照内容转成实际工作区需要经历组装过程。快照越多组装越慢。现在我的方案是“热点上下文走独立目录 归档上下文走 SQLite”。保存时先把快照写入当前目录下的独立 JSON 文件文件名就是上下文 ID读取时直接加载这个文件同时把一条索引信息写入 SQLite用于检索历史版本。两者通过同一个 ID 关联。这样做的好处很实际。当前正在用的上下文最多七八条都是小文件读取基本是毫秒级。更早之前的版本只保留条目和索引真正需要回溯时再去做水合hydrate。数据是分成两层的一层照顾速度一层照顾容量。这背后其实就是“热点数据单独存”的老道理放在上下文管理上同样适用。3. 落地实现一个最小可用的 context-mode 切换器3.1 项目结构和依赖选择为了让这套思路能直接跑起来我做了个很轻的命令行工具代码量不大依赖只用了 Python 3.11 标准库和 SQLite。目录结构大概是这样的ctx/ saved/ auth-refactor__12.json auth-refactor__13.json marketing-plan__04.json index.db ctx_core.pysaved目录放热点 JSON 文件index.db放 SQLite 索引。ctx_core.py是核心逻辑不过几百行。我刻意没有用复杂框架因为上下文这种工具一旦被过度工程化维护成本会很快反超收益最后变成没人再用的玩具。3.2 命令设计保存、切换、恢复、清理命令我用的是朴素风格跟 git 的走向靠拢。常用命令就四个save、ls、switch、drop。命令作用示例ctx save name保存当前上下文ctx save auth-refactorctx ls列出可用的上下文标出最近使用ctx lsctx switch ctx_id切换并恢复上下文对应状态ctx switch auth-refactor__13ctx drop ctx_id删除某个上下文快照ctx drop auth-refactor__12额外还有attach和detach用来把某个窗口或某个临时文件挂到当前上下文名下。这个在设计里很重要因为不是所有资源都适合放进自动快照手动脉冲更可靠。3.3 核心代码逐行拆开看我抽了最核心的保存和恢复逻辑代码不长但把上下文管理的几个重点都覆盖了。import json import sqlite3 from pathlib import Path from datetime import datetime, timezone BASE_DIR Path.home() / .ctx SAVED_DIR BASE_DIR / saved INDEX_DB BASE_DIR / index.db def save_context(name: str, snapshot: dict) - str: SAVED_DIR.mkdir(parentsTrue, exist_okTrue) conn sqlite3.connect(INDEX_DB) conn.execute( CREATE TABLE IF NOT EXISTS ctx_index (id TEXT PRIMARY KEY, name TEXT, saved_at TEXT) ) now datetime.now(timezone.utc).isoformat() seq _next_seq(conn, name) ctx_id f{name}__{seq} snapshot[ctx_id] ctx_id snapshot[saved_at] now (SAVED_DIR / f{ctx_id}.json).write_text(json.dumps(snapshot, ensure_asciiFalse)) conn.execute( INSERT INTO ctx_index (id, name, saved_at) VALUES (?, ?, ?), (ctx_id, name, now), ) conn.commit() conn.close() return ctx_id保存逻辑分四步。先建目录和索引表这是防御式初始化。然后计算序号_next_seq会查 SQLite 里同一个名字下已经有多少条快照返回序号 13这样 ID 不会落地重复。接着把整个快照对象写进文件最后把索引登记进去。这里有一个细节我刻意把saved_at同时写进 JSON 和 SQLite恢复的时候只读文件就够检索的时候只查数据库就够了两边各自独立。恢复逻辑我愿意多花一点时间说明。def restore_context(ctx_id: str) - dict: snapshot_file SAVED_DIR / f{ctx_id}.json if not snapshot_file.exists(): raise FileNotFoundError(fsnapshot {ctx_id} not found) snapshot json.loads(snapshot_file.read_text()) # 分层恢复 for handler in handlers: handler.restore(snapshot.get(handler.layer_key, {})) return snapshothandlers是一个列表里面分别注册了文件恢复器、终端目录恢复器、浏览器标签恢复器。每个恢复器只认自己那一层的数据。我在设计的时候刻意把“恢复器做什么”和“快照里存什么”解耦这样以后想新增一个层比如数据库连接恢复不用改动保存逻辑只要往handlers里多注册一个实现就行。3.4 接层与前端的配合光有命令行还不够工具要真正帮上忙必须融入每天的操作流。我在编辑器快捷键上注册了两个组合键。一个组合键是“保存当前上下文”另一个是“快速切换最近两条上下文”。浏览器方面我写了一个小扩展负责把当前标签页的 URL 和标题写入一个临时 JSON 文件下一次执行restore的时候把对应标签重新打开。前端状态提示条也值得一提。我在终端提示符左侧加了一个小尾巴显示当前上下文 ID。比如auth-refactor__13和一段箭头。这样我在任意时刻或者在任意目录里都能一眼看到“我现在被包在哪条上下文里”。别小看这个提示它是最容易让人坚持用下去的功能。状态可见性一旦建立手动操作的频率就会大大下降。4. 在实践里踩过的坑和对应的修复思路4.1 上下文漂移你以为保存了其实没保存全我第一次跑通这套工具之后最常出现的意外是切换回来发现界面没有完全恢复。特别是浏览器标签总有少数几个没回来。查了很久才发现问题出在“保存时正在加载的页面”上。有些页面要好几秒才能加载完我在页面还没完成加载时就抓了 URL属于没抓全等加载完又产生了跳转比如登录跳转、重定向URL 已经不是最初那个了。解决思路是两层保存时在浏览器扩展里做一次延迟读取等页面进入空闲状态后再补一次 URL恢复时拼接键盘把“恢复 URL 列表”变成“恢复 URL 列表 延时重新匹配已打开标签”。现在恢复接口会先尝试匹配已有的标签如果 URL 已经打开就不重复开避免产生几十个一模一样的页签。这个修复让我少了不少烦心事。4.2 自动保存太勤快反而把有价值的版本挤掉自动保存本来是为了省心结果第一次上线测试我就发现它把重要的版本给覆盖了。原因是我用“同一个名称 最新序号”作为文件写入路径没做去重。比如我手动保存了“auth-refactor__12”三个钟头后自动保存又生成了一条一模一样的名字序号却变成了 13。这时候我想回退到手动保存的 12发现它已经被自动保存的 13 覆盖了。我把机制改成“手动保存和自动保存分开命名”。手动保存叫auth-refactor__manual__12自动保存叫auth-refactor__auto__13。同时增加一个protect标记手动保存的版本默认带保护不能被自动清理删除。这样自动记录成了后备不会淹没真正重要的检查点。这条规则后来让我回退了很多次每次都能精准找回关键版本。4.3 长任务中间的上下文漂移会越滚越大上下文另一种让人头疼的问题是漂移。比如我保存了一条“运营月度报告”但隔了三个小时才回来继续中间我又悄悄改了若干配置文件、临时拿终端跑了几条命令。回来恢复时这些中途产生的改动也会被认为是“恢复的一部分”于是引起冲突。它不是一次性发生的而是逐步累积的。我通过“时间戳差异记录”来处理。每次恢复时我并不是把整条上下文状态一股脑倒回去而是对比保存时的快照和当前的工作区状态生成一个“差异清单”。清单里有“新增”“变更”“删除”三种操作操作前会在终端二次确认。这个流程听起来冗余实际做起来很快因为它把“全量覆盖”变成了“有针对性的小步调整”更贴合真实使用的感受。4.4 上下文快照里的隐私和细节比你想象中多快照会存下很多意想不到的敏感内容。比如浏览器标签 URL 可能会携带查询参数里面可能包含用户 ID 甚至临时的访问令牌编辑器打开的文件路径可能暴露内部项目结构终端历史命令可能留下不可见的信息。这个问题不解决工具只能用在自己一个人、一台机器上根本不敢拿到团队里。我后来引入了两个保护机制。第一是脱敏规则URL 查询参数默认被替换成占位符需要显式开启才保留文件路径里匹配到.env、token、secret等关键词的条目保存时自动从快照里移除。第二是加密存储热点 JSON 默认不加密因为我需要读取速度归档到 SQLite 前会用本地密钥加密密钥放在系统 keyring 里。这个设计至少保证同步到其他设备时不会把全部上下文裸露在外。4.5 上下文的生命周期不该只有“永远存在”刚开始所有上下文不分大小一股脑放在列表里三个月后列表变得非常臃肿。每次ctx ls都要翻半天。我意识到上下文跟代码分支一样也需要生命周期管理。于是加了三条规则超过 90 天没有被访问的上下文自动标记为“已归档”从主列表隐藏明确标记为“已结束”的上下文进入只读归档不能继续切换手动固定常驻的上下文不受上述两条规则影响。生命周期规则落地后列表清爽了很多。这不是什么高超技术就是逼自己在设计里承认一件事上下文不是为了堆积是为了让“找到当下该用的那条”变得更快。5. context-mode 和“多开几个标签页”“VM 快照”的真实区别5.1 再多标签页也只是状态近似很多人觉得搞这么多幺蛾子干嘛直接多开几个窗口、多建几个浏览器标签组不就行了。我的体会是标签页是状态的近似不是状态本身。方式保存内容能不能跨机器迁移能不能按意图检索心智负担多开标签/窗口可见窗口布局通常不能不能低启动高维护VM 快照整个系统镜像能但成本高不能高context-mode分层快照 索引能体积小能按名称和标签查适中标签页保存的只是“哪些页面开在哪里”但不会告诉你这些页面是为了什么开的。我经常面对二十个标签真正需要的可能只有其中三个。context-mode 保存的是“意图”所以恢复之后不只是有标签还会有“这条上下文要干嘛”的说明文字。对长期项目来说这个差异非常大。5.2 VM 快照和容器镜像的力气使错了方向VM 快照和容器镜像解决的是环境一致性问题它可以保证你每次回到同一份操作系统环境。但它有几个毛病体积大、恢复慢、保存频率低。你不可能每五分钟就做一次 VM 快照也不可能为一个“改两行文案再切回来”的动作做镜像切换。context-mode 的定位恰好不同它保存的是轻量的逻辑状态而不是文件系统本身。文件系统有 git、有同步盘在管上下文工具不应该抢这个活。所以在架构上我设计了清晰的边界context-mode 只管“入口”不管“内容”。工作目录里的实际代码变动还是交给 git资料页面还是交给浏览器的历史记录目录里的文件还是交给文件同步工具。context-mode 只负责把“刚才那套入口组合”放进一个可复用的对象里。边界越清晰跟其他工具组合起来越顺。5.3 用了半年之后的实际变化如果你问我这东西到底值不值得做我的答案是因人而异但对我来说变化非常明显。过去我每次换任务平均要花五到八分钟“找回思路”翻聊天记录、看最近改的文件、回忆问题在哪。现在这个时间被压缩到了不足一分钟核心原因是思路找回了。另外意外的好处是因为每条上下文都会带一段“目标描述”我很少再做那种“不知道自己为什么打开这个页面”的操作行为变得比以前有目的性。5.4 我还在打磨的方向当前版本还不是最终形态。我接下来打算做两件事。第一是让上下文可以跨设备同步因为经常需要在台机和笔记本之间移动。同步时只同步已经脱敏且启用了加密的条目热点条目不参与跨设备的实时复制。第二是让上下文支持团队共享不同成员可以把“某个任务相关的上下文文件”发给对方而不是发一长串无从下手的指示。这俩方向短期内不会做成很重的服务大概率还是本地优先外部只做冷同步。如果你也想搞一套类似的 context-mode我的个人建议是别急着写一堆代码先从最笨的办法开始。手动维护一个文本文件记录你当前任务的名称、打开的文件、关键链接和下一步动作。等这个文本文件坚持用了两三个星期你就会自然发现哪些信息最常用、哪些恢复动作最重复那个时候再逐步自动化比闭门造车高效得多。上下文工具本质上是帮你记住“你为什么在这里”而不是把你所有操作都搬进数据库这个分寸从一开始就不能丢。