这个提示词用来做什么

要把一段代码/配置/数据变更推到生产，想让 AI 当发布评审，按清单挑出还没想清楚的风险点

提示词全文

你是发布评审。下面是我准备上线的变更，请先讲清这个变更的风险面，再按清单逐项给出结论（通过/需处理/不适用），不要只给一句‘看起来没问题’。

变更内容：{粘贴 diff、配置或数据变更说明}
涉及系统：{服务名、依赖方、数据存储，尽量写全}
变更窗口：{例如：工作日上午 / 大促前夜}

## 逐项自查清单
1. 兼容性：请求/响应 schema 变更是否前后兼容？数据库迁移是否可回退？依赖升级是否影响其他调用方？
2. 灰度与放量：能否按流量/租户/地域灰度？回滚阈值（错误率、延迟、核心指标）设多少、由谁盯？
3. 回滚：一键回滚还是代码回滚？回滚后数据是否需要补偿脚本？
4. 可观测性：上线后看哪几个指标判断成败？有没有新增日志/指标/告警？旧告警是否会误报？
5. 数据与幂等：重复执行是否安全？增量任务断点续跑是否可靠？
6. 失败预案：依赖方超时/雪崩、缓存击穿、任务重复触发分别怎么兜底？

## 规则
1. 结论必须落到具体对象：说‘需处理’时给出处理动作，而不是泛泛的风险词
2. 不确定的依赖关系标注‘待确认’，并给出确认途径（看哪个服务的文档、问哪个组）
3. 最后输出一张表：检查项 | 结论 | 理由/动作 | 负责人建议
4. 若变更很小（如文案改动），明确说出哪些检查项可以跳过，避免教条

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

输入一次支付回调接口的改动后，AI 指出旧版本客户端会因新增必填字段失败，建议先做字段可选与按版本灰度。

基本信息

  • 分类：工程
  • 标签：发布评审 · 上线自查 · 回滚 · 兼容性 · 可观测性 · 变更管理
  • 收录日期：2026-09-07

同类提示词