用GitHub让ChatGPT与Codex接力开发

最初想到让ChatGPT和Codex接力开发，原因其实很简单：Codex额度不够用。平时从需求分析、阅读源码到修改代码、运行测试，所有工作都放在本机Codex里，很快就会碰到额度限制。与此同时，ChatGPT的普通对话额度还有很多，只拿来问些零散问题实在有些浪费。

ChatGPT接入GitHub以后，事情就有了变化。它虽然不能像本机Codex那样直接进入完整工作树，操作数据库、容器和真实环境，却可以读取仓库里的源码和文档，也能处理分支、提交、PR和Issue。这样一来，需求讨论、方案设计和代码Review可以先交给ChatGPT，真正依赖本地环境的实现与验证再由Codex完成。

这不只是把剩余的ChatGPT额度利用起来。实际使用中，ChatGPT里的Pro模型在长需求分析、跨文档设计和独立审阅方面表现很强，很多时候甚至比Codex里的Max更好。Codex的优势则是身处本机，能够不断重复“修改—测试—诊断—再修改”。一个更擅长把问题想清楚，一个更擅长在真实环境里把事情做完，GitHub正好可以成为两者之间的交接点。

OpenAI的产品和额度规则仍在变化。按当前规则，Codex与ChatGPT Work等Agent功能共用Agent额度，普通ChatGPT对话则不计入这个用量池。这里说的“利用ChatGPT额度”，指的就是这部分普通对话能力。

ChatGPT的沙箱不是开发机

ChatGPT网页版有一个能够运行Bash、Python和Node.js的Linux沙箱。刚发现它时，我曾经想过是否可以直接在里面克隆私有仓库，把ChatGPT当成另一台云端开发机。实际检查后，这条路并不可行。

2026年8月检查到的那个沙箱可以在5个逻辑CPU上调度，但cgroup计算配额只相当于4核；内存硬限制是4GiB，没有可见Swap，也没有GPU。运行小型脚本没有问题，想在里面安装一大堆依赖、编译大型项目或运行多个容器，4GiB内存很快就会成为限制。

更大的问题是网络和持久性。当时在沙箱中访问github.com、api.github.com和OpenAI域名都无法解析，直接连接公网IP也失败。间隔一段时间再检查，容器主机名已经发生变化。这意味着沙箱里的文件、依赖和运行状态都不值得长期依赖。

ChatGPT之所以仍然能读写私有仓库，靠的是GitHub连接器的独立授权，不是这个Linux沙箱可以自由上网。连接器能够读取文件、搜索代码、查看分支和PR，在授权允许时也能修改文件和创建提交。但是它不会把GitHub凭据交给沙箱，所以沙箱不能直接git clone私有仓库，也没有本机Codex那样完整的.git、未提交差异和本地依赖。

这些配置和网络结果只是对当时会话的实测，不代表ChatGPT永远会提供相同规格。但对开发流程来说，结论已经足够明确：ChatGPT可以做远程分析和有限的仓库操作，不能代替本机Codex的完整开发反馈循环。

Pro强在把问题想清楚

如果只看运行环境，ChatGPT明显落后于本机Codex。但开发不只是改代码和跑测试，还有大量工作发生在动手之前和完成之后。

我在这段时间的使用感受是，ChatGPT里的Pro比Codex里的Max更强。这不是跑分结论，而是来自真实需求和设计任务的对比。面对几份相互关联的REQ、设计文档、ADR和源码时，Pro更容易保持主线，也更容易发现文档之间的冲突、隐藏前提和过度设计。

这种优势很适合放在需求和设计阶段。一个模糊想法交给Codex，它很可能会快速读完源码并开始实现；交给ChatGPT Pro长时间讨论，它往往会继续追问这个需求解决什么问题、哪些行为真正需要改变、哪些只是实现者自己补出来的复杂度。

实现完成后，它又很适合以一个新会话重新阅读已经确认的需求、设计和固定提交。Codex经历了完整实现过程，会自然带着之前的判断；ChatGPT从陌生审阅者的视角进入，更容易看到权限、事务、并发、迁移和恢复等边界上的遗漏。

OpenAI当前也将GPT-5.6 Sol定位为面向复杂编码、研究和计算机操作的旗舰模型。不过Pro和Max所在的产品界面、可用工具和上下文都不同，我不打算把这个使用感受写成严格的模型强弱结论。对现在的工作流程来说，知道它在哪些任务上更好用就足够了。

不用再发明一套ChatGPT流程

既然项目里已经有需求、设计、实施和审阅记录，就没有必要再增加“ChatGPT任务”和“Codex任务”。Agent只是当前的执行者，需求还是需求，Review还是Review，不会因为换了一个模型就变成新的工作类型。

我对两者的默认分工是：

ChatGPT：讨论原始想法、收敛需求、设计方案、独立Review
Codex：在本机worktree实现、运行测试、处理数据库和容器、修复Review问题
负责人：确认产品取舍、接受风险、合并和发布

这不是硬性权限表。一个小范围的纯逻辑修改，ChatGPT完全可以先写出候选；一个已经确定行为的局部修复，也没必要先开一轮长时间设计。关键只有两个：这件事是否需要本地反馈，以及当前哪个Agent正在写这个分支。

GitHub负责交接，仓库保存结论

ChatGPT和Codex没有共享同一段对话，也没有共享同一个运行环境。要让它们接力，交接内容就不能只写“我已经改完了，你接着做”。

GitHub在这套方式里负责保存分支、提交、PR和讨论，仓库内的REQ、设计、ADR和实施记录仍然是正式事实。这样即使以后从GitHub换到GitLab或Forgejo，也不会丢掉项目真正的上下文。

一项比较大的功能，可以分成两个PR。

Definition PR先确认要改成什么样。ChatGPT与负责人讨论需求，阅读已有设计和源码，然后把结论写回REQ、设计或ADR。这个PR合入主分支后，对话里哪个方案才是最终结论就不再需要猜。

Implementation PR再实现已经确认的设计。Codex从新的主分支建立任务分支和worktree，修改代码，运行测试，把本机验证结果写进PR。等候选固定下来，再把完整HEAD SHA交给新的ChatGPT会话Review。

小修改不用机械地拆成两个PR。只有产品行为、业务规则、接口含义、权限、安全或数据设计真正发生变化时，才需要先把定义和实现分开。

一个分支同时只有一个写入者

ChatGPT和Codex可以处理同一项任务，但不能同时写同一个分支。最容易出问题的情况是ChatGPT已经在远程提交了新修改，本机Codex却还在基于旧提交继续工作。等到两边同时推送，要么产生冲突，要么有人为了整理历史而覆盖另一边的结果。

我现在使用的规则很简单：

1.交接前先提交并推送全部候选修改。 2.在PR里写出完整HEAD SHA，不说含糊的“最新提交”。 3.接棒者开始前先确认远程HEAD仍然等于交接SHA。 4.交接后不在共享分支上force push，也不改写已经交接的历史。 5.如果两个Agent要尝试不同方案，就分别建立分支，不在同一个分支上互相覆盖。

对Codex来说，隔离空间通常是本机worktree；对通过GitHub工作的ChatGPT来说，隔离空间是远程分支和Draft PR。worktree只隔离代码目录，不会自动隔离数据库、容器、端口和缓存。多个本机Agent并行工作时，这些资源仍然要另外分配。这部分在让多个Agent在不同worktree工作里有更完整的记录。

用Draft PR作为交接面

一项需要ChatGPT和Codex共同参与的工作，可以尽早建立Draft PR。它不是“马上准备合并”的信号，而是两边都能读到的交接面。

PR顶部只需要保留几个当前状态：

## 协作状态

- 当前阶段：需求 / 设计 / 实现 / 验证 / 评审 / 待确认
- 当前写入者：ChatGPT / Codex / 负责人
- 当前候选：<完整HEAD SHA>
- 下一接棒者：ChatGPT / Codex / 负责人
- 下一步：一句话说明要做什么

每次正式交接再增加一条PR评论，把当时的状态固定下来。ChatGPT交给Codex时，说清基线、正式依据、本轮目标、明确不做和下一步验证；Codex交给ChatGPT Review时，说清比较起点、固定候选、实际修改、已运行验证和明确未验证的风险。

这些内容不需要写成一份复杂清单。交接的目的只是让新会话能够回答三个问题：要做什么，现在代码在哪个提交，接下来要验证什么。

Token要省在重复上下文上

把ChatGPT引入开发流程后，如果每次交接都重新发送整个仓库、全部文档和完整对话，Token只会比以前消耗得更快。真正要省的是重复上下文，不是把需求和验证结果写得模糊。

ChatGPT完成需求讨论后，把结论写进REQ、设计和一条交接评论，不需要把整段对话交给Codex。前期否决过的方案，未来仍然有价值就写进ADR，没有进入正式文档的闲聊不再反复传递。

Codex完成实现后，也不需要把终端里的所有输出复制给ChatGPT。PR写清运行了哪些验证、结果如何、哪些失败或跳过就够了，详细日志只在需要诊断时再读。

独立Review则反过来：新会话只读固定SHA、需求、已确认设计和验证摘要，不读实现过程的全部讨论。这样既减少上下文，也避免审阅者沿用实现者的判断。

测试结果仍然要从本机产生

ChatGPT可以读测试代码，判断覆盖是否充分，也可以分析GitHub Actions的失败日志。但它不能因为代码看起来合理，就宣布数据库迁移、容器启动或真实页面已经验证通过。

Codex接棒后运行仓库规定的验证命令，并在PR中记录验证对应的HEAD SHA、运行过的命令、通过、失败或跳过的结果，以及还没有覆盖的风险。本机测试、远端CI、数据库检查、容器运行和负责人真实使用解决的是不同问题，不能互相代替。

ChatGPT的GitHub连接也只需要开放真正参与协作的仓库。日常可以读取源码、文档、Issue、PR和CI结果；需要写入时只修改自己的短期分支，不直接推送主分支，不合并PR，也不接触Secret和真实环境。

最后形成的开发路径并不复杂：

我和ChatGPT讨论需求与设计
  →将确认结论合入主分支
  →Codex在本机worktree实现和测试
  →推送Implementation Draft PR并固定HEAD
  →新的ChatGPT会话独立Review
  →Codex修复问题并重新验证
  →我确认、合并和发布

ChatGPT不需要复制Codex的本机开发过程，Codex也不需要重新经历ChatGPT里的全部需求讨论。GitHub保存交接时的准确状态，仓库文档保存最终结论，两边的额度也用在了它们真正擅长的地方。