Codex 和 GitHub 怎么配合提交代码

Codex 可以帮你读代码、改文件、跑命令、整理说明；GitHub 则负责保存历史、展示 diff、跑 CI、发起 PR 和留下交付证据。对 AI 工具新手来说，最稳的做法不是让 Codex 改完就直接推送，而是把每次修改放进可复查的 GitHub 工作流里。

这篇是草稿，只做流程学习和人工审核参考。可以配合 报错解释器、Proposal 生成器 和 模板库 使用：先把任务范围写清楚，再让 Codex 辅助修改，最后用 GitHub 留证据。

适合谁

适合准备用 Codex 辅助处理小范围代码修改的新手，例如修 bug、改页面、整理 README、调整配置、补测试、修改文案。你需要能看懂基本 git status、git diff 和提交记录。

也适合正在建立项目交付 SOP 的人。客户不只看你有没有改完，还会看你能不能说明改了什么、怎么验证、哪些没覆盖，以及出了问题能不能回退。

不适合谁

不适合没有客户授权就访问私有仓库、直接推主分支、覆盖客户已有改动、提交真实密钥或处理生产敏感数据的任务。遇到这些情况，要先暂停并确认权限。

也不适合把 Codex 输出直接当成最终提交的人。工具生成的改动必须经过 diff、测试和人工复核；GitHub 记录不是装饰，而是责任边界。

风险提醒

GitHub 工作流最大的风险是混入无关改动：你只想修一个小问题，却顺手提交了客户已有修改、临时日志、.env、截图、构建产物或无关重构。另一个风险是权限越界：没有确认就推到主分支、改 CI 配置或触发部署。

凡是涉及真实密钥、生产数据、账号权限、支付配置、部署发布、CI token 或私有客户材料，都要先记录为客户待确认项。需要登录、授权或开通服务的动作，不要由你擅自完成。

具体步骤

1. 保存客户需求和验收标准，明确本次只改什么。
2. 运行 git status，确认工作区是否干净，是否有你不认识的改动。
3. 创建任务分支，例如 fix/button-spacing 或 draft/readme-cleanup。
4. 让 Codex 只读取和任务相关的文件，避免扩大范围。
5. 修改后查看 git diff，逐项解释每个变化。
6. 跑项目已有检查，例如 lint、build、测试、内容检查或页面 smoke test。
7. 写提交信息，说明修改目标，不把多个不相关任务混在一个提交里。
8. 开 PR 或交付补丁，写清修改范围、验证命令、未覆盖范围和客户待确认事项。

可复制命令

git status
git switch -c fix/example-task
git diff
npm run lint
npm run build
git add <files>
git commit -m "Fix example task"

这些命令不是固定答案。不同项目可能用 pnpm、yarn、pytest、go test 或别的检查命令。关键是：每次提交前都要知道当前状态、修改范围和验证结果。

PR 描述模板

目标：
修改范围：
验证命令：
验证结果：
未覆盖范围：
客户待确认：
回滚方式：

PR 描述越具体，后续沟通越省力。客户或维护者能快速判断这次修改是否只处理目标任务，也能知道还有哪些地方没有验证。

为什么不要直接推主分支

主分支通常代表项目当前稳定状态，有些仓库还会自动触发部署。新手直接推主分支，一旦包含错误改动、敏感文件或未验证代码，影响会比本地改错更大。分支和 PR 给你一个缓冲区，让错误在合并前被发现。

即使客户说“直接改就行”，你也可以保守处理：先提交到分支，写清验证结果，再让客户确认是否合并。这个习惯会让你的项目流程更像工程交付，而不是临时试错。

什么时候需要客户确认

如果下一步会触发部署、合并主分支、修改 GitHub Actions、调整仓库权限、添加 secret、删除分支保护或访问私有数据，就不要把它当成普通代码提交。把这些动作写进“客户待确认”，等客户明确授权后再继续。

普通小改动可以由你完成分支和 PR；高权限动作应该由客户或仓库维护者操作。这样既保护客户项目，也保护你自己不承担超出范围的责任。

CTA：下一步

想按步骤执行，可以看 Codex GitHub 提交检查清单。如果你常把无关改动混进提交，继续看 常见错误和修复顺序。项目前拿不准权限和范围，可以用 项目边界判断 和 报价计算器 拆任务。

免责声明

本文只用于 AI 工具实践流程学习和草稿复核，不构成法律意见、安全审计、职业建议或具体项目交付承诺。真实项目应以客户授权、平台规则、仓库规则和人工复核为准；需要登录、授权、合并、部署或高权限操作的事项，应先记录并由客户确认。