Conductor Cloud 停服前的迁移清单

Conductor Cloud 即将关闭，手里还有 Agent 没做完的任务，最急的事是把代码、对话和继续工作的线索保留下来。原文给出的顺序很明确：先迁移工作区、核对 Git、补齐交接说明，再决定下一步用什么工具。

这份清单的价值，在于把「数据已经下载」和「工作可以继续」分开检查。文章后半段也介绍了作者自己的 LetThemBuild，需要把迁移建议与产品推荐分开看。

真正该盯住的是 11 月 13 日

按原文引用的 11 月 4 日公告，Conductor 将加入 Meta。Conductor Cloud 会在 2026 年 11 月 13 日进入只读状态，11 月 20 日关闭。本地版 Conductor 则会继续获得新模型和关键错误修复，直到 2027 年初。

所以，11 月 13 日才应该是迁移工作的实际截止日期。等到关闭前最后几天再处理，云端已经无法正常推进任务。

Conductor 提供了两条迁移路径，用途不同：

• 右键点击云端工作区，选择 Transfer to local，可以把工作区及其聊天记录转到 Mac，继续在本地处理。
• 打开 Settings → Account → Export data，可以下载全部数据。

需要继续工作，也需要留存数据，就两项都做。原文只明确了工作区及聊天记录转到 Mac，没有交代导出包的具体结构，也没有说明它能否被其他工具直接导入。

优先处理有未完成改动、仍依赖历史对话的工作区，再用一份清单排查容易遗漏的旧任务。转移后要实际打开工作区，找到导出文件并检查内容。压缩包下载成功，只能证明拿到了文件，还不能证明备份可用；存放位置也要符合代码和对话的敏感程度。

代码存下来之后，还得证明任务接得上

Agent 在聊天里说「完成了」，不等于改动已经提交，更不等于远程仓库里有可继续使用的分支。

原文建议先用下面三条命令，查看工作区改动、分支状态和最近提交：

git status --short
git branch -vv
git log --oneline --decorate -10

要留意第一行列出的未跟踪文件；后两行也只是排查入口，不能替代对远程状态和 pull request 的核对。

每个活跃仓库都要确认：哪些分支还有未完成工作，哪些文件尚未提交，哪些提交只存在本地，以及已经打开的 pull request 对应哪个分支。需要保留的分支，按团队惯常流程推送到远程。

不要为了备份直接把所有文件一起提交。未跟踪文件里可能混着凭据、本地配置和生成产物。不适合提交的工作，需要另做符合仓库安全要求的备份。

不过，Git 能保存代码，未必能解释代码为什么改、下一步怎么做。因此，每个重要任务还需要一份简短交接说明，记录需求、所在分支、已完成与待完成部分，以及安装、构建、测试命令、已知失败和依赖的本地服务。

环境变量只记录名称、用途和获准的取值方式，不把密钥贴进说明、issue、提示词或仓库。最后，在准备迁入的环境里真正跑一次安装和测试。缺依赖、漏启动服务、遗漏初始化步骤，都应该在云端消失前暴露出来。

迁移完成的标准，是目标环境能接着干活。

替代工具要看执行方式，不能只看「Cloud」

留在本地 Conductor 是原文认可的选项。如果现有能力够用，把云端工作区转到本地，可能就是干扰最小的下一步；但其已公布的新模型和关键修复支持窗口只到 2027 年初。

评估其他工具时，要分别确认两个问题：它能否继续处理这个仓库，以及它是否支持团队需要的工作流程。尤其要问清远端执行什么、返回什么、结果如何检查。

作者推荐的 LetThemBuild 提供 Mac、Windows、Linux 桌面端和 ltb CLI。Mac 安装命令如下：

brew install --cask gpulogyai/tap/ltb

这里的 --cask 指定通过 Homebrew Cask 安装；这条命令只是安装入口，不能说明产品已经兼容原来的云端工作区。

按作者描述，LetThemBuild 先让一个主模型在独立的 Git worktree 中修改代码，主模型可选 Claude、ChatGPT、Gemini 或 Grok。worktree 可以理解为同一仓库下独立的工作目录，用来隔开不同任务的改动。其他模型随后重新运行构建和测试，再表示同意或反对。

它还会生成执行凭据，记录每条命令及退出码，让用户在合并前检查究竟运行过什么。

Pro 支持使用自己的 Claude Code、Codex、Gemini CLI、Grok Build CLI，或 OpenRouter key；Free 对这些自带工具或密钥的选项提供 14 天试用。原文没有给出具体价格。

其 Run in the Cloud 会在 LetThemBuild 的机器上执行某次讨论对应的任务，返回分支或 pull request。作者明确指出，这不代表它具备与 Conductor Cloud 持久化托管工作区相同的能力。

我的判断

这份清单最有用的地方，是把迁移拆成了可检查的结果：数据拿到了、代码去向清楚、任务说明齐全、目标环境能运行。单独导出聊天，或者只推送代码，都可能留下缺口。

但它是一份操作建议，原文没有提供迁移成功率、耗时或不同替代产品的对照数据。LetThemBuild 又是作者自己的产品，因此，多模型复查是否更有效，目前只能按其工作流描述理解，不能当成已经验证的优势。

命令和退出码记录值得参考，但退出码为零只说明命令成功结束。测试覆盖不足时，多名审查模型也可能共享同一处盲区。与直接运行团队现有构建、测试并人工审查 diff 相比，额外引入模型审查是否划算，原文没有回答。

能拿来做什么

• 如果你正在使用 Conductor Cloud，就按 2026 年 11 月 13 日倒排任务，先转移重要工作区并导出数据，再逐项确认能打开、能找到、内容完整。
• 给未完成的前端或 Node 任务补一份交接说明，写清分支、安装与测试命令、所需服务及已知失败，并在目标环境实际执行一次。
• 核查 Agent 留下的成果时，把聊天结论与 Git 状态逐项对应，确认改动是否提交、是否推送、是否已有 pull request。
• 试用替代工具时，从一个小且可撤销的改动开始，检查 diff、执行记录和正常项目检查，并确认它返回的分支或 pull request 能接入现有流程。