这周 Paul Dix（InfluxDB 创始人，经由 Simon Willison 转发）抛出一个数：某个项目用 AI 写出 100 万行代码，几个月打磨后跑在数百万开发者机器上。我们关心的是他紧接着的话——「前提是有人搭好脚手架」。

这是什么

Bun（JavaScript 运行时和工具链）是这场讨论的典型案例。它能在短时间内达到生产可用，背后是 AI 写了绝大部分代码，再由团队几轮迭代。Paul Dix 本人不是项目作者，但作为开源老兵，他对这件事的判断比多数营销稿克制。

他反对的简化叙事是：不就是把一门语言翻译到另一门吗，有原代码做对照当然简单。他的回应是：是的，但「搭出验证系统」本身就是工程能力的体现。如果你能把「什么算对」翻译成机器可执行的检查，AI 就能把代码打磨到能用的程度。

行业怎么看

支持方把这种案例当作「Agent（自主执行多步任务的 AI 助手）已能交付生产级软件」的证据。GitHub Copilot、Cursor 等产品的演示越来越接近「需求进去、可运行代码出来」的形态。

反方也有依据。批评者认为「有 oracle 做对照」这句话被低估了——翻译型任务有现成标准，而真正难的是从零定义「什么算对」。Paul 本人的表述其实站在中间：他没否认脚手架是难点，所以结论是「脚手架决定上限」，不是「AI 决定上限」。

更冷静的解读是：软件工程的瓶颈正在从「写代码」挪向「写测试 + 写规范」。验证系统本身，成了新的核心技能。

对普通人的影响

对企业 IT：短期不必恐慌。能用 AI 产出百万行可靠代码的团队，背后通常有成熟工程实践；没有这套实践的团队直接上 Agent，反而更快踩坑。

对个人职场：开发者的核心竞争力，正从「码字速度」挪向「拆解问题、设计验证、写出可被 Agent 理解的规范」。这三项能力，过去不被重视，现在值得刻意练。

对消费市场：未来一年会有更多「几小时做出原型」的小 SaaS；门槛降低意味着同质化加剧——能跑出来的不一定是技术最好的，而是定位最准的。