前端开发 · 2026年2月27日

AI Computer Use爆发前夜:你的前端代码对AI Agent友好吗

Anthropic上周收购了Vercept,一家专做AI操控电脑的创业公司。Vercept的核心产品VyUI在UI元素识别上打到了92%准确率,OpenAI同类方案只有18.3%。这不是一个小新闻——它意味着AI Agent直接操作GUI界面正在从demo变成产品级能力。作为前端开发者,这件事跟你直接相关:你写的每一个组件、每一行HTML,很快就不只是给人看的了,AI Agent也要”看”懂并且操作它。

AI Computer Use到底在做什么

先搞清楚技术原理。AI Computer Use的核心流程是:

截屏 -> UI元素识别(grounding) -> 理解当前状态 -> 决定操作 -> 执行点击/输入 -> 再次截屏验证

关键瓶颈在第二步:UI元素识别。模型需要从一张截图里准确定位”这个按钮在哪”、”那个输入框在哪”。Vercept的VyUI模型专门解决这个问题,看一下它和OpenAI方案的对比:

基准测试 VyUI OpenAI模型
ScreenSpot v1(UI元素定位) 92% 18.3%
ScreenSpot v2 94.7% 87.9%
GroundUI Web 84.8% 82.3%

ScreenSpot v1的差距尤其离谱——92% vs 18.3%,不是一个量级的东西。而Claude配合Sonnet 4.6在OSWorld(真实电脑任务基准)上已经做到72.5%,2024年底这个数字还不到15%。Vercept团队加入后这个数字大概率还会继续涨。

这跟前端有什么关系

AI Agent操作界面有两种路径:路径一:纯视觉,看截图操作。这就是Vercept在做的事,模型完全靠”看”来理解界面。路径二:结构化信息辅助。除了截图,模型还可以拿到DOM结构、accessibility tree等结构化数据来辅助决策。路径二的准确率显然更高,因为模型不用猜——你直接告诉它”这是一个提交按钮”比让它从像素里识别出来要靠谱得多。这就是前端代码质量直接影响AI Agent表现的地方。

实测:语义化HTML vs 乱写HTML,AI Agent的识别差异

我用Playwright的accessibility tree做了个简单测试,模拟AI Agent”看到”的DOM结构。先看一个典型的”能跑就行”写法:

<div class="btn-wrapper">  <div class="btn primary" onclick="submit()">    <span class="icon"></span>    <span>提交订单</span>  </div></div><div class="input-area">  <div class="label">用户名</div>  <div contenteditable="true" class="fake-input"></div></div>

AI Agent从accessibility tree看到的:

generic "btn-wrapper"  generic "btn primary"    generic ""    generic "提交订单"generic "input-area"  generic "用户名"  generic [editable]

全是generic,没有任何语义信息。AI Agent需要靠文本内容和位置关系去猜这些元素是什么。猜错了就点错地方。换成语义化写法:

<form aria-label="订单提交">  <label for="username">用户名</label>  <input type="text" id="username" name="username"          placeholder="请输入用户名" required />  <button type="submit">提交订单</button></form>

AI Agent看到的:

form "订单提交"  label "用户名"  textbox "用户名" [required]  button "提交订单"

button就是button,textbox就是textbox,label和输入框的关联也是明确的。AI Agent不需要猜任何东西。

Playwright抓accessibility tree的代码

如果你想自己测试自己的页面对AI Agent是否友好,可以用这段脚本:

const { chromium } = require('playwright');(async () => {  const browser = await chromium.launch();  const page = await browser.newPage();  await page.goto('http://localhost:3000');    const snapshot = await page.accessibility.snapshot();    function printTree(node, indent = 0) {    const prefix = ' '.repeat(indent);    const name = node.name ? ` "${node.name}"` : '';    const props = [];    if (node.required) props.push('required');    if (node.disabled) props.push('disabled');    if (node.checked !== undefined) props.push(node.checked ? 'checked' : 'unchecked');    const propStr = props.length ? ` [${props.join(', ')}]` : '';    console.log(`${prefix}${node.role}${name}${propStr}`);    if (node.children) {      node.children.forEach(child => printTree(child, indent + 2));    }  }    printTree(snapshot);  await browser.close();})();

跑一下你自己的项目,看看AI Agent”看到”的是一堆generic还是有意义的语义节点。

具体该怎么改:清单

根据实际测试,列几条对AI Agent识别率影响最大的改动:1. 用原生HTML元素,别自己造轮子

<!-- 别这样 --><div class="dropdown" onclick="toggle()">  <div class="selected">选项一</div>  <div class="options">...</div></div><!-- 该这样 --><select name="option" aria-label="选择分类">  <option value="1">选项一</option>  <option value="2">选项二</option></select>

原生select在accessibility tree里直接就是combobox角色,AI Agent能精确识别。自己用div模拟的下拉框,AI Agent只看到一堆嵌套div。2. aria-label给非文本交互元素加标签

<!-- 图标按钮必须有aria-label --><button aria-label="删除该条目">  <svg>...</svg></button><!-- 纯图标没有文本,AI Agent完全不知道这是什么 --><button>  <svg>...</svg></button>

3. label和input必须关联

<!-- for和id对应 --><label for="email">邮箱地址</label><input type="email" id="email" name="email" /><!-- 或者直接嵌套 --><label>  邮箱地址  <input type="email" name="email" /></label>

没关联的label和input,AI Agent无法确定哪个标签对应哪个输入框,多个输入框放一起时很容易搞混。4. 用data属性给AI Agent额外提示

<div role="tabpanel"      data-testid="user-profile-panel"     aria-labelledby="tab-profile">  ...</div>

data-testid本来是给E2E测试用的,但AI Agent同样可以利用这些稳定的标识符来定位元素。如果你的项目已经有E2E测试的data-testid,那恭喜,你已经走在前面了。

组件库的问题

主流组件库在这方面做得参差不齐。Radix UI和Headless UI做得好——它们底层就是基于WAI-ARIA规范构建的,输出的HTML天然对accessibility tree友好。Ant Design和Element Plus就比较看情况了。它们的组件输出通常有正确的ARIA角色,但也有不少组件是div套div,该补的aria-label得自己补。如果你用的是自研组件库,建议跑一遍上面的Playwright脚本,检查一下每个组件在accessibility tree里长什么样。不友好的组件重点补ARIA属性。

这不只是无障碍的事

你可能注意到了,上面说的所有实践本质上就是Web无障碍(a11y)的基本功——语义化HTML、ARIA属性、label关联。这些东西推了十几年,大部分项目还是没做好。但AI Computer Use给了一个全新的、更现实的动力:不是为了合规,不是为了小众用户群体,而是因为AI Agent的操作效率直接跟你的HTML质量挂钩。Anthropic收购Vercept意味着Claude的Computer Use能力会进一步增强。未来用户让Claude帮忙操作你的Web应用时,语义化程度高的界面体验会显著好于div糊出来的界面。这就是真金白银的用户体验差距。Vercept的VyUI在纯视觉路径上已经做到90%+的准确率。一旦再加上结构化的accessibility tree辅助,准确率还会更高。写好HTML不再只是”最佳实践”,它正在变成AI时代的基础设施。

行动建议

马上能做的:用Playwright脚本跑一遍你项目的核心页面,看accessibility tree的输出质量。generic节点超过50%的页面,优先整改。规范层面:在Code Review里加一条——自定义交互组件必须有对应的ARIA角色和label。CI里加一个axe-core扫描,不通过不让合。长期:选组件库时把ARIA支持作为评估标准之一。从div全家桶迁移到语义化HTML不需要一步到位,按页面优先级逐步改就行。AI Agent操作GUI这件事不是”未来某天”,Anthropic、OpenAI、Google都在押注这个方向。你的代码准备好了吗?