AI 做的产品上线后怎么监控报错？2026 实操指南

你用 Claude Code 或 Cursor 花两天做出一个网站，部署上线，朋友圈一发——然后呢？大部分人到这一步就停了。可真正的问题恰恰从上线那一刻才开始：用户点注册按钮报错、页面在某台安卓机上白屏、服务器半夜挂了六小时你第二天才发现。这些事故没有人会主动告诉你，用户只会默默关掉页面再也不来。这篇文章讲的就是「上线之后」的事：怎么给 AI 做出来的产品搭一套线上报错监控，让机器 24 小时替你盯着，出问题第一时间推到你手机上。全程有免费方案，不写代码也能配完。

为什么 AI 做的产品更需要监控

传统开发里代码是你一行行敲的，哪里脆弱心里有数。AI 生成的代码不一样：它能跑通、结构也整齐，但你并没有真正读完每一个分支。边界情况——空数据、请求超时、并发写入、第三方接口返回了意料之外的格式——AI 常常顺手写个乐观路径就过去了。这类问题在本地开发和自测时几乎不会触发，只有真实用户、真实网络、真实数据撞上去才会炸。

• 沉默失败：前端 JavaScript 报错不会让服务器挂掉，你的站点看起来「正常在线」，实际上按钮已经点不动了。
• 你不是用户：你用桌面版 Chrome 测试，用户可能在微信内置浏览器、老版本 iOS Safari、或者信号很差的地铁里打开。
• 用户不反馈：遇到报错还愿意主动来告诉你的是极少数，绝大多数人直接关页面走人，你连流失都察觉不到。
• 改一处崩一处：让 AI 加新功能时，它可能顺手改坏了旧逻辑（回归 Bug）。没有监控，你要等下一个用户投诉才知道。

监控分三层，先搞清楚你缺哪一层

「监控」是个被说烂的词，落到个人开发者身上其实只有三层，各回答一个不同的问题。先对照下表看看自己现在处于哪一层：

新手最常见的状态是三层全缺，其次是只做了第一层——配了个宕机监控就以为万事大吉。但现实中真正吃掉转化的往往不是「站挂了」，而是「站好好的，某个按钮悄悄坏了三周」。这类问题只有第二层能抓到，所以如果只让你配一样，配 Sentry。

第一层：可用性监控，10 分钟配完

原理很简单：找一个外部服务，每隔几分钟访问一次你的网址，返回不是 200 就给你发通知。最省事的是 UptimeRobot，注册后填网址就能用，免费版可监控 50 个站点、检测间隔 5 分钟，告警支持邮件等渠道。注意一个 2026 年的变化：UptimeRobot 的免费版已限定为个人非商业用途，商业项目需要升级付费套餐。

1. 1注册账号后点 Add New Monitor，类型选 HTTPS。
2. 2填入你的线上域名，检测间隔按免费版默认的 5 分钟即可。
3. 3配置告警联系人：邮箱最基础，建议再接一个能立刻看到的渠道（如 Telegram 或企业微信机器人）。
4. 4关键一步：监控要指向真实业务页面，别只监控首页。首页是静态的，数据库挂了它照样返回 200。

如果你已经有一台自己的服务器，更推荐自建 Uptime Kuma——开源（MIT 协议）、GitHub 上已超过 8 万星、资源占用极低，1 核 2G 的小 VPS 就能跑，而且原生支持 Telegram、企业微信、钉钉、邮件等几十种告警方式。Docker 一条命令启动：

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

# 启动后浏览器打开 http://<你的服务器IP>:3001 完成初始化

第二层：错误监控，让报错自己找上门（Sentry）

Sentry 是这个领域的事实标准，它做的事是：在你的前端和后端埋一个 SDK，一旦有异常抛出，就把完整的错误堆栈、用户浏览器/系统、出错前用户点了什么（面包屑）、甚至出错时的代码上下文全部打包上报到后台，并按「同一个错误」聚合去重。你打开后台看到的不是一堆日志，而是一张按影响人数排序的问题清单。

如果你的项目是 Next.js（AI 生成的网站里最常见的技术栈之一），接入只要一条命令。向导会引导你登录、选择项目，然后自动改好配置：

npx @sentry/wizard@latest -i nextjs

向导会为三个运行环境分别生成配置文件（客户端 client、服务端 server、边缘运行时 edge），因为 Next.js 这三处的错误捕获机制不同。目前 @sentry/nextjs 支持的最低 Next.js 版本是 13.2.0。跑完之后建议手动做两件事，能省掉大量噪音和后续排查时间：

• 在三个配置文件里加上 enabled: process.env.NODE_ENV === 'production'，避免本地开发时的报错疯狂上报，白白吃掉免费额度。
• 在用户登录成功后调用 Sentry.setUser() 设置用户上下文，这样每条报错都能对应到具体用户，排查时能直接问「是不是你刚才注册失败了」。
• 在 app/error.tsx 里把 error.digest 关联上报，方便把用户截图里的错误码和后台记录对上号。
• 上线后立刻手动触发一次测试报错，确认链路真的通了——很多人配完从没验证过，真出事时才发现 DSN 填错了。

Sentry 的计费按事件量走，个人项目起步阶段免费版基本够用：

让 AI 直接读线上报错：接入 Sentry MCP

这一步是 2026 年才真正成熟的玩法，也是 AI 编程和监控结合得最漂亮的地方。Sentry 官方提供了远程 MCP 服务器，把它接到 Claude Code、Cursor 这类 AI 编程工具上之后，AI 就能直接查询你的线上报错数据——拉取 issue 列表、读堆栈、看面包屑、分析性能追踪。你不用再手动复制粘贴错误信息，直接对着 AI 说「看下 Sentry 里今天最高频的那个错，找出原因并修掉」，它会自己去读真实的生产环境信号，然后动手改代码。

官方托管在 https://mcp.sentry.dev/mcp，是远程服务，不需要你自己部署。以 Claude Code 为例：

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# 添加后首次调用会走浏览器 OAuth 授权，登录你的 Sentry 账号即可
# 验证：claude mcp list

接通之后，最实用的三句话：「Sentry 里影响用户数最多的问题是哪个」「把这个 issue 的堆栈拉出来，定位到具体是哪个文件哪一行」「结合这段代码分析根因，给出修复方案」。这就形成了一个闭环——AI 写代码、上线、Sentry 抓报错、AI 读报错再修代码。这也是为什么监控对 vibe coding 特别关键：你读不懂全部代码没关系，但你必须让 AI 拿得到真实的失败信号，否则它只能猜。

不想用 Sentry 云服务？自建与替代方案

有两类情况会让你想避开 Sentry 云版：数据不方便出境，或者不想按量付费。首选替代是 GlitchTip——轻量级开源错误追踪，最大的优点是兼容 Sentry 的 SDK，也就是说客户端代码基本不用改，只把上报地址（DSN）换成你自建的实例即可，迁移成本极低。它比自建 Sentry 轻得多：官方 Sentry 自托管版本组件多、吃资源，个人项目上属于杀鸡用牛刀。

第三层：日志，出事时的黑匣子

前两层告诉你「出事了」，日志回答「当时到底发生了什么」。如果你部署在 Vercel、Netlify 这类平台，控制台自带实时日志面板，直接看即可。如果是自己的服务器，记住这几条最常用的命令，出事时能立刻救场：

# Docker 部署：看最近 200 行并持续跟踪
docker logs -f --tail 200 <容器名>

# PM2 部署
pm2 logs --lines 200

# systemd 服务：按时间过滤
journalctl -u <服务名> --since "10 min ago" -f

# 磁盘满是最常见的「玄学宕机」原因，先查这个
df -h

上线第一周的监控清单

• 配好可用性监控，并且指向的是真实业务页面而不是静态首页。
• 接入 Sentry（或 GlitchTip），前端后端都要埋，只埋一半等于半瞎。
• 手动制造一次报错，确认告警真的推到了你手机上。
• 把告警接到你每天真的会看的渠道：邮件很容易被忽略，Telegram / 企业微信 / 钉钉机器人更靠谱。
• 在 Sentry 里设置用量告警，避免免费额度被噪音打满后静默失明。
• 关掉开发环境上报，并过滤掉浏览器插件引起的无关报错。
• 接入 Sentry MCP，让 AI 编程工具能直接读到线上报错。
• 给自己定个习惯：每周固定看一次错误清单，按影响用户数从高到低修。

把监控配上，你和「随手做个玩具」的分界线就跨过去了——因为你终于能看见真实用户在你的产品里遭遇了什么。这也是 AI 编程时代最容易被忽略的一环：生成代码的门槛被推到了极低，但把一个产品稳定交付给真实用户的能力，依然是稀缺的。如果你想系统补上部署、测试、监控、安全这条完整的交付链路，欢迎来 IMAI 看看我们的体系化实战课程。