Codex 额度用完怎么办？用 ChatGPT 和 GitHub 继续开发

三者分工一眼看懂

1. 只给 ChatGPT 授权需要的 GitHub 仓库

在 ChatGPT 中打开 Settings，在 Apps 或 Plugins 中找到 GitHub；不同产品界面的名称可能不同。开始连接后，跳转到 GitHub 安装或授权 ChatGPT GitHub 应用，然后选择它可以访问的账户/组织和仓库。

1. 打开 ChatGPT 的 Settings → Apps/Plugins → GitHub。
2. 跳转到 GitHub，授权 ChatGPT 应用，并选择正确的账户或组织。
3. 在 GitHub 应用的仓库设置中，只选择目标仓库，例如 owner/project；如果组织要求审批，先请求管理员批准。
4. 回到 ChatGPT，用一个只读请求验证：指定仓库名称和一个已知文件路径。
5. 如果仓库没有出现，先检查 GitHub App 是否安装在正确账户/组织、是否选中了该仓库，不要盲目反复重连。

仓库：acme/storefront
只读验证：
“请在 acme/storefront 中查找结账流程入口，返回相关文件路径和每个文件的作用。不要修改任何内容。”

GitHub 内容是按需读取的，连接并不代表创建了一个由管理员维护的同步索引。计划、工作区、组织策略和产品界面都会影响可用能力。

2. 让 ChatGPT 产出“实施包”，不要只问一句泛泛的问题

告诉 ChatGPT 准确的仓库、用户目标、限制和验收条件。先让它检查授权仓库，再输出另一个编码代理可以执行的计划。如果还需要代码草稿，只允许它针对点名文件生成 patch 或完整文件，不要让它凭空重写整个仓库。

你现在只负责分析和规划，不要修改 GitHub 仓库。

仓库：acme/storefront
目标：用户未登录时，结账页显示登录入口；已登录流程不变。
限制：只允许修改 src/checkout/ 和对应测试；保持现有 React/TypeScript 风格。

请输出：
1. 当前实现涉及的文件和调用链；
2. 最小实现计划；
3. 每个文件的具体改动；
4. 如有必要，给出精确 patch；
5. 回归风险；
6. 测试、构建和 Preview 验收命令；
7. 需要 Codex 继续确认的问题。

3. 交给 Codex 前，先把 ChatGPT 结果保存到 GitHub

只读 GitHub 连接不能作为最终写入步骤。把确认后的计划复制到 GitHub Issue，或写进已有 Issue/PR 的评论。把验收条件、文件范围、代码草稿、未决问题和准确验证命令放在一起；这就是 Codex 要读取的交接对象。

1. 一个 Issue 只对应一个用户可见结果，标题要短，方便在 Codex 提示词中引用。
2. 把确认后的计划和代码 patch 粘贴到 Issue 正文或评论；删除 secrets 和无关代码。
3. 写清禁止修改的内容、基线分支和证明成功的命令。
4. ChatGPT 生成的代码先标为 draft，等 Codex 对照真实仓库和测试检查后再采用。

## Codex 交接
目标：[一个结果]
来源：ChatGPT 于 [日期] 的分析
范围内：[文件]
范围外：[文件/行为]
计划：[编号步骤]
代码草稿：[必要时粘贴]
验收：
- [检查 1]
- [检查 2]
验证：pnpm test --filter checkout
部署：只准备 Preview；Production 需要批准

4. 在同一个仓库上打开 Codex，执行交接内容

在 Codex 中连接 GitHub 并选择仓库环境；如果使用本地 Codex，就打开本地 checkout。让 Codex 先读 Issue、检查真实文件，并在仓库与草稿不一致时指出差异。计划只是输入，不是要求它盲目套用每一行生成代码。

读取 GitHub Issue #123 作为本次任务说明。

先做：
1. 检查当前分支、工作区状态和项目说明；
2. 对照真实文件审计 Issue 中的计划和 patch；
3. 如果计划与仓库不一致，先报告差异，不要猜。

确认后：
4. 创建独立分支；
5. 只修改约定范围内的文件；
6. 添加或更新回归测试；
7. 运行测试、类型检查和构建；
8. 汇报 diff、验证结果和未解决问题；
9. 未经明确批准不要合并或部署 Production。

5. 让 Codex 产出可审查的 PR，再通过部署闸门

Codex 最终应该产生一个小范围分支提交和关联 Issue 的 PR。PR 展示的必须是真实 diff 和 Checks，而不是重复 ChatGPT 的计划。Preview 可以由仓库已有 CI/CD 流程触发；Production 是单独的闸门，需要项目凭据、环境配置和明确的批准或合并规则。

1. Codex 先运行最小相关测试，再运行项目的 typecheck/build。
2. Codex 推送分支并创建或更新 PR；PR 记录改动文件、检查结果和剩余风险。
3. 如果仓库配置了 CI/CD，等待它生成 Preview，并验证真实 Preview URL 和行为。
4. 人工审查和项目发布规则通过后，才让改动进入 Production。
5. 部署后验证公开路由，并把结果写回 PR 或 Issue。

不要只对 Codex 说“部署”。默认说“准备 Preview，然后停止”；成功的本地 build 或合并 PR 都不等于可以部署 Production。

最短可靠版本

1. ChatGPT + GitHub：读取仓库并产出计划。
2. 人工：把计划保存为 GitHub Issue 或 PR 评论。
3. Codex：审计计划、修改真实代码、运行检查并推送 PR。
4. CI/CD 或经批准的 Codex 操作：部署 Preview、验证，再单独发布 Production。

常见问题