带着错误现场去破案：Sentry Seer

“用户那里报错，我这里一切正常。”这类 bug 最磨人。先把堆栈、版本和操作轨迹摆上桌，让 AI 提出可以验证的假设，再沿着证据追下去。

让错误堆栈、调用轨迹和代码一起进入诊断。 Seer 可以先分析根因，再把诊断上下文交给能修改和运行代码的 Agent，形成待验收 PR。

资料核对：2026-10-22；以下使用记录发布于 2026-07-23。

一次有记录的故障调查

使用者实践记录。 独立开发者 Dan Mindru 在 Sentry 的客座文章中，记录了一次 Next.js 故障经 Seer 诊断、交给 Cursor Cloud Agent 实现与验证、再生成 PR 的过程。他查看了补丁、单元测试更新与检查结果，并手动合并。完整实践记录

这是产品博客上的个人实践自述，附有操作和 PR 截图。文中积压问题的处理还包含其他 Agent 与人工调查，不能全部归因于 Seer 自动修复。

从现场走到补丁

线上错误与版本 → Seer 根因分析 → 修复 Agent 获得诊断上下文
              → 修改与运行检查 → PR → 人验收 → 观察同类错误

这给真实故障发起任务的构想补上了具体使用案例。原文也保留了一个涉及生产认证配置和时序、最终仍难以修复的问题：缺少复现环境时，诊断报告只是继续调查的起点。

小挑战：让一个根因假设接受盘问

从已有项目中选一个能复现的错误，准备脱敏后的堆栈、发生版本、操作步骤和相关源码。先让 AI 输出可能的原因、依据与验证步骤，再追问一句：“如果这个解释是对的，什么操作一定能再次触发它？” 这个练习可以手动提供材料，等需要自动收集和修复时，再考虑接入 Sentry 与执行任务的 Agent。

验证一个假设：用相同操作确认修复前会出错、修复后不再出现。正式部署后，继续观察各版本是否还有同类错误；本地结果只覆盖本次检查的操作路径。

把猜错的假设也记下来：它为什么看起来合理，又被哪条证据推翻。下次遇见相似堆栈，你就多了一条能少走的弯路。

这一局的成果：一个有运行证据支持的原因，或一条明确缺失的复现条件。

返回实践目录。