上周，Anthropic 正式发布了 Claude Opus 4，并将其称之为“全球最强的编程模型”。当时，有不少开发者对此说法不以为然——Reddit 上一位网名为“ShelZuuz”的 C++ 大佬，或许也是其中之一。
到了本周，ShelZuuz 却表示：他已经被 Claude Opus 4 “彻底折服”了。
ShelZuuz 可不是一般人。据他自述，他拥有 30 多年的 C++ 开发经验的，曾在知名大厂（FAANG：Meta、亚马逊、苹果、网飞、谷歌）担任过 Staff Engineer，几乎是团队里的“定海神针”，别人搞不定、困扰一周的难题，最终都会找到他来解决。
但就是这样一位大神，却被一个困扰了他长达四年的“白鲸 Bug”折磨得够呛（注：一种在特定条件下会触发渲染错误的 Bug，通常在大规模代码重构后出现）——而本周，他终于在 Claude Opus 4 的帮助下，成功解决了这个长期未解的难题！
困扰了他 4 年的“白鲸 Bug”
根据 ShelZuuz 的分享，这个 Bug 要追溯到四年前。
当时，他在重构一个有 6 万行代码的项目，原本是期望通过这次重构解决老系统遗留的诸多问题，让整个系统运行得更加顺畅高效。可没想到，这次重构却意外引入了一个棘手的新麻烦。
具体来说，是某个特殊着色器在某些特定 GPU 设置和调用路径下会出现渲染异常，导致系统出现故障。可问题在于：它不容易重现，也不会报错，有时你连“哪里出了问题”都说不清楚。
于是，他开始了一场没有终点的 Bug“猎杀”。
这四年来，ShelZuuz 断断续续地来回找这个 Bug，估计花了至少有 200 个小时。或许研究一段底层渲染代码几个小时也徒劳无功、以为找到了问题关键、修改后却 Bug 依旧……正如 ShelZuuz 将其称为“白鲸 Bug”的原因：这个 Bug像极了小说《白鲸记》里的莫比·迪克——神出鬼没、近在咫尺却永远抓不住。
而就在最近，他突然心血来潮，尝试把这个“白鲸 Bug”丢给 Claude Opus 4 来分析。毕竟，Anthropic 能自信把 Claude Opus 4 叫做“全球最强的编程模型”，它总得有点东西不是？
结果，原本这个 ShelZuuz 压根不寄予厚望、只想着随便试试的 Claude Opus 4，真的抓到了这个“白鲸”的尾巴！
我和运行 Opus 4 的 Claude Code 一起工作了几个小时，给了它访问旧代码和新代码的权限，并告诉它去找出重构中的问题所在。结果它找到了！原来，在旧代码中能正常运行的原因仅仅是旧架构的巧合，而当我们改变架构时，并没有考虑到这种巧合。
因此，这不仅仅是一个引入的逻辑错误，它还发现了更改后的架构设计没有考虑到这个旧的边缘情况。
更令 ShelZuuz 惊讶的是，整个过程仅用了几个小时，一共只花了大约 30 次提示和一次重启——要知道，在此之前他也尝试过用 GPT-4.1、Gemini 2.5 pro 以及 Claude 3.7 来解决这个 Bug，但都没有任何进展。
Claude Opus 4 是怎么做到的？
许多开发者都好奇，Claude Opus 4 具体是怎么做到的？为此，ShelZuuz 给出了详细过程。
首先是项目结构准备。他将老版本的代码放入 /proj/oldsrc，新版本代码放入 /proj/src，统一打开 VSCode 的 /proj 目录。Claude 就可以在一个会话中同时看到两份代码。
其次是 prompt。ShelZuuz 透露，他的初始提示词大概只有 10 行，主要描述问题所在，并引导 Claude 去扫描整个项目（加起来约 200 万行代码）。而整个过程用了约 30 条 prompt，最长的一条 prompt 超过 1500 行，多是根据 Claude 要求他插入 printf 语句后的运行日志，以便理解代码流程。
准备工作完成后，Claude 便开始找这个“白鲸 Bug”：
（1）自动 grep 项目中相关函数和路径，无需人工指定文件；
（2）基于现象分析执行路径，并自行在旧代码和新代码中对比找出关键差异；
（3）过程中 Claude 曾多次误判路径，但 ShelZuuz 会通过补充说明帮助它及时修正方向；
（4）最终，Claude 发现了一个由于重构导致的非显式依赖丢失：一个函数依赖的初始化流程在新版中被移动，造成执行路径静默中断。
ShelZuuz坦言，好几次 Claude 都说“我找到问题了！”，但他都不信，因为 AI 总是这么说。但最后一次，他跑了一下代码，Bug居然真的修复了，而且没有引入其他问题。
但是，Claude 依然只是“初级开发者”
既然如此，那 AI 真的比人类还强、可以取代人类了？而对于这个问题，ShelZuuz 在评论中多次强调：虽然 Claude 解决了这个大问题，但它本质上更像是一个“能干的初级程序员”。
这听上去有点贬低？不，恰恰相反。
他举例道：
“我最近用 Claude 做了一个全栈项目，大概花了 200 个 prompt。你可以想象一个新人程序员在 6 个月里通过 200 次问题和代码审查来推进项目。而 Claude 只花了3天。它确实更快，但需要的‘手把手指导’的工作量其实相当。”
他指出，AI 并不是“自动完成”任务的魔法工具，它更像是你团队中的一个“不会上厕所但一直问问题”的实习生——你得时刻关注它的方向，引导它别绕远路、别误删代码、别浪费时间在错的方向上。
ShelZuuz 总结道：AI 在开发中需要的指导时间，相当于团队中有一个初级开发者，而非高级开发者。因此，如果让他在 30 个高级程序员和一个 AI 之间选，他还是会毫不犹豫地选择人类：“光从对 Tech Lead（技术主管）的负担角度来说，我更愿意管理高级开发者。”
不过，不同于 ShelZuuz 的看法，许多开发者仍认为使用 AI 比雇佣工程师的成本要低得多。
以 ShelZuuz 使用的 Claude Max 为例，其每月订阅费为 100 美元，相较于资深工程师 200 小时工时费约 2.5 万美元来说，至少在这件事上可以看出，AI 在提高开发效率、降低开发成本方面有着巨大潜力。
参考链接：
Claude Opus solved my white whale bug today that I couldn't find in 4 years
byu/ShelZuuz inClaudeAI
本文来自微信公众号“CSDN”，整理：郑丽媛 ，36氪经授权发布。
