最近有件事让我特别有感触我同时在用 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 编程工具的使用者普遍习惯键盘操作工作台的主体应该是一个 CLIGUI 只作为辅助查看面板。这样做的原因很务实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 wbpython3 ~/bin/workbench.py alias wb-statuspython3 ~/bin/workbench.py status alias wb-runpython3 ~/bin/workbench.py run alias wb-syncgit 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_MODELgpt-5.4 export WORKBENCH_CLAUDE_MODELclaude-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 常见问题速查表在实际使用这套工作台的过程中我记录下了很多问题。下面是几个出现频率最高、最有代表性的以及对应的排查思路。问题现象可能原因解决思路切换设备后wb-status显示的任务状态是旧的拉取代码后没有执行同步校验在post-merge钩子中加入工作台状态目录刷新逻辑调用wb-run时报auth token is unavailable底层 Codex 或 Claude Code 的登录态没有在当前设备上初始化先单独在终端跑一次codex或claude完成登录然后再回到工作台同一台设备上 Codex 和 Claude Code 的 MCP 配置互相覆盖两个工具默认使用同一个 MCP 配置目录但格式不同使用工作台的 providers 配置层分别管理各自的 MCP 配置不共用同一个配置目录同步时出现大量冲突多台设备同时修改了工作台状态文件改成“单写入”模式同一时间只在一台设备上执行任务其他设备只读中文文件名和路径在 Windows 上乱码Windows 默认使用 GBK 编码而会话文件是 UTF-8在 PowerShell 中设置[Console]::OutputEncoding [Text.Encoding]::UTF8并确保工作台脚本以 UTF-8 模式读写文件底层工具执行时间过长任务卡住没有设置超时机制在工作台适配层给每次调用设置合理的超时时间超时后标记为需人工检查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 的工作方式。