编程开发 编辑复核
Pull Request 说明生成器
把 diff、需求和验证结果整理成审阅者能快速判断风险、范围和验收方式的 PR 说明。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名工程协作编辑。请忠实地整理变更目标、范围、行为差异、测试和风险，不要把未运行的检查标记为通过。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 需求和用户影响
2. 改动文件、数据流和兼容性
3. 已运行的测试与未运行的测试
4. 截图、日志或接口证据
5. 发布风险、回滚和审阅者重点
输入变量：
- 需求（{{requirement}}）：提供原始需求和验收标准。
- 变更摘要（{{diff}}）：提供 diff 或按文件总结。
- 验证记录（{{verification}}）：列出实际运行的命令和结果。
- 风险与回滚（{{risk}}）：说明可能影响和回滚方式。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 只填写真实运行过的检查，保留失败和未运行项。
- PR 描述要让审阅者知道哪里需要重点看。
WHEN IT FITS
适用判断
适合这些情况
- PR 改动较大，reviewer 需要背景信息才看得懂。
- 有方案取舍需要说明，避免 review 时反复讨论。
- 要说清楚测试了什么、还有什么没验证。
换个做法更好
- 你要写的是提交信息：用《Git 提交说明与变更边界》。
- PR 只改了一行且标题已经说清：不需要长描述。
- diff 还没最终确定：描述会跟着改。
FAILURE MODES
常见翻车与修正
- 描述把每个文件的改动都列了一遍。
reviewer 会看 diff。要求描述聚焦在为什么改、方案取舍和需要重点看的地方。
- 声称「已充分测试」，但没说测了什么。
要求具体列出跑过的测试、手动验证的场景，以及明确没有覆盖的部分。
- 漏掉了对 reviewer 重要的风险提示。
要求单独一段写明这次改动的风险点、影响范围和上线注意事项。
ACCEPTANCE
怎么判断输出合格
- 说明了改动原因和方案取舍，不是文件清单。
- 测试情况具体到跑了什么、验证了什么、漏了什么。
- 风险点和上线注意事项单独列出。
- 指出了希望 reviewer 重点看的位置。
SAFETY BOUNDARY
使用边界
- 描述里不要写入安全问题的具体利用方式，PR 记录会长期可见。
- 模型总结的影响范围可能不全，涉及数据和权限的改动要自己确认后再写入描述。