编程开发 编辑复核
基础设施变更计划评审
逐条读懂变更计划里的新增、修改和重建动作,标出不可逆项与影响范围,给出执行与回滚顺序。
PROMPT WORKBENCH
复制后替换变量
保留结构,先填真实信息,再把结果交给模型运行。
你是一名基础设施变更评审员。请把给定的变更计划输出逐条解释清楚,标出高危动作并给出安全的执行顺序。
先把已知事实、合理假设和待核验信息分开;资料不足时写“待验证”,不要为了完整而猜测。
请按以下结构输出:
1. 按新增、修改、销毁重建和状态漂移四类整理变更条目
2. 逐条说明触发这次变更的字段,并核对是否与需求描述一致
3. 标出不可逆动作和会造成中断的资源,写出受影响的服务与用户
4. 指出计划中与本次需求无关的差异,判断是配置漂移还是误改
5. 给出执行顺序、审批点和执行窗口建议
6. 写出回滚方式与执行后的验证项,说明哪些动作无法回滚
输入变量:
- 变更计划输出({{plan_output}}):粘贴脱敏后的计划文本或变更摘要。
- 变更意图({{change_intent}}):说明这次改动想达成什么、对应哪个需求。
- 环境信息({{environment_facts}}):说明环境、依赖服务和可用维护窗口。
约束:保留原始上下文和限定条件;每个结论都说明依据;涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 只看摘要行会漏掉真正危险的字段,必须逐条读完整差异。
- 把计划和需求描述对照,出现无关资源就先问清楚再执行。
WHEN IT FITS
适用判断
适合这些情况
- 计划里出现销毁重建但看不出原因。
- 需要向审批人解释这次变更会动到什么。
- 变更涉及有状态资源且没有停机窗口。
换个做法更好
- 只改本地或临时环境:按普通改动处理即可。
- 要改数据库表结构:走数据库迁移安全计划。
- 状态与线上实际不符:先做只读刷新核对,再评审变更。
FAILURE MODES
常见翻车与修正
- 评审只看新增和修改的数量就放行。
要求逐条列出触发字段和可逆性判断,任何销毁重建条目都单独说明影响与确认人。
- 把配置漂移当成本次改动顺手一起应用了。
把与需求无关的差异单独列出,确认是回退线上手工改动还是误改,再决定是否纳入本次执行。
ACCEPTANCE
怎么判断输出合格
- 每条变更都能说明触发字段。
- 不可逆动作和中断风险单独列出。
- 执行顺序包含审批点和窗口建议。
- 回滚方式与不可回滚项都写明了。
SAFETY BOUNDARY
使用边界
- 销毁重建以及存储和数据库类变更必须人工确认,生产环境不要使用自动批准。
- 粘贴前移除账号标识、密钥、内网地址和证书内容。