30年老兵也折戟!Claude 4 竟助工程师解决4年老Bug

FAANG老工程师4年未解的C++ Bug,被Claude 4解决了!案例突显AI在复杂代码分析中的强大潜力,但人类经验的引导也至关重要。

原文标题:全靠Claude4!30年FAANG老工程师:AI帮我解决了4年老bug

原文作者:机器之心

冷月清谈:

一位拥有30多年经验的前FAANG高级工程师分享了他如何利用Claude Opus 4解决一个困扰了他4年的C++ Bug的故事。该Bug源于一次大规模代码重构,涉及6万行代码,且是一个难以复现的边缘案例。工程师花费了约200小时尝试解决未果,最终Claude Opus 4成功定位了问题根源——一个因代码重构而消失的隐藏依赖关系。这个案例展示了AI在代码分析和问题定位方面的强大能力,尤其是在处理大规模、复杂的代码库时,AI能够发现人类难以注意到的细节和潜在的逻辑错误,但也强调了人类经验和AI分析能力结合的重要性,因为问题解决过程需要工程师通过Prompt来引导AI。

怜星夜思:

1、Claude 4 成功解决 4 年老 Bug,是否意味着未来 AI 将取代大部分程序员的工作?
2、文章中提到 Bug 存在是因为老代码中一个“巧合”导致的隐藏依赖,这种隐藏依赖在实际开发中常见吗?我们应该如何避免?
3、文中的工程师使用了 30 多个 prompt 来引导 Claude 4,这说明什么?我们应该如何有效地与 AI 进行交互,才能更好地利用 AI 解决问题?

原文内容

机器之心报道

编辑:+0、泽南


AI 就像一头野驴,跑起来就不停。人类花了几百万年才走上食物链顶端,而大模型只用了不到十年时间,已经能把你和刘亦菲 P 进一张自拍了。奥!最新进展是已经能自己生成音画同步的超真实脱口秀了。



不过等人类回过味来,发现海的那边好像是敌人,AI 导致的失业潮仿佛近在咫尺。还记得七年前(那时候 ChatGPT 都还没发布)本科第一次班会上,老师问为什么要选这个专业,有同学回答因为这是最不容易被 AI 替代的职业之一(PS. 我学的是建筑,大家别笑得太大声)。



不知是不是预料之内,AI 最先波及的,竟然是写程序这件事本身。Anthropic 的创始人、CEO Dario Amodei 就曾预测,很快 90% 的代码可能都会由 AI 来编写。


先不说这个预言什么时候会实现,至少他家的产品确实在往这个方向发展。请问编程最厉害的大模型是哪个?虽然没有定论,但 Claude 肯定榜上有名。


BigCodeBench 榜单


上个星期刚发布的 Claude 4,让人们的「刻板印象」又加深了一层。


5 月 22 日,Anthropic 推出了全新一代 Claude 4 系列大模型,为代码生成、高级推理和 AI 智能体树立了全新标准。其中,Claude Opus 4 是一款全球领先的编码模型,它在复杂、长时间运行任务和智能体工作流中拥有持续的高性能。



Anthropic 展示了 Claude 4 如何无缝融入人们整个工作日。它拥有三大高级功能:通过 Claude 应用中自定义集成进行深入研究,管理项目,并能在 Claude Code 中独立解决代码任务。


新版本的大模型已经上线,立即吸引了大量程序员前去使用,很多人表示效果出奇的好。


昨天,Reddit 上一位拥有 30 多年经验的前 FAANG 高级工程师发帖表示,他被一个 C++ 的 Bug 困扰了 4 年,花了约 200 小时却毫无进展。而 Claude Opus 4 竟然成功地解决了这个问题,并且是唯一能做到的 AI 智能体。



这篇帖子在 X 和 Reddit 引起了热烈的讨论,Anthropic 工程师 Alex Albert 表示,这样的故事可能会越来越多。



有人展开了技术讨论。



也有人认为,这根本就是个 Claude 推广软文。


image.png


假如这个故事是真的,我们该如何来看待这件事呢?

大家先别激动,等一等外行的朋友们,我们先来梳理一下要点,这里邀请 Gemini 老师场外援助(因为我也是外行)。



Bug 的来源和难度


这个 Bug 是在四年前一次大规模的代码重构(Re-architecting refactor)中产生的。


  • 代码重构:你可以把它想象成对一栋老房子进行彻底的重新设计和装修。原来的房子可能有很多问题(比如布局不合理、管道老化),装修后解决了这些问题,但可能因为改变了结构,导致某个角落里以前能用的某个特殊电器(比如某个特定型号的灯,只有在特定开关下才用)现在用不了了。
  • 6 万行代码:这说明这次「装修」的规模非常大,非常复杂。
  • 边缘案例(Edge case):这指的是一个非常特殊、不常出现的情况。就像上面说的那个特殊电器,平时很少用,只有在特定条件下才会用到。
  • 着色器(Shader):这是一种专门处理图形和视觉效果的代码。你可以理解为那个「特定型号的灯」。
  • 问题所在:在这次大规模「装修」后,那个「特定型号的灯」在「特定开关下」就不亮了。

Bug 的真正原因


AI 发现,这个问题不是因为「装修」时工人犯了个简单的错误(比如接错了一根线,这叫逻辑 Bug)。而是因为:


  • 那个「特定型号的灯」以前之所以能亮,仅仅是因为老房子旧结构下的一个「巧合」。可能有一根电线无意中搭在了某个地方,正好给它供电了。
  • 在重新设计和装修(改变了架构)时,大家并没有意识到这个「巧合」的存在,也就没有在新的设计里考虑进去。所以,当旧结构消失后,那个「巧合」也消失了,灯自然就不亮了。
  • AI 的厉害之处在于,它不仅看懂了新旧两套复杂的「图纸」,还理解了那个「巧合」是怎么回事,并指出了新设计没有考虑到这个隐藏的依赖关系。

很好!那我们现在来分析一下,AI 在这个过程中起到了什么作用呢?



首先,AI 可以轻松地加载、分析和比较新旧两个版本共计数万甚至数十万行的代码。它不会像人类那样感到疲劳或遗忘细节,可以同时「看到」整个 picture。


像 Claude Opus 4 这样的先进模型拥有巨大的「上下文窗口」,这意味着它可以一次性考虑非常多的信息,并追踪它们之间的复杂关系。


同时,AI 不会带有「它应该如何工作」的偏见。它只是客观地分析旧代码如何运行并产生结果,以及新代码如何运行并产生不同结果,它能发现两者之间最细微的差异。


别忘了,这个过程还需要人类的指导。程序员通过超过 30 个 prompt 来引导 AI。这说明人类的经验和直觉与 AI 强大的分析能力相结合,才能发挥最大效果。人类设定目标、提供背景,AI 则执行繁重的分析工作。


参考链接:

https://www.reddit.com/r/ClaudeAI/comments/1kvgg7s/claude_opus_solved_my_white_whale_bug_today_that/?share_id=-Y9J9Hna8rIemyMsG8Jp9&utm_content=1&utm_medium=ios_app&utm_name=ioscss&utm_source=share&utm_term=1


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:liyazhou@jiqizhixin.com

理论上来说,良好的软件设计应该避免隐藏依赖。但实际项目中,时间压力、技术债务等因素常常导致我们妥协。所以,定期进行代码重构,清理技术债务就显得尤为重要。

作为一个程序员,我有点焦虑,但也在积极学习如何使用 AI 工具来提升效率。与其担心被取代,不如拥抱变化。

从架构层面入手,微服务化好像可以解决这个问题,服务于服务之间通过API访问,只要API不变,内部代码随便你怎么优化,这样理解对吗?

这说明提问也是一门艺术!你需要像一个优秀的老师一样,循循善诱,引导AI思考。可以尝试使用不同的prompting技巧,例如角色扮演、情景模拟等,来激发AI的潜力。

30多个prompt说明prompt engineering是很重要的!你需要清晰、明确地描述问题,并逐步引导AI找到解决方案。好的prompt能让AI更好地理解你的意图,从而给出更有用的结果。

取代大部分工作可能有点夸张,但AI绝对会成为程序员的得力助手。以后可能更多的是人和AI协同工作,AI负责重复性的代码编写和Bug查找,程序员则专注于架构设计和业务逻辑。

隐藏依赖确实很头疼。在大型项目中,代码经过多次迭代,很容易出现这种“历史遗留问题”。避免的办法包括编写清晰的文档、进行充分的代码审查、以及使用自动化测试工具来检测潜在的依赖关系。

我觉得可以把AI当成一个知识渊博但缺乏实际经验的实习生。你需要给他提供背景信息、明确目标、并进行适当的指导,他才能帮你完成任务。我最近在学习 LangChain,感觉挺有用的。

我觉得不会完全取代。就像计算器出现后,会计师并没有消失,而是更专注于财务分析。AI 可能会改变程序员的工作方式,但创造性和解决复杂问题的能力仍然是人类的优势。