PR 说明是给审查者的地图，不是作文。 输入只给相关 diff，并禁止模型想象未出现的模块。

提示词

根据下列 diff 写 PR 说明。禁止描述 diff 中未出现的文件或行为。
diff：{{diff}}
输出：
## 摘要（≤2 句）
## 动机/背景（仅基于我补充的：{{背景}}）
## 主要改动（条目）
## 风险与回滚点
## 建议测试
若信息不足，用 【作者补充】 占位。

作者检查项

  • 链接的问题单是否正确
  • 风险是否低估（迁移、权限、缓存）
  • 测试建议是否你真的跑得了

搭配

复杂改动可先让 AI 从工单生成测试关注点：测试计划。审查时仍以代码为准。

实践时如何避免「看起来很忙、没有变好」

  1. 先写清失败案例：哪类输入现在一定会错。
  2. 只改一个环节（提示词、检索、重试或评估），保留前后样例。
  3. 用同一批样例回归，而不是每次换新例子自我安慰。
  4. 把「何时停下来问人」写进流程，避免自动化在错误方向空转。
  5. 文档里区分事实、猜测与待验证，防止团队把草稿当结论。

如果你维护的是团队流程，把上述五步做成合并请求或工单模板中的检查项，比额外再上一个工具更有效。

常见问题

问：一定要用很贵的模型吗？
答：多数通知、清单、结构化合稿用你日常能稳定调用的对话模型即可；关键是材料和规则要由人提供。

问：生成后还要改多久？
答：第一周可能每条改 2–5 分钟；模板稳定后，多数情况只替换变量并扫一眼敏感句。

问：能不能让 AI 直接对客发送？
答：涉及承诺、金钱、健康、未成年人与安全核验的内容，建议始终人工确认后再发。

为什么值得做成固定流程

临时找 AI「帮我写一下」每次都要重新解释背景，结果忽长忽短。固定流程的好处是：规则只维护一份，新人也能按同一口径沟通，并且出了问题可以回看是材料不全还是模板过时。把提示词、审核人和更新日期写在一起，比把文案散落在聊天记录里更可持续。

小 PR 更好写

diff 越大，模型越容易概括错。能拆的改动拆开提交，PR 说明会更准，审查也更快。若必须是大 PR，在背景里手写「阅读顺序」文件列表，再让 AI 按你的顺序摘要，比一次性抛出整包 diff 更可靠。

把上述流程写成团队约定后，新成员可以更快接手，也减少「每个人都用自己的口头禅对客」带来的口径分裂。维护成本主要在规则变更时更新提示词，而不是每天从零写作。

与审查清单对齐

若团队已有审查清单（安全、性能、迁移、特性开关），让 AI 在 PR 说明末尾按清单逐项写「适用/不适用/未改到」。这比空泛的「请帮忙看看」更能帮助审查者分配注意力。你仍要删除模型误标的项，避免审查被错误指引。

相关阅读亦可结合上下文预算：上下文窗口预算。