企业官网建设流程全解析

Claude Code这名字最近在圈子里越来越响，但大多数人还在讨论它怎么装、怎么配、怎么在终端里聊天写代码。我真正想聊的，是它的远程控制能力——不是向日葵那种远程桌面，也不是在网页上点一点的Web IDE，而是把本地开发会话搬到另一台设备上，接着之前的对话继续干活。这个场景听起来很基础，实际操作起来却有不少门道。

我自己的情况是这样的：主力开发机是一台放在家里的Linux工作站，白天在公司用笔记本通过SSH连上去写代码。Claude Code跑在工作站上，而我手里的终端窗口经常在笔记本、公司台式机、甚至手机上的Termius之间来回切换。每次切换最烦的不是重新连SSH，而是Claude Code那个已经聊了几十轮、带着完整上下文的会话，换台设备就丢了，得重新交代需求，那种挫败感谁经历谁知道。

后来我把跨设备接续本地开发会话这套流程彻底捋顺了，现在不管人在哪里、手里拿的是哪台设备，随时都能无缝接上白天的开发现场。这篇文章我就把整个技术实现和应用场景拆开讲清楚，从底层原理到实操命令，再到我踩过的坑，全部记录下来。

1. 项目缘起：为什么需要跨设备接管本地开发会话

1.1 从一次“断线”经历说起的真实痛点

事情得从一次加班的晚上说起。当时我正用Claude Code在一个项目里排查一段诡异的异步任务丢失问题，上下文已经积累了大概40多轮对话，Claude Code记住了我项目的目录结构、失败日志的关键特征、甚至我习惯的代码风格。快到下班时我合上笔记本，想着回家再继续。

到家打开电脑，SSH连上工作站，启动claude，发现会话已经没了。我只能从头开始，又花了20多分钟重新描述问题背景，粘贴日志，Claude Code又从头开始看代码——那种感觉就像跟一个失忆的同事重新对接工作，效率低到让人抓狂。

那次之后我开始认真琢磨这件事：Claude Code本质上是跑在终端里的一个交互式进程，它的“记忆”全在本地会话里。只要这个进程不被杀掉、会话文件不丢，理论上我完全可以从任意设备重新“接上”它。问题的关键，在于怎么管理这个常驻进程，以及怎么让不同设备都能轻松连进去。

1.2 这里的“远程控制”到底指什么

先说清楚概念，避免混淆。Claude Code的远程控制，不是图形界面上的“远控”，也不是通过浏览器访问一个内网穿透页面。它是一个纯终端工具，所以它的远程控制本质上是终端会话的接管。

具体来说，就是三件事：

• 让Claude Code进程在远端开发机上常驻运行，不随某个终端窗口关闭而退出；
• 让任意设备（笔记本、台式机、平板）通过SSH连到开发机后，能重新附着（attach）到这个会话上；
• 让会话的上下文、历史记录、当前工作目录保持一致，真正做到“换设备不换进度”。

这个思路其实和服务器运维里的tmux、screen是同一个套路，只不过Claude Code有人工智能会话这个额外的状态层，所以在技术实现上要处理得更细心。

1.3 这套方案解决的是什么人的什么需求

我认为主要适合三类人。

第一类，是我这种多设备混用的人。公司一台笔记本、家里一台台式机、偶尔还拿iPad应急，代码全在服务器上，希望Claude Code的会话也能跟代码一样，随处可接。

第二类，是做长时间AI结对编程任务的人。比如重构一个模块、排查一个棘手的线上Bug，这类任务往往需要跑很长的会话，中间可能隔几个小时、甚至隔一天。如果每次重新打开都要从头聊起，AI结对的价值大打折扣。

第三类，是给团队成员共享同一台开发环境的人。几个人共用一台高配工作站，希望所有对话记录和上下文都留在服务器上，谁接入都能看到之前的进展，协同起来会顺畅很多。

2. 技术底座：Claude Code会话机制与远程接管的底层逻辑

2.1 Claude Code本质是一个本地交互式进程

要理解远程控制，先得明白Claude Code本身是怎么工作的。它不像Web应用那样有一个“云端服务端”，Claude Code只是把你本地的命令行工具作为一个客户端，通过API去调用远端的大模型服务。真正干活的是你本地的文件系统、执行命令的本机环境、以及那一大段对话上下文。

换句话说，Claude Code的“灵魂”在你本地的进程里。模型推理发生在对方的服务器上，但对话历史、状态管理、工具调用记录都保存在本地。这就引出一个关键结论：只要本地进程的会话文件还在，理论上来任何地方都能恢复。

我自己在实践中的体会是，理解这一点后，整个远程方案就豁然开朗了。我只需要操心一件事：怎么让进程常驻，怎么安全地连上来。

2.2 会话持久化与恢复机制

Claude Code的会话并不是一个看不见的抽象概念，它的历史记录会持久化到本地。正常使用过程中，它会自动管理会话文件，命令行里也有对应的会话恢复能力。

我常用的两条命令是：

# 继续最近一次的会话 claude --continue # 列出可恢复的会话 claude --resume

--continue这个参数非常实用，如果你只在一个项目里干活，它直接帮你把最近一次对话捞回来。--resume则会弹出一个会话列表，像翻聊天记录一样，可以选一个特定时间的上下文接着聊。

这里有一个很关键的细节：会话恢复依赖的是你接入时的工作目录。Claude Code会把会话跟项目目录绑定在一起，如果你在/home/user/project-a下面start了一个会话，切换到/home/user/project-b之后再执行claude --continue，它恢复的其实是project-b里的最近会话，而不是全局最近的会话。

所以在跨设备接续的时候，第一步永远是先cd到正确的工作目录，再做会话恢复。这个顺序搞反了，很容易出现“为什么我看到的不是刚才那个上下文”的困惑。

2.3 远程接管的三种技术路线对比

有了底子，远程接管就清晰了。我试下来，可行方案大概分三种，各有利弊。

我自己首选方案A。它足够透明——Claude Code跑在服务器上，本地的终端只是一个显示器，任何有SSH客户端的设备都能用，不需要额外装东西。方案B我也不排斥，特别是当我还想在浏览器里改代码时。方案C就得看具体工具维护得怎么样了，我试过一些，功能挺惊艳，但偶尔遇到升级不兼容的问题，就不作为主力了。

3. 实操落地：跨设备无缝接续开发会话的完整方案

3.1 前置准备：开发机、终端与密钥配置

主力方案是SSH加tmux，所以前置条件很明确。

第一步，准备一台开发机。Linux工作站或云服务器都可以，配置不用太高，但建议至少有2核4G内存，因为Claude Code本身会占用一些资源，再加上代码构建和终端进程，太小的机器会比较吃力。

第二步，在本地设备上装好SSH客户端。Windows上我用Windows Terminal自带的OpenSSH，macOS和Linux天生就有，手机上我用Termius，iOS和Android都能用。

第三步是最容易忽略的，配置SSH密钥，避免每次连接还要输密码。我习惯把所有本地设备的公钥都追加到开发机的~/.ssh/authorized_keys里：

# 在本地设备上生成密钥（如果没有的话） ssh-keygen -t ed25519 -C "your-name@device-name" # 把公钥拷贝到开发机 ssh-copy-id user@dev-host

这里用ed25519而不是rsa，主要是密钥更短、生成更快，安全性也够。配置好之后，本地连接开发机就是免密的，这为后面频繁切换设备省了很多心。

3.2 方案A：SSH加tmux常驻会话接管

tmux是个终端复用器，核心能力就是让终端会话脱离当前窗口存活。我把Claude Code放进tmux里跑，就实现了“人在不在，会话都在”的效果。

具体步骤是这样的。

第一步，在开发机上创建一个专属的tmux会话，名字叫claude：

tmux new -s claude

第二步，在这个tmux窗口里，cd到项目目录，启动Claude Code：

cd /path/to/your/project claude

到这里，Claude Code已经在开发机上跑起来了，但它现在和这个tmux窗口绑定。如果你直接关掉终端，SSH断开，tmux会话不会死，Claude Code也不会死。

第三步，回到本地设备，重新SSH到开发机，附着到之前的tmux会话：

ssh user@dev-host tmux attach -t claude

就这么简单，你立刻回到了Claude Code的会话里，所有上下文都在。想离开的时候，按一下Ctrl+b，再按一下d，detach出来，SSH断开走人。下次换台设备再重复一遍，又是无缝接续。

我在实际操作中会起多个tmux会话，按项目区分：

tmux new -s coding-project-a tmux new -s ops-fix

这样每个项目有自己的AI会话，恢复的时候也清晰，不会一锅粥。

3.3 方案B：远程开发容器加Web终端

如果你的场景里不只是跑Claude Code，还需要随手改文件、看目录树，方案B更顺手。我在一台常开的开发机上跑了一个基于Web的开发环境，浏览器打开就是完整IDE界面，内置终端能直接跑claude命令。

核心思路很简单：把整个开发工作区放到一个容器或云开发环境里，然后通过Web方式访问。你可以选择自己部署开源方案，也可以使用云厂商的开发环境服务，这类服务通常自带Web终端。

这种方案最大的好处是客户端零安装。我在公司电脑上哪怕是没有SSH工具的临时机器，只要能开浏览器，就能进入环境，打开终端继续Claude Code会话。

但代价是复杂度上去了。Web开发环境本身要维护，配置不当还会出现端口占用、权限错乱的问题。我的建议是，如果你主要用一台固定电脑干活，方案A足够；如果你经常要在各种临时设备上工作，可以给方案B留个位置。

3.4 设备切换时的标准操作流程

经过这段时间的磨合，我总结了一套标准操作流程，现在基本形成肌肉记忆了。

离开时：

1. 在Claude Code里，把当前进度用一句话总结给AI，让它记住关键结论。这个习惯很重要。
2. 按Ctrl+b然后按d，detach出tmux会话。
3. 断开SSH连接。

在新设备上接入时：

1. SSH连上开发机。
2. cd到对应的项目目录。
3. 执行tmux attach -t claude。
4. 如果tmux会话不小心被关掉了，执行claude --continue恢复。

这套流程我实测下来，从掏出手机到重新接上会话，通常不超过30秒。跨设备无缝接续这件事，就这么解决了。

4. 配置细节与权限管理：不让安全拖后腿

4.1 CLI访问权限与授权范围

Claude Code要读写文件、执行命令，肯定涉及权限问题。把它跑在共享开发机上，尤其要注意最小权限原则。

我给自己定了几条规矩。

第一，不要在root账号下跑Claude Code。创建一个专门的开发用户，比如dev，所有Claude Code操作都在这个用户下进行。这样即使AI误执行了什么危险命令，影响范围也被限制在普通用户权限内，不会直接伤到系统。

第二，注意Claude Code自身的授权机制。当你第一次在某个目录里启动它时，它会要求你确认是否允许它执行命令、读写文件。我建议认真看一下提示，选择“允许并记住”，或者只在当前会话允许。不要让Claude Code在所有目录都拥有完全控制权，按项目粒度授权是更稳妥的做法。

第三，如果宿主机的SSH端口暴露在公网，建议只允许密钥登录，关闭密码登录，并且考虑更换默认端口。这是基本的SSH加固三板斧。

4.2 API密钥和模型配置的跨设备一致性

既然Claude Code跑在开发机上，API密钥自然也应该配置在开发机上。这其实是个优点：本地设备不需要存任何密钥，只要SSH连上开发机就自动获得了AI能力。

我一般把API密钥放到开发机的环境变量里，在这个文件里配置：

# ~/.bashrc export ANTHROPIC_API_KEY="your-api-key-here" export ANTHROPIC_MODEL="claude-sonnet-4-20250514"

这里有个细节，Claude Code也支持通过配置文件设置模型和参数，社区里常见的做法是创建一个配置文件，把默认模型、温度等参数统一管理。这样不管谁连上来，用的是同一套配置，不会出现A设备用的模型和B设备不一样的情况。

另外，社区里很流行把Claude Code接到其他模型上，通过环境变量或配置文件切换端点。比如想要用第三方兼容模型时，只需要改一下环境变量中的API地址和模型名即可。这个灵活性也是Claude Code作为CLI工具的优势，配置文件改起来非常透明。

4.3 多用户共享场景下的隔离与安全

如果你的开发机有好几个人共用，那就不能只考虑“无缝接续”了，还得考虑“互不干扰”。

tmux天然支持多用户多会话隔离，每个人创建自己的tmux会话，互不影响。但要注意，默认情况下tmux的socket是per-user的，用户A的tmux会话，用户B默认是看不到也attach不上的。这样反而干净，不需要额外配置。

如果你希望团队成员能看到同一个会话，最简单的方法是共用同一个系统用户，然后都去attach同一个tmux会话。但这带来一个问题：多个人在同一个会话里同时操作，会互相抢占键盘输入，体验不太行。我更推荐让每个人各跑各的Claude Code会话，有需要同步的时候就共享代码和说明文档。

还有一个安全细节容易被忽略：Claude Code的对话历史里可能包含敏感信息，比如私有代码、日志片段、甚至不小心贴进去的密码。如果开发机是多人共享的，最好定期清理不需要保留的会话历史，避免信息泄露。我给自己定了个规矩，敏感项目用单独的专用用户跑，不用共享账号。

5. 常见问题与排查实录

5.1 连不上服务、会话恢复失败的排查套路

在使用过程中，最常遇到的是“Claude Code启动时报无法连接服务”的错。很多人这时候会被各种提示绕晕，我分享一下我自己的排查顺序。

第一步，检查API密钥配没配好。直接在开发机上跑：

echo $ANTHROPIC_API_KEY

如果输出为空，说明环境变量没加载，检查一下~/.bashrc或对应的配置文件。

第二步，检查网络连通性。Claude Code需要访问模型服务，如果开发机所处网络环境有额外限制，会出现连接超时或直接报错。我的建议是先确认开发机本身能正常访问大模型的API端点，再考虑代理或隧道的问题。

第三步，检查模型名是否配置正确。经常有人把模型名配错一个字符，导致接口返回404或者参数校验错误。Claude Code的报错信息通常会带具体原因，仔细读一下错误头部的几个字段，往往比瞎猜更快。

如果以上都没问题，再看是不是版本问题。Claude Code更新比较频繁，有时升级后配置文件格式变了，旧配置会引发启动异常。这种时候我会备份现有配置，重新跑一遍初始化，再逐步把自定义项加回去。

5.2 tmux会话丢失与上下文丢失

tmux本身很稳定，但偶尔也会因为机器重启、tmux server崩溃导致会话丢失。这种时候，Claude Code自己的会话恢复就派上用场了。

我的做法是，定期用claude --resume看看有哪些会话可以恢复。这里有一个小技巧：Claude Code的会话历史是按项目组织的，如果你发现恢复列表是空的，很可能是因为你当前的工作目录和原来创建会话时的目录不一致。

还有一个我自己踩过的坑：tmux里跑Claude Code时，如果我在tmux里不小心执行了exit而不是detach，整个窗口会关闭，tmux会话也会终止，Claude Code进程随之退出。这个误操作我犯过不止一次。后来我养成一个习惯，在tmux配置文件里给Ctrl+b x加了一层确认，避免手滑直接退出。

5.3 为什么同类工具不一定能做到跨设备接续

网上有不少人问“XX工具怎么不能像这样远程控制”，我觉得核心问题在于工具是否把会话状态真正保存在了本地。

有些AI编程工具把对话上下文放在云端服务端，本地只是一个薄客户端，这类工具天然支持跨设备，因为状态在云端。但代价是数据不在你手上，隐私和合规上会有点膈应。

Claude Code这种CLI工具则相反，状态在本地，所以远程接续完全取决于你能不能把本地进程“接住”。用tmux或系统服务把它托管起来，就做到了跨设备接续。同理，如果你用的是其他类似的CLI工具，只要它支持会话持久化并且状态存在本地，套用这套方案一样能行。

我实际切换过几个不同的CLI工具，有些是设计上就偏向云端同步的，有些和Claude Code一样可以本地托管。结论是，选工具之前先搞清楚“会话状态存在哪里”，这个决定了远程接续的玩法上限。

6. 应用扩展与后续构想

6.1 从个人使用到团队协同

跨设备接续会话这件事，用熟之后很容易想到团队场景。虽然我不建议多人直接在同一个tmux会话里抢键盘，但可以做这样几件事。

第一，把Claude Code的会话历史作为项目的“活文档”。每次AI处理完一个重要任务，我让它在对话里生成一段简短的总结。团队成员连上开发机，resume同一个会话，就能看到AI和之前的人已经做了哪些工作、有什么结论。

第二，在共享开发机上给每个项目建立固定的tmux别名，比如起名project-a、project-b，约定成俗。大家想了解某个项目状态时，直接tmux attach -t project-a，读一下最近的对话，比看文档高效得多。

这个玩法和ChatGPT的分享对话链接有点像，但Claude Code的会话是活的、可以继续接着跑的，这在真正的生产环境里价值很高。

6.2 我对“无缝接续”这件事的几点体会

这套方案我用了大约一个多月，最大的感受是，工具还是那个工具，但换了个用法之后工作方式完全变了。之前我在Claude Code里不敢聊太深，因为怕换台电脑就丢了上下文，现在完全不怕了，反而更敢把长任务挂在里面，让AI慢慢梳理。

还有一点体会是关于会话管理的纪律。跨设备接续的前提是会话逻辑清晰，如果你一个会话里混了五六个完全无关的任务，就算恢复成功，AI也容易被乱七八糟的上下文带偏。我现在会坚持一个项目一个会话，一个任务尽量聊完，聊不完就先把结论沉淀下来再走，这样跨设备接续时永远都是清爽的状态。

6.3 最后分享一个小技巧

都看到这里了，送大家一个我自己觉得特别实用的小技巧：在SSH配置文件里，给不同的开发任务设置快捷别名。

在本地设备的~/.ssh/config里这样写：

Host devbox HostName 192.168.1.100 User dev ServerAliveInterval 30

然后本地连接变得非常简洁：

ssh devbox tmux attach -t claude

ServerAliveInterval这个参数很重要，它会每30秒发一个心跳包，防止网络切换或空闲时间过长时连接被静默断开。这个参数加上之后，移动设备在Wi-Fi和4G/5G之间切换时，SSH连接不会那么容易卡死。

实际用下来，这套“Claude Code + 终端复用器 + SSH”的组合已经成了我日常工作流里最离不开的东西。也希望这篇记录能帮到受困于“换个设备就得从头再来”的你。