Codex 和 GitHub 怎么配合：新手工作流

Codex 可以帮你读代码、改代码、解释报错，但 GitHub 才是记录改动、审查差异和交付结果的地方。新手不要把 AI 生成代码直接丢进主分支，而要学会用分支、提交、PR 和检查结果把过程留下来。

这篇仍是草稿。发布前需要人工核对 GitHub 当前界面、权限说明、PR 流程截图和客户授权规则。

适合谁

适合已经能用 Codex 修改小项目，但还不熟悉 GitHub 交付流程的新手。你可能只会基础 Git 命令，但愿意按步骤保存 diff、提交信息和验证结果。

也适合准备做自由职业技术小单的人。客户更需要看到你如何改、如何测、如何说明风险，而不是只听你说“AI 已经完成”。

不适合谁

不适合还不会回滚、不看 diff、直接把代码推到主分支的人。也不适合处理客户生产仓库、组织权限、私有依赖、安全配置或敏感代码的新手。

如果客户没有明确授权你访问仓库，或者要求你直接登录他的个人账号操作，这类事项应该先记录为客户侧授权待办，而不是继续开工。

GitHub 在流程里负责什么

GitHub 的价值不是“存代码”这么简单。对新手来说，它至少承担四个角色：

1. 记录：每一次改动都有提交和文件差异。
2. 隔离：分支让练习改动不直接影响主线。
3. 审核：PR 让你或客户可以逐行查看改动。
4. 验证：CI、预览链接和评论可以把检查结果放在同一个地方。

Codex 负责帮你推进任务，GitHub 负责让任务可追踪。两者配合的重点是“可复查”，不是“速度看起来很快”。

具体步骤

1. 从干净工作区开始，先运行 git status。
2. 新建任务分支，分支名写清楚目的，例如 fix/header-layout。
3. 让 Codex 只处理一个明确问题，不要一次改多个无关范围。
4. 修改后查看 git diff，确认每个文件都和需求有关。
5. 运行项目检查，例如 lint、build、测试或手动页面验证。
6. 写提交信息，说明本次解决了什么，不要只写 “update”。
7. 打开 PR，附上改动摘要、验证命令、截图和未验证事项。
8. 客户确认后再合并；需要账号、环境变量或生产权限的事项列入明日待办。

可以复制的 PR 说明

## Summary
- Updated:
- Reason:
- Out of scope:

## Verification
- npm run lint:
- npm run build:
- Manual check:

## Risks / Follow-up
- Needs customer confirmation:
- Needs account or platform authorization:
- Not verified:

这段模板适合内部草稿和小型 PR。正式给客户时，要按真实项目删改，避免把未验证事项写成已完成。

做项目时怎么用

如果客户只想让你“直接改一下”，你也应该建议走测试分支或 PR。这样客户能看到改动，自己也能保留交付证据。即使是小 CSS 修复，也应该有清楚的截图、提交记录和验收方式。

如果客户没有 GitHub 仓库，可以先建议用压缩包或最小复现做诊断，但最终交付仍然需要版本记录。没有版本记录的交付，后面返工会很难说清责任。

一个新手可执行的练习

可以先做一个很小的练习：新建分支，修改首页一段文案，运行构建，提交，再写一个 PR 说明。这个练习的目标不是炫技，而是确认自己是否能把从需求到交付的过程走完整。

练习时要特别看两件事。第一，Codex 是否只改了你要求的文件；如果它顺手改了无关配置，要停下来确认原因。第二，你是否能解释每一行关键 diff；如果解释不了，就把它标为需要复核，而不是直接合并。

完成后，把 PR 链接、截图、命令结果和未验证事项写进练习记录。以后接小单时，这类记录比一句“我会用 Codex”更可信。

什么时候不要继续

如果客户要求你用他的个人账号登录 GitHub、直接改主分支、跳过 PR 审核，或者把组织权限交给你处理，就应该先暂停。新手可以协助写清楚需要哪些授权，但不应该在没有授权记录的情况下替客户调整权限。

如果仓库里已经出现密钥、客户数据或生产配置，也不要继续普通交付流程。先记录风险，建议客户做权限和历史记录复核，再决定后续技术处理。

风险提醒

不要把客户私有仓库、截图、代码片段或密钥放进公开作品集。不要把 token、.env、本地缓存、日志里的客户数据提交到 GitHub。不要在没有授权的情况下邀请自己进入客户组织或修改仓库权限。

如果 PR 涉及登录、支付、数据库、隐私数据、安全策略或生产部署，必须人工复核，并准备回滚方案。

明日待办

• 补充一份匿名 PR 截图和验证记录。
• 人工核对 GitHub 权限、协作者邀请和 PR 流程说明。
• 准备客户侧授权清单：仓库访问、分支权限、CI 权限、预览链接。
• 检查是否需要单独写“如何避免提交密钥”的草稿。

可以继续看的内容

• Codex 工具页
• 报错解释器
• 模板下载

免责声明

本文仅供学习和交付流程整理，不构成法律、安全或职业建议。涉及客户仓库、账号、密钥、生产分支和组织权限时，需要明确授权并人工复核。

CTA：你可以先用 报错解释器 整理验证日志，再用 Proposal 生成器 写一版 PR 交付说明。