AI 代码调试
AI 代码调试是借助编码 Agent 定位和修复缺陷的过程，缺陷可能来自既有代码，也可能来自 AI 刚生成的实现。允许使用 AI 的编码面试常以“修复失败测试”“找出并发代码中的错误”“审查并改进 AI 的实现”为题。本文讲调试的步骤、如何让 AI 参与，以及避免“连续重写却越改越乱”的方法。
1. 面试核心
先记住这几条，再读正文2. 调试步骤
- 复现：运行失败的测试或复现步骤，确认环境正常、失败稳定。不稳定的失败先找出触发条件。
- 缩小范围：沿测试输入、调用链和关键状态定位到具体模块和函数。可以让 Agent 搜索调用关系、添加临时日志或断点输出。
- 提出假设：根据现象提出原因，例如“分页 offset 用了 page 而不是 page-1”。每个假设都要能被一次运行验证或否定。
- 修复根因：修改导致问题的机制，而不是在出错位置加特殊判断。修复范围尽量小。
- 回归：运行相关测试和更大范围的测试，检查 diff 中没有无关修改。为这次缺陷补一个测试，防止再次出现。
- 说明：能解释修复前后的行为差异和尚未验证的部分。
3. 让 AI 参与的方式
| 环节 | AI 适合做 | 人需要把关 |
|---|---|---|
| 复现 | 运行测试、整理错误输出 | 确认复现条件与线上一致 |
| 定位 | 搜索调用链、阅读陌生代码、总结模块关系 | 检查结论与代码是否一致 |
| 假设 | 列出可能原因及验证方法 | 选择优先验证的假设 |
| 修复 | 编写修改、补测试 | 判断是否修了根因，是否改了测试断言 |
| 回归 | 运行测试、检查 diff | 判断测试覆盖是否足够 |
要求 Agent“先解释原因，再修改”有两个作用：解释错误时可以在写代码前纠正；解释正确时，修改更有针对性。
4. 常见陷阱
- 连续重写：一次失败后让模型整体重写，引入新问题。应该保留可用部分，只修改与假设相关的地方。
- 改测试让它通过：删除断言、放宽比较、跳过用例。除非测试本身违背需求，否则不修改测试。
- 只修症状：在出错位置加
if特判，同类输入的其他路径仍然出错。 - 上下文污染：多次失败尝试留在上下文中，模型被错误的中间结论误导。回退代码、总结已知事实后开启新会话往往更快。
- 未验证的结论：模型说“问题已修复”，但没有运行测试。以运行结果为准。
5 · 面试题卡片
5.1 面对陌生代码库和失败测试，如何借助 AI 定位并修复问题？
出现公司：Meta、Amazon、去哪儿旅行
考察重点
- 复现、定位、假设、修复、回归的顺序。
- 测试是否应该修改的判断，以及修复范围。
相关内容：调试步骤、让 AI 参与的方式。
参考回答
先运行失败的测试，确认环境和失败位置。让 Agent 搜索测试调用的入口和相关模块，总结调用链，人检查它的总结是否和代码一致。把错误输出、相关代码和期望行为交给 Agent，要求先列出可能原因及验证方法，再逐个验证。
确认根因后做最小修改，运行相关测试，再根据影响范围做更大范围回归，检查 diff 中没有无关修改。如果 Agent 建议改测试，先判断测试是否违背需求，不能因为测试妨碍通过就删除断言。时间有限时优先修复影响面大的失败，最后说明修复前后的行为差异以及未验证的部分。
5.2 配置文件热更新任务中，如何发现并修正 AI 生成实现的问题？
出现公司：阿里云
考察重点
- 从外部行为定义正确性。
- 构造失败输入验证问题，给出具体反馈。
参考回答
先确定热更新的外部行为：支持哪些格式、修改后何时生效、解析失败时保留旧配置还是报错、读取方会不会看到半更新的状态、文件被频繁修改时如何处理。然后沿“文件变化 → 解析 → 校验 → 发布新配置”的链路审查实现。
例如发现解析失败前就覆盖了共享配置，就构造一个格式错误的文件，观察旧配置是否仍可用，然后把复现步骤、实际结果和期望结果反馈给模型，要求改为解析校验通过后再原子替换引用。修复后验证正常更新、错误配置和连续修改；是否需要并发测试取决于任务要求。
5.3 使用编码 Agent 时，上下文过长或模型反复出错，怎样把任务拉回正确方向？
出现公司：安软、新旦智能、Stripe、阿里云
考察重点
- 识别上下文污染和无效循环。
- 回退、总结事实和重开会话。
参考回答
先停止让模型继续改。用版本控制回退到最后一个能通过测试的状态，保留已验证有效的部分。把已知事实整理成简短的说明：目标、约束、已确认的根因或已排除的假设、相关文件和复现命令。
然后压缩上下文或开启新会话，只带这份说明重新开始，避免之前错误的尝试和结论继续误导模型。要求模型先解释它对问题的理解再动手，把大任务拆成可单独验证的小步骤，每步运行测试。长期有效的约定写进仓库指令，下次不必重复说明。