编程开发 编辑复核
工程发布说明
把代码变更整理成影响模块、迁移、配置、监控和回滚信息，帮助值班和协作团队接手。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名发布工程师。请根据已合并的变更和部署文档生成工程发布说明，不要把未验证的配置或依赖写成已完成。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 版本、变更范围和影响服务
2. 数据库、环境变量、缓存和外部依赖变化
3. 发布前检查、发布步骤和健康检查
4. 监控指标、告警和负责人
5. 回滚条件、操作和发布后记录
输入变量：
- 变更列表（{{changes}}）：提供 commit、PR 或已批准变更摘要。
- 部署拓扑（{{topology}}）：说明服务、容器、代理和依赖。
- 已有检查（{{checks}}）：列出构建、测试、健康检查和人工验收。
- 回滚方式（{{rollback}}）：提供可用的旧 commit 或镜像。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 发布说明中的状态要与实际日志和命令结果一致。
- 敏感配置只写名称和来源，不粘贴值。
WHEN IT FITS
适用判断
适合这些情况
- 发布内容需要让工程团队知道细节：接口变化、配置项、依赖版本。
- 有需要其他团队配合的改动，得说清楚。
- 要留一份可追溯的记录，出问题时能对照。
换个做法更好
- 你要写给用户看：用《从提交记录整理发布说明》。
- 发布内容只有你自己关心：不需要正式说明。
- 改动细节还没定：等合并后再写。
FAILURE MODES
常见翻车与修正
- 只列了功能，没写接口和配置的变化。
工程读者关心的是会不会影响自己。要求单独列出接口变更、新增配置项、依赖版本和数据库变更。
- 需要其他团队配合的动作写得含糊。
要求把「需要谁在什么时间做什么」单独成段，并标注不做会有什么后果。
- 说明里带了内部服务地址或凭据示例。
要求内部地址用占位符，配置示例不含真实凭据，涉及密钥的只写变量名和获取方式。
ACCEPTANCE
怎么判断输出合格
- 接口、配置、依赖和数据库变更都单独列出。
- 需要他人配合的动作写明了对象、时间和后果。
- 没有内部地址和凭据泄露。
- 有回滚方式和回滚后的注意事项。
SAFETY BOUNDARY
使用边界
- 值班交接说明写漏了破坏性变更，会让接班人在故障时判断失误；变更项要和实际 diff 核对。
- 内部说明可能含系统弱点和临时绕过方案，流转范围要控制。