企业官网建设流程全解析

作为一名常年混迹在 Windows 命令行和 Linux 服务器之间的开发者，我一度觉得在 Windows 上谈“远程开发”就是个伪命题。直到我把 WSL2 里跑 tmux 和 Claude Code 这两个东西搭在一起用，才真正体会到什么叫“舒服到回不去”。这篇文章我打算把我这几个月的折腾经验完整梳理一遍，从为什么选这个组合，到每一步怎么落地，再到那些文档里根本不会写的坑，全部摊开来讲。

有些朋友可能对 Claude Code 还比较陌生，我先用一句话做个定位：它是 Anthropic 出的一个终端 AI 编程代理，直接在命令行里跑，既能回答代码问题，也能按指令改文件、跑测试、提交代码。它本身跟平台无关，但整个安装和体验过程，在 Windows 的 WSL2 环境里可以说是“原生级”的顺滑。而 tmux 这个东西，简单说就是一个终端复用器，能让你在同一个 SSH 会话里开多个窗口、挂多个后台进程，关掉电脑再连回来，任务还在跑。

这两个工具单独用各有价值，但真正产生化学反应的是组合。我给你描述一个场景：你在 Windows 上用 VS Code 连着 WSL2，开了一个 tmux 会话跑 Claude Code，让它去重构一个老项目里的某个模块。你关掉 VS Code，合上笔记本回家。第二天到公司，重新连上 WSL2，tmux attach 回去，Claude Code 已经把改好的代码躺在那等你 review，中间经历了多少网络抖动、终端闪断，跟它毫无关系。这就是 tmux + Claude Code 在 Windows 远程开发里最核心的价值。

1. 整体设计思路：为什么偏偏是 tmux + Claude Code

1.1 你的终端会话需要一个“安全气囊”

先说一个最基础的问题：为什么终端里跑长任务容易“断片”？

因为本地终端和远程服务器之间的连接是走 SSH 的，而 SSH 连接本质上是一条基于 TCP 的通道。一旦你的网络波动、笔记本休眠、或者本地 SSH 客户端崩溃，这条 TCP 连接就断了。连接一断，远程那个终端进程就会收到 SIGHUP 信号，默认行为就是终止进程。所以你会发现，在普通终端里跑 npm install、跑模型推理、跑一个长时间的数据处理脚本，只要断网或者合盖，任务直接失败，而且没有任何恢复的机会。

tmux 的模型完全不同。它会创建一个独立的服务端进程（tmux server），这个进程在你 SSH 断开之后，依然在远程机器上继续运行。你所有的会话、窗口、面板，都挂在 server 下面，而不是挂在 SSH 连接下面。所以你随时可以断开、重新连接，再 attach 回去，一切照旧。这就是我要说的“安全气囊”概念。

你要是搞过云服务器，一定遇到过“半夜跑脚本结果一早发现断在半路”的崩溃瞬间。tmux 就是专门治这个病的，它之于远程终端，相当于游戏里的“自动存档”。

1.2 Claude Code 与 tmux 的天然匹配

Claude Code 是个典型的交互式 AI 工具，它不像普通的 CLI 那样“输入一条命令，输出一个结果就结束”。它有自己的 TUI（文本用户界面），会持续等待你的指令，然后边思考边输出。整个过程可能持续几分钟甚至十几分钟。

这种长时间、高交互的工作负载，放在普通终端里风险极高。比如你用 Windows Terminal 直接连着 WSL2 跑 Claude Code，中途 Windows 更新强制重启，或者 WSL2 虚拟机内存溢出导致 Terminate，你的 Claude Code 就断了，之前让 AI 改到一半的代码、清理到一半的日志、跑到一半的测试全都没了。

但是把它放在 tmux 里就完全不一样。tmux 会话可以作为守护者，把 Claude Code 的整个进程树包在里面。断线、关终端、重启 Windows，只要 WSL2 虚拟机没被完全重置，你随时 attach 回去，Claude Code 还停留在你离开时的状态。有一次我为了省电把笔记本直接合盖带回家，第二天打开，Claude Code 竟然还停在原来的对话界面里，这种感觉只能用“神奇”两个字形容。

1.3 为什么在 Windows 上要特意选 WSL2

选 WSL2 不是因为 WSL1 不行，而是 Claude Code 和 tmux 对 Linux 环境有天然的依赖。Claude Code 官方支持的安装方式是 npm 包，虽然 Windows 原生也能装 Node.js，但这个工具在设计上假设你处于一个“类 Unix”的 shell 环境里，很多操作如权限处理、路径解析、git hook 调用，Windows 原生环境跑起来多少有点不顺畅。

WSL2 本质上是一个轻量级虚拟机，跑的是完整 Linux 内核。tmux 在里面的运行行为和在真实服务器上完全一致，你在 WSL2 里练会的 tmux 操作、写的配置文件，到任何一台 Linux 云主机上都能无缝复用。这一点对我来说特别重要，因为我的代码最终是要部署到云上的，在本地 WSL2 里跟生产环境越接近，踩坑的概率就越低。

另外，WSL2 和 Windows 之间是天然的“文件互访”，你可以用 explorer.exe 访问 WSL2 里的目录，也可以在 WSL2 里通过 /mnt/c 直接访问 Windows 的 C 盘。但是这里有个性能陷阱，我后面会专门讲，就是代码千万别放在 /mnt/c 下跑，否则速度会让你怀疑人生。

2. 环境准备：从 Windows 到 WSL2 再到 tmux 的完整链路

2.1 核实并更新你的 WSL2 环境

Windows 上的 WSL2 环境如果从来没有手动管过，版本很可能比较旧。Claude Code 对系统的要求不算苛刻，但 WSL2 内核太旧的话，偶尔会遇到一些莫名其妙的权限错误和路径解析问题，所以第一步先把环境升到新版本。

打开 PowerShell（管理员模式），跑以下两条命令：

wsl --update wsl --version

如果wsl --version输出一串版本信息，说明你已经是新版 WSL。如果提示“适用于 Linux 的 Windows 子系统必须更新到最新版本才能继续”，就说明内核或 WSL 框架过旧，直接跑wsl --update就行，微软现在把 WSL 作为独立应用，在 Microsoft Store 里更新也可以。这一步是整个环境的基础，我遇到过不少读者卡在这一步，所以这里特意先强调。

更新完之后，用wsl -l -v查看你当前安装的发行版版本号，确保是 2：

wsl -l -v

如果 NAME 那一列旁边写着 1，说明你还在 WSL1 上，可以用下面命令转换：

wsl --set-version <发行版名> 2

2.2 安装 tmux 并理解它的三层结构

WSL2 里装 tmux 非常简单，Ubuntu/Debian 系发行版一行命令完事：

sudo apt update && sudo apt install -y tmux

装完以后可以在终端里验证一下：

tmux -V

然后你要理解 tmux 的层级结构，这个搞明白了，后面操作才会顺手。tmux 一共有三层：session（会话）包含 window（窗口），window 包含 pane（面板）。你可以把 session 理解成一个独立的“工作区”，window 是工作区里的“标签页”，pane 是标签页里分割出来的“分屏”。

日常使用里面，我只需要记住一比多的关系：一个 tmux server 可以有多 个 session，一个 session 可以多 个 window，一个 window 可以多 个 pane。Claude Code 的使用场景里，我通常是一个 session 里开 2 到 3 个 window，一个跑 Claude Code，一个跑普通命令行，一个跑日志监控。

tmux 的默认前缀键是Ctrl+b，作用类似“全局快捷键的前缀”，几乎所有操作都要先按这个再按其他键。举个例子，你想新建一个 window，就先按Ctrl+b，再按c。这个交互模式一开始可能不太习惯，但用顺了之后效率极高。

2.3 一份基础但好用的 tmux 配置文件

tmux 默认配置比较朴素，甚至可以说难用。默认的 pane 分隔键位很绕，鼠标滚动不能直接翻页，状态栏信息也单调。所以我个人强烈建议在~/.tmux.conf里至少加上以下几项配置：

# 开启鼠标支持，方便直接用鼠标滚轮、点击切换 pane set -g mouse on # 修改前缀键为 Ctrl+a，位置更顺手（屏幕阅读里可能叫“前缀键”或“prefix”），避免跟 shell 的 Ctrl+b 冲突 set -g prefix C-a unbind C-b bind C-a send-prefix # 用 Alt+方向键快速在 pane 之间切换 bind -n M-Left select-pane -L bind -n M-Right select-pane -R bind -n M-Up select-pane -U bind -n M-Down select-pane -D # 开启状态栏窗口列表的当前窗口高亮 set -g window-status-current-style "bg=cyan,fg=black" # 开启 pane 编号提示，方便快速跳转 bind -n M-1 select-pane -t 1 bind -n M-2 select-pane -t 2 bind -n M-3 select-pane -t 3

我把前缀键改成Ctrl+a是因为在 GNU screen 时代我就用这个，而且Ctrl+b在 shell 里还有“光标左移”的功能，冲突比较明显。Conf 文件改完之后，在 tmux 内执行tmux source-file ~/.tmux.conf或者直接重启 tmux 让它生效。

这套配置下来，你只需要记住几个高频操作：Ctrl+a然后c新建窗口，Ctrl+a然后n/p切下一个/上一个窗口，Ctrl+a然后d脱离会话，tmux attach -t <会话名>重新回去。

3. tmux 会话管理与多任务编排

3.1 给每个项目建独立会话：命名是第一生产力

我见过太多人用 tmux 的全部操作就是tmux进入、Ctrl+a d退出，从来不命名会话。结果一旦开多个会话，就陷入“哪个是哪个”的混乱之中。我的习惯是给每个项目、每个任务建一个“有名字”的会话，命名规则一般是：项目名-任务名。

创建带名字的会话：

tmux new -s myblog-review

列出所有会话：

tmux ls

重新连接到指定会话：

tmux attach -t myblog-review

删除会话：

tmux kill-session -t myblog-review

这套流程你可能觉得简单，但真正的工作效率关键在于“习惯”。以前我在 Windows 上开远程终端，通常要开好几个窗口，分别对应不同的后端服务、前端服务、数据库客户端。现在我在 tmux 里给每个项目建一个会话，每个会话里开多个 window，一个 window 跑服务，一个 window 做 git 操作，一个 window 跑测试。终端的“窗口管理”逻辑一下变得清晰，不再是一堆乱糟糟的终端标签页。

3.2 用 window 和 pane 完成开发环境分区

进入一个会话后，可以按Ctrl+a c新建一个 window，按Ctrl+a ,给当前 window 改名。我通常会在每个 window 的底部状态栏看到名字，就能立刻知道这个窗口在干嘛。

如果你需要在同一个窗口里“左看一眼代码、右看一眼运行结果”，那就用分屏（pane）：

• 水平分屏：Ctrl+a "（注意是双引号）
• 垂直分屏：Ctrl+a %

我用 Claude Code 干活时的典型 pane 布局是：左侧一个大窗格跑 Claude Code，右侧上下两个小窗格，上面一个跑tail -f看服务日志，下面一个做 git 操作。这样一个屏幕能同时看到“AI在改代码”“服务有没有报错”“改了什么文件”，信息密度极高，那种“四处乱切窗口”的精力损耗就没了。

3.3 tmux 的会话保持与断线重连

会话保持是 tmux 的核心价值，详细展开说两个典型场景。

场景一：SSH 断线。你从 Windows 的 PowerShell SSH 到一台 Linux 开发机，在 tmux 里跑着 Claude Code。突然公司的 Wi-Fi 断了，SSH 客户端提示连接关闭。这时候你只需要重新 SSH 上去，执行tmux attach，瞬间回到你离开时的状态，Claude Code 的整个界面、上下文、正在进行的工作全都在。这得益于 tmux server 进程跟 SSH 会话完全解耦。

场景二：Windows 重启。你在 WSL2 里开着 tmux 跑任务，结果 Windows 自动更新强制重启了。重启完 WSL2 虚拟机也会自动启动，你打开 Windows Terminal 进入 WSL2，执行tmux ls就会发现会话还在。前提是 WSL2 没有被设置为“彻底关闭”的模式，默认的 localhost 转发模式不会重置虚拟磁盘，所以能恢复。

3.4 会话持久化：重启之后依然“记得”

tmux 本身只保证“进程在内存里跑”，但如果 WSL2 虚拟机重启、或者整个 Windows 重启，tmux 里跑的东西还是会没。对于 Claude Code 来说，会话上下文是在它的进程内存里的，进程没了，对话记录也就丢了。

我目前的做法是装一个tmux-resurrect插件，它能帮你把 tmux 的窗口、面板布局、甚至是 pane 里当前运行的命令记录下来，重启后一键恢复。再配合tmux-continuum插件，可以定时自动保存，基本实现了“开机一键回到工作现场”。

安装 tmux 插件需要先装 tpm（tmux plugin manager），在~/.tmux.conf里加上：

set -g @plugin 'tmux-plugins/tpm' set -g @plugin 'tmux-plugins/tmux-resurrect' set -g @plugin 'tmux-plugins/tmux-continuum'

保存 tmux 的布局和命令记录后，每次重启完执行prefix + Ctrl+s保存，执行prefix + Ctrl+r恢复。Claude Code 这种交互式程序不一定能完美恢复，因为它本身有状态，但至少窗口布局和普通 shell 的手头工作能恢复，省掉重开一遍的时间。

4. Claude Code 在 WSL2 里的安装、配置与使用要点

4.1 安装前置条件：Node.js 与验证

Claude Code 是 npm 包，所以需要 Node.js 环境。我建议不要用 Ubuntu 源里自带的旧版本 Node，而是直接装 NodeSource 或 nvm 管理的较新 LTS 版本。一个常见问题是：Windows 上如果先装了 Node.js 原生版，再用 WSL2 里的 node，两个环境容易混淆。我的做法是 WSL2 里只装一个 nvm，然后安装 Node.js 20 LTS。

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 node -v

如果node -v正常输出版本号，就可以安装 Claude Code 了：

npm install -g @anthropic-ai/claude-code

安装完成后，在终端里执行：

claude

如果第一次运行，它会引导你登录 Anthropic 账号，或者让你设置 API Key。这个流程比较简单，跟着提示走就行。

4.2 常见安装报错和排查方法

很多朋友卡在 Claude Code 安装这一步，我来整理几个我实际遇到、以及帮别人排查时遇到的典型问题。

第一个是 npm 权限问题。如果你执行npm install -g时报权限错误，通常是 Node.js 安装时没有正确配置全局目录。解决方案是把 npm 全局目录设置到用户目录下：

npm config set prefix '~/.npm-global' echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc source ~/.bashrc

第二个是执行claude时提示“找不到命令”。这通常意味着 npm 全局 bin 目录不在你的 PATH 里。用npm bin -g查看全局 bin 路径，然后把它加到~/.bashrc的 PATH 里。

第三个是网络问题。如果你在 install 时卡住或者超时，多半是 npm registry 访问慢。换成国内镜像或者公司内部 registry 能缓解。这个根据你当前的网络环境自己定，我就不展开了。

第四个是 Claude Code 启动时报错，说自己的版本和服务器端不兼容。这种一般直接执行：

claude update

强制更新到最新版就行。

4.3 Claude Code 的核心用法：交互式对话与自动化执行

claude命令启动后，你会进入一个交互式对话界面。你可以在里面直接输入自然语言指令，比如“帮我看看 src/utils.ts 第 42 行为什么类型报错”，或者“给这个函数补上单元测试”。Claude Code 会读文件、定位问题、生成修改，并且告诉你它准备怎么做。

对于自动化任务，Claude Code 还支持命令行直接传参数的模式。比如：

claude -p "列出当前目录下的所有 TODO 标记" --output-format text

这个模式非常适合脚本化调用，也适合配合 cron 定时任务做一些代码巡检。不过我最常用的还是交互模式，因为它能多轮对话，上下文连贯，处理复杂的重构任务很好用。

4.4 让 Claude Code 更省 token 的配置经验

关于 token 消耗，我有不少心得。Claude Code 这类工具是按 token 计费的，如果配置不当，消耗会很快。我实战后总结这几个省 token 的点：

第一，开始任务前，先精确告诉 Claude Code 你要处理的文件范围。不要让它“全项目扫描”，而是直接说“只处理 src/ 目录下的 X 文件”。它默认会把相关文件读进上下文，文件越多 token 烧得越快。

第二，尽量在同一个会话里连续完成相关任务，不要频繁开新会话。因为每开一个会话，它都需要重新理解项目背景和你的需求。连续对话还能让它记住前面已经做过的修改，避免重复解释。

第三，善用.claude/settings.json或项目级 CLAUDE.md 配置文件。可以在里面定义项目的代码风格、目录结构、常用命令。这样每次启动 Claude Code 时，它会自动读取这些背景信息，减少你每次打一大段项目说明的 token 成本。Claude Code 对项目里 CLAUDE.md 文件的优先级很高，你可以在里面写清楚“该项目的测试命令是 npm test”、“提交信息格式必须符合 conventional commits”这类约定。

第四，如果你只是想让 Claude 总结一个东西，主动说“不需要修改代码，只需要回答”。这种短任务模式下，它就不会把一堆代码读进上下文然后尝试修改，能省下大量 token。

5. 组合实战：tmux 里跑 Claude Code 的完整工作流

5.1 一次标准的“后台守候”实战

下面我把我的标准操作步骤完整过一遍，你可以直接照着走。

第一步，进入 WSL2，建一个命名会话：

tmux new -s code-review

第二步，在会话里启动 Claude Code：

claude

第三步，让 Claude Code 开始干活。比如我可以跟它说：“帮我在整个项目里搜索所有 fetch 调用，检查有没有缺少超时配置，然后列出需要修改的文件清单。”这个过程它需要读多个文件、做分析，可能要跑几分钟。

第四步，干其他事。此时我按下Ctrl+a d脱离这个会话，回到普通的 WSL2 shell，继续做其他工作，比如在另一个 Windows Terminal 标签页里写文档、看视频、甚至直接把笔记本合上走人。

第五步，回来后重新连上：

tmux attach -t code-review

你会看到 Claude Code 的界面跟你离开时一模一样，它的回答或者修改已经完成了，所有输出都在等着你。如果你不需要那么多 window，把当前 window 关掉也可以，但注意别直接把会话 kill 掉，否则 Claude Code 就真的没了。

5.2 多会话并行：同时跑多个 Claude Code 任务

因为 Claude Code 的对话是串行的，它不会同时做两件事。所以我需要跑多个任务时，会开多个 tmux 会话，每个会话里放一个独立的 Claude Code 实例。

比如我有一次要同时处理“给 A 项目写 README”和“修 B 项目的登录 bug”。我会开两个会话：

tmux new -s task-a tmux new -s task-b

然后分别 attach 进去启动claude，再都Ctrl+a d脱离。两个 Claude Code 互不干扰，各干各的。这个做法的好处是隔离性非常好，任务之间不会因为依赖冲突、上下文互相污染导致出错。

注意别在一个会话里开两个 Claude Code 实例，那样你同时只能跟一个交互，另一个会一直处于等待状态，白白占用额度，这种浪费没必要。

5.3 在 WSL2 与 Windows 之间共享文件时的性能陷阱

前面我提到，WSL2 里访问 Windows 文件系统是通过 9P 协议，性能远低于 WSL2 原生的 ext4 文件系统。如果你把项目代码放在 C 盘（/mnt/c），然后让 Claude Code 去读、去改，速度会非常慢，而且 Claude Code 的“全项目扫描”会慢到让你怀疑人生。

我的建议很明确：所有项目代码统一放在 WSL2 的~/projects目录下，也就是 Linux 原生文件系统里。Windows 侧的 VS Code 通过 WSL Remote 插件直接打开 WSL2 里的目录，代码不需要在 Windows 和 WSL2 之间复制两份。

如果实在有文件需要从 Windows 复制到 WSL2，用命令复制，不要在 Windows 资源管理器里拖拽：

cp -r /mnt/c/Users/你的用户名/Desktop/myproject ~/projects/

另外，不要在 /mnt/c 下跑 git 命令、npm install 这类大量小文件读写的操作。我之前试过在 /mnt/c 下跑 npm install，装完依赖花了将近十分钟，中间还差点卡死，而同样的项目在 WSL2 文件系统下不到一分钟就完成了。这个性能差距你只要踩过一次，就再也不想在 /mnt/c 下干重活了。

5.4 用 Claude Code 配合 git flow 的实操经验

Claude Code 在 WSL2 里能直接调用系统里的 git，这意味着它可以帮你做很多 git 操作。我的习惯是在每个 tmux window 里专门留一个小 pane 做 git 操作，同时让 Claude Code 在另一个 pane 里改代码。

我给 Claude Code 的常用指令示例：

• “帮我查看当前分支的未提交改动，生成一个规范的 commit message，但不要真的提交。”这适合让 AI 辅助书写提交信息。
• “把 main 分支合并到当前分支，然后跑测试，如果测试挂了就尝试修复。”这种带修复任务的指令能让 Claude Code 全职干“merge 之后修冲突”的苦活。
• “分析最近五次提交涉及到的文件，帮我关注这些文件的测试覆盖情况。”这种跨历史文件的检索任务，你自己看至少要翻半天，AI 跑起来也就是一两分钟。

使用的时候有两点要提醒：第一，让 Claude Code 跑 git push 这种“远程写操作”时要格外谨慎，我一般会在指令里明确加上“不要 push”。第二，Claude Code 的修改和 git 状态是实时同步的，所以在给它发任务前，先把当前的 git 状态确认好，比如先把正在改的文件 stash 或者 commit，避免它把半成品代码也一起改了，回头你还得重新理。

6. 常见问题与排查技巧实录

6.1 tmux 相关的问题速查表

我先给一个 tmux 使用中最常见的问题速查表，方便你直接对照排查。

6.2 Claude Code 安装和运行问题排查

Claude Code 的排错逻辑其实不算复杂，我把踩过的坑都整理一下。

第一个是“PowerShell 安装报错”。很多人想在 Windows 原生终端里直接npm install -g @anthropic-ai/claude-code，然后在使用时报各种权限或路径错。我个人强烈建议，所有涉及 Claude Code 的执行，都放到 WSL2 里做，不要用 Windows 原生 Node。因为 Claude Code 对 shell 环境有要求，PowerShell 虽然能用，但很多脚本行为和路径解析会不一样，容易出问题。

第二个是“your organization has disabled claude subscription access”。这个提示的意思是当前账号或者组织有访问限制，不是本地代码问题。你需要检查自己的 Claude 账号有没有被订阅策略限制，或者有没有用组织管理员设置的 allowlist。这个属于账号侧权限问题，本地无能为力。

第三个是“启动时卡住或报错但看不到日志”。Claude Code 里可以开 verbose 模式：

claude --verbose --debug

它能输出详细的调试信息，帮你定位是 API 密钥问题、网络问题还是配置文件问题。

第四个是“想让 Claude Code 接 DeepSeek 或 Ollama 这类第三方模型”。这个目前社区里有一些方案，通常是通过修改 OpenAI 兼容接口或者自定义 API 端点来实现。但这个问题牵涉到不同版本的兼容性和安全配置，建议以官方文档为准，我不在这里过度展开。

6.3 网络与代理问题的处理原则

在中国大陆使用 Claude Code，你会遇到一个很现实的问题：它的 API 请求可能无法直接连通。很多人第一反应是“开代理”，但国内网络环境下代理工具良莠不齐，配置不当反而会带来更多问题，而且代理工具的使用本身也有合规风险。我在这里不展开具体工具，只分享一个原则：如果你的网络能访问 Anthropic 的 API，就直接用；如果不能，你先确认公司或学校有没有提供合规的访问通道。千万不要为了“稳定”去安装来路不明的工具，安全第一。

另外，Claude Code 支持通过环境变量指定 HTTP 代理，但它只读取HTTPS_PROXY/HTTP_PROXY。如果你确实在合规条件下有代理地址，可以在~/.bashrc里加：

export HTTPS_PROXY=http://127.0.0.1:7890 export HTTP_PROXY=http://127.0.0.1:7890

这个 7890 只是示例端口，具体以你自己的客户端为准。设置完记得source ~/.bashrc或重开终端。

6.4 会话与任务异常丢失的恢复建议

即便有 tmux，也不是 100% 不会丢任务。比如 WSL2 虚拟机自身崩溃，或者 tmux server 被 OOM killer 杀掉，就会真的丢会话。我有几个“保底”技巧分享给你：

第一，对 Claude Code 来说，很多关键执行过程是有日志的，你可以配置 Claude Code 把对话记录输出到文件。比如你在启动时加--output-format stream-json并重定向到日志文件，即使会话崩溃，之前的内容还在文件里。

第二，对 tmux 来说，配置好 tmux-continuum 后，即使重启，也能恢复到最近的快照。这个插件默认 15 分钟保存一次，所以最多丢 15 分钟的操作。

第三，重要的长时间任务，我会在 Claude Code 跑完后让它“把变更摘要写到一个文件里”。这样即使之后会话丢了，你也可以通过这个文件快速恢复上下文。这个习惯非常有用，我已经养成肌肉记忆了。

7. 使用体验心得与进阶建议

7.1 我是如何组织日常开发流的

把 Windows + WSL2 + tmux + Claude Code 这套组合跑顺之后，我日常开电脑的固定流程是：打开 Windows Terminal 进入 WSL2，然后执行tmux attach，回到昨天的工作现场。如果当时有多个会话，我会快速看一眼状态栏的会话名，挑一个进入。这个习惯让我的工作流从“每天早上一脸茫然地找文件、找日志、重新跑服务”变成了“一键回到战场”，效率和心情都有明显提升。

如果你习惯用 VS Code，可以装 WSL Remote 插件，在 VS Code 里打开 WSL2 的项目目录时，它的集成终端会自动进入 WSL2 shell。你只需要在集成终端里敲tmux attach就能连接之前的所有会话，非常自然。

7.2 Claude Code 的使用边界：什么活适合它干，什么别让它碰

用了一段时间 Claude Code，我逐渐摸清了它的边界。

适合交给它干的活：跨文件的代码检索、生成单元测试、重构小模块、修 TypeError、格式化代码、写 commit message、根据 TODO 生成实现、批量重命名、生成文档。这些任务的特点是：上下文范围相对清晰，有明确的输入输出，AI 的容错空间大。

不适合交给它干的活：涉及多端联调的问题排查、需要看大量运行时数据的线上故障、需要审批的部署操作、对整个系统架构做重大调整。这些任务要么风险太高，要么信息量太大且变化太快，AI 目前的模式不太适合直接上手。当你给它分配这种任务时，它会“一本正经”地给出看似合理的建议，但真执行起来容易出大问题。我的原则是：AI 干“体力活”，我干“决策活”。

7.3 后续还能怎么扩展

这套组合的扩展空间还挺大的。比如你可以把 Claude Code 接入项目的 CI/CD 流水线，让它自动分析测试失败的原因，或者自动生成 changelog。你甚至可以在 tmux 里跑多个会话，每个会话监控不同的仓库，用 Claude Code 定时巡检代码质量。

如果你喜欢折腾自动化，还可以用 tmux 的分屏功能，让 Claude Code 在左边 pane 里跑，右边 pane 里跑一个nodemon热更新服务。每当 Claude Code 改了代码，nodemon 就自动重启服务，你一眼就能看到服务是否正常。这种“AI 改代码 + 自动验证”的循环一旦跑起来，开发效率会进入完全不同的节奏。

我现在常用的组合是 tmux 里开三个 pane：左边 Claude Code，右上方跑测试监听器，右下方跑 git log。Claude Code 每改完一版，我只需要看一眼右上方测试有没有跑过，就能决定是继续让它修还是自己接手。远处看，就像有一条流水线在自动运作，而我是那个最终把关的工头。这种感觉，说实话，第一次体验的时候还是挺震撼的。