换个角度想
PR 像论文投稿：稿子写完不能直接见刊，审稿人提意见、你修改，通过了才发表。主线就是那本期刊，进去的都过了同行评审。
术语 · 工程与协作
合并请求
Pull Request
请求团队审查一组代码修改，并在确认后合并到目标分支。
合并之前，先过一道评审
直接推主线先发 PR进主线前，有没有人看
问题在线上爆问题被评审拦拦在门外，代价最小
- 这一步不存在——
改完直接 push，没人知道改了什么PR #42标题重构支付模块内容完整 Diff + 改动说明 没有闸门
改动已经躺在主线上了
自动检查测试✓ 通过构建✓ 通过第一个「评审」是线上用户
老账户的余额显示成了 0
同事的评论第 87 行「老账户没这个字段吧？」你补上兼容逻辑 ✓- 半夜回滚事故报告加熬夜修复，代价最大化问题总会被发现，差别在时机和代价干净合入兼容问题在评审里就解决了多等一晚，省一场事故
分支改完，发起 PR
什么时候会遇到它
AI 代码的闸门
Agent 写的代码先出 PR，人看过 Diff 再进主线。
团队知识流动
评审里的讨论，让整个团队理解这次改动。
出问题可追溯
半年后回看，当时为什么这么改，PR 里全有。
想一想
深夜赶工，AI 生成了一个大改动，测试也绿了，能不能跳过 PR 直接推主线？
看答案
测试绿只说明没破坏已有用例，用例覆盖不到的坑机器看不见。越是大改动、越是深夜，越需要第二双眼睛——发 PR，明早让同事看过再合。
最容易踩的坑
PR 评审不是走形式。「LGTM 秒批」的团队，主线和没有评审时一样脆——评审的价值全在认真看 Diff。