这个提示词用来做什么

要给一个已经在用的接口 / 字段 / 表结构做改动，怕漏掉下游调用方，又不想靠群里问一圈来确认

提示词全文

我准备对现有系统做一个改动，请你帮我产出一份可执行的「变更影响评估」，不要给我泛泛的注意事项。

## 输入
改动内容：{接口 / 字段 / 表结构 / 配置，改前是什么、改后是什么}
已知调用方：{能确定的服务、客户端、脚本、报表，注明是自己还是别人维护}
不能停机的要求：{有 / 无；如果有，允许的窗口是多久}
回退手段：{现在能怎么退回旧版本}

## 输出
1）影响面清单，四列：受影响对象 / 受影响方式（编译期报错、运行时拿不到值、语义变了但代码不报错）/ 严重度 / 由谁确认。列到「语义变了但代码不报错」这一类必须单独标出来——它才是最容易被忽略的。
2）把改动拆成三档：可以马上做、必须先加兼容层再做、必须先通知对方改完才能做；每档写清触发条件。
3）兼容层方案：如果要做双写 / 双读 / 旧字段保留，写清保留多久、靠什么指标判断可以撤掉。
4）回归清单：列出必须重跑的用例（含数据校验，不只是接口能通），并指出哪几条是这次改动的高风险点。
5）上线与回退步骤：按分钟写清谁执行哪一步、什么现象算失败、失败后退回哪一步。
6）未知清单：列出你无法从现有信息判断、必须去问人或查代码才能确认的点，并写明该找谁。

怎么用

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

输出示例

它通常会在第一列就把「编译不报错但取值变成空」这类静默失败单独拎出来，而不是和报错混在一起——这类问题在回归里最容易被跳过，也最容易上线后才被发现。第二步的「先加兼容层」往往是最终选择的路径：直接改字段的那一天，就是下游开始报警的那一天。

基本信息

  • 分类：工程
  • 标签：变更管理 · 接口 · 回归测试 · 风险评估 · 协作
  • 收录日期：2026-10-04

同类提示词