Codex、Dot、Codex Cloud怎么配合？从派活到验收的完整教程

先把三个工作位置认清

Dot自带云电脑和浏览器，可以研究资料、处理文件，也能使用已创建的Codex Cloud环境派出单独的编码任务。

本地Codex使用你电脑上的项目、文件和工具；Codex Cloud在远端环境运行，准备好的任务可以在你电脑休眠后继续。按这两个位置分工，Cloud适合处理能在仓库中独立完成的修改，本地适合接住本机联调和界面验收。

当前Codex Cloud环境还不支持电脑和浏览器操作。因此，这篇教程把浏览器里的导出验收安排给具备相应工具和权限的本地任务。命令行测试、实际打开页面、下载并检查CSV，要分别留下结果。

这张表是我建议的分工。先让一项工作顺利交接，再考虑同时派出更多任务。

整理本地项目，明确从哪里开始

在桌面应用的Projects中打开本地项目。需要添加或调整目录时，进入项目菜单里的 Edit project → Add folder，把仓库加进去；指向应当作为起点的目录，选择 Make primary。

这个主目录会影响新任务的起始位置、Git操作，以及Codex自动发现的 AGENTS.md、Skills和项目配置。如果应用代码、文档各在一个目录，先确认主目录选的是本次要改的仓库。

在这个项目里，让本地Codex先完成一次只读检查：

请先检查当前项目，不修改文件。  
  告诉我：  
1. 当前工作目录和Git仓库根目录。  
2. origin对应哪个仓库，    
    当前分支和提交号是什么。  
3. 有没有尚未提交的改动。  
4. 根据README、AGENTS.md    
    和锁文件，    
    这个项目怎样安装、启动和执行相关测试。  
  这份结果用于后续Cloud任务与本地验收交接。

需要交给Cloud的本地改动，应先形成明确的提交并推送到约定分支。Cloud使用自己的仓库与工作区；电脑里刚改完、尚未交付的文件，要在交接时单独处理。

把开发命令写清很划算。环境准备阶段能安装依赖、测试工作流，后面的编码任务和本地验收才有同一套起点。已有README和 AGENTS.md 就复用，不必另造一本手册。

创建并发布Codex Cloud环境

在网页或桌面应用新建任务，依次选择：

Work in → Cloud → Select environment → Create environment

选择GitHub仓库，按提示连接GitHub。也可以从 Settings → Codex Cloud → Environments → Create environment 进入。

把环境命名为容易辨认的名字，例如 my-app-cloud。下面所有提示词里的这个名字，都要替换成你界面里真实存在的环境名。

选好仓库后点击 Get started。Codex会检查项目、安装依赖和工具，并测试工作流。需要特定运行时、命令或服务，可以在环境准备对话里说明：

请为这个仓库准备可复用的Cloud环境。  
  先阅读README、AGENTS.md、  
运行时版本文件和锁文件，  
使用项目要求的版本安装依赖。  
  确认安装、启动和测试分别使用什么命令。  
实际运行能执行的检查，报告结果。  
缺少服务、凭据或信息时，列出具体缺项。  
  把已验证的安装步骤记录到Install script；  
把服务启动及就绪检查记录到Start skill。

Install script负责安装依赖和准备开发资源；Start skill负责启动服务并确认就绪。启动了一个进程，后面还要检查服务能否响应。这个细节我很在意，等到修完代码才发现环境根本起不来，实在扫兴。

项目需要配置时，在环境设置中分别管理 Environment variables 和 Network secrets。前者供程序直接读取变量；后者用于向指定HTTPS服务发送凭据，程序拿到占位值，由代理在匹配的HTTPS 443请求中替换。要让程序直接读取原始值，应选择环境变量。

如果项目依赖公司内网服务，还要准备对应网络访问。之前的《Codex Cloud接入内网教程》展开了Tailscale和访问配置。第一次练习也可以选一个不依赖私网服务的小问题。

环境检查完成后，保存并点击 Publish，等到界面出现 Environment published。保存存下配置，发布把准备好的文件系统提供给新任务。检查完这一项，再让Dot往里面派活。

Cloud可以使用仓库内的Skills，本机个人Skills不会自动同步。某个项目技能如果是完成任务的必要条件，就要在Cloud可访问的仓库中准备好，并检查它依赖的工具能否运行。

让Dot连接电脑和GitHub

在准备做本地验收的那台电脑上，打开ChatGPT桌面应用中的Dot资料页：

Computers → Your computer → Allow access

阅读确认后，再点一次 Allow access。目前Dot一次只能连接一台个人电脑；使用本机时，电脑需要在线，ChatGPT应用也要保持打开。

Dot的本机权限与Codex电脑连接、Work Sync分开。已经能在手机里看到对话，也要单独核对Dot的电脑连接。

接着安装并连接GitHub插件，让Dot有权限查看目标仓库的Issue和PR。Cloud环境连接仓库、Dot通过插件读取GitHub、Dot访问本机，是分别需要核对的访问条件。

第一次连接后，可以发一个很小的检查请求：

请确认你能使用的电脑和GitHub连接。  
  目标仓库：  
本地项目：  
本地目录：  
Cloud环境：  
  检查这些目标是否可访问。  
把无法访问的对象和实际报错告诉我。

界面里显示 Offline，表示电脑当前不可用，连接权限可能仍然保留。先恢复电脑和应用，再继续本机工作；需要撤销访问时才使用 Revoke access。

把一个完整任务交给Dot

Dot可以创建可见任务，再向它们发送后续指令。这里给它一个具体结果：Cloud提交修复，本地核验相同版本，失败就回到原任务修。

下面这段可以直接复制。尖括号都替换成实际内容；“导出CSV”也要换成你的真实问题和复现材料。

请协调完成这个问题，并跟进到验收报告。  
  项目：my-app  
GitHub仓库：  
基准分支：  
Cloud环境：my-app-cloud  
本地项目：  
本地目录：  
Issue或需求材料：  
  问题：  
筛选订单后，导出的CSV仍包含全部订单。  
  复现步骤：   
验收条件：  
- 导出行与当前筛选结果一致；  
- 保留约定的表头、字段和编码；  
- 没有结果时，按产品约定处理；  
- 相关自动化检查通过，并完成本机导出验证。  
  请按下面的顺序工作：  
  一、创建Cloud编码任务。  
使用指定环境，读取仓库说明和需求。  
核对远端基准分支与起始提交。  
在独立分支修复，执行相关测试。  
推送修复分支并创建PR。  
  二、读取Cloud任务结果。  
取得任务链接、PR、分支、完整提交号，  
以及实际执行的测试命令和结果。  
  三、创建本地Codex验收任务。  
在独立worktree中检出上述完整提交号。  
按相同验收条件检查。  
记录实际运行的测试、导出结果和发现的问题。  
  四、如果验收失败。  
读取本地报告，把复现步骤和失败证据  
发回原Cloud任务继续修复。  
修复后取得新的提交号，  
再让原本地验收任务检查新版。  
  请负责读取这两个任务的结果，  
并发送完成上述流程需要的后续指令。  
每次交接都带上准确任务链接与提交号。  
本轮交付PR和验收报告，  
合并、部署另行安排。

发出后，打开Dot资料页的 Activity，进入它创建的任务，检查运行位置、文件、结果和需要你回应的请求。Cloud环境名、仓库、目标问题都应与交接一致。

Dot会沿用任务原来的电脑或云环境继续工作。更换Dot当前连接的电脑，不会把已有任务迁移过去。因此，要换执行位置时，先留下代码提交、未完成事项和运行条件，再明确安排接手任务。

它们之间到底怎么通信

这一步最容易把事情想玄乎。把工作拆开看，就很具体。

需求和进度通过任务传；代码通过GitHub传。 Dot读取任务结果，再把下一步要求交给另一个任务。新任务只拿到Dot为它选出的上下文，完整需求、复现材料和版本信息要跟着交接走。

让每个任务把结果写成同一份交接格式，会省掉不少猜测：

任务链接：  
执行位置：  
仓库及分支：  
本次检查的完整提交号：  
PR：  
实际执行的命令或操作：  
实际结果：  
未完成事项及原因：  
下一步交给谁、做什么：

Cloud返回“修好了”时，继续要求它提交并保存重要工作，交出可拉取的远端版本。Cloud会保存任务状态，但保存状态仍然需要配合版本管理。

本地验收结束后，可以对Dot说：

请读取这个本地验收任务的结果：   
  把报告中的失败步骤、日志和提交号，  
发给这个原Cloud任务继续修复：   
读到新提交后，再交回原验收任务。

这里由Dot负责读取与转交，本地任务先把结果写在自己的对话里。对于已有本地Codex任务，也可以直接告诉Dot准确任务和修改要求，让它接着跟进。

手机、ChatGPT、Slack和Teams可以作为联系同一个Dot的渠道，相关上下文能帮助它继续工作；各渠道的可见消息不会自动复制。手机只是发指令的入口，本地执行仍需要电脑在线。

还有一个群聊里容易混淆的入口：GitHub PR评论里的 @codex review 触发代码审查；@codex fix the CI failures 这类请求会启动带PR上下文的 Legacy Cloud 任务。它们属于GitHub集成路径，不是给本地Codex发消息的按钮。

本地验收，要盯住同一个提交

worktree是Git仓库的独立工作副本，共享提交历史，可以让验收与当前开发目录分开。它仍然在本地电脑或对应远程开发环境运行。

想手动创建验收任务，可以在本地项目的新对话里选择 Worktree，选好起点分支，再提交要求。对于Cloud修复，交接时让Codex先取得远端分支，并明确检出PR对应的完整提交号。

验收任务开头先执行：

git rev-parse HEAD  
git status --short

第一条输出当前完整提交号，应与Cloud交付的一致；第二条查看当前工作副本有没有未提交改动。有改动就先说明它来自哪里，以及是否会影响本次验收。

同一个PR可以继续增加提交。Cloud说第三版修好了，本地拿第一版测得满头大汗，这种返工最让人窝火。所以每次重验，都重新记录提交号。

对导出CSV这个练习，本地验收要实际启动项目，设置对应筛选，执行导出，再检查下载文件里的行、字段与编码。若本地任务缺少所需浏览器工具或登录条件，就明确报告缺项，保留已完成的命令行测试结果。

新建worktree时，本地的 .env、依赖和运行服务也要检查。桌面应用托管的worktree，可以通过仓库根目录的 .worktreeinclude 指定需要复制的已忽略文件，例如开发用的 .env.local。这项复制机制不适用于自己从命令行创建的worktree；按实际创建方式补齐环境，再启动服务。

需要把验收工作带回熟悉的本地目录，可以用任务标题栏的 Hand off → Local；之后也能回到 Worktree。这个入口负责Local与Worktree之间的交接，Cloud到本地的代码仍按前面的PR与提交号传递。

出问题，回到对应的位置处理

代码没修好，继续原Cloud任务。 原Cloud任务保留自己的文件、未提交改动和安装过的工具。把失败证据发回去，能接着已有调查往下做。另开的新Cloud任务从已发布环境取得独立工作区，交接时需要重新给它修复分支和必要背景。

环境配置要改，回环境设置。 进入 Settings → Codex Cloud → Environments，在对应环境菜单选 Edit，修改并检查后 Republish，再开新任务验证。原任务保留原来的工作状态；若要用新版环境继续修复，把已推送的分支、提交号和待办明确交给新任务。

本地电脑离线，恢复原电脑。 先恢复网络并打开应用，再读取原任务状态。切换Dot连接的电脑不会搬走已有任务；这时候乱开新任务，只会多出一份需要解释的现场。

Dot说任务完成，仍要检查输出和错误。 任务运行结束、相关测试通过、CSV导出正确、PR已合并、产品已上线，是不同的状态。这篇练习的终点是PR和验收报告，报告里应写清实际达到哪一步。

你可以把最后的核验要求直接发给Dot：

请读取Cloud编码任务  
和本地验收任务的实际结果。  
  逐项确认：  
- Cloud推送的最新完整提交号；  
- 本地验收检查的完整提交号；  
- 两者是否一致；  
- 哪些检查已执行，结果如何；  
- 哪些检查没做，原因是什么；  
- PR当前处于什么状态。  
  有失败或缺项就继续处理对应步骤，  
最终按实际结果报告。

Dot“休息”了，先看限的是哪一段

那张限额截图挺会气人：先恭喜你成为“最活跃的用户之一”，接着通知你达到使用上限。用户追问“多久能休息好”，它又发了一遍同样的话。

先进个人，原地停工。

官方对额度的解释要分开看：和Dot的对话不计入ChatGPT使用额度；它启动或管理的Work、Codex任务，照常消耗对应产品额度。套餐另有深入工作额度。

截图没有给出恢复时间，也不足以判断具体触发了哪一种限制。不能据此报一个“等几小时就好”的数字。

已经创建的任务，可以从Activity找到并打开，直接查看结果、补充指令；该任务接下来能否运行，仍取决于自己的服务状态、权限和额度。把重活委派出去，是为了让任务、代码和结果更好追踪，别把它当成无限额度配方。

跑通一次，再交给Dot长期跟进

第一次先看四样东西：Cloud任务链接、本地任务链接、PR、对应同一提交的验收记录。都找得到，再把这套项目位置和交接方式交给Dot长期使用。

Dot可以在对话之间继续跟进；需要固定时间检查时，要保存明确计划。把任务、时区、期限、通知条件交代完整，例如：

接下来两周，每个工作日北京时间09:30，  
检查my-app项目中由你创建且尚未完成的任务。  
  读取实际进展，沿已确定的验收条件继续跟进。  
出现测试失败、验收完成，  
或需要我提供访问条件时通知我。  
没有变化时保持安静。  
  请确认保存的时区、时间和结束日期。

发出后，到Dot的 Scheduled 核对计划。临时跟进和固定定时各有入口，界面里保存的安排才是后续检查依据。

我喜欢Dot能读取任务结果、继续派活这个设计。Cloud有独立工作区，本地能接住具体环境里的验收，两边还有PR和提交号可以核对，活儿就有机会一段一段往前走。

AI越来越能干，我对它们的要求也会越来越具体：代码在哪，谁接着改，检查的是哪一版。

把这些事情接好，人才能从三个聊天窗口之间抽身出来。否则请来一群助手，最后自己当全职传话筒，这班也太冤了。