多AI工具协作实战：Dot、Codex Cloud与本地Codex如何从派活到验收

当一个项目同时启用Dot、Codex Cloud和本地Codex三款AI工具时，开发者的角色常常从决策者变成专职传话筒：这边说修好了，那边说文件没变，还有一个根本不知道前面的上下文。问题的根源不在于AI不够聪明，而在于缺少一套清晰的分工和交接机制。Dot具备任务协调能力，可以创建Codex任务、读取任务结果并发送后续指令，每个新任务拥有独立对话并接收为该工作专门准备的上下文。将这些能力串联起来，才能真正把传话的活儿也交出去。本文以筛选订单后导出的CSV仍包含全部订单这一真实问题为练习贯穿全程，讲解从派活、交接到验收的完整操作流程，帮助开发者建立一套可复用的多AI协作规范。

三工具定位与分工原则

理解三者的定位是协作的基础。Dot自带云电脑和浏览器，可以研究资料、处理文件，也能执行软件工作；需要特定仓库和开发配置时，它还能调用已创建的Codex Cloud环境派出独立的编码任务。本地Codex使用本机项目、文件和工具；Codex Cloud在远端环境运行，准备好的任务可以在电脑休眠后继续执行。基于这个位置差异，建议的分工是：Dot跟进任务整体进度，Codex Cloud负责修复代码并提交PR，本地Codex负责检查指定提交号、运行项目并验证导出结果。这个分工表是起点，先让一项工作顺利交接，再逐步扩展到同时派出多个任务。

本地项目准备与Git基准

在开始协作前，需要整理本地项目并明确交接基准。桌面应用中打开本地项目后，通过 Edit project → Add folder 将仓库加入项目，并选择本次要修改的仓库目录作为主目录。主目录决定了新任务的起始位置、Git操作基准以及Codex自动发现的 AGENTS.md、Skills和项目配置。先让本地Codex完成一次只读检查：确认当前工作目录和Git仓库根目录、origin对应的仓库、当前分支和提交号、有无未提交的改动，以及根据README和锁文件如何安装和测试。这份结果用于后续Cloud任务与本地验收的交接。交给Cloud的本地改动，应先形成明确的提交并推送到约定分支。

Cloud环境配置与GitHub连接

创建Cloud环境时，依次选择 Work in → Cloud → Select environment → Create environment，连接目标GitHub仓库并命名环境（例如 my-app-cloud）。Codex会检查项目、安装依赖和工具并测试工作流。可以发送准备指令让Cloud阅读README和AGENTS.md后确认安装和启动命令，并报告执行结果。在环境设置中分别管理 Environment variables（供程序直接读取）和 Network secrets（用于向指定HTTPS服务发送凭据）。Cloud环境发布后，它可以使用仓库内的Skills，但本机的个人Skills不会自动同步，必要时要确保项目Skills在仓库中已准备好且依赖的工具可用。同时在Dot的资料页确认 Computers → Your computer → Allow access，并安装GitHub插件让Dot能查看目标仓库的Issue和PR。

任务派发与验收交接机制

协作的核心在于建立标准化的交接格式。每个任务完成后应报告：任务链接、执行位置、仓库及分支、本次检查的完整提交号、PR链接、实际执行的命令或操作、实际结果、未完成事项及原因、下一步交给谁做什么。Cloud修复代码后，本地验收使用 Git worktree 隔离检出同一提交号，先执行 git rev-parse HEAD 和 git status --short 确认版本与工作副本状态，然后启动项目设置对应筛选、执行导出并检查下载文件的行、字段与编码。若验收失败，将失败证据发回原Cloud任务继续修复，修复后再交回原验收任务检查新版本。Dot负责读取与转交，本地任务先将结果写在自己的对话里。任务运行结束、测试通过、CSV导出正确、PR已合并，是不同的状态，验收报告应写清实际达到哪一步。

第一次跑通时需要找到四个结果：Cloud任务链接、本地任务链接、PR链接，以及对应同一提交的验收记录。都找得到后，再把这套项目位置和交接方式交给Dot长期跟进。可以给Dot保存明确的定时检查计划，例如每个工作日固定时间检查未完成任务并按验收条件继续跟进。多AI协作的成败，不在工具的数量里、不在单个模型的性能里，而在每一次任务交接的完整提交号里、在每一版代码的可回溯路径里。建立这套规范，人才能真正从传话筒的角色中抽身出来。