封面图
接着这个系列往下，讲一个东西上线之后马上要用的模块：监控。一句话说清它干嘛的，就是让你在出问题的第一时间知道，不是干等着用户来报。它也是现成的，不用自己搭一套日志和报警系统。
有些毛病，只有上线才露头
我现在写代码基本靠 AI 往前推，快是真快，但有一类问题它特别容易埋下去。发新版本的时候，引入一个新的 SDK，跟原来的东西命名撞了，或者某个依赖悄悄冲突了。在自己电脑上跑，一切正常；打包构建，也不报错，绿灯放行。它就那么藏着，非要等真上线、真有人走到那条特定路径上，才当场炸。
更闹心的是缓存。东西其实已经出问题了，页面缓存还兜着旧版本，你刷新看也是旧的，问题就这么被盖住。
这类毛病的共同点是，构建拦不住，本地复现不出，只有线上会暴露。没装监控就只能等用户来告诉你，前提还是他愿意开口，不是默默关掉走人。
监控和埋点，是两件事
一拨是看人：谁来了、点了啥、走到哪一步不玩了，叫埋点。另一拨是看系统：接口报没报错、崩没崩、慢不慢，叫监控。常被搅在一起，但盯的东西不一样。
看人那摊，对现在的我优先级不高。统共没几个用户，漏斗里每格就那么两三个人，看不出啥规律，先接上放着。这一篇讲看系统，上线第一天就用得上。
我是怎么接的
监控听着唬人，不用一上来就搞一套完整的。
我面向用户的东西有两处，一个网站，一个 Mac 客户端，都用一个现成工具一把抓。行为、报错、连 App 直接闪退的硬崩它都能收。能抓硬崩是因为 SDK 内嵌了崩溃采集（基于微软开源的 PLCrashReporter，fork 后自己维护的），不只是 JS 那种软报错，真闪退也能捞回来，还能上传 dSYM 把堆栈翻成可读的代码行。网站那边更直接：报错跟会话回放同一个 session，点开看他在崩之前点了啥、填了啥。
后端没接第三方。部署平台自带可观测面板，接口的报错、快慢、超时都在上面，随部署长在那儿。
有个我自己踩过的小提醒：别一上来啥都埋，只盯那几个要回答的问题（崩没、慢没、关键动作成没成），埋多了又乱又拖页面；涉及用户内容的地方也别塞。
让 agent 自己去查
这个模块还有个用法我近期才琢磨过来。
项目设置里能生成一个 Personal API key。把这个 key 给 agent，它就能自己调 API 去埋事件、查数据，不用你打开后台看板一步步点。
关键在部署之后。正常流程 agent 写完代码、部署上去，就没法往下走了。到底部署对不对、埋点活了没、bug 真修掉没，它看不见，一问就是好了。有了 key 之后，它部署完自己去问监控后台：刚才那个事件到了吗？那几个报错还在报吗？查到了、不报了，它才告诉你好了。这是在让事情合上闭环。
更有甚者，“GitHub issue 报 bug → agent 自动改代码部署 → agent 自动查监控确认修好 → agent 自动关 issue”，原理上跑得通的。
要不要上更专业的
有人会问，要不要上个 Sentry 这种专门做报错的。别急着上。
报错分组、主动报警、按版本看崩溃率，Sentry 打磨了十年，工作流深得多。跟手上通用工具比，差别在深度，不在能不能。等你报错多到肉眼分不过来了，或手上工具定位不到 bug 了，才值得多养一个。我自己特意没上，因为东西碰用户语音，多送一家第三方可能夹着用户内容的崩溃报告，跟隐私初衷拧着。
接上监控这一层，你就从"用户不吭声我啥都不知道"，变成"出问题第一个知道，改完 agent 自己去确认真修好"。上线不算把事做完，接上它，才算能盯着自己的东西跑起来。