上线翻车的根因就那几样：dev 与 prod 的 env 不一致、DNS 没传播完、缓存还在发旧资源、回滚没演练过。下面这些 Prompt 上线前把常见雷区先扫一遍，并给上线后 24 小时的结构化观测——避免一个回归被忽略整整一天。构建侧可配合Claude Code 执行 Prompt。
这套 Prompt 适合用在哪
- 新项目首次生产上线
- 带破坏性改动的大版本发布
- 自定义域名在 DNS 商之间迁移
- 托管平台切换
- 站点级基础设施变更（CDN、图床、DNS）
- 改动到计费、鉴权或任何承重模块的发布
1. 上线前清单
我的栈：{框架 + 托管}。请按此栈生成上线前清单：
- build（命令、env、输出目录）
- env 变量（必需、可选、Secret 存储指向）
- DNS、SSL（证书、跳转、www vs apex）
- sitemap、robots.txt、canonical
- analytics、错误追踪、真实用户监控
- AdSense / 变现状态（如适用）
- 合规页、隐私政策、cookie 横幅
≤25 项。每项标记"阻塞 / 非阻塞"。2. env 变量 diff
下面是 dev + prod 的 env 列表。请识别：
- prod 缺、代码却需要
- 值不匹配且可能弄崩（URL 指错环境、feature flag 反了）
- prod 有、代码已不用
- 在非 secret 文件里泄漏的密钥
{粘贴}
输出 4 个列表，每条带严重度。3. DNS 迁移计划
把域名 {domain} 从 {A} 迁到 {B}。
计划：
- 提前降 TTL 的步骤与时间（开始切换前 48h）
- 待重建的全部记录（A / AAAA / CNAME / MX / TXT / CAA）
- 切换时刻的操作顺序
- 回滚路径（以及允许回滚的 TTL 窗口）
- 验证命令（dig、nslookup、在线传播检查）4. 缓存失效计划
上线影响缓存的改动。
请列：
- 需要失效的层（CDN / 边缘 / 框架页面缓存 / 浏览器通过缓存头）
- 各层预计传播时间
- 哪些资源可继续缓存不动
- 各层验证命令
- 失效慢时的兜底（按 tag purge、给资源 URL 加版本号）5. 冒烟测试脚本
为 {站点} 生成上线后 10 步冒烟脚本：
1. 首页加载
2. 关键文章 / 详情页
3. sitemap.xml 合规且列出预期 URL
4. robots.txt 允许生产环境抓取
5. 404 页可用
6. 登录流程（若有）
7. API 健康检查
8. RSS feed（若有）
9. hreflang 正确互链
10. 移动布局首屏不破
每步：命令或 URL + 预期结果 + 失败如何记录。6. 可观测性检查
为 {栈}，请列上线前最低限度的可观测性：
- 错误追踪（前端 + 后端）
- 结构化日志
- 外部 uptime 监控
- 真实用户指标（Web Vitals、转化）
- 告警路由（落在哪、On-call 轮值）
按类别建议免费档工具，每个给 5 分钟内可配完的步骤。7. 回滚演练
为我的栈 {框架 + 托管}，设计回滚步骤：
- 代码回滚（git revert vs 提升上一次部署）
- DB 迁移回滚（only-forward？反向迁移？还是用 feature flag？）
- DNS 回滚（TTL 限制）
- 回滚后的缓存失效
文档具体命令。每步注明"谁有权限"。8. 上线后 24 小时监控计划
上线后 24 小时该盯什么、什么时候盯。
每个指标给出：
- 触发关注的阈值
- 命中阈值后的第 1 步动作
- 若第 1 步无效的升级路径
指标：错误率、p95 延迟、Search Console 错误、托管告警、AdSense / 变现状态、转化相对基线。9. 安全头审计
为 {site URL} 起一套安全头：
- Content-Security-Policy（默认严格 + analytics / AdSense / 字体的必要放行）
- Strict-Transport-Security
- X-Frame-Options / frame-ancestors
- Referrer-Policy
- Permissions-Policy
输出：{托管平台} 上的具体配置 + 验证命令（curl -I）。10. Hreflang / i18n 验证
我的站有 {N} 个语言：{清单}。每种页型（{首页、文章、分类}）请验证：
- hreflang 互链所有语言变体
- x-default 指向正确
- canonical 不跨语言
- sitemap 含各语言条目
- 每个语言挑 1 个示例 URL 抽查
输出验证清单 + 待手动测试的具体 URL。11. 状态页 + 故障沟通模板
为 {站点} 起 4 份状态页 / 故障沟通模板：
1. 调查中——故障前 10 分钟
2. 已定位——根因清楚、修复中
3. 监控中——修复已发布、观察稳定
4. 已解决——完整时间线、根因、后续动作
每个状态条 ≤200 字符 + 一封更长的邮件版。语气：冷静、事实、不指责。12. 故障复盘 Prompt
我们发生了一次故障：{一句话描述、持续时长、用户影响}。
请走结构化复盘：
1. 事件时间线（发现 → 缓解 → 解决）
2. 直接原因 vs 根因 vs 诱因
3. 响应中做对的事
4. 应改进的（流程、代码、可观测性）
5. 行动项，配负责人与截止日期
输出一份可填写的模板，方便我贴进复盘文档。容易踩的坑
- 上线前没做 env 变量 diff——一半的”本地能跑”问题死在这
- 跳过缓存失效计划——用户看到旧版本几个小时，工单跟着来
- 上线前没回滚演练——回滚第一次被调试是在故障当下
- 上线后只盯错误率——转化回归在错误日志风平浪静时悄悄持续
- i18n 站点忘了 hreflang 验证——Google 索引一个语言，其余全丢