发链接之前先走一遍：vibe 项目的上线前检查清单实战

上线前夜最常见的死法：不是功能没做完，是没人走一遍清单

很多 vibe 项目的上线故事都是同一个剧本：周五晚上兴冲冲地把链接发到群里，周六早上发现注册流程在第三步卡死、支付页在手机上错位、官网的标题还是脚手架默认的“Create Next App”。问题很少是“核心功能没做完”，而是“没人完整地走过一遍”。vibe coding 把“做出东西”的速度提上去了，却没有自动补上“确认东西能用”的环节——而上线前检查清单，就是补这个环节最便宜的工具。它不是什么方法论，就是一张表：上线之前，逐项打勾，任何一项没通过都不发。这篇文章给出一张可以直接抄走的清单，按“拦路项”和“加分项”分层，并讲清楚每一项在 vibe 项目里最容易踩的坑。文中的示例项目“记账小助手”纯属虚构，数字和流程都是为了讲清楚而编的例子，不是任何真实产品的记录。

先定一条铁律：清单分两层，拦路项不过、绝不上线。拦路项是指“一旦出问题，用户立刻受损、或者你立刻要熬夜修”的那些：注册登录、核心流程、支付、数据安全、备份回滚。加分项是指“没有它也能上线，但有了体验更好”的那些：SEO、分享图、埋点、帮助文档。很多团队的上线事故，根源都是把两层混在一起谈——有人觉得分享图没做好就拖着不发，也有人觉得支付没测通“先上线再说”。分层的好处是决策变简单了：拦路项是红线，加分项可以排期，红线面前没有“差不多”。

第一层拦路项：账号、核心流程与支付

账号体系先测三条路：注册、登录、找回密码。每条路都要在真实环境里用真实邮箱和真实手机走一遍，而不是只在本地用测试账号点一点。vibe 项目特别容易在这里翻车，因为 AI 生成的登录流程常常在 happy path 上很顺，却在边界上全是洞：邮箱验证链接过期时间是不是太短、密码重置链接点两次会不会报错、第三方登录回调失败时用户会不会卡在一个白屏上。找回密码尤其要测，因为它平时没人用、上线后第一个丢密码的用户就会撞上。还有一个常被忽略的点：注销账号的入口有没有、注销后数据是不是真的按承诺处理了——这既是合规问题，也是用户信任问题。

核心流程要按“新用户第一次用”的视角重走一遍，而不是按开发者“我知道怎么点”的视角。找一个没用过这个产品的人，给他任务、不给他提示，看他能不能在五分钟内完成最核心的一件事。比如记账小助手的核心流程就是“记一笔、看报表、改一笔”，如果新用户在“记一笔”这一步就要先看教程，流程就有问题。vibe 生成的界面常常“看起来都对”，但步骤之间缺了必要的反馈：点了保存有没有提示、网络慢的时候按钮会不会重复提交、失败了有没有一句人话而不是一串错误码。这些反馈缺失在演示时看不出来，在真实用户手里就是流失。

支付是拦路项里最严的一层，测试顺序应该是：沙箱走通、真实小额走通、退款走通、异常走通。沙箱只能证明代码逻辑没错，真实小额（比如 1 元）才能证明商户配置、回调地址、签名密钥都没配错。退款流程必须在上线前亲自走一遍，因为退款是用户最容易动怒的场景，客服现找流程就来不及了。异常场景至少要覆盖三种：用户付了钱但回调丢了怎么办、用户重复支付怎么办、支付页面中途关闭订单状态是什么。每一项都要有明确的答案和负责人，不能是“到时候再看”。如果你的项目根本不收钱，这一层可以直接划掉，但要在清单上写明“本项目无支付功能”，而不是留空——留空和“已确认不需要”是两回事，复查的人分不出来。

第二层拦路项：数据、性能与回滚

数据安全先查三处：备份、权限、敏感信息。备份要验证“能恢复”，而不只是“有备份任务在跑”——上线前做一次恢复演练，从备份里把数据恢复到一个临时环境，确认数据是对的、应用能跑起来。权限要查“越权”：A 用户能不能通过改 URL 参数看到 B 用户的数据，这是 AI 生成代码里最高频的漏洞之一，测法很简单，拿两个账号交叉访问对方的资源链接。敏感信息要扫一遍代码和日志：API 密钥、数据库密码有没有进仓库，日志里有没有把用户密码、token 原样打出来。vibe 项目尤其要查这一项，因为 AI 有时会为了“跑通演示”把密钥写进示例配置，开发者一高兴就提交了。

性能检查不用搞得很重，但底线要有：首屏在 4G 弱网下能不能在 3 秒内出现主要内容、核心接口在 100 个并发下会不会超时、图片和静态资源有没有压缩和缓存。测法可以很土：手机开节流模式刷一遍、找十个朋友同时点一遍、看一眼最大的三张图有没有超过 500KB。vibe 项目常见的性能坑是“AI 为了好看堆了很多动效和大图”，首屏看起来很炫、加载起来很慢。上线前把首屏资源清单拉出来，超过预算的先砍掉或懒加载，别等用户用流量打开时才后悔。

回滚方案是整张清单里最容易被跳过、也最救命的一项。上线前就要写好：如果新版本出问题，用什么命令、几分钟内能回到上一个版本、数据库的迁移能不能逆向、回滚后用户正在进行的操作会不会丢。更重要的是，回滚方案要演练过一次，而不是只写在文档里。很多团队第一次演练回滚就是在真实事故里，那时候手忙脚乱、每一步都要现查文档。演练的方法很简单：先在预发布环境故意上一个坏版本，再按文档把它滚回去，计时、记录卡住的地方、把文档改到能照着做。这一项通过的标准是“凌晨三点、半睡半醒的人也能照着文档滚回去”。

加分项：SEO、分享、埋点与帮助文档

拦路项全过之后，再看加分项。SEO 至少要做到：每个公开页面有独立的标题和描述、没有把测试环境的 noindex 带到生产、sitemap 能正常访问。分享图要单独检查：把链接发到微信、X、Slack 里各看一次，标题、描述、配图是不是你想让别人看到的样子——很多项目的分享图是脚手架默认图，或者干脆是空白，这在传播上等于白白浪费一次曝光。埋点不用一开始就全量上，但核心转化漏斗要有：注册、核心动作、付费，这三个事件的埋点要在上线前验证上报正常，否则上线后两周你都不知道用户到底卡在哪一步。

帮助文档和客服入口是加分项里性价比最高的两项。帮助文档不用写成长篇，五个最常见问题就够了：怎么注册、怎么用核心功能、怎么取消、怎么退款、出了问题找谁。每个问题给一句话答案加一张截图，比写十页手册有用。客服入口要让用户在出问题的地方就能找到：页面底部、设置页、报错提示里，至少要有一个能联系到人的方式——可以是邮箱、表单，或者一个群链接，但不能是“请自行搜索”。vibe 项目的用户往往是第一批吃螃蟹的人，他们遇到问题时愿意反馈，前提是反馈的路够短。

清单怎么用：谁打勾、谁复核、卡住怎么办

清单本身只是一张表，真正让它起作用的是三条规矩。第一，每项都要有“打勾的人”和“复核的人”，不能是同一个人。vibe 项目常常是一个人从头做到尾，自己打勾自己复核等于没复核——哪怕是找朋友帮忙点一遍，也比自己闭着眼睛打勾强。第二，每项的通过标准要写成“可验证的句子”，而不是“感觉没问题”。比如“注册流程通过”要写成“用新邮箱注册、验证、登录、找回密码四步全部走通，且每个步骤都有明确的成功或失败提示”；“性能通过”要写成“4G 节流下首屏 3 秒内出现主要内容”。标准越具体，复核时扯皮越少。第三，卡住的项要写进“上线后待办”，标上负责人和日期，而不是在清单上划掉假装通过。诚实地带着已知问题上线，比假装没有问题上线要安全得多——因为已知问题可以被监控、被优先修复，未知问题只能等用户投诉。

最后给一个可以直接用的节奏：上线前三天冻结新功能，只修拦路项；上线前一天完整走一遍清单，拦路项不过就推迟上线，不要为了赶一个“吉日”硬上；上线当天留出半天只做监控和响应，不安排新需求；上线后三天每天复查一次待办，把加分项按优先级补齐。这个节奏对 vibe 项目尤其重要，因为 AI 让“加功能”变得太容易了——没有冻结期，上线前夜永远会有人想“再加一个小功能”，而每一个小功能都可能带进一个新的拦路问题。清单的意义，最终不是那张表，而是“上线前停下来、认真看一遍”的那个动作。

真实案例复盘：三次上线事故本来都可以用清单拦住

讲三个虚构但典型的事故，看看清单是在哪一步起作用的。第一个是注册事故：某个记账小助手上线当天，新用户注册后收不到验证邮件，原因是开发环境用的测试邮件服务商，上线时忘记切换成正式服务商的密钥和域名。清单里的“账号体系”那一项要求用真实邮箱在真实环境走一遍——如果走过，第一次注册就会发现邮件根本没发出来，而不是等用户投诉才发现。复盘时最常见的借口是“本地明明是好的”，而清单要的就是“本地好不算好，生产环境走通才算好”。环境差异是上线事故的第一大来源，清单的价值就在于强迫你在生产环境验证，而不是在开发环境自我安慰。

第二个是支付事故：某项目上线第一天就收到一笔真实付款，但订单状态一直显示“待支付”，原因是支付回调地址配成了内网地址，支付平台根本访问不到。清单里的“支付”那一项要求真实小额走通、回调丢了怎么办有明确答案——如果走过，回调问题在上线前就会暴露。更值得注意的是，这个事故的修复成本远高于预防成本：已经付款的用户要一个个手动对账、改状态、发道歉，客服压力和信任损失加起来，比上线前多花半小时测试贵得多。支付类问题还有一个特点：它们很少在上线当天全部暴露，往往是用户量上来后才集中爆发，那时候再修，数据已经乱了。

第三个是回滚事故：某项目上线新版本后发现核心报表算错了数字，团队想回滚，却发现数据库迁移没有逆向脚本，旧版本代码也已经被覆盖，只能硬着头皮在新版本上修。清单里的“回滚方案”那一项要求演练过一次——如果演练过，团队会提前发现迁移不可逆，要么补逆向脚本、要么改成分步迁移。回滚事故最伤人的地方不是故障本身，而是故障发生后“想退退不回去”的绝望感。很多团队事后总结时都会说“早知道就先演练一次”，而清单就是把这句“早知道”提前到上线前说出来的工具。

清单的维护：上线后它不是废纸，而是下一轮的起点

清单不是一次性用品，上线后要做三件事。第一，把上线当天实际遇到的问题补进清单：凡是上线后才发现、但本可以提前发现的问题，都要在清单里加上一项，并写清楚验证方法。这样清单会越用越贴合你这个项目的实际情况，而不是一份从网上抄来的通用表。第二，把“上线后待办”按时清掉：上线时带着已知问题上线是正常的，但已知问题如果三个月都不处理，它就会从“已知问题”变成“产品的默认行为”，再想改就难了。建议每周复查一次待办，按“影响用户数 × 修复成本”排序，先清影响大、成本小的。第三，定期给清单做减法：如果某项连续三次上线都一次通过、且验证成本很高，可以考虑把它降级为抽查项；如果某项每次都要返工，说明它对应的环节本身有问题，要修流程而不是反复打勾。

对一个人的 vibe 项目，清单的执行方式可以轻量化，但不能省略。你可以把清单放在项目的 README 里或者 issue 模板里，每次上线前复制一份、逐项打勾、把结果贴在发布记录里。一个人做复核确实难，但有一个折中的办法：把“复核”外包给真实用户——上线前找两三个目标用户，给他们任务、不给提示，让他们完整走一遍核心流程，录屏或者口头反馈卡住的地方。这比自己打勾可靠得多，因为开发者对自己的产品有“知道怎么点”的盲区，而新用户没有。记住清单的最终目的：不是为了让上线仪式感更强，而是为了让“上线”这个动作，从一次赌博变成一次验证。

最后再强调一次清单的使用心态：清单不是为了证明“我们准备好了”，而是为了找出“我们还没准备好的地方”。打勾的时候如果某一项让你犹豫，犹豫本身就是信号——停下来，把犹豫的原因写下来，变成一项待办或者一次验证，而不是凭感觉打勾过去。上线前夜最危险的一句话不是“这个有问题”，而是“应该没问题吧”。清单存在的意义，就是把“应该”变成“确认过”。