1. 工具链选型与整体设计思路别的不说先给结论Windows 上做远程开发如果你还停留在“用记事本改代码 → 手动上传服务器 → 跑一下看结果”的原始阶段那你大概率每天都在浪费人生。我过去大半年把日常开发工作流彻底重构了一遍核心就两样东西tmux 和 Claude Code。前者解决“远程会话怎么管”的问题后者解决“重复劳动谁来干”的问题。先说一个很多 Windows 开发者的通病拿到服务器 IP 和密钥之后第一反应是打开 PowerShell 或者 Windows Terminalssh 连上去跑一个长任务然后不敢关窗口一关任务就断。后来有人告诉你可以用 nohup 把进程丢后台但 nohup 的问题在于你根本没有一个直观的界面去看这个进程的输出、去和它交互。再往后你听说了 screen但 screen 的键位和现代终端多窗格工作流相比还是太老旧了。这个时候 tmux 就是正解。tmux 全称 terminal multiplexer翻译过来叫“终端复用器”。它的核心价值就一句话让你在 SSH 断开、Windows 蓝屏、笔记本合盖、公司网络断线之后远程服务器上的工作现场还在原地等你。所有正在跑的任务不会因为你的 SSH 连接中断而跟着挂掉。这个特性对长任务、后台任务、多任务切换、远程协作来说简直是刚需中的刚需。然后说 Claude Code。它是 Anthropic 官方推出的一个终端里的 AI 编程代理不是简单的代码补全插件而是能听懂你自然语言指令、直接帮你读写文件、执行命令、跑测试、修 bug 的自动化工具。把它装在你的 Windows 开发机上配合远程服务器上的 tmux 会话你能做到什么程度举个例子我在本地终端输入一句“帮我连上服务器在 tmux 会话里跑一下前端构建构建完把报错信息整理给我”剩下的活全部自动完成。这才是“远程开发环境进阶”该有的样子。这篇文章我不会只讲命令怎么敲我会把 tmux 会话管理和 Claude Code 自动化怎么结合、为什么要这么结合、实际踩过哪些坑全部摊开来讲。适合的读者有两类一类是刚把开发环境从纯 Windows 迁到 WSL 远程服务器的同学另一类是已经在用 tmux 但还没有引入 AI 自动化、想知道两者怎么打通的开发者。2. Windows 上 tmux 的安装与基础会话管理2.1 在 Windows 上装 tmux 的正确姿势tmux 本身是 Linux 世界的工具Windows 原生环境装不了。所以这里首先要有一个概念你真正的工作环境在你的远程 Linux 服务器上Windows 只是你的“入口”。你在 Windows 上要做的事情是准备好一个终端客户端ssh 到服务器然后在服务器上使用 tmux。换句话说tmux 不需要装在 Windows 上它装在远程服务器上。不过如果你的远程服务器一时半会儿还没准备好纯粹想在本地 Windows 环境里先熟悉 tmux 的操作我可以负责任地告诉你直接用 WSLWindows Subsystem for Linux最快。打开 Microsoft Store 搜 Ubuntu安装完以后打开 WSL 终端执行sudo apt update sudo apt install -y tmux装完以后你就拥有了一个 Linux 环境里的 tmux。我见过很多人绕了一大圈去用 Cygwin 或者 MSYS2 跑 tmux不是说不行但 WSL 的体验绝对是最接近生产环境的。而且 WSL 和 Windows 的互操作做得已经非常好了你可以直接在 WSL 里挂载 Windows 的磁盘路径也可以调用 Windows 上的工具。这里有一个我在实际使用中总结出来的经验别在 Windows 上直接管理远程 tmux 会话的配置文件统一放在服务器上。原因很简单你 ssh 到服务器之后tmux 读取的是服务器的~/.tmux.conf配置和你 Windows 本地环境没关系。你在本地配得再花哨到了服务器上全部不生效。所以正确做法是把配置文件写到服务器上可能的话用 dotfiles 仓库管理几台服务器之间同步。2.2 tmux 会话的创建、分离与重连tmux 的基本使用流程可以用一句话概括创建一个会话干你的活关掉终端下次重新连上去把会话召回来。这是整个会话管理体系的地基。创建新会话的常用方式有两种tmux new -s work tmux new -s code -d第一条命令创建一个名为 work 的会话并直接进入第二条创建一个名为 code 的会话但在后台运行不会立刻切进去。实际开发中我更喜欢先-d创建需要的时候再 attach。断开当前会话detach不用输入 exit快捷键是Ctrlb然后按d。这个操作不会杀掉会话只是把你从会话里“退出来”所有正在运行的进程继续跑。重连就一条命令tmux attach -t work如果你手头有多个会话像我这样同时开着 dev、build、log 三个会话可以用tmux ls查看当前所有会话列表每个会话后面会显示创建时间和窗口数量一目了然。还有一个高频操作是会话之间切换。我个人的习惯不是先 detach 再 attach而是直接用Ctrlb加s打开会话列表用上下键选择之后回车直接就切过去了。这个操作在 Windows Terminal 里实测很稳没有遇到过键位冲突的问题。2.3 窗口与窗格多任务并行的高级姿势会话session下面还有两个层级窗口window和窗格pane。初学者最容易混淆的就是这两个概念。我用一个生活化的类比来解释会话就是你开了一家餐厅窗口是餐厅里的不同功能区后厨、前台、包间窗格是某个功能区里同时工作的几个厨师。创建窗口的快捷键是Ctrlb然后按c关闭当前窗口是Ctrlb然后按。窗口之间切换用Ctrlb加窗口数字编号或者Ctrlb加n下一个、p上一个。我通常一个窗口跑一个项目比如窗口 0 是后端 API 服务窗口 1 是前端 dev server窗口 2 是数据库终端互不干扰。窗格则是把同一个窗口切成多个子区域。Ctrlb然后按%是左右分屏Ctrlb然后按是上下分屏。在远程开发场景里窗格的实际使用频率其实很高比如你在跑构建的时候需要同时盯日志和改文件直接左右分屏一边是构建输出一边是代码编辑器效率比来回切换窗口高得多。但这里必须说一句大实话窗格虽好但不要贪多。分三四个窗格还能看清每个区域的输出分到六七个以上基本就是在玩拼图了。屏幕空间有限每个窗格的字体小到看不清反而拖慢速度。我的经验是同一个窗口最多三个窗格再多就开新窗口。2.4 远程开发下的 tmux 配置优化直接给一套我打磨了很久的 tmux 配置你抄回去就能用。这套配置的核心思路有三个鼠标支持、更符合直觉的快捷键、更清晰的状态栏信息。# ~/.tmux.conf # 开启鼠标支持 set -g mouse on # 使用 Ctrla 作为前缀键而不是默认的 Ctrlb # 原因Ctrlb 在终端里偶尔会被其他软件占用Ctrla 更顺手 set -g prefix C-a unbind C-b bind C-a send-prefix # 设置窗口和窗格索引从 1 开始 set -g base-index 1 setw -g pane-base-index 1 # 保持窗口在当前目录 set -g default-path $PWD # 状态栏显示负载、CPU、内存、时间 set -g status-right #[fggreen]#(uptime | awk -Fload average: {print $2}) #[fgwhite]| %H:%M set -g status-left #[fgblue]#S 第 4 行到第 6 行是全局前缀键的修改默认的Ctrlb很多人用不惯我个人更推荐Ctrla因为这个组合键离左手更近按起来快。第 8、9 行把窗口编号从 0 改成 1适应大多数人的数数习惯。鼠标支持打开之后你可以直接用鼠标点击切换窗格、拖动调整窗格大小、滚动查看历史输出。这在 Windows Terminal 里表现很稳定但在一些老旧的终端模拟器里可能会有兼容问题。实测下来Windows Terminal 和 VS Code 的内置终端都对 tmux 的鼠标模式支持得很好可以放心开。配置改完以后执行tmux source-file ~/.tmux.conf使其生效或者直接开新会话。我的建议是如果当前正在跑重要任务不要立即 reload等手头工作告一段落再重启会话避免配置加载过程中出幺蛾子。3. Claude Code 安装配置与自动化能力拆解3.1 安装前的环境准备与依赖检查说完了 tmux我们把目光转向 Claude Code。Claude Code 是一款面向开发者的 AI 代理工具它的大致工作方式是在终端里启动一个交互式环境你输入自然语言指令它理解之后调用各种工具去完成操作。工具包括但不限于读写文件、执行 shell 命令、搜索代码、运行测试、调用外部 API。在 Windows 上安装 Claude Code 有一个绕不开的坑官方要求 Node.js 18 环境而且当前版本在 Windows 上推荐通过 WSL 安装和使用纯 Windows 的 PowerShell 环境兼容性不如 WSL 好。我在实践中的建议是如果你打算用 Claude Code 做正经开发工作先用 WSL。WSL 里跑 Claude Code 的稳定性要明显优于 PowerShell因为 Claude Code 的很多工具调用依赖 Unix 风格的 shell 语义比如文件权限、管道操作、信号处理等PowerShell 在这些方面有诸多不一致的地方。先检查环境node -v # 需要 v18.0.0 以上推荐 v20 npm -v git --version如果你还没有 Node.js在 WSL 里安装最省心的是用 nvmNode Version Manager不要直接用 apt 装因为 apt 里 Node 版本通常偏老curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install --lts nvm use --lts装完之后用node -v确认一下。我在实际安装时遇到过 nvm 下载慢的问题这时候可以设置镜像源但这里不展开网络调整的细节只说一个替代方案如果你网络条件不理想也可以直接去 Node 官网下载 Windows 安装包在 WSL 里通过ln -s做一个软链接指向 Windows 侧的 node.exe不过这种方法容易出权限问题我试过一次就放弃了老老实实用 nvm 最省事。3.2 安装 Claude Code 的完整流程与权限处理环境就绪之后Claude Code 的安装本身非常简单npm install -g anthropic-ai/claude-code装完以后验证一下claude --version看到版本号输出就说明核心安装没有问题了。但是真正会绊倒大多数人的是 API 认证和权限配置。Claude Code 有两种工作模式一种是官方 API 计费模式依赖ANTHROPIC_API_KEY环境变量另一种是订阅用户模式登录 Anthropic 账号后凭借订阅权限直接使用。如果你用的是 API 模式需要先设置环境变量export ANTHROPIC_API_KEYsk-ant-xxxx注意这个环境变量每次打开新终端都需要重新设置。不想重复设置的话把它写进~/.bashrcecho export ANTHROPIC_API_KEYsk-ant-xxxx ~/.bashrc source ~/.bashrc还有一类常见报错是权限问题。在我 Windows WSL 的组合下npm 全局安装目录如果权限不对会出现类似EPERM或者EACCES的报错。解决办法有两种一是用 sudo 装不推荐但有效二是手动修改 npm 的全局安装路径。我采用的是第二种因为长期来看更干净mkdir -p ~/.npm-global npm config set prefix ~/.npm-global echo export PATH~/.npm-global/bin:$PATH ~/.bashrc source ~/.bashrc3.3 Claude Code 核心命令与自动化操作场景Claude Code 启动很简单在项目目录下直接输入claude这会进入交互模式你会看到一个提示符可以在里面输入自然语言指令。比如你在一个项目目录里输入帮我分析一下当前目录下 src 文件夹里有哪些函数没有对应的单元测试Claude Code 会读取相关文件、分析代码、给你一份详细的清单。这只是最基础的使用方式。更进阶的用法是一次性非交互式调用把 Claude Code 嵌入到自动化脚本里claude -p 运行 npm test 并修复所有失败的测试然后重新运行直到全部通过 --dangerously-skip-permissions这里的-p参数表示 print mode打印模式执行完指令后直接把结果输出到终端不会进入交互界面。--dangerously-skip-permissions参数的意思是跳过所有权限确认直接执行文件读写和命令调用。这个参数用起来很爽但务必在可信的、不影响生产环境的目录里用因为它等于把所有的权限检查都关了。这种非交互式模式非常适合和 tmux 结合做自动化流程。举个例子你可以在 tmux 会话里启动一个监听脚本每次代码仓库有新的 commit 时自动运行一次 Claude Code让它检查代码质量、补测试、甚至生成提交信息。这种工作流一旦跑通你的角色就从“写代码的人”变成了“管流程的人”。3.4 多模型供应商切换与省 Token 实战有一件事我在网上看很多人问但是回答都比较零散Claude Code 能不能接其他的模型答案是能而且生态里已经有好几个工具专门干这件事最典型的就是 CC SwitchClaude Code Switch。CC Switch 是一个命令行工具效用一句话讲就是它帮你管理多个 Claude Code 的供应商配置比如官方 API、第三方兼容网关、本地跑的开源模型Ollama 等然后一键切换。它的实现原理其实不复杂本质上就是维护多份环境变量配置不同供应商对应不同的 API 地址和密钥。我用 CC Switch 的场景是日常小任务用本地模型跑免费、隐私性高、不需要外部网络遇到复杂重构任务才切回官方大模型。这样做的直接收益是 token 消耗大幅下降省钱效果立竿见影。关于省 token 的操作习惯我也分享几个实打实的经验不要一次性抛给 Claude Code 一个超大文件。它的 context window 有限你把整个项目的 5000 行代码全丢进去还没开始干活 context 就消耗了一大半。正确做法是先让它列目录结构再按需打开具体文件。用-p模式跑脚本类任务时指令要短小明确。别让它做太多无关的推理和分析指令越具体输出越可控消耗也越少。善用 CLAUDE.md 文件。Claude Code 每次启动时会自动读取项目根的 CLAUDE.md你可以在里面写好项目背景、代码风格、常用命令等上下文。这样每次对话时不用重复交代背景省 token 的同时准确度也更高。4. tmux 与 Claude Code 结合的远程开发工作流体系4.1 一个典型的 Windows 远程开发日常现在把 tmux 和 Claude Code 合起来模拟一个我每天都在用的工作流你看看能不能对号入座。早上到工位打开 Windows Terminal分三个标签页第一个标签页 ssh 到远程开发服务器第二个标签页是本地 WSL 终端用来跑 git 或者轻量脚本第三个标签页挂着 VS Code 的 Remote-SSH 窗口。在第一个标签页里输入tmux attach -t dev如果 dev 会话不存在就先创建tmux new -s dev进入 tmux 的 dev 会话之后我通常会开三个窗口窗口 1 是主工作区代码、编辑器、终端交互都在这里窗口 2 是日志监视器运行tail -f或journalctl -f窗口 3 是构建/部署窗口跑 CI 脚本或 docker compose。然后在窗口 1 里进入项目目录启动 Claude Codecd ~/projects/my-service claude此时你获得了一个有完整项目上下文的 AI 协作终端。你问它“昨天加了新接口之后哪些测试挂了”它会自动去搜代码、跑测试、告诉你结果。整个过程中 tmux 保证你的会话不中断Claude Code 保证你的操作自动化程度足够高。4.2 无人值守模式tmux Claude Code 自动跑任务我觉得这一小节是全文最值得你收藏的部分。远程开发最怕什么最怕任务跑了一半网络断了或者因为你要离开工位去开会任务没法盯着。tmux 解决的是“连接断开但任务不断”的问题Claude Code 解决的是“任务需要人来盯着判断”的问题。两者一合就能实现真正意义上的无人值守自动化。举一个我实际部署过的例子我有一个前端项目每次构建需要先拉最新代码、安装依赖、跑单元测试、构建产物、再上传到测试服务器。以前这些步骤我要手动一步步敲命令每一部都要等着看输出整体下来差不多要十五分钟。后来我把它改成了 tmux Claude Code 的自动化脚本。具体做法在 tmux 的构建窗口里先启动一个空白会话然后在里面写一个 shell 脚本把整个构建流程的步骤和每个步骤的判断逻辑写清楚。遇到需要动态处理的错误就调用 Claude Code#!/bin/bash # build-workflow.sh cd ~/projects/my-frontend git pull --rebase npm ci if ! npm run test; then echo 测试失败了请修复问题并重新运行测试 claude -p 运行 npm test 定位失败原因并自动修复修复后重新执行 npm test直到测试通过为止 --dangerously-skip-permissions fi npm run build scp -r dist/* usertest-server:/var/www/html/这个脚本放在 tmux 的一个窗口里跑即使 SSH 断开整个流程依然会继续执行。你只需要每隔一段时间回来看一下结果即可。这就是我说的“从写代码的人变成管流程的人”的落地实现。4.3 与 Docker、Elasticsearch 等基础工具的协同在远程开发环境里除了你写的业务代码还有一堆基础设施工具需要管理。这里我认为 Windows 远程服务器的典型组合是服务器上跑 Docker容器化你的服务数据库用 Elasticsearch 做搜索服务。这两个工具的日常运维操作完全可以用 tmux Claude Code 的方式统一起来。关于 Docker在 Windows 本地 WSL 里也能装 Docker Desktop但在生产场景下我强烈建议不要这么做因为 Windows 的 Docker 和 Linux 的 Docker 在文件共享、性能上都有不小的差距。直接在远程服务器上装 Docker Engine然后用 tmux 去管理相关的日志和命令体验会好很多。比如在 tmux 里开一个专属于 Docker 的窗口日常操作会非常顺手docker ps docker compose logs -f --tail100 app docker compose exec app yarn migrate再结合 Claude Code你可以让它自动解读容器日志里的报错并给出修复代码。我曾经遇到一个线上问题Elasticsearch 集群状态变成 yellow我直接把curl localhost:9200/_cat/indices?v的输出丢给 Claude Code它很快通过 unassigned shards 的分布情况定位到了问题原因并给出了 rebalance 和 reroute 的建议命令。这在以前是必须人工查文档才能解决的。另外网上有一个高频热搜“windows启动elasticsearch”很多新手在 Windows 本地起 ES 就各种踩坑JDK 版本不对、内存初始大小设置错误、ES 不允许 root 运行等等。我的观点是Elasticsearch 这种服务型工具能放服务器上就不要在 Windows 本地折腾。在服务器上跑一个 Docker 化的 ES一条命令搞定完全不需要在 Windows 上安装 JDK 和调配置。这个思路我相信会让你少走很多弯路。4.4 开发机与远程服务器之间的文件协同既然讲到了远程开发Windows 开发机上的文件怎么和服务器上的代码保持同步就是一个绕不开的问题。这里我按照自己的实践顺序给你排一个优先级参考最常用也最简单的方式是 VS Code 的 Remote-SSH 插件。它不会把你本地文件和历史记录同步到服务器而是直接在服务器目录里工作你在 Windows 上的 VS Code 界面里编辑远程文件等于把一个重量级 IDE 变成了远程文件编辑器。好处是和 tmux 共存没有任何冲突坏处是如果你本地还要跑一些需要读服务器文件的服务就会比较痛苦。第二种方式是用 rsync 做单向同步。适合编译产物、静态资源的推送。命令示例rsync -avz --delete ./dist/ userserver:/var/www/html/第三种方式是 WSL 和 Windows 的文件互访。在 WSL 里你可以直接访问 Windows 的磁盘cd /mnt/c/Users/你的用户名/Projects而从 Windows 侧看 WSL 的文件在资源管理器地址栏输入\\wsl$\Ubuntu\home\用户名就能像访问共享文件夹一样访问。这个互访机制对本地开发来说非常方便但请注意频繁在 /mnt/c 路径下跑大型编译任务性能会很差因为跨文件系统读写有额外的开销。建议大项目放在 WSL 的原生文件系统里Windows 侧只负责编辑。5. 常见问题排查与实战经验5.1 tmux 会话消失与意外退出我见过最多的问题就是SSH 断开了重连上去之后tmux attach却提示找不到会话。这种情况十有八九不是因为 tmux 会话挂了而是因为你连接的是一台不同的服务器或者对应的 tmux server 实例已经结束了。排查思路是这样先tmux ls看看当前的 tmux server 能列出哪些会话。如果列表是空的但你确信之前有会话那就要确认你是否连着同一台机器。有些人 Windows 本地上了一个 WSL远程服务器又开着一个 tmux两边一搞混就以为会话丢了。还有一种隐蔽的情况服务器重启了tmux 会话自然也就没了。这个问题无法完全避免但可以通过 tmux-resurrect 和 tmux-continuum 这两个插件来实现会话恢复。tmux-resurrect 可以保存会话的窗口、窗格、当前路径等信息tmux-continuum 则定时自动保存。服务器重启之后你执行prefix Ctrlr就能把之前的会话结构恢复到重启前的状态。注意恢复的是 tmux 布局和面板不是你的进程状态。进程本身还是需要靠 systemd 或者 Docker 的 restart policy 来保证。5.2 Claude Code 安装运行中的高频报错在 Windows WSL 这个组合下使用 Claude Code有几类报错是我实测中高概率会遇到的这里总结成一张速查表你碰到的时候直接对号入座报错现象可能原因处理方式EACCES: permission deniednpm 全局目录无写权限用~/.npm-global重新配置 npm prefixplease run WSL update提示WSL 内核版本过旧wsl --update更新 WSL 内核Your organization has disabled Claude subscription access订阅权限策略限制检查组织设置或改用 API 模式Failed to connect to API网络不稳定或密钥无效检查ANTHROPIC_API_KEY是否写错、是否过期命令执行卡住不动context 窗口过长或等待权限确认检查是否有未确认的权限弹窗或换-p模式其中wsl --update这条我要提醒一下网上热搜里就有“适用于 linux 的 windows 子系统必须更新到最新版本才能继续”这个报错很多人会忽略 WSL 本身的版本问题直接去排查 Claude Code。实际上新版本 Claude Code 依赖一些底层的终端交互能力WSL 内核版本过旧会导致终端转义序列解析异常表现就是命令没反应或输出乱码。遇到这种情况先wsl --update重启终端再试。5.3 PowerShell 与 WSL 环境混用时的编码坑还有一个 Windows 特有的坑值得单独拿出来说编码问题。我最初在 WSL 里跑 Claude Code让它读取 Windows 共享目录下的文件结果中文注释全变成了乱码一度以为是 Claude Code 的问题。后来定位到原因是文件编码是 GBK而 Claude Code 默认按 UTF-8 解析。这个问题的解决思路有两个方向一是统一文件编码在 WSL 里用iconv批量转换iconv -f GBK -t UTF-8 oldfile.txt newfile.txt二是在 Windows 侧调整系统区域设置开启 Beta 版“使用 Unicode UTF-8 提供全球语言支持”。路径是设置 → 时间和语言 → 语言和区域 → 管理语言设置 → 更改系统区域设置 → 勾选 Beta 选项。改完重启 Windows 生效。这个操作能把很多历史遗留 GBK 文件都当 UTF-8 处理对开发者来说省心很多。不过要提醒一下改系统编码会对一些老旧的 Windows 程序产生副作用比如中文版软件会显示成乱码。如果你只是做开发建议优先用第一种方案只转换需要处理的项目文件不要动系统全局设置。5.4 实战避坑清单最后整理一份我自己实践下来的避坑清单全是拿时间换来的教训没有一句废话不要在 tmux 里跑交互式的 sudo 密码输入。tmux 的窗口在密码提示时不会弹出界面会导致任务卡在密码输入状态。解决办法是使用 SSH key 登录或者用sudo -n加配置文件里的 NOPASSWD 条目。不要用 root 账号跑 Claude Code。Claude Code 的权限自动模式下会用 root 身份执行命令一旦误操作破坏力会比普通用户大得多。我吃过一次亏它把我服务器上某个配置文件的权限改错了排查了半天。tmux 的快捷键前缀和 VS Code 的键位可能有冲突。如果你在 VS Code 的集成终端里使用 tmux记得把 VS Code 的某些快捷键关掉否则你按Ctrla的时候可能触发了 VS Code 里的选择全部文本而不是 tmux 的前缀键。Claude Code 的输出日志会占用大量磁盘空间。在~/.claude目录下长时间使用会积累几十 GB 的日志文件。建议定时清理或者把日志输出重定向到 /dev/null。写在最后这一套 tmux Claude Code 的工作流是我在 Windows 上做远程开发的最终形态。它解决了我过去最痛的两个问题一是远程任务不能持久化、人一走就断的焦虑感二是重复性开发操作白白消耗精力的浪费感。现在我的日常是tmux 负责把服务器上的工作现场保存好Claude Code 负责把那些机械式的检查、修复、构建动作自动化而我只需要在关键节点上做决策。如果你准备从零搭这套环境我建议你的学习路径是先在 WSL 里装好 tmux花一天时间把会话、窗口、窗格的快捷键练熟然后在服务器上跑一个长任务人直接断开 SSH再重新连回来感受一下“会话还在”的安心感最后再装 Claude Code从一个简单的需求开始让它帮你改代码。这个顺序下来每一步的收益都很明确不会被复杂的工具链劝退。最后再分享一个小技巧tmax 到现在我还在用建议你也给每一个项目约定一个固定的 tmux 会话名比如项目名缩写。这样不管你隔了多久回来tmux attach -t projectA就能立刻回到那个项目的现场不用每次tmux ls翻来找去。这套流程真正用顺之后你会发现自己对 Windows 和 Linux 的边界已经没有概念了——你的开发工作流就是跨平台的永远在线永远可控。
