vibe 项目上线第一周：监控、日志与回滚，一份独立开发者的值班手册

上线不是终点，是值班的开始

vibe coding 把「想法到上线」压缩到了一周，但它没告诉你后半句：上线之后的那一周，决定了这个项目是活还是死。第一波用户是最宽容的——他们愿意忍受 bug；也是流失最快的——一个白屏、一次支付失败，就足够他们永远不回来。

独立开发者没有 SRE 团队，没有 on-call 轮班，on-call 的人就是你，睡觉也在 on-call。所以你需要的不是大公司的可观测性平台，而是一套「上线前夜 2 小时配好、第一周每天 15 分钟巡检」的值班手册。下面就是。

上线前夜：四个东西，缺一不可

1. 错误追踪（Sentry / GlitchTip）。这是优先级最高的。console.error 只在你开着终端时有用，用户遇到白屏时你正在睡觉。Sentry 的免费额度对 vibe 项目绰绰有余，配好之后第一件事是关掉噪音：把已知的、无害的报错（比如浏览器插件注入的异常）过滤掉，否则第一周你就会被 2000 条重复告警淹没，开始已读乱回——那和没装一样。让 AI 帮你写 Sentry 的 beforeSend 过滤规则，它干这个很在行。

2. 可用性监控（Uptime Kuma / Better Stack）。每 1 分钟 ping 一次你的首页和核心 API，挂了就发通知到你的手机。Uptime Kuma 可以自己搭（一个 Docker 容器），Better Stack 有免费档。关键细节：监控要从外部看，别在你自己的服务器上 curl 自己——服务器活着不代表用户打得开。

3. 结构化日志。AI 生成的代码最爱 console.log('here1') 这种调试遗产，上线前让 agent 做一次「日志大扫除」：删掉调试 log，关键路径（注册、支付、核心操作）换成带 userId、requestId、时间戳的结构化日志。第一周定位问题时，你会感谢这个 30 分钟的投入——没有 requestId 的日志，就是一堆互相不认识的句子。

4. 回滚预案（写下来，不是想想）。Vercel/Netlify 的一键回滚、Docker 镜像打 tag 保留上一个版本、数据库迁移脚本准备好 down。把回滚步骤写成三行字贴在项目 README 里：1. vercel rollback / 2. 恢复 DB 快照 / 3. 在状态页公告。凌晨 3 点出事故时，你的大脑不值得信任，纸值得信任。

第一周：每天 15 分钟的巡检清单

把下面这张清单设为每天的第一个任务（或者让 agent 替你跑，人工看结果）：

① 错误数有没有突增。打开 Sentry 看过去 24 小时：新出现的错误类型有几个？同一个错误影响了多少用户？规则很简单——新错误类型当天修，老错误看影响面。第一周不要重构，不要加功能，修线上 bug 是唯一的优先级。

② 核心链路通不通。注册→核心功能→支付/分享，随手点一遍。AI 生成的项目有个经典死法：开发者自己天天用 chrome 桌面版测，用户用 Safari 手机版打开直接白屏。第一周借朋友的手机点一遍，比你写 100 个单测管用。

③ 用户说了什么。在产品里放一个最显眼的反馈入口（别藏在三级菜单里），每天看一遍。第一周的用户反馈含金量极高：他们替你做了免费 QA。回复每一条——不是为了客服 KPI，而是因为第一个给你提 bug 的用户，是你最便宜的共建者，别让他觉得自己在对空气说话。

④ 账单有没有异常。第一周最容易爆的不是 bug，是账单：AI 写的轮询逻辑 5 秒打一次付费 API、某个大文件被反复下载烧掉 CDN 流量。每天看一眼云账单和 API 用量，设置好 spending limit 和告警。Replit 最近刚宣布 11 月起部署涨价、数据库存储开始收费——基础设施的钱，永远比你想象的走得快。

一个反直觉的建议：第一周别看数据看板

最后说个反直觉的。第一周别天天盯着 UV、转化率看板——样本量太小，任何波动都是噪音，你会忍不住为了「把曲线拉起来」去改产品，而第一周的产品最不需要的就是乱改。看板可以搭（Plausible 轻量够用），但第一周只看两类数据：错误和反馈。错误告诉你产品哪里 broken，反馈告诉你用户哪里 confused，这两件事修好了，曲线自己会走。

等第一周过去，错误收敛了、回滚一次都没用上（最好是这样）、你开始收到「什么时候加 XX 功能」的留言而不是「打不开了」——恭喜，这个项目活下来了。这时候再去看增长数据，再去想第二周做什么。

vibe coding 让你一个人干了一个团队的活，上线第一周就让你一个人值一个团队的班。好消息是：团队要开会，你不用；团队要排班，你只需要每天 15 分钟。把手册配好，然后去睡觉——让告警决定你什么时候起床，而不是焦虑。