AI 编程工具把写代码的速度拉得很快，但上线前真正决定质量的，往往不是“它写得多快”，而是你有没有做最后一轮检查。Cursor、Claude Code、Codex 都可以帮你改代码、跑命令、解释结果，但发布按钮最好不要交给惯性。
这篇文章给一套通用的 AI 编程上线检查清单。它和 AI编程测试自动化 不完全一样：测试自动化偏“怎么让工具自己跑检查”，这篇偏“发布前最后一道关卡”，更适合每次合并、部署、改主题或上线功能前使用。
如果你正在系统化使用 AI 编程工具，可以先看 AI编程工具专题 和 AI智能体与自动化专题。工具越像 Agent，越需要明确的上线门禁。
第一步：确认这次到底改了什么
上线检查的第一句话不是“测试通过了吗”，而是“这次改动范围是什么”。AI 编程最常见的问题，是顺手改了不该改的地方。
发布前先让工具输出一份变更说明：
请总结本次改动：
- 改了哪些文件；
- 每个文件解决什么问题；
- 是否有超出原需求的修改；
- 是否影响接口、数据结构、样式或配置。你要重点看两类异常：一类是文件数量突然变多，另一类是修改进入了配置、权限、数据库、支付、登录等高风险区域。哪怕代码看起来没报错，也应该停下来复核。
第二步：审 diff，不要只听总结
AI 给的总结可以参考，但不能替代 diff。发布前至少看一遍实际差异，尤其是删除行、条件判断、默认值和配置文件。
你可以让 AI 先帮你审：
请以代码审查方式检查当前 diff。
只列可能影响上线的真实风险：
- 逻辑错误；
- 边界条件；
- 安全问题；
- 配置变更；
- 缺少测试；
- 回滚难点。然后你自己再抽查关键文件。站内的 Claude Code 代码审查 和 AI代码审查流程 都讲过类似原则：AI 可以先筛风险，但最终要看它有没有遗漏和误判。
第三步：测试命令要和改动类型匹配
很多人让 AI 跑一句测试就放心了，但测试命令是否匹配改动类型更重要。
- 改样式：要看页面预览、移动端布局和关键组件复用场景。
- 改接口：要跑接口测试、错误输入、权限场景和返回结构。
- 改数据：要看迁移、备份、回滚和历史数据兼容。
- 改脚本：要跑 dry-run 或小样本，确认不会批量误操作。
- 改发布流程：要检查标题、摘要、图片、链接、meta、状态和权限。
如果项目没有自动测试，也不要放弃验证。可以让 AI 根据这次改动生成一组手动检查步骤，再逐条执行。对网站和前端页面来说，浏览器预览往往比命令输出更能发现问题。
第四步：页面和真实流程必须打开看
AI 编程工具很容易在命令行里显得一切正常，但用户看到的是页面、表单、文章、按钮和流程。上线前至少打开关键路径看一次。
例如：
- 新增页面是否能访问；
- 移动端是否遮挡、换行或溢出；
- 按钮是否能点击；
- 表单提交后是否有正确提示；
- SEO 标题、描述、图片 alt 是否正常；
- 错误状态是否有兜底文案。
老达AI博客的发文流程里，发布后会检查标题、摘要、关键词、特色图 alt、正文 h1 和站内链接数量。这类检查看起来琐碎，但能挡住很多“代码没错、页面不对”的问题。可以延伸阅读 WordPress发布后检查自动化。
第五步：上线前先准备回滚方案
发布前最容易被忽略的是回滚。很多 AI 生成的改动一旦合并，文件之间互相牵连，出问题时很难快速撤回。
上线前至少确认三件事：
- 代码能回退：知道本次改动对应哪个提交、分支或补丁。
- 数据能恢复：涉及数据库、批量脚本、内容更新时要有备份或 dry-run。
- 配置能撤销：API Key、环境变量、权限开关和定时任务要有记录。
如果你还没有建立这套意识，可以先看 AI编程版本管理。AI 改代码越快，越要把“能不能退回去”当成上线条件。
第六步：让 AI 写一份发布备注
发布备注不是形式主义，它能逼你确认本次变更是否可解释。尤其是多人协作或未来要回看问题时，一段清楚的发布备注很有价值。
可以要求 AI 输出：
请生成发布备注：
- 本次上线解决的问题；
- 主要改动；
- 已执行的验证；
- 未覆盖的风险；
- 回滚方式；
- 上线后需要观察的指标。这里不要让 AI 写空泛总结。没有跑过的测试不要写“已验证”，不确定的风险要明确保留。AI 交付最怕把不确定包装成确定。
一份可复制的上线检查清单
每次上线前，可以直接按下面这张清单走：
- 需求范围已确认，没有顺手改无关功能；
- diff 已审查，重点看删除、条件、默认值、配置和权限；
- 测试命令或手动验证与改动类型匹配；
- 关键页面或关键流程已经实际打开检查；
- 移动端、错误状态、空数据状态没有明显问题；
- 涉及数据、配置、定时任务的改动有回滚方案；
- 发布备注写清楚验证结果和剩余风险；
- 上线后有观察点，比如错误日志、表单提交、转化、页面访问或用户反馈。
这套清单不复杂，但很适合给 Cursor、Claude Code、Codex 这类工具做统一门槛。不同工具可以有不同命令，但发布前的判断逻辑应该一致。
老达点评：AI 编程越快，发布越要慢半拍
AI 编程最大的诱惑，是让你觉得“既然它已经改完并解释清楚了，那就可以上线”。但真实项目里，很多事故不是因为代码完全不能跑，而是因为范围扩大、边界没测、页面没看、回滚没准备。
所以我更建议把 AI 编程分成两种速度：写代码可以快，发布要慢半拍。让工具尽快给你方案、补丁和测试结果，但最后一道关卡要回到工程常识：看 diff、跑验证、开页面、备回滚、留备注。
当你把这套上线检查固定下来，AI 编程工具才不会只是“写得快”，而是能真的进入可交付、可维护的工作流。
