AI PR 摘要生成：别把变更说明写成流水账
一、PR 摘要不是复制提交记录
前端项目里，一个 PR 可能同时改组件、样式、接口字段、构建配置和测试用例。AI 很适合帮忙生成摘要，但如果只是把 diff 按文件复述一遍，读者仍然不知道这次变更影响什么、风险在哪里、该怎么 review。
AI PR 摘要的目标，是帮 reviewer 快速建立上下文，而不是制造一篇更长的流水账。
二、先把 diff 分类
flowchart TD
A[Git Diff] –> B[文件分类]
B –> C[组件变更]
B –> D[样式变更]
B –> E[接口变更]
B –> F[构建配置]
C –> G[PR 摘要]
D –> G
E –> G
F –> G
摘要前要先做分类。组件逻辑、视觉样式、接口契约、测试和构建配置的 review 关注点完全不同。AI 如果不分类，就容易把一堆细节揉成“优化了若干功能”。
pr_summary_sections:
– user_visible_changes
– api_contract_changes
– performance_risk
– test_coverage
– review_focus
让摘要固定包含这些部分，比自由发挥稳定得多。
三、输入要控制范围
type DiffFile = {
path: string
kind: "component" | "style" | "test" | "config"
additions: number
deletions: number
}
不要把完整 diff 一股脑塞给模型。可以先提取文件路径、变更块、函数名、测试变化和关键配置，再让 AI 生成摘要。大 diff 尤其要截断无意义的快照、lock 文件和自动生成代码。
如果有设计稿链接、需求 ID、接口文档，也应该作为上下文输入。没有业务背景，AI 很容易只写代码层面的变化。
四、摘要要指出风险
好的 PR 摘要应该告诉 reviewer：哪些地方可能影响用户，哪些地方需要重点看，哪些地方需要设计或测试确认。
{
"risk": "修改了支付按钮禁用条件，可能影响下单转化",
"review_focus": ["状态判断", "接口字段兼容", "移动端样式"],
"tests": ["新增 SubmitButton.spec.ts"]
}
AI 还要诚实标注不确定。比如它无法判断接口是否兼容，就写“需要确认后端字段是否已上线”，不要假装一切正常。
摘要生成后可以作为 PR 模板的草稿，而不是直接提交。开发者最后要确认它没有夸大、遗漏或误解需求。AI 负责压缩信息，人负责承担责任。
最后，摘要质量要回收反馈。如果 reviewer 经常手动修改某类风险描述，就说明提示词或 diff 分类规则需要调整。PR 摘要也是工程系统，不是一次 Prompt 就完事。
还可以把摘要和变更规模绑定。小 PR 不需要长篇报告，大 PR 则必须给出模块影响和回滚注意事项。摘要长度如果不随风险变化，要么浪费 reviewer 时间，要么漏掉关键风险。
summary_length_policy:
small_pr: 5_lines
medium_pr: structured_sections
large_pr: require_risk_and_rollback
对于自动生成的摘要，最好标记“AI 草稿”。这不是降低可信度，而是提醒开发者最后确认。AI 能压缩信息，但不能替开发者承诺变更影响。
五、总结
AI PR 摘要生成要先分类 diff，再围绕用户影响、接口契约、性能风险、测试覆盖和 review 重点组织内容。
别把变更说明写成流水账。让 reviewer 更快抓到风险，才是 AI 摘要的价值。
