Skip to main content

端到端排查一个 Bug 报告

将包含 Datadog 日志和数据库访问权限的缺陷报告交给 Devin，即可获得根因分析和修复 PR。
AuthorCognition
Category事件响应
FeaturesMCP
1

连接 Datadog

Devin 需要访问你的 Datadog 日志，以搜索与该 bug 相关的错误。如果你尚未启用，请先开启 Datadog MCP：
  1. 前往 Settings > MCP Marketplace，找到 Datadog
  2. 点击 Enable，并提供两个密钥：
  3. 如果你的 Datadog 实例使用自定义站点（例如 datadoghq.eu），还需要设置 DATADOG_SITE
连接完成后，Devin 可以搜索日志、拉取错误追踪信息，并将问题与部署关联——全部在当前会话内完成。完整的设置细节请参见 MCP Marketplace。
2

为 Devin 授予数据库的只读访问权限

对于数据类 bug —— 错误的数值、缺失的字段、出错的查询 —— 当 Devin 能够直接验证数据状态时，效果会显著更好。将只读连接字符串作为 Secret 传入：
  1. 前往 Settings > Secrets 并添加一个新的 Secret：
    • Name: DATABASE_READ_REPLICA_URL
    • Value: postgresql://readonly_user:password@read-replica.internal:5432/production
  2. 添加类似这样的备注：“Read-only connection to the production read replica. Safe for SELECT queries only.”
或者，在 Settings > MCP Marketplace 中连接一个数据库 MCP（PostgreSQL、MySQL 等）——Devin 可以通过任一方式查询你的数据。
始终使用只读副本或仅具有 SELECT 权限的用户。Devin 在排查 bug 时从不需要写入权限。如果你担心高开销查询影响性能，可以让 Devin 指向一个专用只读副本，或一个与生产数据库分离的现有分析副本。
3

将错误报告发送给 Devin

将 bug 报告直接粘贴到 Devin 会话中。尽量包含报告者提供的全部上下文——问题什么时候开始、受影响的是谁、出了什么问题、以及发生在什么位置。若需要结构化排查，可以使用 !triage 模板 playbook——复制一份，并根据你的技术栈自定义各个步骤。报告越具体，Devin 找到答案就越快。“自上周五的部署以来”可以让 Devin 缩小 Datadog 的时间窗口，“Pro plan 用户”则能精确限定需要查询的记录。
4

Devin 会排查和修复问题

在接入 Datadog 并配置好数据库访问后，Devin 会执行一次完整的排查：拉取 Datadog 日志 — 从周五起搜索计费服务（billing service）的错误日志，按服务名和错误状态进行过滤。发现从部署当天 UTC 时间 18:12 开始，TypeError: Cannot read property 'name' of undefined 错误开始激增。查询数据库 — 在只读副本上运行 SELECT id, company_name, plan FROM users WHERE plan = 'pro' LIMIT 20。确认 Pro 用户确实有 company_name 字段值——数据没有问题，因此 bug 出在代码中。追踪代码变更 — 检查 git log --since="2026-02-13"，发现提交 a1b2c3d 重构了用户 API 响应，把 company 重命名为 organization。而位于 src/pages/billing/BillingHeader.tsx 的计费页面仍然引用 user.company.name。编写修复 — 将 BillingHeader.tsx 更新为使用 user.organization?.name ?? 'Your Company'，并添加一个回归测试，用旧的和新的 API 响应结构分别渲染该组件。在浏览器中验证 — 启动开发服务器，在 Devin 内置浏览器中打开计费页面，并确认测试用户的公司名称现在可以正确渲染。创建一个 PR，其中包含修复代码、测试，以及说明根本原因和影响范围（所有 Pro 和 Enterprise 用户，约 350 个账户）。
5

后续跟进

一旦修复 PR 合并完成后，你可以让 Devin 排查相关问题或添加监控：如果你希望 Devin 在下次也记住这次排查中的某些信息，只需直接告诉它——例如，“记住 user API 使用的是 user.organization，而不是 user.company。” Devin 会建议创建一个 Knowledge 条目，供你查看和保存。这样，后续会话就会从你团队已经掌握的上下文开始。