企业官网建设流程全解析

用了好几年的远程开发，我一直觉得这是个“用着别扭但说不上来哪里别扭”的事。直到最近把日常主力机切到 Windows，项目代码又全在远端 Linux 服务器上，才真正把这件事重新捋了一遍。标题里这三个东西——Windows、tmux、Claude Code——单拎出来每个都不新鲜，但把它们串成一条完整工作流，确实解决了我好几个长期痛点：SSH 一断会话就丢、AI 编码工具在 Windows 端水土不服、批量改代码时永远要人盯着终端。

这篇文章就是把这套组合的完整搭建过程、踩坑记录和自动化思路整理出来。不管你是刚接触远程开发的新手，还是被“代码在服务器上、人却离不开本地编辑器”折磨的资深开发者，这套方案都可以直接抄作业。

1. 为什么是“Windows + tmux + Claude Code”这套组合

先说结论：远程开发的核心矛盾不是“连不上服务器”，而是“连接不稳定”和“任务没法持续跑”。tmux 解决前者，Claude Code 配合自动化解决后者，Windows 则是把这两者粘合起来的本地枢纽。

1.1 远程开发里最容易被低估的三个痛点

我见过太多人远程开发的方式是：打开 Windows 自带的命令行，敲ssh user@server，然后直接在上面跑命令、改文件。这种方式有两个致命问题，一旦网络抖动或者笔记本合盖，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 终端与 SSH：Windows 11 其实啥都不用装

Windows 10 1809 之后的版本，系统设置里就能启用 OpenSSH 客户端，Windows 11 更是默认就带。所以绝大多数情况下，你不需要再装任何第三方 SSH 工具。

我推荐用Windows Terminal作为本地终端，原因很实际：

• 支持多 Tab，我习惯一个 Tab 连开发服务器，一个 Tab 连测试服务器，另一个 Tab 留给本地命令。
• 支持自定义快捷键，复制粘贴符合直觉（Ctrl+Shift+C/V），不像老版 conhost 那样反人类。
• 对 UTF-8 和中文显示支持很好，这一点在跑 Claude Code 这类输出大量文本的工具时尤其重要。

如果你还没装 Windows Terminal，去 Microsoft Store 搜“Windows Terminal”安装即可。装完后把默认终端设成它，默认配置文件可以选 PowerShell 或 CMD，这个不影响远程操作。

SSH 连接我建议直接生成密钥对，别再每次输密码了。在 Windows PowerShell 里执行：

ssh-keygen -t ed25519 -C "your_email@example.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 默认前缀键是Ctrl+b，意思是先按一下Ctrl+b，再按对应功能键。下面这些是我每天必用的，其他不常用的暂不列：

这套操作足够覆盖 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，再按Ctrl+b I安装插件。开了自动保存和自动恢复之后，基本就告别“会话丢失焦虑”了。

第二，修改前缀键和增加窗口内切换的快捷键。

默认前缀Ctrl+b在键盘上离左手有点远，容易按出腱鞘炎。我把它改成了更顺手的Ctrl+a（这也是很多老玩家的选择），同时在配置里加了一行用Ctrl+hjkl在窗格间跳转的映射，手指不用离开主键区：

# 修改前缀键 set -g prefix C-a unbind C-b bind C-a send-prefix # 用 Ctrl+hjkl 直接跳转窗格 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 22（Ubuntu 下推荐用 NodeSource 源） curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt-get install -y nodejs

第二步，用 npm 全局安装 Claude Code：

sudo 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 user@server，进入项目目录再跑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.md

Claude 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 commit，message 格式为 '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:*)" 2>&1 | 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 的同步输入功能（Ctrl+b然后输入: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 3

ServerAliveInterval 60的意思是每 60 秒发一个心跳包给服务器，让网络设备认为这个连接还是活跃的，避免被剪断。ServerAliveCountMax 3表示连续 3 次心跳无响应才主动断开。

配置好之后，以后连接服务器直接ssh myserver就行，不用再输 IP 和用户名。进了服务器第一件事永远是tmux attach或tmux new -s work，这已经是我的肌肉记忆了。

6. 常见问题与避坑速查

最后这部分，我把实际使用中碰到频率最高的问题整理成速查表，每个坑都是真金白银换来的经验。

6.1 高频问题速查表

6.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 也不慌，改代码不用自己动手”的踏实感。