凌晨两点，线上告警还在响，日志里只有一行模糊的 undefined is not a function，你一边翻提交记录，一边怀疑人生。对工程师来说，AI 写 demo 已经不稀奇，真正有价值的是：它能不能读懂历史代码、定位复杂问题、给出可合并的修复方案。如果你想直接体验 Claude、ChatGPT、Gemini、DeepSeek 等模型的代码能力，可以通过一个国内 AI 镜像平台快速调用，无需复杂网络配置，手机或邮箱注册即可使用：全球大模型订阅服务站。

一、为什么要测 Opus 4.7 的“修 Bug”能力？

很多 AI 编程评测喜欢跑算法题，比如 LeetCode、HumanEval。
但真实工作里，工程师面对的通常不是“从零实现函数”，而是：

• 项目已有大量上下文；
• Bug 可能来自边界条件；
• 代码风格不能随便改；
• 修复后不能引入新问题；
• 还要补测试、解释原因。

所以这次我把重点放在“真实 Bug 修复任务”上，而不是单纯看模型能不能写出漂亮代码。

测试对象是 Claude Opus 4.7，任务集来自 Web 后端、前端组件、数据处理脚本、测试用例维护、并发逻辑、类型系统等场景，共 100 个 Bug。每个任务都包含问题描述、相关代码片段、失败日志和期望行为。

二、测试方法：不是问答，而是按工程流程跑

为了更贴近实际开发，我没有直接问“这段代码哪里错了”，而是采用类似 Code Review 的流程：

1. 给出 Bug 描述和失败日志；
2. 提供相关文件内容；
3. 要求模型先分析原因；
4. 输出最小修改方案；
5. 补充测试用例；
6. 解释潜在风险。

评分维度分为四项：

维度	权重	说明
定位准确率	35%	是否找到真正根因
修复可用性	35%	代码能否通过测试
修改克制程度	15%	是否避免大范围重构
解释质量	15%	是否能讲清楚为什么这样修

这里有个关键点：AI 不怕写代码，怕的是“过度自信”。很多模型在日志不完整时会直接编一个原因，看起来很专业，但实际修不动问题。

三、100 个任务的整体结果

实测下来，Opus 4.7 的表现比较稳定，尤其在多文件上下文和复杂逻辑推理上有优势。

任务类型	数量	一次修复成功	二次提示后成功
前端状态 Bug	20	15	18
后端接口 Bug	25	18	22
数据处理 Bug	15	12	14
并发/异步 Bug	15	9	12
类型/测试 Bug	25	20	23

综合来看，100 个任务中，一次修复成功 74 个；经过补充提示后，成功数提升到 89 个。
这说明它不是“万能自动修复器”，但作为工程师的辅助排查工具，效率提升很明显。

四、一个典型案例：边界条件修复

下面是一个简化过的真实场景：分页接口在最后一页偶尔返回重复数据。

js

function getPage(items, page, pageSize) {
  const start = page * pageSize;
  const end = start + pageSize;
  return items.slice(start, end);
}

如果业务约定 page 从 1 开始，上面代码就会跳过第一页。
Opus 4.7 不只是指出 off-by-one 问题，还建议补测试：

js

function getPage(items, page, pageSize) {
  const start = (page - 1) * pageSize;
  const end = start + pageSize;
  return items.slice(start, end);
}

并补充：

js

expect(getPage([1, 2, 3, 4], 1, 2)).toEqual([1, 2]);
expect(getPage([1, 2, 3, 4], 2, 2)).toEqual([3, 4]);

这个例子不难，但能看出它的一个优点：不是只改代码，而是会主动锁定回归测试。

五、它在哪些场景更好用？

我认为 Opus 4.7 最适合三类任务。

第一类是“日志明确但代码分散”的问题。
比如接口 500、测试失败、字段为空，只要你能提供相关文件，它通常能快速缩小范围。

第二类是“历史代码没人敢动”的问题。
它会倾向于做最小修改，而不是上来重构一大段逻辑，这点对老项目很重要。

第三类是“需要解释给团队听”的问题。
不少技术负责人不只是要一个 patch，还要判断修复是否可靠。Opus 4.7 的解释相对清晰，适合拿来做初步 Review 材料。

六、它也有明显短板

实测中失败最多的是并发和隐式状态问题。
比如缓存失效、竞态条件、异步任务顺序异常，如果没有足够日志，它会给出“看似合理但不完整”的修复。

还有一种情况是依赖项目内部约定。
例如某些字段虽然看起来可以为空，但业务上其实必须保留；或者某个异常不能吞掉，必须向上抛。这些信息如果不在提示词里，模型很难凭空知道。

我的建议是：
不要只丢一段代码过去，而是同时给出“失败现象、期望行为、相关约束、测试命令”。上下文越工程化，输出越接近可合并代码。

七、给工程师的使用建议

如果你准备用它处理真实 Bug，可以按这个模板提问：

text

请你作为资深工程师分析这个 Bug。
要求：
1. 先说明可能根因；
2. 给出最小修改方案；
3. 不要大范围重构；
4. 补充必要测试；
5. 说明潜在风险。

背景：
失败日志：
相关代码：
期望行为：
限制条件：

这个模板的重点不是“命令 AI 修复”，而是把它纳入工程流程。
让它先分析，再改代码，再补测试，最后讲风险。这样更容易发现幻觉，也方便人工复核。

八、结论：适合当高级副驾驶，不适合完全托管

从 100 个真实 Bug 修复任务看，Claude Opus 4.7 在代码理解、跨文件分析、测试补充方面表现不错，尤其适合中高复杂度的排障场景。

但它仍然需要工程师提供上下文和做最终判断。
如果把它当“自动提交代码的机器人”，风险不小；如果把它当“能快速读代码、给修复建议、补测试思路的副驾驶”，价值就很明显。

对软件工程师来说，未来的竞争点可能不是“会不会用 AI 写代码”，而是“能不能把 AI 放进可靠的工程流程里”。

注：本文配图由ChatGpt Image-2辅助生成。 【本文完】