企业官网建设流程全解析

1. 先想明白“上下文丢失”到底丢了什么

1.1 一次被打断的真实场景

我做这个叫context-mode的小项目，起因不是什么宏大的提效命题，而是我自己的日常实在太碎了。

典型的一天是这样的：上午正对着一个数据处理模块调参，刚把报错定位到某个边界条件，同事过来讨论排期；五分钟前还在脑子里排布的几个变量，等回到工位上只剩下“刚才看到哪里了”的模糊印象。更麻烦的是下午切换到另一个脚本任务，中途又插入一个临时故障排查，等到晚上再切回主线任务时，光是回忆“我上次分析到哪一步、为什么做了那个决定、还有哪些假设没验证”就花掉了大把时间。

这类损耗有个很经典的名词叫“任务切换代价”，指的是人在多个任务之间来回切换时，大脑需要重新加载每个任务的背景信息，这个加载过程既耗时又耗注意力。以前我靠的是“备忘录+浏览器标签页+脑内记忆”三件套，但真实效果很不稳定：标签页一多就懒得整理，备忘录写得太简略等于没写，脑内记忆在连续加班的时候完全不可靠。

后来我意识到一个关键点：我缺的不是笔记工具，也不是待办清单，而是一个能够把“我做某件事时大脑里的全部背景信息”存下来、并在需要时完整恢复出来的工具。顺着这个思路，我做了context-mode。

1.2 上下文的三种形态：环境态、状态态、记忆态

要做一个上下文管理工具，首先得把“上下文”这个词拆清楚。我把日常工作里的上下文分成三层。

第一层是“环境态”，指当前工作所依赖的外部环境。写代码时，环境态包括当前所在的目录、用的分支、开启的服务端口、依赖的配置文件；写文档时，环境态是当前打开的章节、参考的资料路径、排期表的位置。环境态的特点是“客观存在，但容易散落”，你换一台机器或者隔两天回来，光是把环境重新搭起来就要花不少时间。

第二层是“状态态”，指工作进行到了哪一步。它回答的是“我做到了什么程度”这类问题。比如“数据清洗脚本已经跑通前三个步骤”“接口文档写到第4节”“某Bug怀疑和缓存刷新机制有关，还没验证”。状态态是动态的，也是最容易丢失的，因为它在你的工作区里并没有对应的物理载体，只存在于你的短期记忆里。

第三层是“记忆态”，指你做决定时依赖的复杂背景，包括分析过程、对比过的选项、暂时搁置的假设、还没验证的想法。记忆态不像环境态能通过列表查看，也不像状态态能用进度条表达，它更像是一个思维切片。很多“切回来之后接不上”的体验，本质都是记忆态没有保存。

context-mode的设计目标，就是把这个三层信息统一封装成一份可恢复的上下文记录。环境态用命令自动获取，状态态靠人用一两句话补完，记忆态通过关联文件把分析过程固化下来。三层合在一起，才构成一份真正有用的上下文。

1.3 把上下文做成显式工程的目标

为什么要用工具来做这件事，而不是靠自律？因为人脑的“上下文缓存”容量实在有限，而且特别容易受干扰。与其逼自己记，不如把这些信息显式地保存到外部介质里，让工具负责存取，人只负责在关键节点做一次简单的记录。

我给自己定了几条原则：记录动作必须足够快，不能超过十秒钟，否则就会懒得记；恢复动作必须足够完整，不能只给目录不给思维过程；工具不能改变我原有的工作方式，只能在旁边默默辅助。这三点是整个项目所有设计决策的出发点。

2. 设计一个能落地的上下文栈

2.1 为什么是栈，不是数据库

刚开始我也想过要不要做成一个能长期保存、按项目分类、支持全量搜索的数据库型工具。但做了一半就发现不对：上下文和知识库是两种不同的东西。知识库追求的是长期积累和可检索，而上下文最大的特点是“只在某段时间内有效”，它服务于当前进行的任务，任务切换之后，旧上下文的价值会迅速衰减。

我最后采用了“栈”这个结构。你可以把它想象成洗碗池里的盘子架：每开始一个新任务，就往顶上放一个新上下文；任务暂时放到一边时，这个上下文不删除，只是被压到下面；切回旧任务时，把对应上下文重新拿出来放到栈顶。栈天然适配“多任务并行但单线程操作”的特点。

和数据库相比，栈的另一个好处是心智负担低。它强制你任何时候都只需要关心“当前这个任务”，不需要考虑长期分类、标签体系、目录规划这些东西。栈顶永远代表当下，栈里压着的是将来可能要回访的旧工作。

2.2 捕获（capture）的粒度：应该记什么，不记什么

设计捕获功能时，我踩过一个很典型的坑：一开始想记录一切，包括终端输出、浏览器历史、光标位置，结果做出来的东西又重又没用。因为上下文工具不是录屏软件，它不应该记录“所有信息”，而应该记录“恢复思维所需的最小信息集”。

环境态这一层，我通过几个内置命令自动获取：当前工作目录、活跃分支、最近的 Git 记录、打开的配置文件路径。这些信息一条命令就能拿到，不需要人工补充。

状态态这一层，我要求每次捕获时写一句话，格式很自由，比如“完成了数据校验模块，下一步接接口文档”“正在查定时任务偶发失败的问题，怀疑和内存占用有关”。这句话的目的是给未来的自己一个衔接点。

记忆态这一层，我把关联文件的路径和简要备注打包进上下文。比如某次排查问题，我把相关的日志文件、临时分析脚本、怀疑对象列表都附着在上下文里，恢复时一键打开，不需要再去翻找。这样既保证了信息完整度，又避免了“什么都存”导致的臃肿。

2.3 恢复（restore）的三种策略

恢复是上下文工具里最难做对的部分。一条上下文如果只是被展示出来，那它和一个笔记没有任何区别；只有真正把当前工作区恢复到记录时的状态，它才算合格的工具。

我在实现里设计了三种恢复策略。第一种是全量恢复，适用于切回主线任务的情况：把目录切过去、打开关联文件、恢复 Shell 历史、展示上下文说明。第二种是增量恢复，适用于只想找回某个具体信息的情况，比如只需要打开某个配置文件或某段日志，不需要改变当前的工作目录。第三种是差分恢复，适用于两个任务之间只有细微差别的情况：工具会对比当前上下文和目标上下文的差异，只把不同的部分恢复过去。

三种策略并不是一开始就设计好的，而是在使用中慢慢总结出来的。很多任务其实不需要完整切换，只是“借用”一下之前的某个分析结论，这时全量恢复反而打扰了当下的思路。

2.4 存储格式与结构

存储格式我最终选择了本地 JSON 文件，原因有三个：可读性好，可以直接手改；格式简单，方便用脚本和编辑器插件读取；文件级存储天然支持版本管理，可以随时回滚到某次捕获的状态。

每个上下文记录包含以下核心字段：

• id：上下文唯一标识，用创建时间加短随机串生成，避免重名
• label：任务的简短名称，比如“数据清洗脚本优化”
• notes：用一两句话记录当前状态，由用户在捕获时填写
• paths：关联文件或目录的绝对路径列表
• tags：用于快速筛选的标签列表，比如“前端”“后端”“紧急”
• env：环境快照，记录工作目录、Shell 历史等
• created_at、captured_at：创建时间和最后捕获时间
• data：扩展字段，留给未来功能使用

这个结构其实非常简单，但足够支撑我在实际工作中的所有场景。复杂的东西都留给了上层逻辑，格式本身越简单越好。

3. 实现一个最小可用的 context-mode

3.1 环境准备与整体清单

我选用了 Node.js 来实现这个 CLI 工具。选它不是因为性能最强，而是因为生态成熟、跨平台支持好，而且让人能用 npm 全局安装，在任何目录下都能直接通过cm命令调用。

整个项目由五个模块组成：命令解析模块负责处理子命令和参数；上下文仓库模块负责读写 JSON 文件；环境快照模块负责抓取当前工作状态；恢复模块负责把上下文应用到工作区；交互模块负责展示列表、接受输入。

提示：如果你也想复刻一个，不一定非要用 Node.js，Python 或 Go 也完全可以。核心不在语言，而在上下文数据模型的设计是否清晰。

3.2 CLI 骨架代码

一个靠谱的 CLI 首先要有一个清晰的子命令结构。我最终确定了一组最小命令集：capture捕获当前工作状态，switch切换上下文，restore恢复指定上下文，list查看已有上下文，delete删除不再需要的上下文。

# 捕获当前状态到上下文，label 是必填参数 cm capture "数据清洗脚本优化" # 切换到某个上下文 cm switch 数据清洗 # 恢复最近一次捕获的状态 cm restore --latest # 列出所有上下文 cm list

命令解析我没有用第三方库，直接用process.argv手工写了简单的映射，因为命令集很小，引入额外依赖反而增加维护成本。

3.3 上下文捕获模块实现

捕获模块是我花时间最多的地方，因为“快”是这条命令的核心体验。设计目标是不超过一秒完成环境快照的抓取和写入。

环境快照里，我重点关注三个信息源：

• 当前工作目录，直接读process.cwd()；
• 活跃分支和最近提交，执行git branch --show-current和git log --oneline -5；
• 当前开启的会话和后台服务，读取系统进程表中和自己工作目录相关的进程。

// 文件: lib/collect-env.js const { execSync } = require('child_process'); function collectEnv(cwd) { const env = { cwd }; try { env.branch = execSync('git branch --show-current', { cwd, encoding: 'utf-8' }).trim(); env.recentLog = execSync('git log --oneline -5', { cwd, encoding: 'utf-8' }).trim(); } catch (e) { env.branch = ''; env.recentLog = ''; } return env; }

用户补充的状态说明是最关键也最容易敷衍过去的部分。我特意把交互设计成阻塞式提问：“当前任务的进展是什么？”强制用户必须留下至少一句话。如果用户直接回车，命令会提醒并再次询问，直到收到有效输入为止。

3.4 切换与恢复逻辑

switch命令是整套工具里逻辑最复杂的一个。它需要做三件事：保存当前上下文（如果还没保存过）、把目标上下文设置为当前上下文、执行恢复操作。

恢复逻辑的伪代码大致是这样的：

1. 读取目标上下文 JSON 文件 2. 比对当前工作区和目标上下文的 env 差异 3. 如果目录不同，执行 cd 切换 4. 逐个打开目标上下文记录的 paths 文件 5. 将上下文说明渲染到终端顶部 6. 把目标上下文标记为“当前活跃”

这里有一个很现实的问题：如果当前工作区里有未保存的修改，直接切换目录会导致修改被误伤。所以我在switch里增加了一道安全检查，检测到未提交的 Git 变更时，会提示用户先提交或暂存，而不是直接切换。这个保护逻辑救过我好几次。

3.5 渲染与交互：简单即美德

CLI 工具的交互体验，核心原则是“不给用户添堵”。列表展示我做了三种视图：默认视图只显示id和label，适合快速浏览；详细视图会展示全部字段，适合深度检查某个上下文；摘要视图用一行文本显示每个上下文的要点，适合做每日回顾。

终端彩色输出和表格对齐我用了通用的控制字符，没有引入 Unicod 表格库，因为这部分不是核心价值。真正让工具变得好用的，反而是另一个细节：list命令支持用关键词模糊搜索。搜索时会对label、notes、tags三个字段做子串匹配，一次输入就能快速定位需要恢复的任务。

4. 把它嵌入工作流之后，我补了哪些关键能力

4.1 全局快捷键与自动捕获

CLI 工具最大的问题是：它需要你主动打开终端输入命令。而人在专注工作时往往不会想到要主动记录，等想起要记录时，上下文已经丢了一半。

所以我给context-mode加了全局快捷键支持，在系统层面注册了一个组合键，按下后立即调起一个简洁的捕获弹窗，自动抓取当前环境信息，只等待用户输入一句话的状态说明。整个动作大约三秒钟完成，比开终端敲命令舒服得多。

为了弥补“忘了按快捷键”的情况，我还加了一个半自动机制：检测到git switch操作或工作目录变化超过一定阈值时，会在后台静默捕获当前状态，并将捕获的结果标记为“临时上下文”。后续用户可以在列表里决定是保留还是清理。这个机制不是为了完全取代手动捕获，而是为了兜底，确保至少有一个可回退的状态。

4.2 编辑器/终端集成

一周的实测之后我发现，环境快照里的目录和分支信息虽然有用，但不足以支撑真正复杂的任务迁移。比如上下文记录里有一串关联文件，可如果恢复到一半，用户发现配置文件里还没有保存最新版本，那整个恢复就打了折扣。

于是我开始做编辑器侧的集成，把“保存当前打开文件列表”这个能力扩展成“保存文件列表 + 各文件的未提交改动摘要”。这样恢复上下文时，不仅能打开文件，还能通过对比改动摘要快速判断该文件当时处于什么状态。这个功能对写作类任务尤其有用，章节写了一半、材料贴了一半，恢复后一眼就能看到差异在哪。

终端方面的集成则简单许多：上下文记录里保存终端多标签页的分组信息，通过一组脚本恢复到对应的标签页布局。这部分我做得比较克制，因为终端布局管理属于高度个人化的东西，工具不应该强行统一。

4.3 时间衰减与自动归档

上下文存多了以后，列表会变得很长，反而干扰快速定位。我有段时间上下文积累了几百条，list输出能刷满好几个终端屏，搜索起来也很费劲。

解决这个问题我用了一个叫“时间衰减”的思路：上下文的排序权重会随着时间自然降低，七天内访问过的上下文排在最前，超过三十天没有访问的上下文自动移到归档区，归档区不进入默认列表，只在主动搜索时出现。这不单单是删除，而是保留了一份“出栈”的历史记录，万一某天要回溯一个特别老的任务，仍然能找回来。

注意：自动归档的阈值需要根据自己的工作节奏调整。我一开始设的三十天偏长，后来改成十四天，列表清爽很多。

4.4 轻量加密与隐私保护

工作上下文里很可能包含敏感信息，比如数据库连接串、内部服务器地址、未公开的业务逻辑。如果单纯把上下文明文存在本地，万一临时借电脑给别人用，就等于把底牌全部翻了出来。

我在存储层加了一层可选加密，使用系统密钥环里的主密钥对上下文文件做对称加密。加密的粒度是“上下文文件整体”，不是单个字段，这样实现起来简单可靠。恢复时输入一次主密码，后续在会话内保持解锁状态。这个功能不是默认开启的，因为加密会拖慢捕获和恢复的速度，但一旦涉及敏感项目，我会主动开启。

5. 实测中踩过的坑和完整排查记录

5.1 “恢复后文件反而乱了”的根因

第一次严重事故是这样的：某任务 A 捕获上下文之后，我在任务 B 里修改了同一个目录下的文件。回到任务 A 执行恢复，工具直接把整个工作目录切过去。结果任务 B 里的未提交修改被隐藏，任务 A 的旧文件版本又和新产生的修改混在一起，整个目录乱成一团。

排查后定位到根因：switch时没有检查目标上下文记录的环境是否与当前环境冲突。修复方案是在switch命令里加入了“环境冲突预检”环节，比较当前目录的 Git 工作区状态和目标上下文的记录状态，如果发现未提交修改，就中止切换并列出冲突文件列表，让用户手动决定处理方式。

5.2 “上下文不完整”的根因

另一个高频问题是：有时候恢复上下文后，明明文件和目录都打开了，但思路还是接不上。我一开始以为是笔记写得太简略，后来仔细分析才发现是环境快照捕捉了，记忆态却没有被有效捕获。

具体表现是：上下文的notes只写了“研究缓存问题”，没有记录“已经确认了 Redis 连接参数没问题，怀疑是本地缓存目录权限异常”。缺失的这部分，恰恰是整个排查过程中最关键的思维分支。

修复方式不是强制用户写更长的笔记，而是在捕获交互里增加引导性提问：“当前进度”和“下一步计划”分开填写。这个改动看似简单，实际效果非常好。把“我现在在哪”和“我接下来要去哪”分开，思维衔接就顺畅得多。

5.3 大上下文导致的卡顿问题

使用四个月后，工具出现了一个性能问题：某个上下文所附的关联文件数量膨胀到了五十多个，每次恢复都要逐个打开文件，整个工具卡顿得没法用。排查发现是我在捕获时设置了一个很宽松的规则，会把最近访问过的所有文件都自动加入paths，日久天长就积累了大量冗余。

修复思路不是加缓存，而是改变记录策略：默认只记录用户显式选择的关键文件，自动加入的文件降级为“候选引用”，不参与恢复时的自动打开。这个改动直接让恢复速度回落到了秒级。

6. 这类工具后续可以扩展的方向

context-mode目前已经是我每天离不开的小工具，但它还有很多明确可以扩展的空间。比如结合终端智能提示，在新建目录时主动询问是否要恢复某个上下文；比如支持多设备同步，让上下文在笔记本和台式机之间无缝迁移；再比如引入语义索引，让恢复不再依赖关键词匹配，而是通过自然语言描述来检索相关上下文。

我在实现这些扩展前的原则始终没变：每个功能都必须服务于“更快地保存当前思维、更完整地恢复当前思维”这一目标，而不是为了堆砌功能而堆砌功能。一个上下文工具如果本身用起来很重，那它就已经失败了。