AI 修 Bug，先把现场交给它

AI 编程最让人抓狂的时刻，不是它写不出代码，而是它开始修 Bug 以后。

你把报错贴给它。它改了一处。新的报错出现了。再改一处，原来能用的功能又坏了。来回几轮，代码看起来改了不少，问题却没离开原地。

原因往往很简单：AI 看到的只有错误结果，没有看到错误发生时的现场。

Sentry 加上 MCP 后，Codex 可以先去查项目里的错误记录，再决定改哪一段代码。它拿到的不只是“哪一行报错”，还可能包括发生时间、版本、堆栈、请求上下文、用户操作和调用链。信息完整一些，排查就不必全靠猜。

Sentry 是什么

Sentry 是一套错误追踪和性能监控平台。你在网页应用或服务里接入 SDK，程序出错时，Sentry 会收集事件并把它们整理成可以搜索、聚合和分析的问题记录。

它能帮你回答几类问题：

这个错误什么时候开始出现；
哪个版本受到影响；
错误发生在哪个接口或页面；
调用经过了哪些函数；
是一个用户遇到，还是大量用户都遇到了；
某次请求为什么变慢，性能卡在哪一段。

这些信息的前提是项目已经正确接入 SDK，并且按需要配置了版本、环境、用户和请求等上下文。 Sentry 不会凭空补出项目没有上报的数据。

MCP 补上的一块信息

MCP 可以理解成一套让 AI 连接外部工具的协议。 Sentry 提供了一个远程 MCP Server，Codex 通过它访问 Sentry 里的项目数据。

Sentry 的官方 MCP 页面列出的能力包括搜索错误、分析性能、处理问题、查询文档和管理项目。第一次连接会走 OAuth，需要登录自己的 Sentry 账号。也就是说，Codex 不是拿到一份神秘的“全局 Bug 数据”，而是在你的账号权限范围内查询。

连接时可以直接使用总地址：

https://mcp.sentry.dev/mcp

也可以把地址限定到某个组织或项目：

https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}

项目级地址更适合日常开发。范围小一些，Codex 看到的工具和数据也更聚焦，误查其他项目的机会少一点。

给 Codex 接上 Sentry

当前 Codex 支持 Streamable HTTP 类型的 MCP Server，也支持 OAuth 。官方配置方式有两种，命令行更直接：

codex mcp add sentry --url https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}

然后登录：

codex mcp login sentry

查看是否已经配置成功：

codex mcp list

也可以直接编辑 ~/.codex/config.toml：

[mcp_servers.sentry]
url = "https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}"
auth = "oauth"

上面的组织名和项目名需要换成你自己的值。如果你不想把范围限制到具体项目，可以使用基础地址，但排查生产问题时，我更建议先缩小范围。

这组命令来自 Codex 和 Sentry 的公开文档。是否能顺利登录，还取决于当前账号权限、 Sentry 项目配置和本机 Codex 版本。不要把“配置成功”当成“已经能修好所有问题”。

正确的调试顺序

接入以后，别直接对 Codex 说“把这个 Bug 修掉”。先让它查数据，再让它动代码。

可以这样问：

先从 Sentry 查看最近 24 小时出现频率最高的错误。
只分析当前项目，不要修改文件。
告诉我错误的事件数量、受影响的版本、完整堆栈、相关请求上下文，
以及你认为最可能的根因。缺少的信息请明确说出来。

拿到分析后，再进入修改阶段：

根据刚才确认的错误现场，检查本地代码。
先指出可能出问题的文件和判断依据，再提出最小修改方案。
修改前不要执行删除、迁移或批量重命名。
修改后补一个能复现这个问题的测试，并运行相关测试验证。

这个顺序很重要。第一步只读，先让 AI 把线上事件和本地代码对上。第二步才允许改动。这样可以避免它看到一条模糊报错，就马上在项目里到处试错。

它真正省下的是什么

Sentry 不会让 AI 突然拥有经验，也不会替你做产品判断。它省下的是收集现场的时间。

没有监控时，开发者往往要自己翻日志、问用户复现步骤、确认版本、猜请求路径，再把这些内容整理成一段提示词。项目越大，准备工作越长。

有了结构化的错误记录，Codex 可以先围绕真实事件提问：这个问题从哪个版本开始？是否只发生在某个接口？调用链上哪一步耗时异常？最近的改动和它有没有时间上的关系？

问题从“请帮我修这个报错”变成了“请根据这次事件的证据，找出最小修复”。两句话看起来差不多，实际工作量差很多。

不能忽略的边界

第一，Sentry 只能提供已经收集到的数据。如果 SDK 没接好、版本没有配置、采样率太低，或者敏感字段被主动过滤，Codex 看到的现场就不完整。

第二，线上数据会包含隐私和业务信息。请求参数、用户标识、 URL 、堆栈和日志都可能进入第三方服务。接入前要检查数据脱敏、保留期限、团队权限和组织合规要求。不要为了让 AI 看得更全，就把密码、令牌或完整用户隐私上传出去。

第三，AI 的修复仍然需要人审。它可能把相关性误认为因果，也可能只修复了一个触发点。至少要检查改动范围，补测试，在隔离环境复现，再决定是否发布。

第四，Sentry 的开源仓库和托管服务不是一回事。getsentry/sentry 的根许可证文件当前是 FSL-1.1-Apache-2.0，并不是简单的 MIT 。仓库适合研究和自托管评估，使用时要按许可证条款判断。文章里这套 MCP 接入走的是 Sentry 提供的远程服务，账号、权限和数据处理规则也要单独看服务条款。

适合谁

如果你只是写一个几十行的小脚本，直接看报错通常够用。接 Sentry 和 MCP 会增加配置成本，不一定划算。

如果你在维护一个持续上线的网页、接口服务或 AI 应用，问题来自真实用户和真实请求，单靠终端里的最后一行错误就不够了。这时，先让 Sentry 收集现场，再让 Codex 做分析，是一条更稳的工作流。

我的建议很简单：先把“只看报错就改代码”这个习惯停下来。让 AI 先查事件、说证据、给判断，再申请修改。它不一定每次都能修对，但至少不会一上来就把项目当成猜谜游戏。

项目地址：https://github.com/getsentry/sentry

Sentry MCP：https://mcp.sentry.dev/

Codex MCP 说明：https://developers.openai.com/codex/mcp