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 摘要的价值。