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都在押注这个方向。你的代码准备好了吗?