eryajf PR 变更总结
对 PR 的代码变更进行分析，生成结构化的变更总结。
执行步骤
1. 获取变更信息
使用 cnb-pr-diff Skill 获取 PR 变更：
- 先获取变更统计（
--stat）和文件列表（--name-only） - 再按需获取关键文件的具体 diff
2. 过滤文件
优先分析（核心代码）：
- 业务逻辑：
src/、lib/、app/、packages/ - API/接口：
api/、routes/、controllers/ - 配置文件：
*.config.*、*.yml、*.yaml - 数据库/模型：
models/、schema/、migrations/
跳过（非核心文件）：
- 依赖锁文件：
package-lock.json、yarn.lock、go.sum - 构建产物：
dist/、build/、.next/ - 生成文件：
*.min.js、*.map - 纯测试文件（除非测试是本次变更重点）
3. 分析变更
按以下维度分析：
| 维度 | 关注点 |
|---|---|
| 变更类型 | feat（新功能）、fix（修复）、refactor（重构）、perf（性能）、docs（文档）、chore（配置/依赖） |
| 影响范围 | 涉及哪些模块、影响哪些功能点 |
| 关键改动 | 核心逻辑变更、API 变化、数据结构变更 |
| 破坏性变更 | 不兼容改动、需要迁移的内容 |
若上下文不足以理解代码意图，使用 Read 工具读取完整源文件。
输出格式
**{type}**: {一句话描述}
**主要改动**
- {模块}: {变更说明}
- {模块}: {变更说明}
**注意**: {破坏性变更或风险点；如无则省略}
总结原则
- 简洁明了：突出重点，避免逐行复述 diff
- 按功能分组：按模块/功能组织，而非逐文件罗列
- 突出意图：说明"为什么改"而非仅描述"改了什么"
- 识别风险：主动指出破坏性变更和需要关注的点
大型 PR 处理
当文件数超过 20 个时：
- 先用
--stat分析变更分布，按模块归类 - 重点分析核心模块变更（变更量大或涉及关键逻辑）
- 在末尾概括未详细分析的文件/模块