企业官网建设流程全解析

我最近在内部工作流里把context-mode从一个一闪而过的念头，变成了每天离不开的固定习惯。简单说，它是一套以"任务上下文"为单位的现场保存与恢复机制：你在做一件事的时候，把相关的工作目录、已打开的文件、正在用的环境变量、临时查到的资料统一打包成一份 version，也就是一个 context；下次切回来，一条命令就能回到当时的现场，连"我刚才写到哪一步"都不用重新回忆。

它解决的问题非常具体：大脑那点工作记忆扛不住频繁的任务切换，而常见的窗口布局保存、终端会话恢复，只救了窗口没救状态。这篇文章会把我从需求分析到实现、再到踩坑后的改进全过程展开，所有脚本都可以直接抄来改，适合喜欢自己折腾工作流、经常在多项目并行场景中挣扎的开发者。

1. 我为什么非要做 context-mode：工作记忆溢出的切肤之痛

1.1 一次上午 10 点的崩溃现场

先说一个真实发生在我自己机器上的场景。某天上午，我正在修一个跨版本的数据兼容问题，刚在一堆调用链里定位到某个函数需要改，消息就弹了出来：新需求要紧急看一下。我只好把当前代码的来龙去脉写进一条备注，切到另一个项目，打开几个文件瞄了几眼接口文档，又跑去测试环境拉数据。

半小时后回到原来的终端窗口，我盯着满屏的代码愣住了。我知道自己要改那个函数，但"为什么改、改到这里还剩什么没验证"已经变得模模糊糊。无奈之下，我只能把之前关掉的文件一排排重新点开，顺着控制台日志一点点找回当时的思路。真正让我崩溃的不是加班，而是明明刚才还在脑子里的东西，一旦被强制切走，就要花几分钟甚至更久才能重新加载回来。

这种瞬间我估摸很多开发者都经历过。文件多不是问题，问题是所有关键上下文都悬在脑内缓存里，没有任何外部工具帮我们落地。传统做法是把一堆窗口开着别关，或者开一堆终端标签页，实际上只是把切换成本延后了，并没有降低。

1.2 任务切换不是免费的，昂贵的其实是"回忆成本"

很多人把任务切换的代价简单理解为"重新读代码的时间"。其实真正贵的是回忆成本：你上次做到哪里、下一步打算验证什么、这个临时变量是拿来干嘛的。代码还能靠翻文件找回，但那些还没落地的思考过程，一旦断掉就丢了。

这里有个不算新鲜但很痛的规律：工作记忆的容量极小，只能同时握住几个概念。当你同时处理多个任务时，每个任务对应的变量、路径、命令和临时决策都在抢占这有限的缓存空间。context-mode 想做的事情，就是把这些内容从脑内搬到磁盘上，做成一份可搜索、可恢复、可对比的快照。

我后来回忆，自己以前常用的"我来得及就把它记住"策略，本质上是在赌任务切换次数不会太多。而现实是，一个上午可能切换四五次。与其锻炼脑力，不如接受一个朴素的道理：如果你的工作本身就擅长打断你，那就让工具替你记住"现场"。

1.3 现有方案为什么都不够：workspace 只保存了"窗口"而不是"脑子"

我并不是没有用过现成的工具，它们各有价值，但都只覆盖了局部。

主流 IDE 的 Workspace 类型功能能保存窗口布局、最近打开的文件列表，这解决了"文件在哪"的问题。可它不知道你当时正在执行哪条命令，也不关心你临时写在注释里的疑问。终端复用器能保存一组终端会话，但会话之间往往没有主题关联，就算保存了三个面板，你也未必记得当初开这几个面板是为了调查同一个故障。笔记工具倒是能记录想法，但它和应用环境是割裂的，写完一条"这里要改成新接口"之后，你仍然需要手动切换到对应目录、打开对应文件，才能继续操作。

所以 context-mode 的思路是把这三类信息收敛到一起，统一放在一个文本目录里。它不像数据库那样强调整合，更像一个现场照片：记录环境、文件、想法和下一步动作，恢复的时候一次性把所有东西都放回眼前。这个思路并不复杂，但真正做成之后，我才意识到"少了一个动作"对心流有多重要。

2. context-mode 的核心抽象：把现场做成快照

2.1 快照里到底装了什么

我的 context 目录里通常会放六类东西，少了哪一类，恢复的时候都会觉得"差了点意思"。

第一是工作目录。这看起来最基础，但非常重要。很多任务绑定在特定仓库或者子目录里，如果没有记录 cwd，光切目录就要想一下。第二是当前打开的文件列表。恢复现场时，文件有没有开在桌面上，直接影响能不能立刻进入状态。第三是环境变量，比如虚拟环境路径、当前分支名、某组件的监听端口。这些信息往往不在代码仓库里，却是本地调试的关键。第四是最近要执行的命令，比方说"启动开发服务"或者"查看日志"。不需要把终端每个字都录下来，但至少要留下几条核心命令。第五是临时笔记，也就是大脑中那些还没整理成文档的碎片想法。第六是书签或参考资料链接，通常是本次任务相关的文档入口。

我比较看重的其实是"临时笔记+命令"这两项。以前它们分散在剪贴板、微信文件传输助手和各种 txt 里，丢了就再也找不回来。放进 context 之后，每次存档都顺便把思考碎片洗一遍，哪怕是乱写的也没关系，能帮自己恢复记忆就行。

2.2 context 文件长什么样：一份可读可改的配置

我的数据组织方式很简单，按 context 名称建目录，不建数据库。

~/.context-mode/ └── contexts/ └── task-001/ ├── state.json ├── files.txt ├── env.sh └── scratch.md

state.json保存元信息，比如创建时间、最后使用时间；files.txt每一行是一个文件路径，恢复时按这个列表逐个打开；env.sh是需要 source 进 shell 的环境变量和别名；scratch.md是任务小抄，随写随存。

state.json内容大概长这样：

{ "name": "task-001", "created": "2025-04-17T10:00:00+08:00", "cwd": "~/work/project-a", "files": [ "src/controller.py", "tests/test_controller.py", "docs/api.md" ], "env_vars": { "VIRTUAL_ENV": "venv", "CURRENT_BRANCH": "feat/ctx" }, "terminal_commands": [ "make dev", "tail -f logs/app.log" ] }

实际使用时，files.txt可以比state.json里的 files 字段更朴素，因为编辑器插件只需要逐行读取；env.sh则是用户在切换 context 时手动维护的，比如声明export CURRENT_BRANCH=feat/ctx。

你可能会问：为什么不用一个 SQLite 数据库，把所有 context 塞进去？我不是不想，而是刻意保持简单。目录加纯文本的好处是可以直接 grep、可以直接 diff、可以放进 Git 管理，手工改错了一个字符也不怕。工具一旦退化成黑盒，我就不会信任它；而文本状态在任何时候都是透明的。

2.3 为什么用目录加纯文本，而不是一个数据库

再展开说说这个选择。context 的本质是一个环境的快照，不是知识库。快照需要频繁增删改，但同一时刻活跃的 context 数量不会很多，最多十几个。用数据库反而会把简单问题复杂化：你要做表设计、备份恢复、权限控制，还要担心数据文件损坏。

纯文本目录有几个非常实在的优点。第一是可以用编辑器直接修改，比如我临时想删掉某个文件记录，打开files.txt删一行就行。第二是可以纳入版本管理，每次存档或修改后，我可以用 Git 查看某个 context 在时间轴上的变化，找回一两周前删除的某条命令。第三是更容易被脚本集成，因为只要懂最基本的文件读写，就能写一个自己的 capture 或 switch 工具。

当然，纯文本在并发写入上确实弱，但个人工具本来就很少有并发需求。一句话：再复杂的状态，只要你能把它读出来、改回去、放进备份，它就不太容易失控。

3. 手把手实现一个迷你 context-mode：核心逻辑与编辑器联动

3.1 先写 capture：把当前环境定格下来

我实现的最小可用版本只有两个函数：capture和switch。先看 capture。

context_mode_capture() { local name="$1" [ -z "$name" ] && { echo "usage: context_mode_capture <name>"; return 1; } local dir="$HOME/.context-mode/contexts/$name" mkdir -p "$dir" pwd > "$dir/cwd" [ -f "$dir/files.txt" ] || : > "$dir/files.txt" [ -f "$dir/env.sh" ] || : > "$dir/env.sh" [ -f "$dir/scratch.md" ] || touch "$dir/scratch.md" cat > "$dir/state.json" <<EOF { "name": "$name", "updated": "$(date +%Y-%m-%dT%H:%M:%S%z)", "cwd": "$(pwd)" } EOF echo "context '$name' captured at $dir" }

这个函数只做三件事：创建 context 目录；记录当前工作目录；更新元信息。files.txt和env.sh如果没有就初始化成空文件。重点在于"只负责定格"，不负责猜你要哪些文件。

那么文件列表从哪里来？如果你的编辑器支持导出会话，就在 capture 之前把当前打开的缓冲区列表追加到files.txt。如果不支持，也有一个笨但特别可靠的办法：手动编辑files.txt，把你接下来要切回来的文件一行一个写进去。我在早期就是这么干的，虽然看起来原始，但正因为手动，我对每个 context 里有什么心里很有数。

3.2 switch 如何恢复现场

switch 函数负责把环境还原回来。

context_mode_switch() { local name="$1" local dir="$HOME/.context-mode/contexts/$name" [ -d "$dir" ] || { echo "context '$name' not found"; return 1; } local cwd_file="$dir/cwd" [ -f "$cwd_file" ] && cd "$(cat "$cwd_file")" || return 1 if [ -f "$dir/env.sh" ]; then . "$dir/env.sh" fi if [ -f "$dir/files.txt" ]; then while IFS= read -r f; do [ -n "$f" ] && open_current_editor "$f" done < "$dir/files.txt" fi echo "switched to context '$name' (cwd: $(pwd))" }

open_current_editor是唯一的抽象点，每个人绑定方式不同。如果你的编辑器支持从命令行打开文件列表，可以直接调用它的命令行参数；如果不支持，也可以在编辑器里写一个插件，读取files.txt后批量打开。

脚本里最值得注意的细节是[ -n "$f" ]。空行在文本文件里非常常见，如果不加这个判断，恢复现场时会多出一堆无效打开命令，很烦。另外，env.sh用的是.而不是sh env.sh，目的是让环境变量的修改留在当前 shell 里，而不是子 shell 里消失。

3.3 怎么和编辑器绑定，而不绑定任何一家

很多人以为 context-mode 必须做成某个编辑器的专属插件。其实核心脚本只需要暴露两个入口：存档入口告诉我"现在打开的文件是哪些"，恢复入口告诉我"打开这些路径"。

我在编辑器配置里做了两个快捷键：一个调用 capture 前，先把当前所有文件列表写进files.txt，再执行context_mode_capture task-xxx；另一个直接执行context_mode_switch task-xxx。

如果你的编辑器暂时不支持写文件列表，还有一种通用的 bridge 方案：在 shell 里维护一个变量$ACTIVE_FILES，每次打开文件时手动把它更新到上下文文件里。这听起来麻烦，但只要养成习惯，其实每次只需要一条命令。我有一位同事用的是完全手写files.txt的方案，他的 context-mode 依旧跑得很顺，因为他真正依赖的是这套存档逻辑，而不是某个花哨插件。

3.4 一段完整的操作演示

下面是一个典型的使用流程，假设我在做 task-a，中途要切到 task-b。

第一次切出去之前，执行：

context_mode_capture task-a

这时task-a目录里存好了 cwd、文件列表和环境。然后切到另一个项目，开始处理 task-b：

context_mode_capture task-b

如果想回到 task-a，不需要记得之前打开哪些文件，只需要：

context_mode_switch task-a

shell 会切回 task-a 的工作目录，source 好当时的环境变量，再把文件列表里的文件重新打开。整个过程不到一秒，但省掉的是我大脑重新加载上下文的几分钟。

我后来把命令封装成cm c <name>和cm s <name>，两个一字母的命令，成本低到几乎不需要思考。"低摩擦"非常重要，如果每次存档要敲一大串命令，你很快就会放弃它。

4. 实测一个月后，我踩过的那些坑

4.1 未保存缓冲区，被快照"吃掉"了

第一个坑非常疼。某次我在编辑器里改了三个文件，还没保存就执行了 capture。当时我下意识觉得"文件都在编辑器里，应该没问题"，结果切走再切回来，编辑器打开的是磁盘上的旧版本，改动全丢了。

原因是files.txt记录的是路径，不是缓冲区内容。capture 只管"打开哪些文件"，管不了"文件里有哪些未落盘的修改"。从那以后，我把 capture 流程改成了强制保存：先通知编辑器保存所有缓冲区，再生成 file list。如果你用的编辑器有"保存全部"命令，把它绑到 capture 快捷键的前置步骤里，不要依赖肌肉记忆。

4.2 绝对路径在机器间漂移

context 里存了/home/me/work/project-a这样的绝对路径。在自己机器上没问题，但一旦换电脑、换用户名或把仓库克隆到另一个目录，整条路径就废了。我经历过一次在另一台机器上打开 context，发现 cwd 指向不存在的目录，那一瞬间真的很想砸键盘。

解决方式很简单：存档时优先存仓库相对路径和仓库根目录，恢复时用当前机器上的仓库根目录去拼接。比如 cwd 记录成~/work/project-a这种带~的相对形式，而不是$HOME/work/project-a展开后的绝对路径；文件列表也一律存相对cwd的路径。这样只要仓库位置符合约定，就能跨机器恢复。

4.3 嵌套 context 导致 env 互相污染

task-a 的env.sh里定义了export CURRENT_BRANCH=feat/a，切到 task-b 后，task-b 的env.sh里只有export PORT=3000。结果 task-b 环境里莫名其妙多了一个CURRENT_BRANCH=feat/a，有些脚本读到这个变量就会走错分支。

根因是 switch 没有清理旧 context 的环境变量。这比想象中常见。我的改进是维护一个"环境变量白名单"，切换时先把白名单里已有的变量值备份到临时文件，source 完新 context 之后，再把不在env.sh里的旧值清掉。

# 切换前 local backup_file="$dir/env_backup_$(date +%s).sh" declare -x > "$backup_file" # source 新 context . "$dir/env.sh" # 清理：这里按你的白名单列表逐个比较

这个方法不算完美，但能把传染性降到最低。至少我现在不会因为切 context 而带着一堆来自上个任务的幽灵变量。

4.4 自动恢复太积极，反而打断手头思路

我一开始总想让工具更"聪明"：进入某个目录就自动加载对应 context。比如打开终端时检测到当前目录是 project-a，就自动执行switch task-a。听起来很顺，但实际操作中非常吵。

有次我只是想临时看一眼 project-a 的某个配置，还没决定要不要进入工作状态，自动恢复就弹出来，把一堆文件窗口全部打开，加上一堆环境变量，瞬间把当前终端弄得乱七八糟。这种"过度帮忙"比不帮忙还难受。

后来我把自动触发改成了"手动触发、自动恢复"：存档要手动按，恢复可以自动执行，但必须绑定在一个显眼的快捷键上。自动化不是越多越好，它必须发生在你真正需要的那一刻，而不是由目录变化这种弱信号来猜测。

4.5 这些问题沉淀成了一张表

这张表基本就是我用一个月 context-mode 的全部教训。踩坑不可怕，怕的是每次都得重新踩一遍。

5. 进阶玩法与适用边界：context-mode 不该替你决定一切

5.1 写作、研究和并行项目怎么用

code 开发是 context-mode 最常见的场景，但我用得最多的是写作和混合研究。

写作时，我把资料链接、草稿路径、以及几条待办命令放进同一个 context，名称叫article-context-mode。查资料时短暂切走，随时能回到草稿；引用资料时不用重新找链接，因为有 scratch.md。

做技术调查时，我会把发现的问题、对应日志片段和要验证的命令存进 context。以前搞这种调查最怕半路被打断，现在哪怕隔了三天，只要回到这个 context，连当时的临时结论都能看到。它最大的价值是把零散信息串成一条时间线，而不是让它们躺在各自的文件里互不相认。

并行项目维护就更直接了：一个 project 对应一个 code context，一个临时故障对应一个 hotfix context。命名上用project-name-任务描述的格式，不会混。

5.2 hook 要克制：自动化不是越多越好

我见过一些人把 context-mode 做成全自动：打开仓库自动记录，关闭仓库自动存档，甚至连文件变化都实时写进 context。听起来高大上，但实际用起来只会让你觉得无时无刻被监视。

我给自己的规则很简单：只有三种情况值得自动触发。第一是长时间离开工位，回来时需要恢复现场；第二是从一个任务明确切换到另一个任务；第三是结束一天工作前，把当天的 context 更新一次。其余情况都手动。

自动化应该降低选择成本，而不是增加噪音。context-mode 更像一台相机，随手拍一下才能留住现场；如果相机永远在录，你反而找不到重点。

5.3 适合谁、不适合谁

这套东西不是灵丹妙药，我对适用人群有自己的判断。

如果你只写一个长期项目、每天固定的几个文件，那 context-mode 带来的收益很小。它的核心价值出现在"被频繁打断"和"任务类型多样"的组合场景里。我见过更极端的用法：有人给每个客户建立了 context，从代码到会议记录全放在一起，这其实已经不是工具了，而是工作方式。

5.4 我的最终配置和最想说的一句话

我最后的配置非常朴素：三个别名，一个目录，一份习惯。

alias cmc='context_mode_capture' alias cms='context_mode_switch' alias cml='ls ~/.context-mode/contexts'

存就用cmc 名字，切入就用cms 名字，看有哪些就用cml。没有后台服务，没有数据库，没有复杂的规则。真正让我留下的，不是这些脚本写得有多好，而是它让我把"在哪个问题上"这个状态从脑内搬到了磁盘上，从此告别了反复重构记忆的狼狈。

我自己实际用下来最大的体会是：context-mode 的第一版本不需要完美，只需要一个目录和两个函数。等你真正依赖它之后，自然会根据自己的痛点去加新功能。反过来，如果一开始就奔着一套无所不包的框架去做，大概率撑不过第一周。开始做吧，"记录现场"这个动作本身，就已经能帮你赢回大量时间。