用了好几年的远程开发我一直觉得这是个“用着别扭但说不上来哪里别扭”的事。直到最近把日常主力机切到 Windows项目代码又全在远端 Linux 服务器上才真正把这件事重新捋了一遍。标题里这三个东西——Windows、tmux、Claude Code——单拎出来每个都不新鲜但把它们串成一条完整工作流确实解决了我好几个长期痛点SSH 一断会话就丢、AI 编码工具在 Windows 端水土不服、批量改代码时永远要人盯着终端。这篇文章就是把这套组合的完整搭建过程、踩坑记录和自动化思路整理出来。不管你是刚接触远程开发的新手还是被“代码在服务器上、人却离不开本地编辑器”折磨的资深开发者这套方案都可以直接抄作业。1. 为什么是“Windows tmux Claude Code”这套组合先说结论远程开发的核心矛盾不是“连不上服务器”而是“连接不稳定”和“任务没法持续跑”。tmux 解决前者Claude Code 配合自动化解决后者Windows 则是把这两者粘合起来的本地枢纽。1.1 远程开发里最容易被低估的三个痛点我见过太多人远程开发的方式是打开 Windows 自带的命令行敲ssh userserver然后直接在上面跑命令、改文件。这种方式有两个致命问题一旦网络抖动或者笔记本合盖SSH 连接一断正在跑的编译、测试、部署任务全部中断而且终端里之前的输出也全丢了。第二个痛点是代码编辑。有人用 VS Code Remote-SSH有人用 JetBrains 的 Remote Development这些方案本身没问题但都有一个隐性成本本地要装一套 IDE远程要跑一个 server 端资源占用高而且遇到复杂项目时同步延迟很影响手感。第三个痛点才是 AI 时代新增的——Claude Code、Codex 这类命令行 AI 工具本来是给 Unix/Linux 环境设计的Windows 原生跑起来常有兼容问题。但你的日常工作电脑偏偏是 Windows这就很尴尬。1.2 这套组合的选型逻辑我在选型时参考了一个原则本地尽量轻远程尽量全AI 工具跑在能稳定运行的地方。Windows 只做三件事提供终端Windows Terminal、提供 SSH 客户端系统自带 OpenSSH、提供文件编辑入口VS Code 或直接终端编辑。tmux 跑在远程服务器上负责会话保持、窗口分割、后台任务持续运行让 SSH 断开不再导致任务中断。Claude Code 也跑在远程服务器上因为大多数开发项目编译、测试、依赖安装都在 Linux 环境下最顺畅而 Claude Code 本身需要执行命令、读写文件放在 Linux 端没有路径和权限的坑。这样设计的好处很明显本地 Windows 就算重启远程的 tmux 会话和 Claude Code 任务都不受影响。下次开机ssh连上去tmux attach一切恢复原样就像没断过线一样。也有朋友问为什么不用 WSL我在 1.1 到 1.3 节会详细对比简单说WSL 适合做本地 Linux 环境但如果你已经有真实的远程开发服务器直接在服务器上配 tmux 和 Claude Code 是更干净的选择。2. Windows 端的准备工作与工具链在碰服务器之前先把 Windows 这端的“底座”打好。这一步做扎实后面能少踩 80% 的坑。2.1 终端与 SSHWindows 11 其实啥都不用装Windows 10 1809 之后的版本系统设置里就能启用 OpenSSH 客户端Windows 11 更是默认就带。所以绝大多数情况下你不需要再装任何第三方 SSH 工具。我推荐用Windows Terminal作为本地终端原因很实际支持多 Tab我习惯一个 Tab 连开发服务器一个 Tab 连测试服务器另一个 Tab 留给本地命令。支持自定义快捷键复制粘贴符合直觉CtrlShiftC/V不像老版 conhost 那样反人类。对 UTF-8 和中文显示支持很好这一点在跑 Claude Code 这类输出大量文本的工具时尤其重要。如果你还没装 Windows Terminal去 Microsoft Store 搜“Windows Terminal”安装即可。装完后把默认终端设成它默认配置文件可以选 PowerShell 或 CMD这个不影响远程操作。SSH 连接我建议直接生成密钥对别再每次输密码了。在 Windows PowerShell 里执行ssh-keygen -t ed25519 -C your_emailexample.com一路回车生成到C:\Users\你的用户名\.ssh\下然后把公钥内容追加到服务器的~/.ssh/authorized_keys文件里。这一步做完后续所有 SSH 连接都免密也为后面的自动化脚本铺平了路。2.2 为什么我最终推荐 WSL2 而不是原生 PowerShell这是个容易引战的问题但我凭实际体验说结论在 Windows 上跑 Claude Code我强烈建议先装 WSL2在 WSL 里跑而不是原生 PowerShell。原因有三个第一Claude Code 官方安装脚本是一段 Shell 脚本原生 PowerShell 跑不了你得手动装 Node.js 再 npm 安装步骤多且容易出权限问题。而在 WSL 的 Ubuntu 里直接curl -fsSL https://claude.ai/install.sh | bash一步搞定。第二Claude Code 在运行时会执行大量子进程git 命令、测试命令、文件搜索这些命令在 Linux 环境下行为最标准。WSL2 虽然不是完整 Linux 内核但对这些常见命令的兼容性已经非常好了。我实测过同一段自动化工单在 WSL 里跑比在原生 PowerShell 里跑少踩一半的路径和转义坑。第三WSL2 的网络和文件系统对 Windows 的适配做得不错你可以直接在 WSL 里访问 Windows 盘符下的文件/mnt/c/...也可以从 Windows 访问 WSL 里的文件\\wsl$\Ubuntu\...两边倒文件很方便。装 WSL2 的命令wsl --install装完默认是 Ubuntu它会让你设置一个 Linux 用户名和密码。之后每次打开 Windows Terminal新建一个 Tab 选 Ubuntu就进入 Linux 环境了。2.3 本地编辑器的连接方式终端和命令行搞定了还差一个编辑器。我的推荐方案非常朴素主力用 VS Code连服务器用 Remote-SSH 插件小改动直接在 tmux 里用 vim 搞定。VS Code 的 Remote-SSH 插件逻辑很简单本地装 VS Code远程不装完整 VS Code只装一个 server 组件。打开远程文件夹就像打开本地项目一样代码补全、跳转、调试都好使。但这里有个技巧VS Code Remote-SSH 连接上之后打开终端它默认就是连接到远程服务器的。你在这个集成终端里直接敲tmux attach就等于把 tmux、Claude Code、VS Code 三者串到了一起。本地编辑远程文件远程终端跑 AI 自动化互不干扰。如果只是改一个配置文件、看一段日志我甚至连 VS Code 都懒得开直接在 tmux 里进 vim 改完就退出。轻量、快速也是一种效率。3. tmux 会话管理从入门到“救了我的命”tmux 是这套工作流里最“稳”的一环也是我建议每个远程开发者都要熟练掌握的工具。它的核心价值一句话就能说清你在远程服务器上跑的每个任务都可以在 tmux 会话里持续运行就算你本地断网、重启电脑任务也不受影响。3.1 tmux 的核心概念Session、Window、Pane很多教程一上来就丢一堆快捷键容易把人绕晕。我换个角度讲。tmux 的结构可以类比成你在用一套房子Session会话就是整套房子。你可以在房子里干任何事关了门detach房子还在下次开门attach一切原样。Window窗口就是房子里的房间。一个会话可以有多个窗口每个窗口是一个独立的终端界面。Pane窗格就是房间里被隔断出来的小空间。一个窗口可以被均分成多个窗格同时显示不同内容。举个我日常的场景一个 tmux 会话里开三个窗口。窗口 1跑开发服务器的日志tail -f窗口 2打开 Claude Code 交互界面让它帮我重构代码窗口 3留着做 git 操作和临时命令每个窗口都是独立终端互不影响。而这一切都跑在远程服务器上本地断开再连上输入tmux attach就能全部恢复。3.2 高频操作清单够用就行tmux 默认前缀键是Ctrlb意思是先按一下Ctrlb再按对应功能键。下面这些是我每天必用的其他不常用的暂不列操作命令说明新建会话tmux new -s work-s给会话命名方便后面恢复分离会话Ctrlb d会话继续在后台跑本地先断开查看会话列表tmux ls列出所有存活的会话重新连接会话tmux attach -t work-t指定会话名新建窗口Ctrlb c在当前会话里开一个新窗口切换窗口Ctrlb 数字按编号切换窗口横向切分窗格Ctrlb %当前窗格左右分成两个纵向切分窗格Ctrlb 双引号当前窗格上下分成两个在窗格间跳转Ctrlb 方向键按方向键移动焦点滚动查看历史输出Ctrlb [进入复制模式用上下键翻看q退出这套操作足够覆盖 90% 的日常场景。记不住全部没关系先把new、attach、d、c这四个焊死在肌肉记忆里后面再慢慢加。3.3 两个让我“真香”的进阶配置只掌握基础操作tmux 已经很好用了。但下面这两个进阶配置才是真正让它成为生产力工具的杀手锏。第一配置持久化插件 tmux-resurrect tmux-continuum。我有一段时间特别烦一件事服务器偶尔要重启比如内核升级重启后所有 tmux 会话全部消失窗口布局、正在跑的进程全得手动重建。后来装了两个插件问题彻底解决。tmux-resurrect 手动保存当前 tmux 的所有会话、窗口、窗格布局甚至能恢复 vim、SSH 会话。tmux-continuum 每 15 分钟自动保存一次服务器重启后如果配置了自动恢复还会在 tmux 启动时自动把上次的会话全部恢复。这个功能在远程开发里太实用了。我印象最深的一次是周六晚上在服务器上跑了三组数据批处理任务分别放在三个 tmux 窗口里。周日早上发现服务器半夜做过一次重启当时心都凉了——结果重新 SSH 上去tmux attach三个窗口整整齐齐躺在那里批处理任务甚至自动继续跑完了后半段。安装方法很简单前提是你装了 tpm tmux 插件管理器。在~/.tmux.conf里加set -g plugin tmux-plugins/tpm set -g plugin tmux-plugins/tmux-resurrect set -g plugin tmux-plugins/tmux-continuum set -g continuum-restore on然后tmux source ~/.tmux.conf再按Ctrlb I安装插件。开了自动保存和自动恢复之后基本就告别“会话丢失焦虑”了。第二修改前缀键和增加窗口内切换的快捷键。默认前缀Ctrlb在键盘上离左手有点远容易按出腱鞘炎。我把它改成了更顺手的Ctrla这也是很多老玩家的选择同时在配置里加了一行用Ctrlhjkl在窗格间跳转的映射手指不用离开主键区# 修改前缀键 set -g prefix C-a unbind C-b bind C-a send-prefix # 用 Ctrlhjkl 直接跳转窗格 bind h select-pane -L bind j select-pane -D bind k select-pane -U bind l select-pane -R再补充几个提高效率的配置开启鼠标模式set -g mouse on这样可以直接鼠标点选窗格、滚动窗格内容开启会话编号显示set -g base-index 1窗口从 1 开始编号而不是 0符合直觉。4. Claude Code 在远程环境下的安装与使用tmux 把远程开发的“稳定性”问题解决了Claude Code 负责的是“自动化”这半边。这一节我详细拆解 Claude Code 是什么、在 Windows 远程环境里怎么装、以及它真正能帮你干什么。4.1 Claude Code 是什么、能干什么Claude Code 是 Anthropic 推出的命令行 AI 编程工具。你可以把它理解为一个“能看懂项目、能改代码、能执行命令”的 AI 同事直接跑在你的终端里。它的工作方式跟你在网页上提问完全不一样它能看到当前目录下的项目结构能读取文件内容能理解你写的 README 和代码注释。它可以直接执行 shell 命令跑测试、装依赖、查 git 日志、执行构建脚本。你可以给它一个任务描述比如“帮我把登录接口的超时时间从 30 秒改成 5 秒并更新相关测试”它会自己找出涉及的文件、修改代码、跑测试、汇报结果。它支持交互模式和脚本模式后者是做成自动化的关键我一会儿细讲。网上有人把它归类为“AI 编程助手”我自己的体验是它更像“一个驻守在终端里的自动化工程师”。尤其适合处理那些“重复、机械、但需要看代码逻辑”的改动任务。4.2 Windows 环境下安装 Claude Code 的完整步骤我前面说了强烈建议在 WSL2 里装和跑。下面这套步骤我在干净的 WSL2 Ubuntu 上实测过可以直接照抄。在 WSL2 终端里依次执行第一步确保 Node.js 版本足够新。Claude Code 要求 Node.js 18推荐 22。# 检查版本如果低于 18 或没装用下面的命令装新版 node -v # 安装 Node.js 22Ubuntu 下推荐用 NodeSource 源 curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt-get install -y nodejs第二步用 npm 全局安装 Claude Codesudo npm install -g anthropic-ai/claude-code安装完成后验证一下claude --version第三步登录认证。首次运行claude命令它会打印一个登录链接让你在浏览器里完成授权认证。这个认证会用浏览器打开 Anthropic 的页面登录你的账号并允许终端访问。在 WSL2 里跑的时候浏览器会从 Windows 侧弹出来直接复制链接到 Windows 浏览器打开就行验证完成后 WSL 里的 Claude Code 就自动登录了。这里要提醒一句认证之后你的登录凭证会存在 WSL 的 home 目录下。如果你 WSL 里有多套项目用的都是同一个凭证这点很清楚但要注意这台机器就代表你的身份别在公共电脑上乱装。第四步确认 WSL 里能访问到项目代码。如果你的项目代码在 Windows 盘符下比如D:\project在 WSL 里访问路径是/mnt/d/project。你可以直接把 WSL 的工作目录切过去cd /mnt/d/project claude如果在服务器上开发就先ssh userserver进入项目目录再跑claude。我实际使用下来Claude Code 跑在远端 Linux 服务器上比跑在本机 WSL 里更顺因为远程服务器一般配置高、网络稳定而且项目依赖通常在服务器上已经装好了。4.3 交互模式 vs 非交互模式自动化的关键Claude Code 最有价值的一点是它提供了非交互模式print mode。交互模式就是你敲claude回车进入一个对话式的命令行界面像聊天一样跟它交流。而非交互模式可以直接把任务作为参数传进去执行完就退出非常适合写进脚本里批量调用。基本用法claude -p 把 src/utils/date.ts 里所有函数加上 JSDoc 注释每个函数至少三行说明-p就是 print mode它会在不进入交互界面的情况下直接让 Claude Code 执行任务并把结果输出到 stdout。这等于把 AI 变成了一台“任务执行机器”可以被你的脚本调用。我再加几个常用参数--model sonnet指定模型版本追求速度和性价比可以选 Sonnet。--allowedTools Bash(git:*)限制 Claude Code 只能执行 git 相关的命令安全隔离。--output-format json输出结构化 JSON方便脚本解析。--max-turns 20限制最大执行轮数防止 AI 在某些任务上陷入死循环。这几个参数组合起来自动化的想象空间就打开了。比如你可以写一个脚本循环读取一个待办清单把每一条任务交给claude -p去执行并把输出记录下来。4.4 让 Claude Code 更懂你项目的 CLAUDE.mdClaude Code 支持在项目根目录放一个CLAUDE.md文件它会在每次会话开始时自动读取这个文件的内容把它当作你的项目背景说明。我在所有项目里都会维护这个文件写上项目结构、编码规范、常用命令、以及“哪些目录别动”等注意事项。这样 Claude Code 在干活的时候就像来了一个看过项目文档的资深同事而不是一个只会瞎猜的机器人。一个最小示例# 项目说明 这是一个支付网关服务使用 Node.js TypeScript 编写。 ## 项目结构 - src/ 源码目录 - tests/ 测试目录 - scripts/ 工具脚本 ## 常用命令 - npm test 跑单元测试 - npm run build 构建产物 - npm run lint 代码检查 ## 编码规范 - 新增文件必须有对应的单元测试 - 所有错误码在 src/errors.ts 中统一定义 - 不要修改 migrations/ 目录下的内容有了这个文件Claude Code 改代码前会先读它改完后跑测试时也会参考“常用命令”效率和准确率都能上一个台阶。5. 把 tmux 和 Claude Code 串成自动化工作流前面几节都是搭零件这一节把它们组装成一条能跑的通的工作流。我会用一个真实场景来演示自动修复项目里的测试失败用例。5.1 场景拆解自动修复测试失败假设我现在负责一个 Node.js 服务端项目今天早上跑了一遍测试发现有 7 个用例失败。正常的流程是我打开测试报告逐个失败用例定位代码、修改、再跑测试。如果用例本身不复杂比如只是字段名改了、超时时间调整了这种事完全可以交给 Claude Code 做。我的方案是在 tmux 里开一个会话窗格左侧跑 Claude Code右侧开一个实时日志窗口然后给 Claude Code 一条特别明确的任务claude -p 运行 npm test逐个分析失败用例修复导致失败的源代码问题。 要求 1. 不要修改测试文件本身只改源码 2. 每次修改后重新运行对应测试文件 3. 所有用例都通过后提交 git commitmessage 格式为 fix: resolve failing tests 4. 执行完毕后输出每个失败用例的原因和你的修复方案这条指令的信息量很大它告诉 AI 要做什么跑测试、分析失败、修代码、怎么做改源码而不是测试文件、以及验收标准全部通过后 commit。Claude Code 会自己调度工具去完成整个流程中间不需要任何人介入。为什么要放在 tmux 里跑而不是直接本地跑因为这类自动化任务通常要几分钟甚至更久中间我不可能一直盯着终端。我把它丢进 tmux 窗口然后去开别的会回来后tmux attach任务早就做完了输出结果都存在终端历史里一条都不丢。就算中间我想用这台电脑干别的SSH 断开也不影响任务继续跑。5.2 进阶用脚本批量派发任务给 Claude Code单条任务用claude -p直接跑很简单但是当任务量上来之后手动输入就不合适了。我写了一个简单的脚本把待办事项存在todo.md里脚本逐条读取并交给 Claude Code 执行输出写入日志文件。#!/bin/bash # claude-task-runner.sh # 用法: ./claude-task-runner.sh todo.md TASK_FILE$1 LOG_DIR./claude-logs mkdir -p $LOG_DIR # 逐行读取任务跳过空行和#注释 grep -v ^# $TASK_FILE | grep -v ^$ | while IFS read -r task; do echo 执行任务 echo 任务内容: $task # 给任务生成一个时间戳文件名 LOG_FILE$LOG_DIR/$(date %Y%m%d_%H%M%S).log # 交给 Claude Code 执行非交互模式最多运行 50 轮 claude -p $task --max-turns 50 --allowedTools Bash(git:*) 21 | tee $LOG_FILE echo 完成日志文件: $LOG_FILE done配合 cron服务器端或 Windows 任务计划程序如果任务要每天定时触发这套脚本就能变成真正的自动化流水线。比如我每周五下午三点自动触发的“代码规范自动修复”“依赖安全检查”这些任务就是这么跑的。5.3 多窗格协作把自动化过程“可视化”如果只是把任务丢给后台那和黑盒脚本也没区别。我习惯在跑 Claude Code 自动化的时候把过程“亮出来”让自己随时能看到 AI 在干什么。做法就是利用 tmux 的多窗格功能。窗格 1运行 Claude Code 交互模式或非交互脚本窗格 2运行git log --oneline -10查看提交记录变化窗格 3保持一个htop进程监控服务器负载三个窗格横向排开我偶尔扫一眼就知道 AI 是否卡住、是否乱提交代码、服务器负载是否异常。配合 tmux 的同步输入功能Ctrlb然后输入:setw synchronize-panes我还可以同时往多个窗格发送命令——比如一键在所有窗格清空终终端。5.4 SSH 连接与会话保持的最佳实践说到 Windows 远程连接很多人会在“连接不稳定”上栽跟头。我的习惯是SSH 连接一定要设置心跳保活不然隔几分钟没操作连接就被网络设备“回收”了。在 Windows 的~/.ssh/config文件里加上Host myserver HostName your-server-ip User your-username Port 22 ServerAliveInterval 60 ServerAliveCountMax 3ServerAliveInterval 60的意思是每 60 秒发一个心跳包给服务器让网络设备认为这个连接还是活跃的避免被剪断。ServerAliveCountMax 3表示连续 3 次心跳无响应才主动断开。配置好之后以后连接服务器直接ssh myserver就行不用再输 IP 和用户名。进了服务器第一件事永远是tmux attach或tmux new -s work这已经是我的肌肉记忆了。6. 常见问题与避坑速查最后这部分我把实际使用中碰到频率最高的问题整理成速查表每个坑都是真金白银换来的经验。6.1 高频问题速查表问题原因解决方案本地断开后 SSH 连接半天不释放没有心跳保活按 5.4 节配置ServerAliveIntervaltmux 里鼠标滚轮不能翻历史输出鼠标模式未开启set -g mouse on后重新加载配置tmux 会话突然没了服务器重启无持久化装 tmux-resurrect tmux-continuum 插件Claude Code 安装时报权限错误npm 全局目录权限不足用sudo npm install -g或配置 npm 用户级目录WSL 里 claude 命令找不到全局 node_modules 不在 PATH检查node -v必要时echo $PATH排查Claude Code 无法访问 Windows 盘符文件路径不对确认用/mnt/d/...而不是D:\...复制 Windows 文本到 tmux 粘贴不全转义问题在 Windows Terminal 设置里开启应用剪贴板操作Claude Code 跑到一半卡住不动可能是在等待确认进入交互模式运行或限制--max-turns让他尽早退出服务器上的 git 操作需要输入密码未配置密钥在 Windows 生成公钥加入服务器的authorized_keys6.2 我踩过的两个真实深坑第一个坑是WSL2 的路径转换坑。有次我在 WSL2 里运行 Claude Code给它指定的项目目录在 Windows 的 D 盘然后让它执行npm install。结果它执行的命令参数里带有 Windows 风格路径导致一系列诡异的“文件找不到”错误。后来统一规范在 WSL2 里跑 AI 任务时所有路径一律用 Linux 格式别混用。第二个坑是Claude Code 的 hooks 和子进程权限。有次我配置了一个 git commit 的 hook希望提交代码时自动跑 ESLint。结果 Claude Code 通过Bash(git commit ...)执行提交时它的 Shell 环境和登录 Shell 不一样一些 PATH 里的工具比如nvm管理的 node找不到。解决办法是在~/.bashrc里把 PATH 环境变量配置好并确保 Claude Code 启动时通过bash -lc加载了登录 Shell 的环境。这类问题排查的思路其实很通用看日志、看环境变量、逐步缩小区间。自动化工具再聪明也受限于运行环境的完整性环境配置好它的成功率就会高很多。6.3 给新手的三个实操建议第一不要一上来就配一堆 tmux 插件。先把会话的新建、分离、重连这三个操作练熟其他的后面需要再补。工具是越用越顺手的不是越配越顺手的。第二用 Claude Code 时任务描述越具体越好。我见过太多人说“帮我优化一下代码”然后吐槽 AI 做得不好。优化哪里什么方向验收标准是什么你把这些说清楚Claude Code 的产出质量会翻倍。我现在写任务指令的模板是目标 约束 验收标准 输出格式。第三自动化任务一定要留日志。我前面脚本里用tee把 Claude Code 的输出存到文件这种事不要省。AI 自动化执行最大的风险不是它做错而是你事后查不到它为什么做错。留日志是所有排查的起点。结尾这套工作流改变了我什么说实话刚把 tmux 和 Claude Code 组合起来用的时候我并没有期待它带来什么颠覆性的改变。但用了一个月之后回头再看变化确实很大。最直观的体验是远程开发不再是一件“时刻要盯着”的事而是一件“可以放心交给它自己跑”的事。tmux 像一个永远不会关机的办公桌Claude Code 像一个能听懂需求、能动手干活的实习生我只需要偶尔去看一眼进度做做审核和纠偏。我也越来越理解一句话自动化的目的不是替代人而是把人从重复劳动里解放出来。像批量改接口字段、跑回归测试、修复格式错误这类事情让 tmux 在后台稳稳托底、让 Claude Code 去动手执行、让我自己只保留“拍板”这个最核心的职责。如果你也在用 Windows 做远程开发我强烈建议你也试试这套组合按这篇文的步骤走一遍很快就能体会到“断开 SSH 也不慌改代码不用自己动手”的踏实感。
Windows + tmux + Claude Code：远程开发自动化工作流实战
用了好几年的远程开发我一直觉得这是个“用着别扭但说不上来哪里别扭”的事。直到最近把日常主力机切到 Windows项目代码又全在远端 Linux 服务器上才真正把这件事重新捋了一遍。标题里这三个东西——Windows、tmux、Claude Code——单拎出来每个都不新鲜但把它们串成一条完整工作流确实解决了我好几个长期痛点SSH 一断会话就丢、AI 编码工具在 Windows 端水土不服、批量改代码时永远要人盯着终端。这篇文章就是把这套组合的完整搭建过程、踩坑记录和自动化思路整理出来。不管你是刚接触远程开发的新手还是被“代码在服务器上、人却离不开本地编辑器”折磨的资深开发者这套方案都可以直接抄作业。1. 为什么是“Windows tmux Claude Code”这套组合先说结论远程开发的核心矛盾不是“连不上服务器”而是“连接不稳定”和“任务没法持续跑”。tmux 解决前者Claude Code 配合自动化解决后者Windows 则是把这两者粘合起来的本地枢纽。1.1 远程开发里最容易被低估的三个痛点我见过太多人远程开发的方式是打开 Windows 自带的命令行敲ssh userserver然后直接在上面跑命令、改文件。这种方式有两个致命问题一旦网络抖动或者笔记本合盖SSH 连接一断正在跑的编译、测试、部署任务全部中断而且终端里之前的输出也全丢了。第二个痛点是代码编辑。有人用 VS Code Remote-SSH有人用 JetBrains 的 Remote Development这些方案本身没问题但都有一个隐性成本本地要装一套 IDE远程要跑一个 server 端资源占用高而且遇到复杂项目时同步延迟很影响手感。第三个痛点才是 AI 时代新增的——Claude Code、Codex 这类命令行 AI 工具本来是给 Unix/Linux 环境设计的Windows 原生跑起来常有兼容问题。但你的日常工作电脑偏偏是 Windows这就很尴尬。1.2 这套组合的选型逻辑我在选型时参考了一个原则本地尽量轻远程尽量全AI 工具跑在能稳定运行的地方。Windows 只做三件事提供终端Windows Terminal、提供 SSH 客户端系统自带 OpenSSH、提供文件编辑入口VS Code 或直接终端编辑。tmux 跑在远程服务器上负责会话保持、窗口分割、后台任务持续运行让 SSH 断开不再导致任务中断。Claude Code 也跑在远程服务器上因为大多数开发项目编译、测试、依赖安装都在 Linux 环境下最顺畅而 Claude Code 本身需要执行命令、读写文件放在 Linux 端没有路径和权限的坑。这样设计的好处很明显本地 Windows 就算重启远程的 tmux 会话和 Claude Code 任务都不受影响。下次开机ssh连上去tmux attach一切恢复原样就像没断过线一样。也有朋友问为什么不用 WSL我在 1.1 到 1.3 节会详细对比简单说WSL 适合做本地 Linux 环境但如果你已经有真实的远程开发服务器直接在服务器上配 tmux 和 Claude Code 是更干净的选择。2. Windows 端的准备工作与工具链在碰服务器之前先把 Windows 这端的“底座”打好。这一步做扎实后面能少踩 80% 的坑。2.1 终端与 SSHWindows 11 其实啥都不用装Windows 10 1809 之后的版本系统设置里就能启用 OpenSSH 客户端Windows 11 更是默认就带。所以绝大多数情况下你不需要再装任何第三方 SSH 工具。我推荐用Windows Terminal作为本地终端原因很实际支持多 Tab我习惯一个 Tab 连开发服务器一个 Tab 连测试服务器另一个 Tab 留给本地命令。支持自定义快捷键复制粘贴符合直觉CtrlShiftC/V不像老版 conhost 那样反人类。对 UTF-8 和中文显示支持很好这一点在跑 Claude Code 这类输出大量文本的工具时尤其重要。如果你还没装 Windows Terminal去 Microsoft Store 搜“Windows Terminal”安装即可。装完后把默认终端设成它默认配置文件可以选 PowerShell 或 CMD这个不影响远程操作。SSH 连接我建议直接生成密钥对别再每次输密码了。在 Windows PowerShell 里执行ssh-keygen -t ed25519 -C your_emailexample.com一路回车生成到C:\Users\你的用户名\.ssh\下然后把公钥内容追加到服务器的~/.ssh/authorized_keys文件里。这一步做完后续所有 SSH 连接都免密也为后面的自动化脚本铺平了路。2.2 为什么我最终推荐 WSL2 而不是原生 PowerShell这是个容易引战的问题但我凭实际体验说结论在 Windows 上跑 Claude Code我强烈建议先装 WSL2在 WSL 里跑而不是原生 PowerShell。原因有三个第一Claude Code 官方安装脚本是一段 Shell 脚本原生 PowerShell 跑不了你得手动装 Node.js 再 npm 安装步骤多且容易出权限问题。而在 WSL 的 Ubuntu 里直接curl -fsSL https://claude.ai/install.sh | bash一步搞定。第二Claude Code 在运行时会执行大量子进程git 命令、测试命令、文件搜索这些命令在 Linux 环境下行为最标准。WSL2 虽然不是完整 Linux 内核但对这些常见命令的兼容性已经非常好了。我实测过同一段自动化工单在 WSL 里跑比在原生 PowerShell 里跑少踩一半的路径和转义坑。第三WSL2 的网络和文件系统对 Windows 的适配做得不错你可以直接在 WSL 里访问 Windows 盘符下的文件/mnt/c/...也可以从 Windows 访问 WSL 里的文件\\wsl$\Ubuntu\...两边倒文件很方便。装 WSL2 的命令wsl --install装完默认是 Ubuntu它会让你设置一个 Linux 用户名和密码。之后每次打开 Windows Terminal新建一个 Tab 选 Ubuntu就进入 Linux 环境了。2.3 本地编辑器的连接方式终端和命令行搞定了还差一个编辑器。我的推荐方案非常朴素主力用 VS Code连服务器用 Remote-SSH 插件小改动直接在 tmux 里用 vim 搞定。VS Code 的 Remote-SSH 插件逻辑很简单本地装 VS Code远程不装完整 VS Code只装一个 server 组件。打开远程文件夹就像打开本地项目一样代码补全、跳转、调试都好使。但这里有个技巧VS Code Remote-SSH 连接上之后打开终端它默认就是连接到远程服务器的。你在这个集成终端里直接敲tmux attach就等于把 tmux、Claude Code、VS Code 三者串到了一起。本地编辑远程文件远程终端跑 AI 自动化互不干扰。如果只是改一个配置文件、看一段日志我甚至连 VS Code 都懒得开直接在 tmux 里进 vim 改完就退出。轻量、快速也是一种效率。3. tmux 会话管理从入门到“救了我的命”tmux 是这套工作流里最“稳”的一环也是我建议每个远程开发者都要熟练掌握的工具。它的核心价值一句话就能说清你在远程服务器上跑的每个任务都可以在 tmux 会话里持续运行就算你本地断网、重启电脑任务也不受影响。3.1 tmux 的核心概念Session、Window、Pane很多教程一上来就丢一堆快捷键容易把人绕晕。我换个角度讲。tmux 的结构可以类比成你在用一套房子Session会话就是整套房子。你可以在房子里干任何事关了门detach房子还在下次开门attach一切原样。Window窗口就是房子里的房间。一个会话可以有多个窗口每个窗口是一个独立的终端界面。Pane窗格就是房间里被隔断出来的小空间。一个窗口可以被均分成多个窗格同时显示不同内容。举个我日常的场景一个 tmux 会话里开三个窗口。窗口 1跑开发服务器的日志tail -f窗口 2打开 Claude Code 交互界面让它帮我重构代码窗口 3留着做 git 操作和临时命令每个窗口都是独立终端互不影响。而这一切都跑在远程服务器上本地断开再连上输入tmux attach就能全部恢复。3.2 高频操作清单够用就行tmux 默认前缀键是Ctrlb意思是先按一下Ctrlb再按对应功能键。下面这些是我每天必用的其他不常用的暂不列操作命令说明新建会话tmux new -s work-s给会话命名方便后面恢复分离会话Ctrlb d会话继续在后台跑本地先断开查看会话列表tmux ls列出所有存活的会话重新连接会话tmux attach -t work-t指定会话名新建窗口Ctrlb c在当前会话里开一个新窗口切换窗口Ctrlb 数字按编号切换窗口横向切分窗格Ctrlb %当前窗格左右分成两个纵向切分窗格Ctrlb 双引号当前窗格上下分成两个在窗格间跳转Ctrlb 方向键按方向键移动焦点滚动查看历史输出Ctrlb [进入复制模式用上下键翻看q退出这套操作足够覆盖 90% 的日常场景。记不住全部没关系先把new、attach、d、c这四个焊死在肌肉记忆里后面再慢慢加。3.3 两个让我“真香”的进阶配置只掌握基础操作tmux 已经很好用了。但下面这两个进阶配置才是真正让它成为生产力工具的杀手锏。第一配置持久化插件 tmux-resurrect tmux-continuum。我有一段时间特别烦一件事服务器偶尔要重启比如内核升级重启后所有 tmux 会话全部消失窗口布局、正在跑的进程全得手动重建。后来装了两个插件问题彻底解决。tmux-resurrect 手动保存当前 tmux 的所有会话、窗口、窗格布局甚至能恢复 vim、SSH 会话。tmux-continuum 每 15 分钟自动保存一次服务器重启后如果配置了自动恢复还会在 tmux 启动时自动把上次的会话全部恢复。这个功能在远程开发里太实用了。我印象最深的一次是周六晚上在服务器上跑了三组数据批处理任务分别放在三个 tmux 窗口里。周日早上发现服务器半夜做过一次重启当时心都凉了——结果重新 SSH 上去tmux attach三个窗口整整齐齐躺在那里批处理任务甚至自动继续跑完了后半段。安装方法很简单前提是你装了 tpm tmux 插件管理器。在~/.tmux.conf里加set -g plugin tmux-plugins/tpm set -g plugin tmux-plugins/tmux-resurrect set -g plugin tmux-plugins/tmux-continuum set -g continuum-restore on然后tmux source ~/.tmux.conf再按Ctrlb I安装插件。开了自动保存和自动恢复之后基本就告别“会话丢失焦虑”了。第二修改前缀键和增加窗口内切换的快捷键。默认前缀Ctrlb在键盘上离左手有点远容易按出腱鞘炎。我把它改成了更顺手的Ctrla这也是很多老玩家的选择同时在配置里加了一行用Ctrlhjkl在窗格间跳转的映射手指不用离开主键区# 修改前缀键 set -g prefix C-a unbind C-b bind C-a send-prefix # 用 Ctrlhjkl 直接跳转窗格 bind h select-pane -L bind j select-pane -D bind k select-pane -U bind l select-pane -R再补充几个提高效率的配置开启鼠标模式set -g mouse on这样可以直接鼠标点选窗格、滚动窗格内容开启会话编号显示set -g base-index 1窗口从 1 开始编号而不是 0符合直觉。4. Claude Code 在远程环境下的安装与使用tmux 把远程开发的“稳定性”问题解决了Claude Code 负责的是“自动化”这半边。这一节我详细拆解 Claude Code 是什么、在 Windows 远程环境里怎么装、以及它真正能帮你干什么。4.1 Claude Code 是什么、能干什么Claude Code 是 Anthropic 推出的命令行 AI 编程工具。你可以把它理解为一个“能看懂项目、能改代码、能执行命令”的 AI 同事直接跑在你的终端里。它的工作方式跟你在网页上提问完全不一样它能看到当前目录下的项目结构能读取文件内容能理解你写的 README 和代码注释。它可以直接执行 shell 命令跑测试、装依赖、查 git 日志、执行构建脚本。你可以给它一个任务描述比如“帮我把登录接口的超时时间从 30 秒改成 5 秒并更新相关测试”它会自己找出涉及的文件、修改代码、跑测试、汇报结果。它支持交互模式和脚本模式后者是做成自动化的关键我一会儿细讲。网上有人把它归类为“AI 编程助手”我自己的体验是它更像“一个驻守在终端里的自动化工程师”。尤其适合处理那些“重复、机械、但需要看代码逻辑”的改动任务。4.2 Windows 环境下安装 Claude Code 的完整步骤我前面说了强烈建议在 WSL2 里装和跑。下面这套步骤我在干净的 WSL2 Ubuntu 上实测过可以直接照抄。在 WSL2 终端里依次执行第一步确保 Node.js 版本足够新。Claude Code 要求 Node.js 18推荐 22。# 检查版本如果低于 18 或没装用下面的命令装新版 node -v # 安装 Node.js 22Ubuntu 下推荐用 NodeSource 源 curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt-get install -y nodejs第二步用 npm 全局安装 Claude Codesudo npm install -g anthropic-ai/claude-code安装完成后验证一下claude --version第三步登录认证。首次运行claude命令它会打印一个登录链接让你在浏览器里完成授权认证。这个认证会用浏览器打开 Anthropic 的页面登录你的账号并允许终端访问。在 WSL2 里跑的时候浏览器会从 Windows 侧弹出来直接复制链接到 Windows 浏览器打开就行验证完成后 WSL 里的 Claude Code 就自动登录了。这里要提醒一句认证之后你的登录凭证会存在 WSL 的 home 目录下。如果你 WSL 里有多套项目用的都是同一个凭证这点很清楚但要注意这台机器就代表你的身份别在公共电脑上乱装。第四步确认 WSL 里能访问到项目代码。如果你的项目代码在 Windows 盘符下比如D:\project在 WSL 里访问路径是/mnt/d/project。你可以直接把 WSL 的工作目录切过去cd /mnt/d/project claude如果在服务器上开发就先ssh userserver进入项目目录再跑claude。我实际使用下来Claude Code 跑在远端 Linux 服务器上比跑在本机 WSL 里更顺因为远程服务器一般配置高、网络稳定而且项目依赖通常在服务器上已经装好了。4.3 交互模式 vs 非交互模式自动化的关键Claude Code 最有价值的一点是它提供了非交互模式print mode。交互模式就是你敲claude回车进入一个对话式的命令行界面像聊天一样跟它交流。而非交互模式可以直接把任务作为参数传进去执行完就退出非常适合写进脚本里批量调用。基本用法claude -p 把 src/utils/date.ts 里所有函数加上 JSDoc 注释每个函数至少三行说明-p就是 print mode它会在不进入交互界面的情况下直接让 Claude Code 执行任务并把结果输出到 stdout。这等于把 AI 变成了一台“任务执行机器”可以被你的脚本调用。我再加几个常用参数--model sonnet指定模型版本追求速度和性价比可以选 Sonnet。--allowedTools Bash(git:*)限制 Claude Code 只能执行 git 相关的命令安全隔离。--output-format json输出结构化 JSON方便脚本解析。--max-turns 20限制最大执行轮数防止 AI 在某些任务上陷入死循环。这几个参数组合起来自动化的想象空间就打开了。比如你可以写一个脚本循环读取一个待办清单把每一条任务交给claude -p去执行并把输出记录下来。4.4 让 Claude Code 更懂你项目的 CLAUDE.mdClaude Code 支持在项目根目录放一个CLAUDE.md文件它会在每次会话开始时自动读取这个文件的内容把它当作你的项目背景说明。我在所有项目里都会维护这个文件写上项目结构、编码规范、常用命令、以及“哪些目录别动”等注意事项。这样 Claude Code 在干活的时候就像来了一个看过项目文档的资深同事而不是一个只会瞎猜的机器人。一个最小示例# 项目说明 这是一个支付网关服务使用 Node.js TypeScript 编写。 ## 项目结构 - src/ 源码目录 - tests/ 测试目录 - scripts/ 工具脚本 ## 常用命令 - npm test 跑单元测试 - npm run build 构建产物 - npm run lint 代码检查 ## 编码规范 - 新增文件必须有对应的单元测试 - 所有错误码在 src/errors.ts 中统一定义 - 不要修改 migrations/ 目录下的内容有了这个文件Claude Code 改代码前会先读它改完后跑测试时也会参考“常用命令”效率和准确率都能上一个台阶。5. 把 tmux 和 Claude Code 串成自动化工作流前面几节都是搭零件这一节把它们组装成一条能跑的通的工作流。我会用一个真实场景来演示自动修复项目里的测试失败用例。5.1 场景拆解自动修复测试失败假设我现在负责一个 Node.js 服务端项目今天早上跑了一遍测试发现有 7 个用例失败。正常的流程是我打开测试报告逐个失败用例定位代码、修改、再跑测试。如果用例本身不复杂比如只是字段名改了、超时时间调整了这种事完全可以交给 Claude Code 做。我的方案是在 tmux 里开一个会话窗格左侧跑 Claude Code右侧开一个实时日志窗口然后给 Claude Code 一条特别明确的任务claude -p 运行 npm test逐个分析失败用例修复导致失败的源代码问题。 要求 1. 不要修改测试文件本身只改源码 2. 每次修改后重新运行对应测试文件 3. 所有用例都通过后提交 git commitmessage 格式为 fix: resolve failing tests 4. 执行完毕后输出每个失败用例的原因和你的修复方案这条指令的信息量很大它告诉 AI 要做什么跑测试、分析失败、修代码、怎么做改源码而不是测试文件、以及验收标准全部通过后 commit。Claude Code 会自己调度工具去完成整个流程中间不需要任何人介入。为什么要放在 tmux 里跑而不是直接本地跑因为这类自动化任务通常要几分钟甚至更久中间我不可能一直盯着终端。我把它丢进 tmux 窗口然后去开别的会回来后tmux attach任务早就做完了输出结果都存在终端历史里一条都不丢。就算中间我想用这台电脑干别的SSH 断开也不影响任务继续跑。5.2 进阶用脚本批量派发任务给 Claude Code单条任务用claude -p直接跑很简单但是当任务量上来之后手动输入就不合适了。我写了一个简单的脚本把待办事项存在todo.md里脚本逐条读取并交给 Claude Code 执行输出写入日志文件。#!/bin/bash # claude-task-runner.sh # 用法: ./claude-task-runner.sh todo.md TASK_FILE$1 LOG_DIR./claude-logs mkdir -p $LOG_DIR # 逐行读取任务跳过空行和#注释 grep -v ^# $TASK_FILE | grep -v ^$ | while IFS read -r task; do echo 执行任务 echo 任务内容: $task # 给任务生成一个时间戳文件名 LOG_FILE$LOG_DIR/$(date %Y%m%d_%H%M%S).log # 交给 Claude Code 执行非交互模式最多运行 50 轮 claude -p $task --max-turns 50 --allowedTools Bash(git:*) 21 | tee $LOG_FILE echo 完成日志文件: $LOG_FILE done配合 cron服务器端或 Windows 任务计划程序如果任务要每天定时触发这套脚本就能变成真正的自动化流水线。比如我每周五下午三点自动触发的“代码规范自动修复”“依赖安全检查”这些任务就是这么跑的。5.3 多窗格协作把自动化过程“可视化”如果只是把任务丢给后台那和黑盒脚本也没区别。我习惯在跑 Claude Code 自动化的时候把过程“亮出来”让自己随时能看到 AI 在干什么。做法就是利用 tmux 的多窗格功能。窗格 1运行 Claude Code 交互模式或非交互脚本窗格 2运行git log --oneline -10查看提交记录变化窗格 3保持一个htop进程监控服务器负载三个窗格横向排开我偶尔扫一眼就知道 AI 是否卡住、是否乱提交代码、服务器负载是否异常。配合 tmux 的同步输入功能Ctrlb然后输入:setw synchronize-panes我还可以同时往多个窗格发送命令——比如一键在所有窗格清空终终端。5.4 SSH 连接与会话保持的最佳实践说到 Windows 远程连接很多人会在“连接不稳定”上栽跟头。我的习惯是SSH 连接一定要设置心跳保活不然隔几分钟没操作连接就被网络设备“回收”了。在 Windows 的~/.ssh/config文件里加上Host myserver HostName your-server-ip User your-username Port 22 ServerAliveInterval 60 ServerAliveCountMax 3ServerAliveInterval 60的意思是每 60 秒发一个心跳包给服务器让网络设备认为这个连接还是活跃的避免被剪断。ServerAliveCountMax 3表示连续 3 次心跳无响应才主动断开。配置好之后以后连接服务器直接ssh myserver就行不用再输 IP 和用户名。进了服务器第一件事永远是tmux attach或tmux new -s work这已经是我的肌肉记忆了。6. 常见问题与避坑速查最后这部分我把实际使用中碰到频率最高的问题整理成速查表每个坑都是真金白银换来的经验。6.1 高频问题速查表问题原因解决方案本地断开后 SSH 连接半天不释放没有心跳保活按 5.4 节配置ServerAliveIntervaltmux 里鼠标滚轮不能翻历史输出鼠标模式未开启set -g mouse on后重新加载配置tmux 会话突然没了服务器重启无持久化装 tmux-resurrect tmux-continuum 插件Claude Code 安装时报权限错误npm 全局目录权限不足用sudo npm install -g或配置 npm 用户级目录WSL 里 claude 命令找不到全局 node_modules 不在 PATH检查node -v必要时echo $PATH排查Claude Code 无法访问 Windows 盘符文件路径不对确认用/mnt/d/...而不是D:\...复制 Windows 文本到 tmux 粘贴不全转义问题在 Windows Terminal 设置里开启应用剪贴板操作Claude Code 跑到一半卡住不动可能是在等待确认进入交互模式运行或限制--max-turns让他尽早退出服务器上的 git 操作需要输入密码未配置密钥在 Windows 生成公钥加入服务器的authorized_keys6.2 我踩过的两个真实深坑第一个坑是WSL2 的路径转换坑。有次我在 WSL2 里运行 Claude Code给它指定的项目目录在 Windows 的 D 盘然后让它执行npm install。结果它执行的命令参数里带有 Windows 风格路径导致一系列诡异的“文件找不到”错误。后来统一规范在 WSL2 里跑 AI 任务时所有路径一律用 Linux 格式别混用。第二个坑是Claude Code 的 hooks 和子进程权限。有次我配置了一个 git commit 的 hook希望提交代码时自动跑 ESLint。结果 Claude Code 通过Bash(git commit ...)执行提交时它的 Shell 环境和登录 Shell 不一样一些 PATH 里的工具比如nvm管理的 node找不到。解决办法是在~/.bashrc里把 PATH 环境变量配置好并确保 Claude Code 启动时通过bash -lc加载了登录 Shell 的环境。这类问题排查的思路其实很通用看日志、看环境变量、逐步缩小区间。自动化工具再聪明也受限于运行环境的完整性环境配置好它的成功率就会高很多。6.3 给新手的三个实操建议第一不要一上来就配一堆 tmux 插件。先把会话的新建、分离、重连这三个操作练熟其他的后面需要再补。工具是越用越顺手的不是越配越顺手的。第二用 Claude Code 时任务描述越具体越好。我见过太多人说“帮我优化一下代码”然后吐槽 AI 做得不好。优化哪里什么方向验收标准是什么你把这些说清楚Claude Code 的产出质量会翻倍。我现在写任务指令的模板是目标 约束 验收标准 输出格式。第三自动化任务一定要留日志。我前面脚本里用tee把 Claude Code 的输出存到文件这种事不要省。AI 自动化执行最大的风险不是它做错而是你事后查不到它为什么做错。留日志是所有排查的起点。结尾这套工作流改变了我什么说实话刚把 tmux 和 Claude Code 组合起来用的时候我并没有期待它带来什么颠覆性的改变。但用了一个月之后回头再看变化确实很大。最直观的体验是远程开发不再是一件“时刻要盯着”的事而是一件“可以放心交给它自己跑”的事。tmux 像一个永远不会关机的办公桌Claude Code 像一个能听懂需求、能动手干活的实习生我只需要偶尔去看一眼进度做做审核和纠偏。我也越来越理解一句话自动化的目的不是替代人而是把人从重复劳动里解放出来。像批量改接口字段、跑回归测试、修复格式错误这类事情让 tmux 在后台稳稳托底、让 Claude Code 去动手执行、让我自己只保留“拍板”这个最核心的职责。如果你也在用 Windows 做远程开发我强烈建议你也试试这套组合按这篇文的步骤走一遍很快就能体会到“断开 SSH 也不慌改代码不用自己动手”的踏实感。
