Rick 用 Claude 写下 18 万行代码，在 Wine 中实现 Paint

关注 Wine 兼容性层时，Rick Brewster 实现 Paint 的经历让我深感触动。这不只是完成一个功能，而是一场极其激进的 AI 协作实验。他借助 Claude 产出了整整 18 万行代码，并将这种方式形容为一种"极其不可靠但高效"的"Vibe Coding"（氛围编程）。

在这种模式下，程序员的身份从"代码编写者"转向"AI 导师"和"代码审查员"。问题在于，面对 18 万行代码，人类根本不可能完成一次完整的 Code Review。Rick 也坦言，很多模块未经严谨审查，仅凭"Trust me bro"的直觉便直接合入并运行起来。

整个开发过程显得十分诡异：AI 看起来像是由十几个天才程序员组成的联合体，瞬间就能给出极其精准的架构建议；可紧接着，它又会犯一些非常低级的错误。内存管理便是一个典型例子，Claude 曾在很长一段时间里连续忘记在 COM 组件中调用 AddRef()。对任何一位资深 C++ 开发者来说，漏掉引用计数都会造成内存泄漏和不可预知的崩溃。这种错误在传统开发中几乎不可原谅，但在 AI 驱动的快速迭代中，它变成了需要反复修正的"噪音"。

为何 AI 在数学问题上反而更可靠？

Rick 还提到，Claude 在设计架构时偶尔会给出一些极其愚蠢的方案，气得他想要"slap 它一顿"。然而，面对复杂数学问题时，这种不稳定性又转化成了强大的生产力。处理 Direct2D 内置特效库所需的数学公式时，Claude 展现出了惊人的理解力和勤奋度，能够迅速推导并实现枯燥的图形学计算。这部分效率甚至让 Rick 这种级别的开发者都感到惊叹。

逆向工程构建如何绕开文档依赖？

这次实现 Paint，并不是让 AI 模拟 Direct2D API 的既有行为，而是从零开始进行一次"逆向工程构建"。AI 没有翻阅现成文档来复刻，而是在不断的指令与调试中，构建出一套功能等效的新实现。

18 万行代码的审查成本为何失控？

这种方式的核心矛盾非常明显：它大幅降低了开发门槛，同时也在代码质量上埋下巨大隐患。面对 18 万行代码，没有任何一个人敢拍胸脯保证绝对没有 Bug，因为审查成本已经超过人类的认知极限。最终，它在功能上跑通了 Wine 对 Paint 的支持，而采用传统且追求严谨的开发模式，可能需要数倍的时间成本与人力投入。

结果导向编程能否容忍随机缺陷？

这次实验带来的启发是，AI 编程正在进入一个"以结果为导向"的狂暴期。当代码规模增长到一定程度，传统审查机制失效后，我们或许需要接受一种新的共存方式：容纳 AI 带来的随机性缺陷，只要它能实现功能闭环。这种"Vibe Coding"听上去并不专业，但在 Wine 这种庞大而复杂的兼容层开发面前，它或许是目前唯一能够快速突破瓶颈的手段。