查找并修复缺陷

随着编码 agent 编写的代码越来越多，工程师需要投入更多时间评审代码并排查缺陷。即使有编码 agent 的帮助，也值得复习高效调试的基础知识，并探索将部分工作委托给智能体以加快进度的方法。

调试基础

无论由人还是智能体执行，良好的调试都遵循相同的原则：

1. 建立可靠的复现步骤。 如果无法复现缺陷，就无法验证修复是否有效。记录触发问题的确切步骤、输入和条件。
2. 缩减到最小案例。 去除一切与缺陷无关的内容。复现案例越小，越容易找到根本原因。
3. 隔离变量。 每次只改动一项。如果改了三项后缺陷消失，就无法确定是哪项改动修复了它。
4. 提出具体假设。 针对可能的根本原因提出几个假设。“缺陷可能出在支付代码中”太过模糊。“缺陷发生是因为 calculateTotal() 未考虑负折扣”则足够具体，可以进行验证。
5. 为您的代码添加日志。 在怀疑存在问题的位置的输入和输出处添加日志记录。将预期值与实际观察到的值进行比较。
6. 用测试防止回归。 找到并修复缺陷后，编写一个本可以捕获该缺陷的测试。这样可以防止同一缺陷再次出现。

两种调试方式

快速解决简单错误

对于错误消息明确或原因显而易见的缺陷，智能体通常可以直接定位并修复问题。粘贴错误信息，补充一些发生时的上下文，然后交给智能体处理。

TypeError: Cannot read properties of undefined (reading 'profile')
at getProfile (src/services/UserService.ts:45)
at UserController.show (src/controllers/UserController.ts:23)

当能从错误消息中看出原因时，这种方法效果很好。智能体可以读取堆栈跟踪，找到相关代码并修复。不过，这种方法并非总是奏效，你可能需要采用更系统的方法来查找根本原因。

调试模式：证据优先

对于更棘手的缺陷，调试模式采用不同的方法。它不会猜测如何修复，而是先收集运行时证据。

调试模式遵循五个步骤，反映了调试的基本方法：

1. 提出假设，判断可能出错的原因
2. 通过有针对性的日志记录为您的代码插桩
3. 在收集数据时请您复现缺陷
4. 分析日志以确定根本原因
5. 根据收集到的证据进行针对性修复

调试模式可以帮助您发现并修复最棘手的缺陷。它将前面介绍的基本方法融入其中，训练智能体成为高效的调试助手，自动完成原本需要您手动进行的排查工作。

并行运行多个模型

对于棘手的缺陷，不同模型有时会发现不同的线索。Cherri Code 允许你同时让多个模型运行同一条调试提示词。每个智能体都在隔离环境中工作，因此不会相互干扰。

工作流程：

1. 编写清晰的调试说明，包含复现步骤和你的假设
2. 从智能体下拉菜单中选择多个模型
3. 提交提示词；每个模型独立工作
4. 比较各模型提出的修复方案
5. 保留证据最充分的方案

Cherri Code 会建议它认为最佳的解决方案，但你应评估其推理过程，而不只是最终方案。要进一步确认修复是否准确，可以要求模型验证其工作，并确保该方案正确。

将运行时数据引入智能体循环

智能体仅凭阅读代码就能发现性能问题和常见缺陷。但你提供的运行时证据越多，它就能分析得越深入。

从提问开始

排查问题时，并非总需要日志或性能分析工具。直接向智能体提问，它会分析您的代码，找出常见问题。

在上面的示例中，智能体通过阅读代码发现了一个慢查询，无需日志或性能分析。对于某些性能问题，这样就足够了。

向智能体提供运行时证据

当仅靠代码分析还不够时，为智能体提供真实数据。将终端输出、查询日志或其他数据粘贴到对话中。智能体可以利用这些数据更高效地找出根本原因。

例如，排查缓慢的数据库查询时，你可以对慢速 Postgres 查询运行 EXPLAIN ANALYZE，粘贴输出结果，智能体便可根据你的 schema 追溯问题根源：

Seq Scan on orders  (cost=0.00..45892.00 rows=47 width=244) (actual time=0.423..1203.112 rows=47 loops=1)
Filter: (user_id = 'usr_abc123')
Rows Removed by Filter: 2341856
Planning Time: 0.089 ms
Execution Time: 1203.298 ms

同样的方法也适用于应用日志、性能分析数据，以及构建和测试输出。

使用浏览器调试前端

对于前端问题，Cherri Code 的集成浏览器让智能体可以直接访问你的 Web 应用。它可以读取控制台日志、检查网络请求并查看 DOM，无需你手动复制任何内容。

让智能体打开页面、复现问题，并检查控制台中的错误或网络标签页中的慢请求。智能体能看到你在 DevTools 中看到的内容，并可将问题追溯到源代码。

将监控工具接入 MCP

MCP 服务器 可为智能体提供新能力，并将其连接到生产环境的可观测性工具。智能体无需手动粘贴数据，可按需获取所需信息。

在上面的示例中，智能体通过 MCP 查询 Sentry 并获取相关错误详情。它将错误与日志关联，找到问题代码并提出修复方案，所有操作都在同一对话中完成。

适用于调试的 MCP 服务器：

• Sentry：错误详情、堆栈跟踪和面包屑
• Datadog：生产环境日志和 APM 跟踪
• 数据库：查询生产数据以验证假设
• Linear 或 GitHub Issues：将缺陷报告和复现步骤引入对话

你可以设置工作流，让生产环境应用的监控告警自动触发智能体调查。如果错误率激增，Linear 会创建一个工单，智能体会在人工介入前开始诊断问题。这可以缩短解决客户报告的错误所需的时间，甚至在客户察觉前修复问题。

常见失败模式：接受自己不理解的修复方案

如果你不理解修复方案，就无法验证它是否正确。智能体可能会添加空值检查，让错误消失，但底层的数据不一致问题依然存在。

当智能体提出修复方案时，要不断追问，直到完全理解。为什么这个值是 null？是什么变化导致了这种情况？这是根本原因，还是只是在掩盖症状？正如我们在 基础知识中介绍的，智能体可能会编造看似合理的解释。你需要形成自己的判断，并利用调查获得的数据确认智能体是否找到了真正的根本原因。

接下来

现在你已经了解调试，以及编码 agent 如何加快排查速度，接下来需要确保所做的更改正确无误，不会引入回归问题。下一章将学习如何评审代码并系统地进行测试。