创建 Pull Request
创建 Pull Request
Section titled “创建 Pull Request”提 PR 这件事，看起来简单——git push 然后 gh pr create 嘛。但一个好 PR 和一个差 PR 的差距，全在提交信息和 PR 描述上。
差 PR 长这样：commit message 是 fix，PR 描述是「修了一些问题」。同事打开一看，得自己 diff 全部文件才能搞清楚你干了什么。好 PR 是 commit 信息有结构、PR 描述讲清来龙去脉、审查者 5 分钟就能下判断。
Claude Code 把这件事从「苦差」变成「一键事」。
第一步：让 Claude 总结 diff
Section titled “第一步：让 Claude 总结 diff”写 PR 描述最难的，是俯瞰整个改动。你刚改完，脑子里全是细节——哪里加了一行、哪里删了一个 if——但缺一张全景图。
让 Claude 来画这张图：
summarize all uncommitted changes in this branch. group them by theme (feature, bugfix, refactor, docs). for each group, list files and the intent of the change它会跑 git diff、读改动、按主题归类，给你一份结构化的改动清单。这份清单后面就是你的 PR 描述骨架。
第二步：遵循 Conventional Commits
Section titled “第二步：遵循 Conventional Commits”提交信息别瞎写。Conventional Commits 是工业界的共识，长这样：
<type>(<scope>): <subject>
<body>type 通常是这几个：
| 类型 | 何时用 |
|---|---|
feat |
新功能 |
fix |
修 Bug |
refactor |
重构（不改行为） |
docs |
文档改动 |
test |
加/改测试 |
chore |
杂项（依赖、配置） |
perf |
性能优化 |
style |
格式调整 |
让 Claude 按这个格式提交：
commit with a descriptive message following Conventional Commits. group related changes into separate commits if they span multiple concerns. don't lump everything into one commit「don’t lump everything into one commit」这一句很重要——它逼 Claude 拆分提交。一个 PR 里如果既有 bugfix 又有 refactor，应该是两个 commit；既有 feature 又有 docs，也应该是两个。审查者一眼能看清「这个 PR 干了几件事」。
第三步：让 Claude 开 PR
Section titled “第三步：让 Claude 开 PR”提交完，让它直接开 PR：
commit with a descriptive message and open a PR
the PR description should include:- what changed (one paragraph)- why it changed (link to issue or business reason)- how to verify (test commands or repro steps)- breaking changes, if any这份 prompt 给了 PR 描述的四段式结构：What / Why / How to verify / Breaking changes。这四块是审查者最关心的——「改了啥」「为啥改」「我怎么验证它没坏」「有没有破坏现有用法」。
Claude 会调用 gh CLI 创建 PR，描述按你要求的结构填好。比手敲 gh pr create --body "..." 高效十倍。
第四步：用 /review 请求代码审查
Section titled “第四步：用 /review 请求代码审查”PR 开了之后，让 Claude 自己先审一遍——这是免费的第一道关：
/review/review 会启动一个审查子代理，独立上下文，从外部视角看这个 diff。它会找出：
- 潜在 bug
- 风格不一致
- 缺失的测试
- 安全隐患
- 可以更简单的写法
子代理的产出是一份审查报告，你拿到后决定哪些采纳——不是所有反馈都要改，有些是「风格偏好」可以忽略。
更猛的版本是 Ultrareview：
/code-review ultra或
claude ultrareview它会做多轮深度审查——不只看 diff，还看周边代码、调用方、潜在影响面。适合改动较大、风险较高的 PR。
第五步：GitHub Actions 集成 @claude mention
Section titled “第五步：GitHub Actions 集成 @claude mention”PR 提了之后，真正的代码审查通常发生在 GitHub 上。Claude Code 提供了 GitHub Actions 集成——你可以 @claude 在 PR 评论里直接召唤它。
@claude review this PR and focus on the auth flow changes@claude is there any risk that this change breaks existing sessions?@claude write a test for the edge case where the user is logged out, then commit it to this branch这些评论会触发 GitHub Actions 里的 Claude Code，它会以 headless 模式跑一遍，把结果回帖到 PR。这让你的 PR 审查有人接力——同事下班了，Claude 接着看。
要启用这个集成，在仓库里装上官方的 GitHub Action（参考 GitHub Actions 章节），并在 PR 评论里 @claude 召唤。
一个完整的「提 PR」prompt
Section titled “一个完整的「提 PR」prompt”把上面五步串起来：
1. summarize all uncommitted changes, grouped by theme2. commit each group separately following Conventional Commits: - feat/fix/refactor/docs/test/chore - scope in parentheses - imperative mood subject line under 72 chars - body explaining why, not what3. push the branch and open a PR via gh4. PR description: What / Why / How to verify / Breaking changes5. run /review on the diff before I merge走完这五步，你得到的是一个结构清晰、描述完整、自查过、可被同事 5 分钟审完的 PR。比「fix + 「修了一些问题」」的 PR 强一个量级。
- PR 大小：一个 PR 别超 400 行 diff。Claude 能帮你拆，问它：「this PR is too big. suggest how to split it into smaller PRs」。
- 测试在前：PR 里要有测试。没有测试的 PR，让 Claude 补一个：「add a test that would fail if this change were reverted」。
- 描述讲 Why，不讲 What：What 看 diff 就知道，Why 才是 PR 描述的价值。让 Claude 在描述里讲为什么这么改，而不是列改了什么。
- 想让 PR 审查更系统——看 代码审查流水线。
- 重构完准备发 PR——读 代码重构流程。
- GitHub Actions 集成详情——回顾 GitHub Actions。