100 万行代码的“海市蜃楼”：为何 Cursor 的 AI 浏览器是一场被高估的狂欢？

在 AI 编程领域，并没有什么比“从零构建一个浏览器”更性感的军令状了。

1 月 14 日，Cursor 发布了一篇名为《Scaling long-running autonomous coding》（扩展长期运行的自主编码）的博客文章，引爆了整个开发者社区。文章描绘了一个令人眩晕的未来：数百个 AI 智能体（Agents）在数周内协同工作，在没有人类干预的情况下，编写了超过100 万行代码，横跨1000 多个文件，构建了一个名为fastrender的网络浏览器。

听起来像是科幻电影成真了？先别急着庆祝。

当我们剥开“自主智能体”和“百万行代码”的华丽外衣，深入 GitHub 仓库的真实代码时，看到的不是工程学的奇迹，而是一场无法编译的“AI 废料（AI Slop）”狂欢。

01. 只有“苦劳”，没有“功劳”

Cursor 在文章中使用了极具误导性的叙事手法。他们展示了复杂的视频演示，声称这一实验“解决了大多数协调问题”，并取得了“有意义的进展（meaningful progress）”。

然而，作为一名软件工程师，我们判断“进展”的标准只有一个：代码能跑吗？

答案是残酷的：不能。

如果你尝试克隆他们公开的仓库fastrender并运行最基础的构建命令：

cargo build

迎接你的不是浏览器的启动画面，而是编译器绝望的尖叫——34 个错误（Errors），94 个警告（Warnings）。

这不是偶尔的构建失败。翻看该项目的 Git 历史，你会发现一个惊人的事实：在最近的 100 次提交中，找不到任何一个能够干净编译的版本。CI（持续集成）流水线全线飘红，所有的 Pull Request 都是在测试失败的情况下强行合并的。

这意味着什么？这意味着那数百个日夜工作的 AI 智能体，从未执行过一次成功的cargo check。它们就像一群不知疲倦但毫无常识的打字员，疯狂地堆砌代码，却从不检查这些代码是否符合逻辑、是否符合语法。

02. “AI 废料”的诞生

我们在fastrender中看到的，是典型的“AI Slop”（AI 废料）。

这是一种看起来像代码、读起来像代码、甚至结构也像代码的产物。但它缺乏软件工程最核心的灵魂——意图（Intention）和 因果律（Causality）。

• •没有工程底线：一个标榜“从零构建浏览器”的项目，居然连最基本的 HTML 文件渲染演示都无法复现。
• •忽视最佳实践：GitHub Issue #98 已经成为了开发者们的吐槽大会，指出了大量根本性的架构错误。
• •数量不仅不代表质量，反而成为了累赘：AI 生成了 100 万行代码，这听起来很酷，但对于维护者来说，这 100 万行无法运行的代码就是纯粹的技术债务。

Cursor 的博客文章极其狡猾地回避了“功能性”问题。他们用“极其困难（extremely difficult）”来形容这个任务，用截图来暗示成功，却从未明确说过：“嘿，这东西真的能用。”

03. 重新定义“成功”？

Cursor 得出的结论是：“我们可以通过增加智能体数量来扩展自主编码。”

但这结论真的站得住脚吗？如果投入更多的智能体，只是为了更快地生成更多无法编译的垃圾代码，这叫什么“扩展”？这叫熵增。

一个真正的“浏览器实验”不需要对标 Chrome。它的底线应该是：在支持的工具链上通过编译，并渲染一个最简单的 HTML 文件。

Cursor 目前展示的，连这个最低门槛都没跨过。

结论：我们需要的是工程师，不是“Token 生成器”

Cursor 的这次实验，与其说是 AI 编程的里程碑，不如说是一次警示。它告诉我们，当前的 Agentic Coding（代理编码）在缺乏严格的反馈循环（如编译器检查、单元测试）时，会退化成何种模样。

真正的技术进步，不是看谁生成的 Token 多，不是看谁的仓库文件多，而是看谁能交付可用的、可维护的、解决实际问题的软件。

在 AI 能够学会先运行cargo build再提交代码之前，请不要告诉我们它已经“解决了协调问题”。

参考资料：

1. 1.Cursor Blog Post:Scaling long-running autonomous coding
2. 2.GitHub Repository:wilsonzlin/fastrender
3. 3.GitHub Issue (Build Failures):Issue #98 - Compilation Errors