context-mode：用tmux和AI上下文把多项目切换压缩到1分钟-开发者社区

1. 先说我为什么会被"上下文切换"逼疯

如果你跟我一样，手头同时压着两三个项目，那下面这个场景你一定不陌生：上午还在写 Python 后端接口，下午要切到 React 项目调样式，晚上可能还要打开博客写点东西。每次切换，都不是单纯换个文件夹那么简单，而是要重新记起这个项目用哪个端口启动、依赖装在哪个版本管理器里、代码风格是 tab 还是空格、Lint 规则有哪些例外、测试命令是 pytest 还是 pnpm test……这些琐碎信息全部堆在脑子里重新过一遍，状态才能回满。我实测过，一个人从 A 任务切到 B 任务，最顺利的情况下也需要 15 到 20 分钟才能恢复到"心流"水准，如果切完发现环境还没配好，半小时就直接浪费了。

后来我给自己定了一个目标：把这种"切换后的重新回忆"压缩到 1 分钟以内。也就是说，打开项目、进入状态、开干，三个动作必须一气呵成。围绕这个目标做的整套方案，我给它起了个名字叫 context-mode，也就是"上下文模式"。核心思路很简单：不靠脑子记上下文，而是把上下文固化成可以随时加载的模式。

说白了，context-mode 不是什么高深算法，就是一套"环境 + 工具 + 提示词"的组合打包方案。工程上有一句老话叫"约定优于配置"，context-mode 做的就是类似的事：把每个项目、每类任务需要的所有隐性信息，显式地写进一个模式配置里，然后让 shell、编辑器、AI 助手在进入对应模式时自动加载。这篇文章里我把整套做法的原理、脚本、配置和踩过的坑全部摊开讲，适合那些正在被多项目切换折磨的开发者参考。

2. 我的 context-mode 架构长什么样：三层分离

动手写脚本之前，我先把问题拆了一遍。一个人要真正"进入状态"，其实需要三层上下文同时就位：

环境层：终端会话、项目目录、环境变量、启动命令。这层没准备好，你连 dev server 都起不来。
工具层：编辑器里打开的缓冲区、缩进规则、LSP（语言服务器）选择、格式化工具。这层没准备好，你写的每一行代码都可能被 format 得跟你预期不一样。
协作层：给 AI 助手的项目背景说明、代码规范、当前任务目标。这层没准备好，AI 的回答永远是泛泛而谈的"通用建议"。

我最初只搞了环境层，命令能用就以为大功告成。用了一周发现，终端是切过去了，但 Neovim 里没有这个项目的自定义配置，AI 助手也不知道这个项目的技术栈，等于只恢复了三分之一的状态。所以后来我把方案调整成三层各自维护一套配置，关键词是"模式文件"。

每个项目（或者说每类任务）在根目录下放一个隐藏文件.ctxrc，内容长这样：

name: blog root: ~/dev/blog session: blog shell: zsh nvim_workspace: true env: NODE_ENV: development BLOG_PORT: 5252 ctx_file: .ctx/context.md

这个文件就是"模式"的定义。name是模式的别名，root是项目根目录，session表示我要挂靠的 tmux 会话名，env是这个模式下必须存在的环境变量，ctx_file是给 AI 助手看的项目上下文说明文件。下文所有脚本和配置，都是围绕解析这个.ctxrc来做的。

我用了一个非常古老的类比来跟同事解释这套东西：它就像家里的"情景灯光"。你可以设置"观影模式"把主灯关掉只留落地灯，也可以设置"阅读模式"把书桌灯调亮。模式切换之后，整屋的光环境一起变化，而不是你一个个去拧开关。context-mode 也一样，进入某个项目，终端、编辑器、AI 提示词全部跟随模式自动切换，不需要你一条条自己配置。

3. 环境层实操：tmux 会话自动恢复脚本

环境层我选 tmux 作为核心载体，没有用 docker 也没用虚拟机。原因很简单：开发者日常工作流里，tmux 是绝大多数人都能零成本上手的东西，而且会话分离、重连的功能天然适合"模式恢复"。哪怕你是 VS Code 党，终端窗口里跑一个 tmux 也完全不冲突。

3.1 脚本整体逻辑

脚本总共做了四件事，对应下面几个关键步骤：

用find在当前项目目录（我统一放在~/dev下）搜索所有的.ctxrc文件，把这些模式列出来。
用fzf交互式选择要进入哪个模式。
解析.ctxrc的session和root字段，判断对应 tmux 会话是否已存在；不存在就创建，存在就直接附加。
在会话里设置环境变量，并自动执行启动命令（比如打开 Neovim）。

完整脚本我贴出来，注释写得很细：

#!/usr/bin/env bash # ctx-switch.sh - 加载 context-mode 环境层 DEV_ROOT="$HOME/dev" RCFILE=".ctxrc" # 第一步：找出所有模式配置 mapfile -t ctx_files < <(find "$DEV_ROOT" -maxdepth 3 -name "$RCFILE" 2>/dev/null) if [ ${#ctx_files[@]} -eq 0 ]; then echo "没有找到任何 .ctxrc 模式配置，请先在项目目录创建。" >&2 exit 1 fi # 第二步：用 fzf 做选择，展示模式名称和所在路径 selected_file="$( for f in "${ctx_files[@]}"; do name="$(grep '^name:' "$f" | head -1 | awk '{print $2}')" dir="$(dirname "$f")" echo "$name $dir" done | fzf --prompt="选择要进入的 context-mode: " --with-nth=1 )" if [ -z "$selected_file" ]; then echo "未选择任何模式，直接退出。" exit 0 fi # 由显示文本反查配置文件路径 selected_name="${selected_file%% *}" target_dir="$DEV_ROOT/$selected_name" # 第三步：读取 .ctxrc 字段 root="$(grep '^root:' "$target_dir/$RCFILE" | awk '{print $2}')" session="$(grep '^session:' "$target_dir/$RCFILE" | awk '{print $2}')" cmdline="$(grep '^cmd:' "$target_dir/$RCFILE" | tail -1 | cut -d: -f2-)" root="${root/#\~/$HOME}" session="${session:-${selected_name}}" # 第四步：tmux 会话不存在则新建，存在则直接附加 if ! tmux has-session -t "$session" 2>/dev/null; then tmux new-session -d -s "$session" -c "$root" # 按模式注入环境变量 while IFS=: read -r key val; do if [ -n "$key" ]; then tmux set-environment -t "$session" "$key" "$val" fi done < <(grep -A99 '^env:' "$target_dir/$RCFILE" | grep -E '^\s+[A-Z_]+:' | tr -d ' ') fi tmux switch-client -t "$session" # 如果配置了启动命令，执行它 if [ -n "$cmdline" ]; then tmux send-keys -t "$session" "$cmdline" Enter fi

几个细节我特别想说明一下：为什么用grep + awk而不是source加载.ctxrc？因为.ctxrc是配置不是脚本，如果里面有 shell 特有的语法，source会造成意外副作用（比如把未转义的特殊字符当成命令执行），而grep是按行解析，更可控。再者，我故意让模式名称用目录名，而不是把名字单独抽出来，这样find反查路径非常直观，不容易出错。

3.2 这个脚本帮我省掉了哪些重复动作

以前我每次切到博客项目，都要手动执行这么一串：

cd ~/dev/blog nvm use 18 export NODE_ENV=development tmux new -s blog nvim .

如果中间漏了nvm use 18，启动的时候 node 版本不对，报错还要现排查。现在脚本把这些全部收敛成一条指令：ctx-switch。进去以后，目录、node 版本、环境变量、tmux 会话名称全部就位，直接开写。

还有一个很实用的点：tmux 会话和后台进程的关系。实际开发的时候我不会傻乎乎地所有事情都在前台跑，经常是开一个窗口跑 dev server，另一个窗口写代码。tmux new-session -d之后会话没有前台附加，dev server 不会因为终端关掉被杀掉；下次重新进入 context-mode，直接附加到原来的会话，所有后台任务都还在，无缝衔接。这一点对远程开发尤其重要——我从家里 SSH 到服务器上，切回公司电脑再 SSH 上去，tmux attach一眼恢复昨天的战场。

4. 工具层实操：编辑器跟随模式自动换配置

环境层解决了"我在哪"的问题，接下来编辑器要解决"我该怎么写"的问题。编辑器这一层我花了最多时间打磨，因为每个项目对缩进、格式化、语言服务的要求差异真的很大。

4.1 Neovim 自动配置的触发机制

我用 Neovim 配了 Lua 逻辑，核心是一个自动命令（autocmd），监听两个事件：BufEnter（进入缓冲区）和DirChanged（目录切换）。每次触发时，从当前文件路径向上回溯，找到最近的.ctxrc，然后执行模式对应的编辑器设置。

-- ~/.config/nvim/lua/ctx-mode.lua local function find_ctxrc_dir(start) local dir = vim.fn.fnamemodify(start, ":p:h") while dir ~= vim.fn.fnamemodify(dir, ":h") do if vim.fn.filereadable(dir .. "/.ctxrc") == 1 then return dir end dir = vim.fn.fnamemodify(dir, ":h") end return nil end local function set_mode_from_dir(dir) if not dir then return end -- 读取 .ctxrc 中的 tool 字段，这里用简单的键值解析 local tool = vim.fn.system("grep '^tool:' " .. dir .. "/.ctxrc | awk '{print $2}'"):gsub("%s+", "") if tool == "go" then vim.bo.expandtab = false vim.bo.shiftwidth = 4 vim.bo.tabstop = 4 vim.g.go_fmt_autosave = 1 elseif tool == "js" then vim.bo.expandtab = true vim.bo.shiftwidth = 2 vim.bo.tabstop = 2 end -- 可选：动态切换 LSP 配置 local lsp_name = vim.fn.system("grep '^lsp:' " .. dir .. "/.ctxrc | awk '{print $2}'"):gsub("%s+", "") if lsp_name and lsp_name ~= "" then vim.lsp.stop_client(vim.lsp.get_clients()) -- 这里按 lsp_name 拉起对应 server，细节略 end end vim.api.nvim_create_autocmd({ "BufEnter", "DirChanged" }, { callback = function(args) local dir = find_ctxrc_dir(vim.fn.expand("%:p")) set_mode_from_dir(dir) end, })

这段配置真正解决问题的地方在于"向上回溯"。我们在 monorepo 里打开一个包内的文件时，项目的.ctxrc不在当前位置，而在多个父目录之上。回溯到最近的配置，是避免用错模式的关键。我专门测试过嵌套目录的情况——在packages/web下打开文件，能正确落到web的模式配置上；如果web本身没有.ctxrc，那就继续向上，直到仓库根目录。逻辑虽然简单，但顺序必须正确，先找最近的，再一层层往外退，否则很容易被子目录里的残留配置带偏。

4.2 editorconfig 和 direnv 是天然的盟友

说实话，单独用 Neovim 脚本管缩进，远不如把这一类约定写到.editorconfig里干净。我的方案是两者结合：.editorconfig管"风格约定"，Neovim 脚本管"编辑体验"。风格约定是给所有用这个项目的人看的（哪怕他不用 Neovim，用 VS Code 也能识别）；编辑体验是给我自己用的（自动切换 LSP、启动代码补全引擎等等）。

环境变量那部分，则直接用direnv接管。.ctxrc里写的env.NODE_ENV=development，我会同步在.envrc里写一份：

export NODE_ENV=development export BLOG_PORT=5252

direnv会在你 cd 进目录的那一刻自动加载这些变量，退出目录自动卸载。tmux 里如果开了 direnv 插件，连新建窗口都会自动继承。这一个组合拳打下来，"模式环境"完全不需要我手动 remember 了。

编辑器和环境变量的联动，是我认为整个 context-mode 方案里最容易被低估的环节。很多人只做了 tmux 会话恢复，结果倒了环境层漏了工具层，切过去之后缩进乱了、LSP 没起来，体验比不用这套方案还差。所以我把工具层放在跟环境层同等重要的位置，宁可脚本少写点，也要把编辑器自动配置和direnv的加载做扎实。

5. 协作层实操：给 AI 助手配一个固定上下文窗口

第三个层次现在越来越重要了：AI 协作时的上下文。我平时会让 AI 帮我生成代码、排查报错、写测试，但很早就发现一个问题——如果我不把项目背景告诉它，它答出来的东西基本是模板级别的。比如我让它"给这个 API 加一个限流中间件"，它不知道我们用的是什么框架、什么语言、项目里有没有现成的限流库、代码风格是函数式还是面向对象。每次都要在对话里重新解释一遍，既费时间又容易越说越乱。

我的解法是在项目里维护一个.ctx/context.md文件，内容包含三块：

项目一句话介绍和技术栈清单
目录结构说明和关键模块职责
常用命令、代码风格约定、历史决策原因

然后写一个脚本，把这份文件自动注入到我要发给 AI 的 prompt 里。我的算法是这样的：

#!/usr/bin/env bash # ai-ask.sh - 组装带上下文的问题 context_file="" # 从当前目录逐层向上寻找 .ctx/context.md dir="$(pwd)" while [ "$dir" != "/" ]; do if [ -f "$dir/.ctx/context.md" ]; then context_file="$dir/.ctx/context.md" break fi dir="$(dirname "$dir")" done if [ -n "$context_file" ]; then cat > /tmp/ctx_prompt.md <<EOF 请基于以下项目上下文回答我的问题。 # 项目上下文（来自 $context_file） $(cat "$context_file") # 我的问题 $* EOF # 这里可以根据你的 AI 工具替换命令，比如 claude、opencode，或者直接复制到剪贴板 command="$(cat /tmp/ctx_prompt.md)" echo "$command" | pbcopy 2>/dev/null || echo "$command" echo "--- 上下文已组合并复制 ---" fi

这个脚本最核心的价值不在于它多复杂，而在于它把"每次都要人工告诉 AI 的信息"变成了"项目目录里显式维护的文本"。你只需要把上下文文件写好，之后每次提问，脚本自动带上项目背景。实测下来，AI 给出的代码在风格匹配、依赖选择上的准确度提升非常明显，尤其体现在：

它知道我们用的是 pnpm 还是 npm，给出的安装命令不会跑偏
它知道项目的目录约定，接口文件放在api/而不是乱建议新目录
它知道项目里已有的工具函数，会主动复用而不是重复发明轮子

我也试过直接把上下文文件固定放在~/ctx/base.md里，不区分项目，结果效果大打折扣。原因很简单：不同项目的上下文差异太大，通用模板只能覆盖 20% 的信息，剩下 80% 还得靠单项目维护。所以后来我一直坚持"每个项目一份 context 文件"这个原则。

6. 用了一个月后，我要说几个特大坑

再好的方案，落地过才能知道哪里会翻车。我这套 context-mode 用了一个多月，踩了几个坑，有的修复了，有的还留着，都值得说一下。

6.1 坑一：环境变量泄漏

最早我写 tmux 脚本时，没有用tmux set-environment，而是直接在 attach 之后export变量。问题来了：tmux 会话里的环境变量是会话级的，如果你设置了NODE_ENV=production，切到另一个不带这个变量的模式，残留的NODE_ENV=production会继续污染后续所有命令。最典型的翻车现场是：我从博客项目切到另一个项目跑测试，结果测试环境莫名其妙变成了生产环境，排查了半天发现是旧会话里残留的环境变量在作祟。

修这个问题的思路是双管齐下：一是所有环境变量必须通过tmux set-environment -t 会话名来设置，这样它只属于特定会话；二是在切换到新模式时主动清理会话里旧的环境变量，脚本里加一段：

tmux set-environment -u NODE_ENV tmux set-environment -u BLOG_PORT

从今往后，每个会话只保留自己模式的环境，不跨模式混用。

6.2 坑二：模式数量失控

刚开始搭这套系统的时候，我像收集癖一样给每个小目录都配了.ctxrc，从日常开发到临时脚本，前前后后配了十几个模式。结果用了一周发现效率反而下降了：ctx-switch的选择列表太长，fzf 模糊匹配反而增加了决策成本，而且模式之间的配置经常相互干扰。

后来我给自己下了一条铁律：同时保持活跃的模式绝不超过 5 个。不是项目的数量限制，而是并行工作的模式限制。手头只有 2、3 个活跃项目，就把模式精简到这几个；其余的等真正需要时再加，不提前铺开。这条铁律让模式维护成本降到了近乎为零，切换体验才真正回归到"快"。

6.3 坑三：编辑器配置的"幽灵回退"

Neovim 脚本里我用BufEnter监听，但有个头疼的场景：用 Leader 快捷键随意切换 buffer 时，BufEnter高频触发，每次都要向上回溯寻找.ctxrc，如果当前文件不在任何项目目录下（比如打开了一个/tmp/test.js），就会匹配不到模式，编辑器回到默认配置。这本是合理行为，但有时用户打开的一批缓冲区混合了项目和临时文件，切来切去时，配置会在"模式 A"和"默认模式"之间反复横跳，视觉上非常烦人。

我的妥协方案是：只有当前目录确实都找不到.ctxrc时才用默认配置，而且设置一个标志位，避免同一目录下反复刷新 Neovim 的 LSP 配置（这个 Flash 的代价很高）。最终效果是：临时文件按默认配置处理，一旦切回项目文件，配置能准确跳回对应模式，且不会出现无意义的重复加载。

7. 关于 context-mode 的几个延伸想法

整套方案基本稳定之后，我发现自己对"上下文管理"的理解发生了点变化。以前总觉得，效率工具的价值在于"快"，现在觉得更关键的是"少操心"。context-mode 让我不需要每次开工前回忆一堆琐碎细节，把有限的注意力留在真正需要思考的代码逻辑上。

扩展方向上，我觉得有几个特别值得继续做：

一是把.ctxrc的解析逻辑做成一个统一的命令行工具，而不是散落在 bash、lua 脚本里。比如ctx init、ctx run dev、ctx edit这类子命令，能进一步降低使用和分享的门槛。二是在团队层面推广，让.ctx/context.md成为项目的标配文档，新成员 clone 下来之后，AI 辅助问问题都能直接带着团队上下文，而不是靠老员工口述半小时。三是我还在尝试把 context-mode 跟"番茄钟"或者"时间块"结合起来，按任务类型而不是项目目录来定义模式——比如"写作模式""深度编码模式""代码审查模式"，各自的窗口布局、通知策略、AI 提示词都不同。

最后想分享一个小技巧：无论你准备用 tmux、Neovim 还是 AI 工具来实现 context-mode，一定要从最小可用版本开始，不要一上来就配十几个脚本。先解决最痛的那个场景，比如只做 tmux 会话恢复，用顺手了再一层层加工具层、协作层。我最初就是急着一口气把所有模式都配上，结果踩了坑再逐步精简，绕了不少远路。这套东西的内核，是把"记住上下文"这件事从你的大脑转移到文件系统和工具链里，而这个转移过程本身也是需要迭代优化的，别指望一次到位。