Paint.NET的作者Rick Brewster在论坛里扔出一句实话:18万行代码,我不可能审完。这不是抱怨,是他给自己新写的WINE兼容层下的注脚——这套代码,主要是Claude写的。
发生了什么
Direct2D一直是Paint.NET在WINE上跑不顺的老毛病。这个图形接口在WINE里从来没被实现到够用的程度,而Paint.NET又没法直接关掉对它的依赖。Brewster的解法很直接:从零逆向重写一套Direct2D替代实现,专门给WINE环境用,存在PaintDotNet.Windows.Direct2D1.Managed.dll里,通过/wine参数触发,论坛帖子标题写着“extremely experimental”——这是实验功能,不是稳定支持。
这套东西的作者写的是Claude。Brewster说得很坦白:大部分代码是“vibe coded”——没有经过认真审查,基本是“trust me bro”式信任。作为对照,Paint.NET主体代码大约70万行,他自己写了二十年;而Claude生成的这18万行,他连逐行看一遍都做不到。
能力与代价
Claude干得漂亮的地方,是把Direct2D内置特效库背后的一堆公式,一个个逆向推出来。Brewster原话是“像十个刚解开镣铐的爱因斯坦级10x程序员”。这活儿枯燥、需要耐心比对行为细节,恰恰是AI擅长啃的硬骨头。
但翻车的地方也不含糊:COM对象的引用计数——相当于AddRef()的操作——Claude一度就是没做,资源管理出了问题。架构设计上也出现过明显的坏决策,Brewster得回头“打回去”重做。
这两件事说明一个道理:AI在“把已知规律翻译成代码”这件事上效率极高,但在“系统该怎么设计、边界条件有没有想全”这件事上,仍然需要人盯着。
我的判断
“纸上得来终觉浅,绝知此事要躬行”——古人说的是知识不能只靠听说,得亲手试过才算数。放到今天,这句话反过来同样成立:代码能被生成出来,不代表它已经被“知道”了。Claude写出18万行能跑的东西,是真本事;但“能跑”和“被验证过、被理解过、出了问题能被人接手修”,中间还差一整层功夫。
- 结论.AI编程的分水岭不再是“能不能生成代码”,而是“谁来验证、谁能维护、出事谁担责”。Brewster自己承认这批代码没被真正审过,这不是谦虚,是风险还悬在那儿。
- 风险.clean-room逆向重写在法律上是不是干净的,目前没有定论;“实验性支持”也不等于Direct2D已经被完整、稳定地兼容了。
我不太买账的说法,是把这类故事简单讲成“AI自己写完了一个大项目”。事实是Brewster全程在盯着、纠着、否着——COM引用计数那个坑,是他发现的,不是Claude自己意识到的。AI把逆向工程这种苦活儿的效率拉起来了,这点该认;但审查、验证、长期维护的成本,一分没少,只是被往后推了。等这套“实验性”的Wine支持真要走向稳定可用的那天,才是账单结清的时候。