Git、PR 与 CI 协作
完成代码不等于工程交付完成。研发团队需要的是可读 diff、清楚 PR 描述、可复现验证、可处理 review 意见，以及 CI 失败后的定位、修复、重跑和复盘。
本章目标
- 能要求它把本地改动整理成可 review 的 diff。
- 知道如何让 agent 以 reviewer 姿态看 PR。
- 能把 CI 红灯闭环到根因、修复和复盘。
先让 diff 可评审
进入 Git 流程前，让它用真实 diff 讲清楚：改了哪些文件、每个文件为什么改、有没有无关变化、哪些地方需要人判断。不要默认让它自动 commit；commit 是团队协作边界，只有明确要求时才做。
CASE
提交前自查
场景
它刚完成页面修复，你不急着提交，先让它自己按 review 标准过一遍。
可以这样说
请做提交前自查：1. 读取 git status；2. 按文件说明 diff 中每处改动服务哪个需求；3. 标出可能属于无关改动的部分；4. 列出已运行验证和未验证风险。不要 stage、commit 或 push。验收点
- 区分本次改动和已有改动。
- 每个文件都有改动理由。
- 无关 diff 被标出。
- 没有擅自提交。
PR 描述要服务 review
- 背景：为什么要改，不要只贴任务标题。
- 改动：按模块或文件说明，不罗列流水账。
- 验证：命令、页面、复现路径、截图对比。
- 风险：未验证项、回滚方式、兼容性或迁移注意点。
- 关联：issue、设计稿、日志、报警或原始需求链接。
请基于当前 diff 起草 PR 描述，结构为：背景 / 改动 / 验证 / 风险。不要编造未运行的测试；没有验证的项目写到风险里。让它以 reviewer 姿态看 PR
评审不是让模型泛泛夸一遍代码。你要给它评审目标：行为回归、边界条件、测试缺口、权限风险、可维护性。被要求挑问题的 reviewer 会倾向于多报，因此只把影响正确性、需求或安全的问题作为必须修。
CASE
fresh reviewer 审当前 diff
场景
实现线程已经完成改动，但对自己的方案有路径依赖。你需要一个新上下文只看 diff 和验收标准。
可以这样说
请用一个全新上下文的 reviewer 视角审当前 diff。只读，不改代码。评审标准：是否满足原始需求、是否有行为回归、是否缺少必要验证、是否夹带无关改动。只报告影响正确性、需求或安全的问题，不报告风格偏好。验收点
- reviewer 不参与实现。
- 只看 diff 和验收标准。
- 问题按影响排序。
- 不把风格偏好当必须修。
处理 review 意见要先分类
请逐条阅读这些 review 意见，先分类为：必须修 / 需要讨论 / 可选优化。只实现必须修的问题；每修一条说明对应评论、改动文件和验证方式。CI 红了怎么闭环
CI 失败不是让它猜一个修复就结束。标准流程是：读失败日志、定位失败阶段、复现最小命令、修复、重跑同一检查、最后说明根因和影响范围。
- 先定位阶段：依赖安装、lint、typecheck、test、build、部署预览。
- 先复现最小命令：能本地复现就不要盲改。
- 修复对准根因：不要为了过 CI 关闭规则、跳过测试或放宽类型。
- 修完重跑同一检查：CI 红在哪，至少重跑对应命令。
- 复盘写规则：如果是项目长期坑点，补进规则文件或 CI 文档。