DHH谈AI编程能力边界：哪些场景可100%由AI生成代码

在与Lex Fridman的一场深度对话中，Ruby on Rails之父、37signals联合创始人DHH（David Heinemeier Hansson）分享了他对AI编程能力边界的最新判断。作为一位从质疑到"完全被AI说服"的资深开发者，他的观察格外值得关注：AI在某些领域已经可以100%生成生产环境的代码，但在另一些场景中却出人意料地难以完全接管。

37signals是科技行业中一家极具影响力的"反主流"公司。在硅谷追逐风险投资、疯狂增长和IPO的大环境下，37signals坚持自筹资金、小团队运营和盈利优先的经营哲学。其旗下产品Basecamp是项目管理领域的先驱之一，而HEY则是一款试图重新定义电子邮件体验的产品。DHH本人不仅创建了Ruby on Rails——这个框架直接催生了Twitter、GitHub、Shopify等科技巨头的早期技术栈——还以其直言不讳的技术观点闻名。他曾公开批评微服务架构、反对TypeScript、质疑云计算的成本效益，并推动37signals从云端迁回自建服务器。正因为DHH长期以来对新技术潮流保持审慎甚至怀疑的态度，他从"质疑AI"到"被AI完全说服"的转变才更具说服力——这不是一个容易被技术炒作打动的人。

按领域划分：AI编程能力的天壤之别

DHH首先指出，程序员工作的领域千差万别，而AI在不同领域的成熟度也截然不同。他将开发工作大致划分为几个梯度。

最普遍、也是AI最擅长的领域是Web开发中的CRUD应用——有数据库、有面向用户的界面，数据在两者之间来回流动。这类系统无论是服务于一个人、少数人还是全世界，AI都能做得极好。

CRUD是Create（创建）、Read（读取）、Update（更新）、Delete（删除）四个基本数据操作的缩写，几乎所有Web应用的核心逻辑都可以归结为这四种操作的组合。从电商平台的商品管理到社交媒体的帖子发布，从企业后台的用户管理到内容管理系统，CRUD操作构成了Web开发中最大比例的工作量。正因为这类应用的模式高度标准化——表单收集数据、API传输数据、数据库存储数据、界面展示数据——它们拥有海量的开源代码和教程作为训练语料，使得AI模型能够极其精准地理解并生成这类代码。Ruby on Rails框架本身就是为了简化CRUD开发而设计的，其"约定优于配置"的哲学思想让标准化的Web应用开发变得高度模式化，这恰好与AI擅长模式识别和复现的特性完美契合。

"对于这个领域，你真的可以做到100%的代码由AI编写。如果你是一个好程序员，对背后发生的事情有良好的直觉，你完全可以不看代码。"

他强调，这里的关键在于开发者能否通过"系统的涟漪效应和症状"来直觉性地判断一切是否正常运转。而在安全关键系统——比如核电站控制或自动驾驶汽车——则需要更仔细地审查代码。

AI在安全漏洞挖掘上的超人表现

谈到安全领域，DHH提出了一个反直觉的观点：AI在发现和修复安全漏洞方面的能力已经强得惊人，甚至超越了绝大多数人类专家。

他以某个模型（对话中提及的"Fable"事件）为例——这个模型发现漏洞的能力太强，以至于"直接发布是不安全的"。原因在于，许多严重的安全漏洞并非单点问题，而是需要将多个看似无害的小漏洞"组合成连招"：

"你在这里发现一个小漏洞，单独看可能不算什么，但你把它和另外四个组合起来，突然就变成了RCE（远程命令执行）。能做到这一点的人类极其罕见。"

RCE（Remote Code Execution，远程代码执行）是网络安全领域中最严重的漏洞类型之一，攻击者可以在不接触目标物理设备的情况下，在远程服务器上执行任意代码，从而完全控制目标系统。DHH提到的"组合连招"在安全领域被称为"漏洞链"（Exploit Chain），这是高级持续性威胁（APT）攻击中的常见手法。单个漏洞可能只是一个低危的信息泄露或权限提升，但将多个漏洞串联起来，就可能实现从外部网络直达内部核心系统的完整攻击路径。传统上，具备这种漏洞链构造能力的安全研究员在全球不超过数百人，他们通常服务于国家级网络安全机构、顶尖安全公司的红队或Bug Bounty猎人社区。AI在这方面的突破意味着漏洞发现的门槛正在被彻底重塑，这既是防御者的福音，也是攻防格局的根本性变化。

他指出，具备这种能力的人类通常隐藏在国家支持的组织或秘密行动中，而现在AI已经在这方面"变得如此擅长"。这意味着在安全漏洞挖掘这类高度专业化的智力任务上，AI已达到了几乎无人能及的水平。

从Linux发行版到100%AI生成代码的实践

DHH坦言，让他彻底转变态度的正是他自己的Linux发行版项目——Omarchi（对话中的Umachi/Quattro版本）。在过去三个月开发最新版本Quattro的过程中，AI智能体的"加速比"几乎从一开始就接近100%，而在最近两个月里达到了完全的100%。

"Quattro中发布的代码，没有一行是我手写的。我审查了所有代码的整体形态，审查了系统模型层中所有关键部分的每一行。但大量UI代码和辅助代码，我根本没看。"

这是一个惊人的表态。作为Rails的作者，DHH对代码质量的要求极高，而他现在愿意在一个追求速度、需要精细控制的系统项目中，让AI承担全部编码工作，自己只做架构层面的审查。他的做法揭示了一种新的协作模式：人类负责架构与关键路径审查，AI负责全部代码实现。

大型Web产品的意外难题：架构会被氛围编程摧毁

有趣的是，DHH发现真正难以完全交给AI的，恰恰是那些看似简单的成熟Web产品。37signals旗下的Basecamp和Hay拥有大量用户和相对庞大的代码库，事实证明它们"出人意料地难以用AI智能体完全加速"。

大型遗留代码库（Legacy Codebase）是软件工程中最棘手的挑战之一。当一个产品经过多年迭代、数十甚至数百位开发者经手后，代码库中会积累大量的隐式约定、历史决策和技术债务。这些信息往往不存在于任何文档中，而是嵌入在代码结构、命名规范、模块边界和测试用例之中。AI模型在处理这类代码库时面临的核心困难在于：它能理解每一行代码的语法和局部语义，但很难把握整个系统的"架构意图"——为什么某个模块被设计成这样、为什么某些功能被刻意分离、哪些看似冗余的抽象层实际上承载着关键的可扩展性。

他讲述了一个教训深刻的案例。在开发Basecamp 5的冲刺阶段，团队曾一度以为问题已经解决——让设计师直接做编程，因为他们清楚想要什么功能、什么形态，于是"让他们尽情vibe coding（氛围编程）"。

氛围编程（Vibe Coding）这一概念由前OpenAI研究员、特斯拉AI总监Andrej Karpathy在2025年初提出，指的是开发者不再逐行编写代码，而是通过自然语言向AI描述自己想要的功能和"感觉"，让AI生成完整的代码实现。开发者的角色从"代码编写者"转变为"意图表达者"——你只需要描述你想要什么样的交互体验、什么样的界面效果，AI就会将这些模糊的"氛围"转化为具体的代码。这种方式极大地降低了编程的门槛，让设计师、产品经理甚至完全没有编程经验的人也能快速构建功能原型。

"我们最终得到了大量PR，单独看每一个在某一刻或许都说得通。但全部加在一起，摧毁了系统的架构。我们不得不手动清理，用人类的双手把它擦干净，才回到一个感觉连贯一致的架构。"

这正是氛围编程的最大风险所在：它优化的是单个功能的局部最优，而非整个系统的全局一致性。每个独立生成的PR可能都能正常工作，但它们各自做出的架构假设可能相互矛盾，最终导致系统的整体架构退化——就像在一座精心设计的建筑上随意加盖房间，最终导致整栋建筑的结构失衡。

这引出了一个核心问题：在现有的、有实质规模的代码库上进行氛围编程，你必须自己是程序员——如果你想保留让系统走到今天这一步的架构要素。DHH也补充说，这是几个月前的情况，如今工具已经进步很多。

AI生成垃圾代码？人类程序员也一样

对于"氛围编程者是垃圾代码生成器"这一常见批评，DHH毫不客气地反驳。他认为批评者应该先看看普通程序员在真实项目中的产出。

"如果你看过许多伟大公司幕后的代码库，看看在3000个人经手之后它们变成了什么样子——那些代码糟糕透顶，绝对糟糕透顶。"

这一观点提醒我们，评判AI生成代码的质量时不应用一个理想化的标准，而应与真实世界中人类协作产生的代码相比较。在这个意义上，AI生成的代码未必更差，甚至在一致性上可能更好。

AI编程的能力边界正在快速移动

DHH的这番分享，勾勒出了当前AI编程能力的真实图景：

• CRUD Web应用和安全漏洞挖掘：AI已经接近甚至超越人类
• 追求极致的系统项目：人类审查架构、AI实现细节的协作模式已经成熟
• 大型遗留代码库：完全自动化仍需要人类程序员把握架构一致性

说个细节，DHH反复强调"这是几个月前的情况，现在已经大不相同"。AI编程的能力边界正在以惊人的速度移动，而对开发者而言，真正稀缺的能力或许正在从"写代码"转向"判断代码是否正确"和"守护系统架构"。

核心要点