Codex和Claude Code虽强，但跨设备工作台才是补上最后一公里的关键

最近有件事让我特别有感触：我同时在用 Codex 和 Claude Code 做项目，前者擅长批量改老代码、处理重构，后者写测试和搭原型很顺手。工具本身是真强，但用着用着我发现一个很尴尬的场景——在公司电脑上跑了一下午的调试思路、已经和 Codex 对齐过的上下文、Claude Code 里排好序的待办任务，回家打开笔记本想接着干，结果一切归零。明明项目代码可以通过 Git 同步，可我“指挥 AI 干活”的过程和中间状态，却实实在在被钉死在了那台机器的本地目录里。

这个问题问出来之后，团队里几乎所有人都点头，说自己也遇到过。于是我开始认真想一件事：在已经有 Codex、Claude Code 这类顶尖 AI 编程工具之后，是不是还缺一层东西？缺一个能把“设备”这个变量彻底从工作流里拿掉的跨设备工作台。这篇文章不是要否定 Codex 和 Claude Code，恰恰相反，我想说的是，正是因为它们太好用了，我们才需要解决“工具变强之后带来的新问题”——AI 会话的连续性、上下文的可迁移性、多设备之间的协作方式，这些就是跨设备工作台要填的坑。

1. Codex 和 Claude Code 在帮我们解决问题，也悄悄制造了新问题

1.1 它们解决的核心问题：从“写代码”到“指挥代码”

先说清楚一个基本判断。Codex 和 Claude Code 这类终端 AI 编程代理，和之前我们熟悉的 ChatGPT 网页版、IDE 里的补全插件，完全不是一个物种。它们的核心变化不是“更智能了一点”，而是把 AI 从“对话助手”变成了“能动手干活的执行者”。

举例来说，以前我让 AI 帮我重构一个模块，它给我一段代码，我自己去替换、跑测试、处理报错。现在用 Codex，我只需要在终端里说清楚目标，它会自己去读项目结构、搜索相关文件、修改代码、运行测试，甚至根据报错自己迭代修。Claude Code 也类似，尤其是它的子代理（subagent）机制，可以拆出多个任务并行推进，比如一个代理去查数据库 schema，一个代理去改服务层代码，一个代理去写测试用例。这种方式下，我的角色从“写代码的人”变成了“指挥 AI 干活的人”，我的核心产出不再是代码本身，而是意图、约束条件、取舍决策，以及过程中的判断和反馈。

这就带来一个很关键的变化：工作的核心资产变了。以前的核心资产是代码，代码在 Git 里，换个设备拉一下就有；现在核心资产变成了“AI 会话上下文”——这个项目为什么这么做、哪些路径不要碰、已经验证过什么方案、接下来要干什么，这些信息都存在 AI 的对话历史里。代码反而变成了会话的“副产品”。

1.2 被忽略的第三维度：设备在哪里

问题恰恰出在这。Codex 和 Claude Code 默认把会话历史、配置、认证状态都存在本地目录。我打开公司电脑上的 Codex，它知道这个项目的来龙去脉；但在家用笔记本上打开同一个仓库，一切都要重头来过。文件可以通过 Git 同步，但“AI 对项目的理解”不会自动跟着走。

这种割裂感在实际工作中特别磨人。打个比方：代码仓库像是一本写了一半的书的文稿，Codex 和 Claude Code 是帮你续写的助手，但那个助手只存在于某一台电脑里。你换一台电脑，就得重新跟一个新助手解释这本书写到哪了、哪些人物关系已经定了、哪条线准备怎么收。不是不能解释，而是要花大量时间重新对齐上下文，而且对齐的效果往往不如之前那一版。

这还不是最麻烦的。更麻烦的是，我在不同设备上用的工具链本来就不一样：公司的机器是 macOS，装了 Claude Code 和一套偏 Java 的 MCP 配置；家里的 Windows 机器上跑的是 Codex，还有一套偏前端的 Node 工具链。两边的环境变量、路径规则、认证令牌都不同。哪怕我想把 AI 会话状态拷过去，也不一定能直接跑起来。设备差异被工具链的差异放大了，AI 工具越强，这种“设备和环境绑定”带来的摩擦就越明显。

2. 跨设备工作台到底在解决什么

2.1 会话即上下文，上下文即价值

很多人第一次听到“跨设备工作台”这个概念，第一反应是：这不就是个聊天记录同步工具吗？我一开始也是这么想的，但真正把需求拆开之后发现，它要解决的核心问题是“会话状态的显性化”。

我们可以对比一下人和人协作的场景。你在办公室跟同事讨论一个方案，讨论完了，结论可能会写进 wiki 或者需求文档，下次开会大家看一眼文档就能接上思路。但用 AI 干活时，这个“文档”天然缺失——你跟 Codex 在终端里来回对话几十轮，每一轮都隐含了大量决策信息：哪些方案试过不行，哪些约束必须满足，哪段代码是临时 hack 的。这些信息存在于会话里，却不一定会写进 Git 提交信息。

跨设备工作台做的第一件事，就是把这些隐性的会话上下文变成一个结构化的、可以跨设备读取和恢复的实体。它不只是同步聊天记录，而是维护“项目当前状态”的完整快照：进行中的任务、已完成的验证、被否决的方案、当前模型和工具配置、尚未执行的下一步计划。你换一台设备，工作台能帮你把“记忆”整体还原出来，而不是让你对着一个空白的终端上下文发呆。

这里的核心认知是：会话不再是一次性的对话过程，而是从始至终伴随项目演进的工作资产。既然是资产，就需要有存放、备份、迁移的机制。跨设备工作台本质上就是一个“会话资产管理器”。

2.2 设备不是容器，工具链才是

跨设备工作台要解决的第二个问题是“工具链的可移植性”。这可能比会话同步更隐蔽，也更难处理。

现实情况是，没有多少开发者会在所有设备上使用完全一致的开发环境。我在 macOS 上用 zsh 加 Neovim 加 Claude Code，在 Windows 上用 PowerShell 加 VSCode 加 Codex，在服务器上又是纯 headless 环境。即便我用同一个工具，不同设备上的配置文件也可能不一致，MCP 服务器的路径、模型供应商的 API Key、CLI 的全局参数，这些都有差异。

一个真正可用的跨设备工作台，需要提供一个“环境无关层”。它要解决以下几个具体问题：

• 把设备的特殊配置和项目级配置分开。项目的核心配置跟着仓库走，设备的特殊配置放在本机覆盖层。
• 抽象出统一的“任务提交”接口。不管底层是 Codex 还是 Claude Code，工作台都以同样的格式接收任务——描述目标、指定文件范围、给出约束——再由工作台决定在当前设备上用哪个工具执行。
• 认证和密钥不能进仓库，但工作台需要提供一致的认证状态管理。每个设备通过工作台的鉴权层访问统一的凭据，而不是各自散落配置。

一旦这层抽象建立起来，设备就退化成纯粹的“运行环境”，不再是信息的孤岛。上午在办公室用 Claude Code 改完的模块，下午回家用 Codex 接着调，中间不需要手动切换任何心智模型，你只需要面对同一个工作台界面、同一套任务状态、同一个项目上下文。

2.3 工作台真正继承的是“你的思考过程”

这里我想再往深挖一层。跨设备工作台表面同步的是会话记录和配置文件，但它真正传递的，其实是“人的思考过程”本身。

我用 Codex 或 Claude Code 的时候，指令是经过我自己思考后输出的：我先判断这个问题该怎么拆，再决定哪部分让 AI 做，哪部分自己来，最后根据 AI 的输出做取舍。这些“决策”在单次会话里是连续的，但跨设备之后，后面的决策很容易脱离前面的决策基础。重新来一遍不是不行，但大概率会在某个细节上出现偏差，导致结论不一致。

工作台通过保留完整的“决策链”，让我在任意设备上都能看到“当时我是基于什么背景、什么约束、做了什么样的选择”，而不是只看到“最后改了什么文件”。这也是为什么我不太认同“把终端历史复制过去就行”的简化方案——终端历史是碎片，决策链才是闭环。

3. 一个可落地的跨设备工作台设计

3.1 设计原则：本地优先，云端同步

聊完了“为什么”，接下来才是重点：“怎么做”。基于我自己的实践，一个可落地的跨设备工作台，应该先守住几个核心设计原则。

第一，本地优先。本地优先不是不要云同步，而是强调本地永远是“一等公民”。所有会话数据、任务状态、配置信息，必须先落在本地，再考虑同步。为什么要这样？因为 AI 编程场景里网络并不总是可靠，而且很多操作需要极低的延迟。本地优先设计保证了断网状态下我依然能查看历史任务、编辑待办、甚至用本地模型继续干活，网络恢复后再做增量同步。这跟笔记软件 Obsidian 的思路是一致的——本地文件永远是主体，云端只是备份和分发通道。

第二，云端同步但可自托管。工作台同步的数据不是普通的聊天记录，而是包含项目路径、文件引用、命令执行记录的敏感工程数据。我并不想让这些数据走一个第三方的公共服务器。最稳妥的方案是支持用户自托管同步端，或者直接用 Git 仓库作为同步通道。数据以加密形式或明文 Markdown 形式存储在私有仓库里，通过 GitHub 或自建 Git 服务来完成跨设备同步。

第三，CLI 优先，GUI 次之。AI 编程工具的使用者普遍习惯键盘操作，工作台的主体应该是一个 CLI，GUI 只作为辅助查看面板。这样做的原因很务实：CLI 更容易被脚本化、更容易嵌入到现有的终端工作流里，而 GUI 的开发和维护成本高，对 AI 编程工具的适配难度也大。

第四，不试图替代 Codex 和 Claude Code。这条原则是底线。工作台不应该重新造一个 AI 编程代理的轮子，它的定位是调度层和状态管理层，真正负责“动手改代码”的依然应该是 Codex、Claude Code 或者其他工具。工作台做的是：接收用户意图、选择合适的底层工具、传递必要的上下文、收集执行结果并更新状态。保持这个边界，工作台才能长期保持轻量和稳定。

3.2 核心模块拆解

基于上述原则，我梳理出了一个最小可行的跨设备工作台应该包含的核心模块。

会话存储模块是地基。它以项目为维度，给每个项目维护一个独立的状态目录，里面记录会话历史、任务列表、上下文摘要和关键决策点。格式上我倾向于纯文本加 JSON 的组合：人类可读的 Markdown 用于记录摘要和决策，机器可读的 JSON 用于存储结构化的状态数据。目录结构大致是这样：

.ai-workbench/ ├── sessions/ │ ├── 2025-06-10-refactor-auth.md │ └── 2025-06-11-fix-db-timeout.md ├── tasks/ │ ├── pending.json │ └── done.json ├── context/ │ └── project-brief.md ├── config/ │ ├── workbench.yaml │ └── providers/ │ ├── codex.yaml │ └── claude.yaml └── state.json

同步模块负责把整个.ai-workbench/目录和项目代码一起同步到其他设备。最省事的方案就是把它纳入 Git 版本控制，配合 Git 的 hook 在每次会话结束时自动提交。稍微复杂一点的做法是写一个后台守护进程，监听状态目录的变更，自动推送和拉取更新，类似 syncthing 的思路，但只同步工作台目录而不是整个项目。

执行适配模块是工作台和 Codex、Claude Code 交互的关键桥梁。它统一了任务提交的接口，不管是调用 Codex 还是 Claude Code，对外暴露的都是同一套参数：目标描述、涉及文件、约束条件、期望输出格式。适配层收到任务后，根据当前设备和配置，决定调用哪个底层工具以及怎么调用。

状态展示模块解决的是“我如何快速知道现在进行到哪一步”的问题。它实时读取state.json和任务列表，用简洁的表格或列表展示当前项目状态、阻塞项、下一步建议。这个模块在桌面端可以做成一个终端 TUI，在手机端可以是一个只读的 Web 页面。

3.3 与 Codex、Claude Code 的接入方式

具体到接入方式，Codex 和 Claude Code 都提供了供自动化调用的非交互模式，这是工作台能够集成它们的前提。

Codex 的exec模式可以直接把任务描述作为参数传入，并在命令结束时一次性返回结果。Claude Code 的-p参数（print 模式）类似，适合在无人值守的状态下执行单次任务并获取输出。工作台在执行适配层封装的就是这一类调用。举个例子：

# 底层封装后暴露给用户的统一命令 wb run "重构用户认证模块，将 JWT 生成逻辑抽取到独立服务" \ --files "src/auth/" \ --constraint "保持现有接口不变" \ --provider auto

用户不知道也不关心这个任务到底是 Codex 执行的还是 Claude Code 执行的，工作台会根据设备上可用工具、任务类型、成本预算等条件自动选择。

接入时还有一个细节非常关键：一定要让底层工具输出结构化结果。Codex 的 exec 模式支持--json输出，Claude Code 的 print 模式也支持读取 JSON 输入输出。工作台应该强制使用结构化格式，这样它才能解析执行结果、提取修改文件列表、判断任务是否真正完成，然后把状态更新到本地状态库中。

对于 MCP 配置，工作台提供一层统一的配置管理。它可以维护一个项目级别的 MCP 配置文件，记录需要哪些 MCP 服务器、服务器地址、认证方式，然后针对不同设备生成对应的本机配置。这样项目的 MCP 需求是共享的，而每台设备的实际连接方式是私有的，不会因为设备差异导致配置互相踩踏。

4. 落地实践：从零搭一个最小可用工作台

4.1 基础环境与我踩过的坑

在给你完整配置步骤之前，我先说说我在搭建环境时踩过的一些坑，这些坑可能比配置本身更有参考价值。

坑一：一开始我试图把所有设备统一成同一套环境，比如全部装 WSL、全部用同一个终端模拟器、路径全部改成软链。折腾了两周，发现这是在给自己挖坑。设备硬件不同、GPU 资源不同、屏幕尺寸不同，强行统一环境，最终只会让每台设备都变难用。正确的思路是接受差异，用配置文件去适配差异，而不是消灭差异。

坑二：API Key 的同步方式一开始我图省事，直接把 Key 写进了项目的配置文件里，然后同一个目录推到了 Git 私有仓库。结果有一次我把仓库权限改成了公开，差点把 Key 泄露出去。从那以后，我定了一条铁律：任何凭据都不能进配置文件，工作台只保存凭据的引用名称，真正的 Key 存在各设备的系统钥匙串或者环境变量里。

坑三：一开始我做同步用的是网盘目录实时同步，但 AI 会话文件是频繁写入的，实时同步会导致文件冲突和写入错乱。后来换成 Git 加手动提交的方式，冲突虽然还存在，但至少可控，不会把正在写入的半截文件同步出去。

基于这几次踩坑，我最终确定的基础环境是：项目托管在自建的 Git 服务器上；每台设备本地安装 Codex CLI 和 Claude Code CLI；工作台本身是一个不到 500 行的 Python 脚本，加上一个配置文件目录；状态同步走 Git 的 pre-commit 和 post-merge 钩子。

4.2 完整配置流程

下面是接近我在实际使用的工作台配置方案，你完全可以照着抄一份。

第一步，初始化工作台目录。先在项目根目录创建.ai-workbench/，初始化配置文件。我用的workbench.yaml长这样：

project: name: my-ai-project default_provider: auto # auto 表示根据设备上可用的工具自动选择 sync: type: git remote: origin branch: main auto_commit: true commit_message_prefix: "chore(workbench):" providers: codex: enabled: true exec_command: "codex" extra_args: ["--json"] claude: enabled: true exec_command: "claude" extra_args: ["-p", "--output-format", "json"]

第二步，创建任务状态文件tasks/pending.json，把你的待办事项结构化地放进去。这样可以保证跨设备恢复时，你看到的不只是一个空终端，而是一份明确的下一步行动计划。示例：

{ "tasks": [ { "id": "TASK-001", "title": "用户认证模块重构", "status": "in_progress", "provider": "claude", "files": ["src/auth/"], "created_at": "2025-06-10T10:00:00Z", "summary": "已抽取 JWT 生成逻辑，待补充测试" }, { "id": "TASK-002", "title": "数据库超时问题排查", "status": "pending", "provider": "codex", "files": ["src/db/"], "created_at": "2025-06-11T09:30:00Z", "summary": null } ] }

第三步，配置 Git 钩子。在.git/hooks/pre-commit里加入自动提交工作台状态目录的检查，确保每次提交代码之前，工作台状态都已经被正确记录下来。在post-merge钩子里加入工作台状态目录的同步校验，拉取代码后自动刷新本地状态。这一步能避免“拉完代码但工作台状态还是旧的”这种奇怪情况。

第四步，编写别名和快捷命令。我在.zshrc里加了几个别名，让日常操作足够顺手：

alias wb="python3 ~/bin/workbench.py" alias wb-status="python3 ~/bin/workbench.py status" alias wb-run="python3 ~/bin/workbench.py run" alias wb-sync="git add .ai-workbench && git commit -m 'sync workbench' && git push"

第五步，配置设备差异层。在.ai-workbench/config/providers/下分别维护codex.yaml和claude.yaml，里面只记录项目相关的配置，比如路径映射、MCP 服务器地址、模型偏好。设备本身的差异（比如 API Key、本机可执行文件路径）通过环境变量注入，不进 git 仓库。以我的 macOS 设备为例，~/.zshrc里加了：

export WORKBENCH_CODEX_MODEL="gpt-5.4" export WORKBENCH_CLAUDE_MODEL="claude-sonnet-4-5"

这些环境变量在不同设备上可以有不同的值，工作台读取的时候优先读环境变量，读不到再用配置文件里的默认值。

4.3 我在实际项目中的使用方式

配置好之后，我的工作流变成了这样。

在办公室的 macOS 设备上，我会先用wb-run把今天要做的重构任务提交给 Claude Code 执行。Claude Code 跑到一半可能需要人工决策，我会在终端里直接介入调整，然后继续。下班前执行一次wb-sync，把工作台状态提交到远端。

回家之后在 Windows 设备上拉取代码，工作台会自动合并状态。我打开终端，wb-status会明确显示：TASK-001 已经进行到“已抽取 JWT 生成逻辑，待补充测试”这个状态。我不需要重新阅读代码、不需要跟 Codex 重新解释项目背景，直接输入wb-run "继续 TASK-001，补充测试用例并修正边界条件"，工作台就会调用本机的 Codex 继续执行。Codex 通过工作台拿到了之前 Claude Code 产生的上下文摘要和文件修改列表，衔接起来很顺畅。

还有一种是更轻量的使用场景。有时候我在外面用手机查看进度，并不想真的跑 AI 任务，只是想知道现在项目处于什么阶段。我只需要打开手机浏览器访问一个简单的只读页面，它能从 Git 拉取工作台状态并展示当前任务列表、关键决策点、最近一次会话摘要。这个只读页面我用了不到一百行 Python 就写完了，只暴露一个受 token 保护的GET /status接口，返回 Markdown 格式的状态报告。

这套方案没有用什么重型框架，也没有额外部署服务器，只是靠 Git、CLI、脚本和少量配置文件就把跨设备工作台立起来了。它足够轻，轻到不会成为日常工作的负担。

5. 常见问题与排错实录

5.1 常见问题速查表

在实际使用这套工作台的过程中，我记录下了很多问题。下面是几个出现频率最高、最有代表性的，以及对应的排查思路。

5.2 几条独家避坑技巧

除了故障排查表，我想单独分享几个我在实践中摸索出来的、非常有价值的技巧。

第一，任务摘要必须强制生成。Claude Code 和 Codex 跑完任务后，模型的最终回复往往很啰嗦，而且经常包含对自己工作过程的自夸。如果直接把整段回复存为任务摘要，跨设备恢复时你根本不想看。我的做法是加一个“摘要提炼”步骤：用一次额外的短调用，要求底层模型输出不超过五十个字的结构化摘要，包含做了什么、改了什么、还有什么没做。这件事看起来很小，但长期下来对跨设备恢复体验的提升非常大。

第二，状态文件不要把大段代码内嵌进去。刚开始设计状态格式的时候，我想过把关键代码片段直接塞进 JSON 或 Markdown 里，方便跨设备查看。后来发现这会让状态文件迅速膨胀，而且容易和仓库实际代码产生版本不一致。正确的做法是只记录文件路径和行号，代码内容以文本方式保存在项目目录中，工作台负责的是“指向”而不是“复制”。

第三，认证问题要事先处理好。AI 编程工具现在基本都有命令行登录机制，比如 Codex 的login、Claude Code 的claude /login。但这些登录态不会自动跨设备复制。我建议在搭建工作台的第一步就把登录确认完成，并且把“登录检查”也做成wb-status的一部分，每次查看状态时都顺带检查底层工具的认证是否有效。这样能避免在任务执行到一半时才发现认证过期。

第四，面对工具更新要保持警惕。Codex 和 Claude Code 都在快速迭代，CLI 的参数和输出格式经常变化。我遇到过 Claude Code 升级后默认输出格式带上了更多干扰文本，导致工作台解析失败。解决办法是给工作台锁版本，或者至少在升级后先跑一次端到端的测试任务，确认解析逻辑没坏再继续用。

6. 我最终得到的体会

做了这套跨设备工作台之后，我最大的感受是：工具链里真正稀缺的不是更聪明的模型，而是能把聪明工具串起来的“稳定器”。Codex 和 Claude Code 已经帮我解决了大量重复编码和踩坑问题，但它们默认的工作方式是单机、单会话、单上下文的。跨设备工作台则补上了最后一公里的短板——它让我的 AI 工作过程变得可携带、可恢复、可跨工具流转。

现在回到标题那个问题：已经有 Codex、Claude Code 了，为什么还需要一个跨设备工作台？答案其实很朴实：因为我换电脑的时候，不希望连带着把我脑子里的上下文和 AI 会话里存下来的判断过程一起格式化掉。工具负责干活，工作台负责记住“我们是怎么干活的”，这两个角色互相配合，才能真正发挥出 AI 编程工具的上限。

如果你也在同时使用多个 AI 编程工具、在多台设备之间来回切换，我建议你从最小的方案开始搭建，哪怕只是一个wb-status加一个 Git 仓库，也能立刻感受到跨设备恢复带来的幸福感。踩过几次坑之后，你会明白一个朴素但重要的道理：AI 编程的下一个瓶颈，往往不是 AI 本身，而是我们组织和使用 AI 的工作方式。