Codex GitHub 提交代码检查清单

这份清单用于每次让 Codex 辅助修改代码并准备提交到 GitHub 前后。目标是避免无关改动、敏感文件、未验证代码和权限越界进入仓库。

这篇仍是草稿，只做流程参考。建议先读 Codex 和 GitHub 怎么配合提交代码，再把下面条目复制到自己的项目记录里。

适合谁

适合准备通过 GitHub 交付代码的新手，尤其是用 Codex 改了文件后，不确定该不该提交、怎么写 commit、PR 里该说明什么的人。

也适合已经开始接客户仓库任务的人。清单能帮助你把“工具改完了”变成“仓库里有可复查的交付记录”。

不适合谁

不适合没有客户授权却访问私有仓库、直接修改主分支、处理生产密钥、变更支付或账号权限的任务。遇到这些情况，先暂停并确认权限。

也不适合把清单当成完整安全审计的人。它是提交前最低限度流程，不能替代项目自己的代码审查、CI 和安全规则。

风险提醒

提交前最危险的信号包括：工作区里有不认识的改动、diff 超出任务范围、出现 .env 或凭证文件、CI 没跑、客户没有确认高权限操作、PR 描述写不清验证结果。

具体步骤

一、修改前

• 是否保存客户需求和验收标准？
• 是否确认仓库访问是客户授权的？
• 是否运行 git status？
• 是否确认当前分支不是主分支，或至少知道为什么要在当前分支改？
• 是否创建任务分支？
• 是否知道本次允许修改哪些文件？
• 是否确认不接收真实生产密钥、账号密码或私有用户数据？

二、修改中

• 是否让 Codex 只读取目标文件？
• 是否禁止无关重构？
• 是否避免修改 CI、部署、权限配置等高风险文件？
• 是否记录需要客户确认的登录、授权、部署或合并事项？
• 是否保存关键命令输出？

三、提交前

• git diff 是否只包含目标任务？
• 是否没有新增 .env、token、私钥、日志、截图、构建产物？
• 是否跑过项目检查命令？
• 是否确认失败项已经解释或修复？
• 是否写了清晰提交信息？
• 是否没有把多个不相关任务混在一个提交里？

四、PR 或交付前

• 是否写清目标？
• 是否列出修改文件或范围？
• 是否写清验证命令和结果？
• 是否列出未覆盖范围？
• 是否写清客户待确认事项？
• 是否说明回滚方式？

PR 模板

Summary:
- 

Verification:
- 

Not covered:
- 

Customer confirmation needed:
- 

命令记录模板

分支：
修改文件：
检查命令：
检查结果：
提交：
PR：
待确认：

审核 diff 的小技巧

看 diff 时不要只看有没有报错，还要看“为什么改”。每一处变化最好都能回答三个问题：它和本次任务有什么关系？它是否会影响其他页面或功能？它是否需要客户确认？答不上来，就先不要提交。

新手还要特别小心自动格式化和批量重排。格式化本身不是坏事，但如果它让 diff 变得很大，会掩盖真正修改。除非任务就是格式整理，否则把格式化改动拆开或避免混入本次提交。

PR 前最后确认

开 PR 前，把描述当成给客户看的交付说明，而不是给自己看的备忘录。客户或维护者应该能从 PR 里直接知道：这次解决什么、为什么这样改、怎么验证、哪些地方没测、哪些动作还需要他们确认。

如果 PR 会触发自动部署、预览环境或 CI 费用，也要提前说明。新手不要默认所有 GitHub 动作都只是本地小事，尤其是客户仓库有自动化工作流时，推送分支本身也可能产生外部影响。

最后再确认一次权限边界：谁负责合并、谁负责部署、谁负责回滚、谁能处理 secret 和仓库设置。只要这些问题没确认，就把它们写进 PR 的待确认部分，不要在交付说明里含糊带过。

CTA：下一步

如果检查中发现自己混入无关改动，先看 GitHub 工作流常见错误。需要写客户交付说明时，可以用 Proposal 生成器 起草，再手动加入验证和未覆盖范围。

免责声明

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