企业官网建设流程全解析

过去几个月，我一直在用一套自己搭的 context-mode 工作流处理日常开发和多任务切换。说真的，一开始我只是被各种半途中断的任务逼得没办法，后来发现把上下文管理变成显式模式以后，切换成本降了不止一半。如果你也经常遇到这种场景——代码写了一半被打断、AI 对话越聊越跑偏、脑子里同时挂着三四个任务的进度，那么这套思路应该能帮到你。

所谓 context-mode，我的理解是：把大脑里那些模糊的「我记得大概在做什么」，变成一个显式的、可切换的、有记录的状态。它不是某个现成软件，而是一种工作方式。我会把完整的设计思路、踩过的坑、以及在 AI 编程场景里的实际用法都写出来，方便你参考之后直接搭一套自己的版本。

1. context-mode 到底解决什么问题：从一次"上下文崩坏"说起

有一次周五下午，我正集中精力改一个 API 的分页逻辑，代码写到一半，脑子里全是游标式分页的边界条件。这时候同事跑过来问一个线上告警的事，我看了一下，顺手帮忙确认了日志和监控面板，大概花了八分钟。再回到编辑器里，看着那半截函数，我居然发了好几秒愣——刚才到底打算怎么处理这个 null 判断？

这不是记性差的问题。我后来复盘，发现真正的问题是：我在那个瞬间丢失了「任务上下文」。操作系统的进程被切走之后会保存寄存器、堆栈和内存页，但人脑没有这个机制。一旦注意力被强制切换，那一大堆隐式的、没写下来的中间状态就全没了。重新捡起来不是看几行代码就能解决，你得重新回忆目标、重新理清前置条件、重新进入心流——运气好几分钟，运气差半小时起步。

我把这种情况叫「上下文崩坏」。它有几个典型特征：

• 你明确知道自己刚才在做某件事，但想不起具体的下一步动作。
• 你还能看懂代码，但想不起当初为什么这么设计。
• 你在多个任务之间来回跳，结果每个任务都只做了 30%-50%，没有一个真正收尾。
• 和 AI 聊代码时，每次都要重新解释一遍项目背景，它还是时不时忘记你的约束。

后来我开始尝试一个很笨的思路：既然大脑靠不住，那就把上下文放到外部，并且给它一个明确的模式名称。就像电视机的输入源切换——你按下 HDMI 1 就切到游戏机，按下 HDMI 2 就切到机顶盒。设备自己记住了每个输入源是什么，你不需要每次把线拔下来重新插。context-mode 本质上做的就是这个事：把「我现在在哪个上下文里」变成一个可切换的开关。

所以这篇文章不是要介绍什么新工具，而是要分享一套完全可以用文件、脚本和习惯实现的上下文管理模式。它解决的核心问题是三个：降低切换成本、避免重复解释、防止任务烂尾。适合程序员、产品经理、研究者、写作者，以及所有需要同时推进多个复杂任务的人。

2. 先拆解：一份完整上下文由哪四层构成

刚开始做 context-mode 的时候，我犯过一个错误：以为把当前进度写下来就够了。后来发现远远不够——进度只是最表面的一层。一次完整的上下文恢复，其实需要四层信息同时就位，缺一层都会出问题。

2.1 任务层：当前目标、进度与下一步

这一层是大多数人最容易想到的。包括：我正在做哪个模块、目标是什么、已经完成到什么程度、接下来的一步是什么。很多人写 To-Do 只写「开发登录功能」，这太粗了。好的任务层记录一定要能回答一个问题：如果我现在坐下，五秒钟之内能不能知道该按哪个键、打开哪个文件、改哪一行？

我的记录习惯是这样：退出一个任务时，不要写「做完了 A 的一部分」，而是写「下一步：打开 src/validation/user.js，为 validator 增加 18 岁以上年龄校验的单元测试」。这一步越具体，恢复的启动成本就越低。模糊的记录等于没有记录，因为恢复时你还是需要重新推理一遍。

2.2 环境层：工具链、分支、依赖与服务状态

这一层非常容易被忽略，而它恰恰是恢复成本最高的部分。有一次我切换回一个两周前做过的前端项目，任务记录写得很清楚，但环境全变了：Node 版本不对、依赖有冲突、本地数据库没启动、git 分支还在一个旧 feature 上。等我把这些全部搞定，四十分钟过去了，而任务本身可能只需要一小时。

所以我在 context-mode 里会给每个模式绑定一份环境清单：用哪个运行环境、需要起哪些服务、当前分支该切到哪、有哪些坑是上次就踩过并写在这里的。关于这一层，我见过一个特别好的类比：你在厨房做饭做到一半关了火，下次要做同一道菜，光是刀在哪、锅在哪、调料缺什么就要找半天；专业厨房会把每样东西固定在同一个位置，这就是环境层的意义。

2.3 知识层：参考资料、已有决策与历史结论

第三层是你完成这个任务需要的外部知识：相关文档、过去的决策记录、已经排除掉的方案。很多人以为自己记住了，但人类的记忆对「结论」很敏感，对「为什么得出这个结论」非常不敏感。两周后你大概率还记得「我们选了方案 B」，但完全不记得为什么没有选 A——而恰恰是那个「为什么」，在下次讨论时最有用。

我在每个模式的上下文包里专门留了一节「已有结论与理由」。比如：图表库从 ECharts 换成了 AntV，原因是打包体积问题，不是功能问题。这种记录看起来啰唆，但它是防止未来重复争论的最好工具。

2.4 时间层：可专注时段与被打断的节奏

第四层是我最近才加进去的，因为它涉及的是「你什么时候适合执行这个模式」。不同任务的认知负担不一样：写文档相对线性，可以放在精神一般的时候；修一个诡异的并发 bug，必须留出整块不被打断的时间。如果不做区分，只是按「任务重要程度」安排时间，最后往往是在精神最好的时候做了不太需要脑子的活，等真正要攻坚时人已经累了。

时间层的记录也很简单：标注这个任务类型属于「深度专注型」还是「琐碎处理型」，再根据自己每天的精力曲线分配。这一层在账户上看得见摸不着，但对实际效率的影响非常大。四层拆完，context-mode 的笔记结构就清晰了：每个模式对应一份 Markdown 文件，文件里包含任务、环境、知识、时间四个部分。下面我把整个搭建过程一步步写出来。

3. 搭建自己的 context-mode 工作流：从模式清单到切换日志

我不会用什么复杂工具，整套系统就是「目录 + 脚本 + 一份模板」。好处是零依赖、可以 git 版本化、检索用 grep 就行，不会哪天某个笔记软件停服把我的上下文全部带走。搭建过程分四步，每一步都有一个明确目的。

3.1 定义你的模式清单：别超过七个

说极端点，如果一个人同时维护几十个 context，那这个系统反而会变成负担。心理学里有个著名的「七加减二」规律，用在这里同样成立：模式太多，切换时光是选模式就花掉你十秒钟，系统就失去了意义。

我的分类方式是按「可复用场景」而不是按「项目」划分。比如我做后端开发时，不会为 A 项目和 B 项目各建一个模式，而是共用一个 DEV-API 模式，进入这个模式之后再具体调用某个项目的环境清单。这样做的原因是：人的思维资源有限，模式的粒度应该匹配「大脑需要消耗多少能量来切换」，而不是匹配「我手头有几个文件夹」。

建议的模式清单长这样：

命名要短，一个词，一眼能看懂。如果你发现自己定义了第八个模式，强制做一次合并。真实情况往往是：某两个模式用的上下文文件高度重叠，说明它们本质上是同一件事。

3.2 设计显式的进入与退出的动作

这一条是整套系统里最重要的原则：模式的切换必须是一个「有意识的动作」，而不只是心里的默念。我自己用 shell 脚本做了两个命令：ctx 和 ctxs。ctx 负责切换模式，ctxs 负责列出所有可用模式。脚本逻辑非常简单，但作用很实在——每次切换都会写一条日志，这会迫使我认真对待每一次切换。

# ~/.config/context-mode/ctx.sh CTX_ROOT="$HOME/.config/context-mode" CTX_CURRENT_FILE="$CTX_ROOT/current" function ctxs() { echo "available modes:" ls "$CTX_ROOT/modes/" 2>/dev/null | sed 's/\.md$//' } function ctx() { if [ -z "$1" ]; then if [ -f "$CTX_CURRENT_FILE" ]; then echo "current mode: $(cat $CTX_CURRENT_FILE)" else echo "current mode: none" fi return 0 fi local mode="$1" local mode_file="$CTX_ROOT/modes/${mode}.md" if [ ! -f "$mode_file" ]; then echo "mode not found: $mode" ctxs return 1 fi echo -n "$mode" > "$CTX_CURRENT_FILE" echo "[$(date '+%F %T')] switch IN -> $mode" >> "$CTX_ROOT/ctx.log" echo "switched to $mode" } function ctx_out() { if [ -f "$CTX_CURRENT_FILE" ]; then local old old=$(cat "$CTX_CURRENT_FILE") echo "[$(date '+%F %T')] switch OUT -> $old" >> "$CTX_ROOT/ctx.log" rm -f "$CTX_CURRENT_FILE" echo "left mode: $old" else echo "no active mode" fi }

你注意到退出动作是独立命令 ctx_out 而不是 ctx none，这是在模仿「关掉煤气灶再离开厨房」的仪式感。写代码时我们讲究显式释放资源，管理自己的注意力也是一样的道理。没有退出动作，模式就一直悬着，心理上总觉得手头的事没结束。

3.3 为每个模式准备一份上下文包

接下来就是把开头说的四层内容物化成文件。每个模式对应 modes 目录下的一份 Markdown，例如 modes/dev-api.md：

# MODE: DEV-API ## 任务层 - 目标：完成 /users 接口的查询参数校验 - 进度：校验器主函数已写完，还差边界测试 - 下一步：为 validator 增加「age < 18 拒绝」的单元测试 ## 环境层 - git 分支：feature/user-validator - 依赖：npm install 后重启 docker-compose 的 mysql 容器 - 本地地址：http://localhost:8080/api/v1/users - 上次坑点：mock 数据里不带 created_at 字段会导致查询超时 ## 知识层 - 决策记录：分页方案选了 cursor 而不是 offset，原因是深分页性能 - 相关文档：docs/api.md、src/validation/user.js - 已排除方案：用 SQL COUNT 统计总数，数据量大时会锁表 ## 时间层 - 类型：深度专注型 - 建议时段：上午 9:30 - 11:30，下午 15:00 - 17:00 - 可碎片化操作的子任务：写周报、回复 MR 评论

这个模板我用了很长时间，几点心得：第一，任务层里「下一步」是最高优先级字段，因为它是你恢复执行的关键入口；第二，环境层要写「上次坑点」，这是普通文档不会写的东西，只有亲自踩过才知道；第三，知识层要区分「决策」和「理由」，理由比决策值钱得多。上下文包不是写给未来的陌生人看的，是写给未来的自己看的，所以可以口语化，只要自己看得懂、恢复得了就行。

3.4 记录每次切换，不是为了复盘，是为了「能复盘」

ctx 命令每次切换都会往 ctx.log 里追加一行。刚开始我觉得这个功能鸡肋，后来发现它特别有价值。每周五下午花五分钟扫一遍日志，你能很直观地看到自己的时间都去哪了——哪类任务停留时间特别短？哪个模式频繁进出？频繁进出说明你根本没有进入心流，一直在被打断。

日志的格式刻意做得极简，一列时间、一列方向、一列模式名。不要设计复杂的统计功能，不要可视化面板，一旦开始在意统计工具本身，你就偏离了「管理上下文」这个初衷。日志的存在是为了在你想复盘时有的看，不是为了让你沉迷于生产出自己的「效率报告」。

4. 在 AI 编程助手场景中的落地：把 context-mode 变成对话的护栏

如果说传统开发场景里 context-mode 解决的是「自己的记忆」问题，那 AI 协作场景里它解决的是「模型的记忆」问题。用过 AI 编程助手的人基本都经历过这种对话：你前一段刚告诉它项目用 Vue 3 + TypeScript，它回答下一段问题时就默认你在写 jQuery。或者你让它改一个函数，它顺带着把不相干的文件也改了。

这不是模型蠢，是「隐式上下文」太多，模型只能靠猜。context-mode 的思路在这里特别好用：别指望 AI 自己记住上下文，而是把上下文做成显式的模式标头，在每次对话开始时主动贴给它。

4.1 给 AI 一份模式标头，而不是零散聊几句

所谓模式标头，就是一段放在对话最开头的结构化说明。它不需要很长，但必须包含五个要素：角色、项目背景、当前目标、约束、参考资料。我习惯直接用 Markdown 写：

你正在以「DEV-API」模式协助我。 项目背景：用户管理服务，NestJS + PostgreSQL，已上线 v1。 当前目标：完成 /users 接口的查询参数校验。 约束： 1. 不改动现有数据库结构。 2. 保持与 v2 接口的兼容性。 3. 输出请先给结论，再给理由，不要展开无关优化。 参考资料：请先阅读 docs/api.md 和 src/validation/user.js。 回答要求：如果遇到信息不足，直接问我，不要替我假设。

这条标头的顺序是有讲究的。模式名放在第一行，等于先给模型一个「行为设定」；项目背景和约束放在中间，是给它划定安全边界；参考资料放后面，是告诉它去哪儿找细节。实测下来，这条标头能把 AI 回答的「跑偏率」降得非常明显，因为它把人类协作时默认的规则显式化了。

4.2 控制上下文窗口：内嵌约束，外置资料

现在的对话模型都有上下文窗口限制，越长的对话，遗忘率越高。很多人遇到 AI 回答质量下降，第一反应是骂模型，其实真相很可能是：你往对话里塞了太多它根本不需要的代码块和历史讨论。

我的做法是把资料分成两类：必须内嵌的和可以外置的。约束、目标、当前正在改的函数——这些必须内嵌在标头里，因为它们是决策的锚点。而项目结构说明、完整的历史代码、第三方库文档——这些外置到文件里，让 AI 按需读取。以我自己的体感，一份标头控制在 500 字以内，AI 的稳定性表现就好很多；超过 1000 字以后，模型反而容易被尾部信息带偏。

4.3 一个典型场景：同样的 bug，有模式和没模式的区别

举一个最近实际遇到的例子。某个接口在并发请求下偶尔返回旧数据，没有加模式标头时，AI 给出的排查路径特别发散：先怀疑数据库隔离级别、再怀疑 N+1 查询、最后甚至建议换连接池。这些方向都「不算错」，但显然没有抓住重点。

当我加上模式标头，明确写「现状是本地 MySQL 8、使用默认隔离级别、仅一个服务实例、怀疑方向应集中在缓存层」之后，AI 立刻把注意力收窄，几十秒内指出问题最可能出在 Redis 缓存与数据库更新之间的失效时机不一致。最后的修复也证实了它的判断。这背后的道理很简单：AI 不知道哪些信息重要，它只会响应你给它的「模式」。显式地说清楚「我们在什么模式下、关注什么、不关注什么」，它的推理效率会高很多。

5. 跑了一段时间后踩过的坑：模式爆炸、过期文件与仪式感失效

context-mode 不是银弹，我推进这套工作流的过程中也走过不少弯路。挑几个最典型的写出来，希望你不用重蹈覆辙。

5.1 模式定义太细，反而让人不想切换

一开始我雄心勃勃，给每个项目、每种任务都定义了模式：project-a-feature、project-a-fix、project-b-refactor……结果就是 ctxs 一列几十个，每次切换时还要想「我该用哪个」。模式变成心智负担之后，我下意识地会逃避切换，最终退回到「硬扛」的老路上。

后来我把所有模式压缩到五个主模式，具体项目信息全部下沉到模式文件的「环境层」里。这样做的效果立竿见影：选择成本低到几乎可以忽略，而项目信息并没有丢失，只是换了个地方存放。记住一条：模式的粒度应该服务于「减少决策」，而不是「提高精确度」。过于精确的模式，精确到不值得维护。

5.2 上下文包过期：记录不更新，等于写了个寂寞

第二个坑是文件写完之后就不管了。模式文件里写着「下一步：实现 xxx」，但实际项目进度已经推进了两轮，这段记录早就过时了。恢复上下文时看到一个过期的「下一步」，比什么都没有更糟——它会把你往错误方向带。

我的补救办法是：每次 ctx_out 退出模式时，顺手更新文件里的「进度」和「下一步」两个字段。不用写多，两三句话就行。这样子每次进入模式时，看到的永远是「上次离开时更新过」的状态，参考价值才有保证。顺便说一句，这也解释了为什么我不建议用特别复杂的知识库软件——更新成本越高，人越懒得更新；一个 vim 就能打开的 Markdown 文件，更新它只需要十秒钟。

5.3 切换动作沦为形式，就失去了全部意义

还有一个问题是「仪式感失效」。刚搭好脚本那会儿，我认真执行每一次 ctx 切换。过了一个月，新鲜感消退，我开始随手敲一下 ctx frontend 应付了事，脑子里其实还在想上一件事。切换动作变成了虚伪的形式，上下文自然没有真正切换。

要解决这个问题，光靠自觉是不够的，得加点「物理反馈」。我目前的做法是把当前模式名显示在终端提示符里，zsh 配置大概这样：

precmd() { local c if [ -f "$HOME/.config/context-mode/current" ]; then c=$(cat "$HOME/.config/context-mode/current") fi if [ -n "$c" ]; then export PROMPT="%F{cyan}[${c}]%f %~ %# " else export PROMPT="%~ %# " fi }

这样每次敲命令时，我都会被视觉信息提醒一次「你现在处于什么模式」。偶尔还会给自己加一个更狠的动作：切到某个模式时，顺手把手机扣在桌上，或者走到另一个桌子前。物理环境的改变比命令行提示符更能告诉大脑「换场景了」。

6. 给想立刻上手的人：最小可行的配置方案

如果你看完前面的内容觉得有道理，但暂时不想搭全套脚本，可以从下面这个最小配置开始。三个文件，十分钟能搞定，不折腾。

6.1 一份只有四行的模式文件

不需要完整的分层模板，先建一个最小可用的：

模式：DEV-API 我在做什么：完成 /users 接口的查询参数校验 下一步动作：为 validator 增加年龄校验的单元测试 环境提醒：本地 mysql 容器先启动，分支切到 feature/user-validator

四个字段就够了，核心是「下一步动作」和「环境提醒」——前者解决启动成本，后者解决踩坑成本。

6.2 一段给 AI 用的最小标头

同样，不用像我那样写五个要素，三行起步：

模式：DEV-API 目标：完成 /users 接口查询参数校验 约束：不改数据库，保持 v2 兼容，先看 docs/api.md 再回答问题

只要这段标头存在，AI 的回答质量就有基本保障。等你用顺了，觉得缺什么再加什么。

6.3 我的最后一条经验：别把所有时间都花在打磨方法上

用 context-mode 大约四个月之后，我形成了一个新的习惯：只在三种情况下打开它。第一种是多任务交替推进、切换频率明显变高时；第二种是重要项目收尾、容错率特别低时；第三种是面对 AI 做高难度技术讨论时。其余时间，比如只是在某个文件里连续写两三个小时代码，我反而会刻意不切模式——因为单一任务不需要模式，这时候模式就是负担。

工具的意义在于省力，而不是增加仪式感。如果某一天你发现自己在琢磨「如何让切换日志统计更美观」而不是「我到底该做什么」，那说明你已经跑偏了。把 mode 文件当成一个长期可复用的伙伴，而不是一个新玩具。好了，以上就是一个普通开发者在实践中沉淀下来的全部经验，希望能给你一些参考。