最近几个月，一个趋势在我身边越来越明显：团队里用 Cursor、Copilot、Claude Code 的人越来越多，但大家聊的不再是"AI 生成的代码有多好"，而是"review AI 代码有多累"。

一个同事上周跟我吐槽：以前 review 同事的代码，至少能理解他的思路，知道为什么这么写。现在 review AI 生成的代码，逻辑上没毛病，但总觉得哪里不对——命名风格不统一，错误处理过度防御，有些地方用了团队从没用过的设计模式，还有些地方莫名其妙地绕了一圈。

他说了一句让我印象很深的话："我感觉自己不是在 review 代码，是在面试一个永远不累的实习生。"

这句话点破了一个很多人还没意识到的事情：AI 编码工具正在把工程师的核心工作从"写代码"变成"审代码"，而大部分团队还没有为这个转变做好准备。

代码审查量在暴增，但审查能力没跟上

先说一个最直观的数据。Cursor 官方说他们的用户已经有超过 50% 的代码是 AI 生成的。我自己团队的感受也差不多——一个中等复杂度的需求，以前可能写两天，现在用 AI 辅助，大半天就能出初稿。

但"出初稿"和"能上线"之间，隔着一道巨大的鸿沟。

最近有个趋势越来越明显：前端工程师看着 Copilot、Cursor 生成的 UI 代码，开始焦虑自己是不是要被替代了。

我觉得这个焦虑方向搞错了。真正值得关注的事情，不是 AI 写的代码比你好，而是 AI 可能根本不需要写代码了。

谷歌刚发布的 A2UI v0.9 就是这个方向上的一步。A2UI 全称 Agent-to-UI，是一套与框架无关的标准，让 AI 智能体声明 UI 意图，由 Web、移动端、桌面端原生渲染。关键词是"声明意图"——AI 不需要生成 HTML、CSS 或组件代码，它只需要说"我需要一个什么界面"，平台自己搞定渲染。

这件事值得认真聊聊。

AI 生成代码的真正问题，不是代码质量

现在 AI 写前端代码的方式，本质上是"生成一堆代码，人来兜底"。Copilot 也好，Cursor 也好，甚至那些号称能生成完整页面的工具，都在解决同一个问题：怎么让生成的代码能跑起来。

但跑起来只是最低标准。在生产环境里，一段前端代码要真正"能用"，得跟已有系统严丝合缝地集成：用团队的设计系统、符合品牌规范、支持无障碍访问、不超标性能预算、跟现有状态管理兼容、能扛住国际化。

最近帮一个 Node.js 中间层排查 OOM。一个聚合接口，把三四个下游接口的数据拼一下吐给前端，单次请求的数据量也就两三 MB,看着毫无压力。但 Grafana 上常驻内存随 QPS 线性爬升，GC 触发得越来越频繁,终于在晚高峰把进程撑爆了。

翻代码，逻辑大致是这样：

```js
const responses = await Promise.all(
endpoints.map(url => fetch(url).then(r => r.json()))
)
return res.json(merge(responses))
```

看起来人畜无害。`fetch` 拿到的是流，`.json()` 一次性消费它，`merge` 拼好再 `res.json()` 序列化出去。整个链路里数据至少出现了三份：原始响应体、解析后的对象、合并后的对象。再加上序列化时的字符串缓冲，单请求峰值轻松到原始数据的四五倍。这还没算 V8 把这些短命对象塞进新生代、触发 Scavenge 的开销。

打开任何一个前端项目的代码，搜索 `catch`，你大概率会看到这样的画面：

```javascript
try {
await fetchData();
} catch (e) {
console.error(e);
message.error('操作失败，请稍后重试');
}
```

后端也好不到哪去：

```javascript
try {
await processOrder(orderId);
} catch (err) {
logger.error('订单处理失败', { orderId, error: err.message });
throw new BusinessException('系统异常，请重试');
}
```

这两段代码有一个共同的特质——它们让你觉得错误被"处理"了。日志打了，提示也弹了，异常也抛了，一切看起来都很体面。

但你仔细想想：用户看到"操作失败，请稍后重试"之后能做什么？重试？然后呢——再失败一次？运维看到一条"订单处理失败"的日志，能定位到什么？是库存扣减超时，还是支付回调丢失，还是风控拦截？