三端协同：用飞书统一调度多台设备上的 Claude Code
我的设备矩阵
先交代背景。我现在日常用三台设备：
| 设备 | 角色 | Claude Code | 在线情况 |
|---|---|---|---|
| 极空间 NAS | 数据中枢 + Docker 宿主 | 容器内运行，命令不全，功能受限 | 24h 开机 |
| MacBook | 办公主力 | 功能最完整 | 下班关机 |
| Windows 笔记本 | 家中辅助 | 功能最完整 | 24h 开机，偶尔关机 |
三台设备分散在不同位置、不同网络环境，但有一个共同点：每台都装了 Claude Code，而且都通过 cc-connect 桥接到了飞书。
核心问题只有一句话——能不能用飞书作为唯一入口，随时随地指挥任意一台设备干活？
答案是能。下面说怎么做到的。
架构全景
两个核心组件：
- cc-connect — 消息桥接层，把飞书机器人消息翻译成 Claude Code 指令，各设备独立配置
- Syncthing（极空间文档双向同步） — 三台设备的工作区数据实时同步，保证任何一台设备拿到任务时，看到的都是同一份最新文件
为什么搞这套架构
三个痛点凑到了一起：
- Mac 下班就关机。晚上想临时让 Claude Code 跑点东西，机器不在线，干瞪眼。
- 极空间 24h 在线，但 Claude Code 是残血版。跑在 Docker 容器里，一些系统命令不完整，复杂操作受限。
- Windows 笔记本 24h 在线且功能完整，但不是主力机。在家放着，偶尔会被家人关机。
单看每一台设备都有短板。但把它们拼在一起，优势互补——24h 在线 + 功能完整 + 数据同步，三个条件同时满足。
各设备的角色分工
极空间 NAS — 数据中枢 + 低负载常驻
擅长的事：
- 文档双向同步永不离线，充当"数据交换中心"
- 简单的文件操作、信息查询、定时任务
- 作为 Syncthing 的常驻节点，保证数据同步不中断
不擅长的事：
- 需要完整 shell 环境的复杂操作
- 需要安装额外工具的 ad-hoc 任务
MacBook — 主力战力
擅长的事：
- 复杂代码编写和重构
- 日常办公期间的高强度 AI 编程
- 所有高级功能（工具调用链路完整）
限制：
- 下班关机，晚上联系不上
Windows 笔记本 — 全天候高战力替补
擅长的事：
- Mac 下班后的主力执行者
- 和 Mac 同等的完整功能
- 24h 在线（只要不被家人关机）
限制：
- 偶尔被关机
- 非主力机，体感上不如 Mac 顺手（但飞书操控时体感一致）
核心技巧：飞书里的设备调度策略
技巧一：按场景指定设备
在飞书群里发消息时，加上前缀指定目标设备：
@bot [mac] 帮我重构 src/auth.ts 的登录逻辑
@bot [win] 跑一下后端测试套件
@bot [nas] 检查 workspace 目录下有哪些未提交的文件
设备名和 cc-connect project name —— 对应，配置在每台设备的 config.toml 里。三台设备注册为三个不同的 project，飞书群里它们各自监听，收到自己名字的消息才响应。
技巧二：让 24h 设备兜底
凌晨时段（Mac 确定关机）的请求自动落到 Windows 笔记本：
# 晚上 11 点，在飞书发：
@bot 帮我给 PR #42 做 code review
# Mac 已关机没反应
# 极空间能力不够
# → Windows 笔记本收到并执行 ✓
不需要手动判断谁在线——离线设备不响应，在线设备自然接管。这个"静默fallback"机制比做复杂的健康检查更可靠。
技巧三：Syncthing 保证数据无缝衔接
这是整个架构最关键的一环。
你在 Mac 上写了一下午代码，commit 推到仓库，工作区里还有一堆未提交的临时文件。下班后 Mac 关机，但这些东西已经通过 Syncthing 实时同步到了极空间和 Windows 笔记本。
晚上你用飞书让 Windows 笔记本继续工作——它打开 workspace，看到的和下午 Mac 上的内容完全一致。没有任何"先 push 再 pull"的手动同步步骤，Syncthing 替你做了。
技巧四：Plan/Task 接力 — 下班前留作业，回家后继续做
这是最能体现这套架构价值的场景。
下班前在 Mac 上干活，功能做了一半，逻辑还没跑通——直接关机会丢上下文。以前要么硬撑着搞完，要么明天重新来过。现在的做法是：
第一步：在 Mac 上把思路结构化。 用 Superpowers 的 brainstorming 理清需求，再用 writing-plans 生成一份实现计划（plan），或者是 executing-plans 拆成一组 task。这些文件直接落在 workspace 里。
第二步：关机上地铁。 Syncthing 已经把 plan/task 文件和所有未提交的改动同步到了极空间和 Windows 笔记本。不需要手动 push，不需要发邮件给自己。
第三步：飞书发指令，让 Windows 笔记本接力。 到家后（或者通勤路上）打开飞书：
@bot [win] 读取 data/superpowers/plans/xxx.md，按计划继续执行
Windows 笔记本上的 Claude Code 打开 plan 文件，上下文完整，接着 Mac 的进度继续干活。
第四步：第二天回到 Mac。 Windows 笔记本昨晚的执行结果——代码改动、生成的文件、task 状态更新——早已通过 Syncthing 同步回来了。打开 Mac，工作区里什么都在，就像没中断过一样。
核心在于——用 Superpowers 把"脑子里的进度"转成"文件里的 plan/task"，跨设备的不是代码，是上下文。 代码 git 能同步，但"接下来该做什么"只有 plan 能传递。
极空间 Docker 容器的取舍
极空间上跑的 claude-code-with-cc-connect 镜像（基于 node:20，详见上篇博客）。虽然容器内环境已经比较完整，但和原生安装的 Claude Code 比还有差距：
| 方面 | Docker 容器内 | 原生安装 |
|---|---|---|
| 系统命令 | 受限（容器最小化） | 完整系统工具链 |
| 工具安装 | 需要重建镜像 | 随时 npm/pip install |
| 权限 | node 用户 | 当前用户 |
| 稳定性 | 容器重启配置丢失 | 稳定 |
所以实际使用中，极空间的 Claude Code 只承担轻量任务。真正重度开发通过 Mac 或 Windows 笔记本完成。
一个教训： 别试图让一台设备干所有事。Docker 容器里的 Claude Code 再优化也比不上原生安装。接受"每台设备各有定位"这个前提，架构设计会简单很多。
踩过的坑
坑一：Syncthing 冲突文件
三台设备同时修改同一个文件时，Syncthing 会产生冲突副本（文件名加 .sync-conflict-*）。Claude Code 操作文件时偶尔会读到冲突副本。
解决： 不要让两台设备同时操作同一文件。飞书调度时，一次任务只落到一台设备。另外 .stignore 里排除 .sync-conflict-* 文件，避免 Claude Code 误读。
坑二：飞书消息延迟
飞书 → cc-connect → Claude Code 的链路有 2-5 秒延迟。发了消息没立刻反应是正常的，不要连发——三条消息会被当成三个独立任务排队执行。
解决： 接受延迟，一条消息等到底。长任务更适合这套链路（"帮我重构 X"比"ls 一下"更合适）。
坑三：Windows 休眠断网
Windows 笔记本长时间不操作可能进入休眠，飞书发消息无响应。
解决： 电源设置里关掉休眠，只保留显示器关闭。或者写个定时 ping 脚本保持唤醒。
坑四：cc-connect 锁文件
容器意外停止后，config.toml.lock 残留导致重启失败。上篇博客已详述，在 entrypoint.sh 里加了 rm -f 解决。
效果：真正的随时随地
现在我的工作方式是：
- 白天在办公室，用 Mac 写代码，Claude Code 全功能直连
- 通勤路上，飞书发消息让家里的 Windows 笔记本提前跑测试、拉代码、准备环境
- 晚上在家，Mac 关机了，飞书继续指挥 Windows 笔记本做白天没搞完的事情
- 周末出门，极空间和 Windows 双保险在线，不会出现"所有设备全离线"
- 所有设备的工作区数据，通过极空间的 Syncthing 实时同步，切换设备零摩擦
核心思路就一条：不要试图让单一设备满足所有需求，而是用消息平台 + 文件同步把多台设备编织成一张网。
飞书是遥控器，Syncthing 是神经中枢，三台设备各司其职。
浙公网安备 33010602011771号