AI 编程项目上线前检查清单

AI 编程工具可以很快生成一个看起来能跑的应用。Cursor、GitHub Copilot、Claude Code、Codex、ChatGPT、Windsurf、Replit Agent、Bolt、Lovable 都能帮助生成代码、修错误、改项目结构。

但上线不是“能跑就行”。真正的问题是：这些 AI 生成或 AI 修改的代码，是否已经被验证到可以交给用户。

先确认 AI 到底改了什么

检查之前，先记录这次 AI 参与的范围：

• 是新项目、修 bug、重构，还是复制了一段代码？
• agent 改了哪些文件？
• 是否碰到登录、支付、数据、部署配置或 SEO？
• 是否新增测试、数据库迁移或环境变量？

很多 AI 工具会为了完成任务顺手修改附近文件。一个很短的 prompt，最后可能变成很大的 patch。

先看 diff，再相信应用

打开 git diff 或编辑器里的 changed files，重点看：

• 新增依赖
• 被改写的配置
• 被删除的校验
• 写死的密钥、测试账号或 demo 值
• 假文案、占位页面、空泛营销文案
• 只复述实现逻辑的测试

配置、prompt、API 示例、README、release note 这类文本变化，可以用文本对比工具辅助检查。

跑生产构建，不只看 dev server

本地 dev server 能跑，不代表能部署。上线前要运行真实构建命令，比如 npm run build、next build、mvn package、flutter build 或部署平台实际执行的命令。

保留输出结果。失败时不要凭印象描述错误，要把准确报错留给下一轮调试。

检查密钥和部署配置

AI 工具可能编造变量名、把配置放错层级，或者把本该后端使用的值暴露到前端。发布前至少检查：

• .env、.env.example 和部署平台变量
• API key、service role key、webhook secret、测试账号
• callback URL、CORS、redirect、custom domain、runtime version
• NEXT_PUBLIC 或类似前端变量是否真的可以公开

这对 vibe coding 项目尤其重要，因为用户可能并不知道哪些值可以暴露。

测高风险流程

不要只点 happy path。上线前至少触发这些容易被 AI 改坏的路径：

• 登录、退出、过期会话、管理员入口
• 支付成功、失败、重试、webhook
• 空状态、表单错误、网络失败、404 页面
• 手机窄屏布局
• 公开页面的 title、description、canonical、sitemap、robots 和 OG 信息

如果项目没有自动化测试，就写一份手工测试记录，不要假装已经有覆盖。

留下交接记录

有用的 AI 编程发布记录应该很短，但要具体：

• 改了什么
• 哪些命令通过了
• 手工测试了什么
• 哪些没有测
• 还剩什么风险
• 如何回滚

这份记录可以给同事，也可以给下一轮 AI agent，避免每次都从头解释上下文。

使用上线检查清单

打开 AI 编程上线检查清单，选择代码来源、项目类型、技术栈、上线目标和高风险功能。工具会生成 Must、Should、Optional 检查项，并可复制 Markdown 报告。

首版不会扫描仓库，也不会调用大模型。这是刻意的：先把发布前验证动作做清楚，再考虑更强的自动化。