Cursor 让 AI 自己写了个浏览器被打假?谈谈现有的AI写代码为什么走上了歪路

新闻

作者：微信文章
大家好，我是bingfeng，杂食型软件工程师，架构师。今天偏个题，聊一个最近的新闻。Cursor 团队的一次「大胆实验」在技术圈刷了屏：让 AI 自主写一个完整的浏览器。演示视频、截图、Repo 链接一应俱全，300万行代码，还能有模有样跑一下，乍一看颇有「通用人工智能写大型软件」的味道。

但热度并没有持续太久。

很快，社区里的工程师开始“拆代码”：

架构混乱，没有清晰的分层，关键代码HTML解析，CSS计算，渲染都是引用外部模块

逻辑重复、状态失控

大量 copy-paste 痕迹

隐含 bug 成片出现，几乎无法维护

有人评价得很直接：这甚至算不上屎山，因为屎山至少还能运行和修补，而它只是代码垃圾。

问题来了：

为什么今天的 AI，已经能在 LeetCode、HumanEval、SWE-bench 上刷出极高分数，却一到真实工程，就迅速失控？

Cursor 的“AI 浏览器事件”，并不是偶然，它只是把一个长期被掩盖的问题，赤裸裸地暴露了出来。

---

一、这不是 Cursor 的问题，而是一整个市场的集体叙事


在指责 Cursor 之前，我们得先承认一件事：

Cursor 并不孤独。

过去一年里，类似的宣传反复出现：

“AI 写了我们 80% 的代码”（Claude 团队）

“公司已经进入 AI First Coding”

“工程师只负责 review，代码全部 AI 生成”

这些叙事在资本、媒体和社交网络中极其有效。

原因也很简单：AI 编码工具处在一个高度内卷、极度同质化的市场。当补全、重构、问答、Agent 都不再稀缺，唯一的差异化方式就是——

不断抬高 AI 能力的“想象上限”。

于是，我们看到了越来越激进的 Demo：

AI 写完整 App

AI 写完整系统

AI 自主完成复杂工程

Cursor 的浏览器，只是这个趋势中最显眼的一次翻车。

而真正值得讨论的，不是「AI 现在行不行」，而是：

为什么现有的 AI 编码路径，本身就注定会走向失败？

---

二、第一条歪路：我们让 AI 使用了“为人类设计的一切”


这是最根本、也最容易被忽略的一点。
1️⃣ 现有的语言、系统、工具链，都是为人类准备的


回顾现代软件工程的核心设计目标：

通用操作系统

通用编程语言

图灵完备

强调产品概念完整性

这些设计背后，其实指向同一个目标：

尽可能覆盖更多的应用场景，从而降低“人类”的学习成本。

代价是什么？

抽象复杂

边界模糊

允许不安全状态存在

这些风险，本来是由人类工程师来兜底的：

人类在 review 中发现问题

人类通过经验规避危险路径

人类在运行时排查异常

但当你把这一整套体系直接交给 AI，会发生什么？

👉 AI 面对的是一个巨大、连续、充满陷阱的潜在向量空间。

它既要理解业务，又要理解语言技巧，还要理解系统语义。

这不是“聪明不聪明”的问题，而是搜索空间本身就不适合 AI 收敛。

---

三、第二条歪路：Benchmark 强化学习的边际效应正在迅速枯竭


过去两年，AI 编码的进步路径高度一致：

针对代码任务做大量 RL

优化 benchmark 指标

HumanEval、MBPP、SWE-bench 分数不断刷新

这在“看得见”的指标上，确实有效。

但在真实工程中，情况完全不同。
为什么？


因为 benchmark 的本质是：

问题规模受控

目标明确

评估函数单一

而真实工程是：

目标不断变化

状态空间爆炸

正确性往往无法立即验证

当你把强化学习继续堆到真实工程上，结果只会是：

每多一点投入，带来的实际工程收益，越来越低。

Cursor 浏览器的问题，并不是“AI 还不够聪明”，而是：

再多的 RL，也改变不了工程复杂性本身。

---

四、第三条歪路：AI 在一个“过大的可能空间”里低效挣扎


从形式化的角度看，AI 写代码本质上是在做一件事：

在潜在向量空间中，搜索一段“可运行、可用、可维护”的程序。

而通用语言（C++ / Java / Python / JS）的特点是：

表达能力极强

语法和语义高度自由

等价实现路径数量巨大

结果就是：

搜索空间巨大

约束极弱

稍微复杂一点，系统就失控

于是你会看到：

AI 能写出“看起来对”的代码

却无法保证整体一致性

也无法长期维持工程结构

浏览器这种复杂系统，几乎是对这种模式的极限拷问。

---

五、第四条歪路：我们误以为“可读性”对 AI 也是优点


现代编程语言极度强调：

可读性

命名语义

面向对象建模

泛型与复用

但这些，几乎全是为人类服务的特性。

对 AI 来说，它们反而是噪声：

名字不等于语义

对象系统制造隐式状态

泛型放大搜索空间

继承层次隐藏真实行为

结论只有一个：

为人类设计的“好代码”，并不等于为 AI 设计的“好程序”。

---

六、真正的出路：假想一种“AI 友好的编程语言与工具链”


如果我们从零开始，为 AI 设计一套编程体系，它会是什么样？
1️⃣ 任务驱动的受限特定语言（Task-Specific DSL）


核心原则只有一个：

极度缩小搜索空间。

特征包括：

根据具体任务动态生成语言

强业务语义、强类型

限制甚至禁止递归和自由迭代

偏函数式，最小化状态

内建正确性约束

刻意移除：

通用对象系统

泛型系统

不必要的抽象层

语言不是长期资产，而是：

一次性工具，用完即弃。

---

2️⃣ 动态生成的“简单编译器 + 数学验证器”


针对特定任务：

自动生成一个极小编译器

在编译阶段完成必要的数学验证

尤其适用于 RoA-1 / RoA-2 类型角色

验证不是附加步骤，而是语言的一部分。

---

3️⃣ 使用受限语言完成任务


AI 不再“写代码”，而是：

在强约束语言中填充解空间

所有非法路径在生成阶段被排除

这一步，收敛性会出现质变。

---

4️⃣ 编译到目标执行环境


最终输出可以是：

现有平台代码

FPGA bitstream

甚至裸机直接执行

OS 不再是前提，而是可选项。

---

七、总结：AI 擅长编程，需要完全不同的前提条件


当编程语言和工具链为 AI 重新设计后，会自然出现一些关键特性：

极小攻击面，安全性指数级提升

设计上消除资源泄露、OOM、缓冲区溢出

性能可超过通用语言

与现有系统集成，但不依赖通用 OS

在某些场景下，直接消灭 OS 层

这不是优化，而是范式切换。

---

八、展望：真正的 AI 编程语言，一定会出现


Cursor 的浏览器翻车，并不是 AI 编码的终点。

恰恰相反，它说明了一件事：

我们已经走到了旧范式的尽头。

在未来几年内：

AI 原生编程语言会出现

工具链会从“通用”走向“任务定制”

编程不再是长期资产积累，而是即时构造

到那时，再回头看今天的“AI 写浏览器”，

它更像是：

用蒸汽机的设计哲学，去解释喷气式发动机为什么飞不远。

问题不在 AI，

而在我们给它的世界，本就不该这样。