用prompt工程把一次线上部署回滚复盘成可复用的检查清单
背景：上周四晚上，我负责的一个文档站准备发新版本。改动很小，只是给文章列表加了个排序字段。我在本地跑通了所有测试，git push 了主分支，然后直接点了自动部署。结果上线后用户反馈文章顺序全乱了，有些页面直接 500。我第一反应是"排序逻辑写错了"，查了半天才发现根本不是代码问题，是部署环境问题。
这次复盘我想聊的不是怎么修 bug，而是我怎么靠一套对话式提问，把这次事故沉淀成了一套下次发版能直接用的检查清单。对经常写代码、经常发版的人来说，这个思路比具体某个 bug 的修复更有复用价值。
怎么做：当时我并没有急着改代码，而是先把这个事故当成一个"案例"来处理。我把线上日志、git 提交记录、部署脚本、还有 500 错误的时间点全部整理出来，然后对着这些事实反复问自己几个问题：这次改动真正影响到的数据流是哪一段？部署脚本和本地开发环境有哪些差异？新字段在线上数据库里是不是真的存在？这些问题问完之后，我发现排序错乱的根因是线上数据库里那个排序字段还没有默认值，NULL 被排到了最前面，表现就和"顺序全乱"一模一样。
遇到什么坑：第一个坑是我最开始被"排序逻辑写错了"这个直觉带偏了，花了一个多小时在业务代码里找问题，其实业务代码一行都没改错。第二个坑是本地环境太"干净"，本地库有默认值、构造数据齐全，线上库因为历史原因缺迁移，所以同样的代码跑出完全不同的结果。第三个坑是日志没有关键时间点对齐，我先看的错误码，没先看部署完成时间，导致排查方向一开始就反了。
关键结论和可复用方法：我把这套经验整理成一份发版前检查清单，每次发布前逐条过一遍。包含四条：第一，先确认线上数据库 schema 和迁移脚本一致，新字段要有默认值或先跑迁移；第二，部署脚本里的环境变量、代理、缓存配置要和本地对得上；第三，错误排查先对齐时间线，把"部署完成时刻"先圈出来，再对比前后的日志；第四，任何直觉判断都要用事实复核一遍，尤其是"这不可能是环境问题"这种话最容易翻车。
