Appearance
26 · Git 与 GitHub 集成：让 Codex 在你的 PR 里当审查员
Git 和 GitHub 是项目协作的底座。 Codex 接进去以后，最适合做的事不是替你乱合并，而是帮你审查、解释、修小问题。
你仍然是最后放行的人。
先把 Codex 定位成审查员，不是合并人
小白最容易犯的错，是让 Codex 一口气写完、提交、合并。
更稳的做法是：
- 你先说清楚要改什么。
- Codex 负责改代码、跑检查、解释变化。
- GitHub 负责留下记录，让你最后确认。
你可以把 Codex 当成一个会干活的同事，但最后点头的人还是你。
第一次练习：只让它审查，不让它合并
小白第一次接 GitHub，先做审查任务：
text
@codex review
请只审查这个 PR，不要修改代码，不要合并。
重点告诉我：
1. 有没有明显 bug
2. 有没有改到无关文件
3. 有没有缺少验证
4. 哪些地方需要我人工确认先让它当审查员。 等你熟悉后，再让它修小问题。
01 先分清两条线：GitHub 里的 Codex，和你终端里的 Codex
有两条线：
- GitHub 里的 Codex：在 PR、issue、评论里工作。
- 本地 Codex：在你的电脑和项目文件夹里工作。
不要混。 本地能看到你的工作区，GitHub 里主要围绕仓库、PR、评论。
02 一句 @codex review：让它在 PR 里挑刺
在 PR 里让 Codex review，适合找：
- 明显 bug。
- 风险改动。
- 缺少测试。
- 文档不一致。
你可以在 PR 里写：
text
@codex review
请重点检查这次改动是否有安全风险、缺少验证、以及是否改到无关文件。03 自动审查：每个新 PR 一开，它就自动出手
自动审查适合团队。 个人项目先不急。
如果要开，先明确标准：
text
请帮我设计一套 PR 自动审查规则。
重点检查：
1. 是否改到无关文件
2. 是否有密钥泄露
3. 是否缺少构建验证04 定制审查规则：把你的标准写进 AGENTS.md
审查标准不要只靠临时评论。 可以写进 AGENTS.md。
比如：
md
PR 审查重点：
- 教程文章是否面向小白
- 是否包含可复制提示词
- 是否有常见错误和检查清单
- 修改后是否构建通过05 改完直接修：@codex fix 与它能动到哪儿
如果 Codex 在 PR 里发现问题，有些环境可以让它修。
但要限定范围：
text
@codex fix
请只修复 review 中指出的第 2 个问题。
不要重构其他代码，不要改无关文件。06 本地 /review：开 PR 之前，先在终端自查一遍
在本地开 PR 前，可以先自查。
提示词：
text
请对当前未提交改动做一次 review。
重点检查：
1. 是否有风险改动
2. 是否缺少验证
3. 是否有无关文件
只给问题清单，不要修改。07 配 gh：让 Codex 桌面端能读到 PR 的来龙去脉
gh 是 GitHub CLI。 配置好后，Codex 更容易读取 PR 信息。
新手先问：
text
当前环境是否已经配置 GitHub CLI？
如果没有，请告诉我检查方法，不要替我登录账号。登录账号这类动作，建议你自己做。
08 守住红线：别让任何 AI 替你按下“合并”和“强推”
这条很重要：
不要让 AI 替你：
- merge PR。
- force push。
- 删除分支。
- 改仓库权限。
- 发布正式版本。
这些动作你自己确认。
09 一张心智图：Codex 当审查员，你当放行的人
Codex 适合：
- 看 diff。
- 找风险。
- 提建议。
- 修小问题。
你负责：
- 判断是否接受。
- 决定是否合并。
- 处理线上影响。
10 动手：本地 /review 跑通一次自查
练习流程：
- 做一个小改动。
- 让 Codex review 当前改动。
- 看它指出的问题。
- 只修一个最小问题。
- 再跑构建。
11 小结
GitHub 集成不是让 AI 替你做最终决定。 它最适合当审查员。
小白记住：AI 可以挑刺，可以建议，可以修小问题，但合并按钮你自己按。