AI智能体网站可操作性自测清单：注册、询价、下单流程能不能走通

**AI智能体网站可操作性，指一个自动化智能体能否在无人干预下，从入口一路走到确认页并拿到可读回执。**它和「能不能被 AI 读到」是两件事——我们实测的 180 次流程里，内容全部能被读取，但只有 35% 真正走完了。

大部分品牌现在盯的还是 AI 提及率和 AI 搜索排名：DeepSeek 有没有推荐我、豆包答案里有没有我。这层要盯。但当智能体开始替用户直接下单时，漏斗末端多了一段没人测过的路——被提及、被点开、然后被走通。前两段做满分，第三段断了，转化照样是零。

这篇给的不是原则，是一套今天下午就能跑完的自测方法：怎么测、断在哪、阈值定多少、先修哪个。

什么是 AI 智能体网站可操作性？

AI智能体网站可操作性是指：一个基于可访问性树（accessibility tree）操作浏览器的智能体，能否独立完成注册、询价、下单这类多步任务，并从页面读到一段明确的成功凭证。 判定二值化——走到确认页且能复述回执，算通过；其余算失败。

这个定义有三个刻意的地方。第一，主语是程序不是人，「视觉上很清楚」不算数。第二，终点是确认页不是提交动作，点了按钮没回执等于没完成。第三，要求「能复述」——智能体必须拿到纯文本证据，一个绿色对勾图标它读不出来。

需要先划清边界：本文测的是开放网页上的通用浏览器智能体（Claude 的 Computer Use、OpenAI Operator 一类，以及基于可访问性树快照的开源方案），不是平台自有智能体调用自家封闭交易 API 的场景。后者不走 DOM，前者才是你的站点需要承接的那一类。

「能被读到」和「能被操作完」差在哪：可读、可达、可完成三层模型

多数 AEO 优化的讨论停在第一层。三层拆开，问题定位会快很多：

层级	问的问题	典型检查项	失败后果
L1 可读	内容能被抓取和渲染吗	robots、SSR/CSR、结构化数据、正文可提取	不被引用，AI 答案里没有你
L2 可达	关键动作入口能被程序定位吗	按钮有无可访问名、表单有无 label、自定义控件的 role	智能体找不到「提交」在哪
L3 可完成	整条流程能端到端走完吗	多步状态保持、弹窗遮罩、验证码、登录态、成功回执	半路中断，用户放弃

L1 属于传统 AI搜索优化的地盘，L2 和可访问性高度重合，L3 是几乎没人系统测过的一层。三层是递进关系：L1 不过，后两层无意义；L1、L2 都过，L3 依然可能全军覆没——我们样本里就有 3 个站点内容抓取完美、控件全部有名字，但因为弹窗时序问题，5 次实跑一次没成。

L1 做得再好也只买到「被推荐」这一步。如果你还在纠结前两层要不要投入，AI 先给答案的时代 SEO 还值不值得做那篇给的结论是：值得，但衡量口径要换——而本文这套 L3 指标，就是新口径里最容易被漏掉的一段。

我们测了什么：12 个站点、36 条流程、180 次实跑

**测试期 2026 年 5 月 12 日至 6 月 6 日。**样本为 12 个中文商业站点：4 个 B2B SaaS（官网询价/预约演示）、4 个电商（加购至支付前一步）、4 个消费服务（注册开户/线上预约）。每站定义 3 条目标流程，共 36 条，每条独立重跑 5 次，合计 180 次。

执行环境为桌面 Chrome，驱动方式是基于可访问性树快照的浏览器智能体（browser-use 这类开源方案，以及 Chrome DevTools MCP 的 snapshot 模式），并用 Playwright 脚本做对照，交叉确认失败点是「智能体不会」还是「页面确实不可达」。

三条判定规则先说清楚：

• 每次重跑清空 cookie 和本地存储，模拟冷启动；这是智能体的常态。
• 只给一次自然语言指令，中途不补提示。人类补一句「点右上角那个 X 关掉」就能过的，不算通过。
• 成功标准是智能体能原样复述回执文本，不是它自己说「我完成了」。

样本量的边界也要说明：12 站 × 5 次的规模，足以定位断点类型的相对排序，但单项占比的置信区间不窄（26.5% 这类数字应读作「最大的一类」，不是精确值）。跨行业推广时，电商和 B2B 的差距比样本内更大是大概率事件。

还有一个在正式测试前就出现的结论：连通性预检阶段，12 个站点里有 4 个对非常见 User-Agent 直接返回验证页或 403。我们统一切换到真实浏览器指纹后才进入正式测试。如果你的 WAF 规则做得很粗，很多智能体连第一步都到不了——这条不写进后面的失败统计，但它是真实存在的第 0 号断点。

实测结果：180 次里只有 63 次走到了确认页

**整体流程完成率（AFCR）35%。**分流程类型看，差距非常大：

流程类型	尝试次数	走到确认页	完成率
询价 / 预约演示	60	33	55%
注册 / 开户	60	21	35%
下单至支付前	60	9	15%
合计	180	63	35%

比总数更值得看的是稳定性：36 条流程里，5 次全部通过的只有 10 条（28%）；完全跑不通的 18 条；剩下 8 条「时成时败」。「有时候能过」比「一直过不了」更麻烦——它意味着监控看不出问题，用户侧却在随机流失，根因通常是弹窗出现时机或异步加载竞态。

失败归因（117 次失败）如下，这里出现了本次测试最反直觉的一条结论：

断点类型	失败次数	占比
动态弹窗 / 遮罩抢焦点	31	26.5%
多步表单状态丢失	24	20.5%
隐藏必填项 / 控件无可访问名	22	18.8%
登录态与 OTP 验证	18	15.4%
验证码与风控拦截	14	12.0%
成功回执不可判定	8	6.8%

**验证码不是第一杀手，你自己加的弹窗才是。**行业讨论几乎全部聚焦在 CAPTCHA 上，但在我们的样本里它只排第五。把弹窗、隐藏必填、回执三类加起来是 52%——超过一半的失败，是品牌方自己在 30 分钟内能改掉的东西，不需要动风控策略，不需要开发排期。

六类断点逐项拆解与修复动作

断点一：动态弹窗与遮罩——被抢走的那三秒

现象：页面加载后 2–5 秒弹出优惠券、Cookie 同意、客服 widget 或退出挽留层，覆盖在提交按钮上方。智能体已经算好了坐标准备点击，遮罩恰好在这时插进来。

判定标准：在提交按钮中心坐标上调用 document.elementFromPoint()，返回的如果不是按钮自己，就是被盖住了。

修复：所有非法定必需的弹窗延后到用户产生第一次交互后再出；关闭按钮必须是 <button aria-label="关闭"> 而不是一个 <div> 里的图标；Cookie 横幅用底部固定条，不要用全屏遮罩。这一条改完，我们复测的 6 个站点平均 AFCR 从 22% 提到 51%——单项改动里收益最大的一条，也是唯一一条前端一个人半小时能改完的。

断点二：多步表单——状态丢在第几步

现象：向导式表单第二步刷新后回到第一步；「上一步」清空已填数据；步骤间靠内存态而非 URL 或 sessionStorage 传递。

判定标准：在第 N 步手动刷新页面，如果已填内容消失，智能体的任何一次重试都会从头开始，且很可能触发重复提交拦截。

修复：每一步给独立 URL（/quote/step-2），关键字段落 sessionStorage；步骤指示器用 aria-current="step" 标注当前位置。

断点三：隐藏必填项与无名控件

现象：视觉上看不见但校验必填的字段（条件显隐、折叠区块内）；自定义下拉、开关、评分控件用 <div> + JS 实现，没有 role 和可访问名。

判定标准：按 W3C WAI-ARIA 1.2 规范，每个可交互元素都应有明确的 role 和 accessible name。用 getByRole('button', { name: '提交' }) 定位不到的控件，智能体基本也定位不到。

修复：优先用原生 <button>、<select>、<input>；确实要自定义就补齐 role + aria-label；条件必填项在触发时用 aria-live 区域播报，而不是提交后才红字报错。

断点四：登录态与 OTP

现象：下单前强制登录，登录要短信验证码，验证码进了用户手机而智能体拿不到。这是下单流程完成率只有 15% 的主因——12 次下单失败中有 9 次卡在这里，且全部发生在第 2–3 步，用户连商品页都还没走完。

修复：开放游客下单是投入产出比最高的一步。保留账号体系没问题，但把「必须登录才能询价/加购/结算」改成「可选登录」。B2B 场景同理：预约演示不该要求先注册。

如果账号墙必须保留，退一步的做法是把关键信息前置到不需要登录的页面上——价格、库存、规格、对比表放在公开 URL 上，智能体至少能替用户完成决策环节再把最后一步交还给人。这也是/vs 和 /alternatives 页面能被 AI 大量引用的同一个原因：可公开读取的结构化对比信息，机器拿得走。

断点五：验证码与风控

现象：滑块、点选文字、reCAPTCHA v2。硬墙，且短期内不会消失。

修复思路是分级而不是关闭。别为了智能体关掉验证码——那是拿安全换转化。可行方向是身份可验证：AWS 在 Bedrock AgentCore Browser 支持 Web Bot Auth 的说明里提到，这套基于 IETF 草案的机制给智能体可验证的密码学身份，Cloudflare、Akamai、AWS WAF 等可以据此放行已验证机器人而不弹验证码。

近期先做一件事：把验证码从「全流程强制」改成「风险触发」，低风险表单（询价、订阅、预约）不要挂。同时检查 robots.txt 和 WAF 规则里对 AI 爬虫的处置——很多站点在 L1 层就把 GPTBot、ClaudeBot 拦了，却在 L3 层期待智能体带用户来。

断点六：成功回执不可判定

现象：提交成功后只有一个 toast 弹一下就消失、只有一个动画对勾、或者跳转到一个标题写着「感谢」但没有任何订单号的页面。

判定标准：成功后页面上必须存在一段稳定停留、可被选中复制的纯文本，包含「成功 / 已提交 / 订单号 / 预计联系时间」中至少两项。

修复：成功页给一个 <h1>提交成功</h1> 加一段确认文案，附上单号；不要只靠 toast。这一步对 AI可见度有额外收益——可复述的确认文本同时是智能体愿意向用户转述的内容。同一个道理在引用侧也成立：AI 搜索最常引用的内容格式排下来，纯文本的、结构清晰的、能被整段摘出来的一直排在前面。

可复现的自测脚本：零代码版与 Playwright 版

零代码版：三条固定 Prompt，各跑 5 次

打开任意能操作浏览器的智能体，逐字使用下面的指令，中途不要补充任何提示：

1. 打开 {URL}，用邮箱 {测试邮箱} 注册一个账号，一直做到看到注册成功的提示为止，然后把你看到的成功提示原文贴出来。
2. 在 {URL} 提交一次询价，公司名填「测试公司」，需求写「了解报价」，提交后把页面回复的原文念给我听。
3. 在 {URL} 把 {商品名} 加入购物车，走到支付页面前一步停下，把订单确认页上的金额和收货信息念出来。

**判定口径只有一条：能不能原样复述回执。**说「我已经完成了」但复述不出文本的，一律计为失败。5 次里成功次数就是这条流程的 AFCR。

跑之前准备两样东西：一个能收信的测试邮箱（用 +tag 后缀区分批次），以及和运营打好招呼——这些测试会真实进入你的线索池和订单系统，公司名统一填「测试公司」便于事后清理。

代码版：用语义定位器当「可达性」代理指标

这是本次测试里最有用的发现——不用真跑智能体，也能提前预测完成率。我们对 36 条流程的关键控件统计了 Playwright role 与 label 定位器的可定位率，它和实际完成率强相关：

关键控件语义可定位率	流程条数	平均 AFCR
≥ 80%	12	62%
50%–79%	15	31%
< 50%	9	7%

原因不难理解：Playwright 的 getByRole 走的是和智能体同一套可访问名计算规则。**Playwright 找不到的按钮，智能体大概率也找不到。**这让你可以用一个几秒钟跑完的确定性脚本，替代昂贵且不稳定的智能体实跑。

注意这是上界估计而不是等价物：可定位率 ≥80% 的那 12 条流程平均 AFCR 也只有 62%，缺口全部来自 L3 特有的时序和状态问题。可定位率低几乎必然跑不通，可定位率高只是必要条件。

// agent-reachability.spec.js —— 先估「可达」，再验「可完成」
import { test, expect } from '@playwright/test';

const FLOW = {
  url: 'https://example.com/pricing',
  steps: [
    { action: 'click',  role: 'button',   name: '预约演示' },
    { action: 'fill',   label: '公司邮箱', value: 'agent-test@example.com' },
    { action: 'fill',   label: '公司名称', value: '测试公司' },
    { action: 'select', label: '团队规模', value: '51-200' },
    { action: 'click',  role: 'checkbox', name: '我已阅读并同意' },
    { action: 'click',  role: 'button',   name: '提交' },
  ],
  success: { role: 'heading', name: /提交成功|已收到你的需求/ },
};

test('语义可达性与端到端完成', async ({ page }) => {
  const missing = [];
  await page.goto(FLOW.url, { waitUntil: 'domcontentloaded' });

  for (const step of FLOW.steps) {
    const el = step.label
      ? page.getByLabel(step.label)
      : page.getByRole(step.role, { name: step.name });

    // 第一层：找得到吗——找不到就记账，继续往下走
    if (await el.count() === 0) { missing.push(step); continue; }

    // 第二层：真的操作一次
    if (step.action === 'fill')   await el.fill(step.value);
    if (step.action === 'select') await el.selectOption(step.value);
    if (step.action === 'click')  await el.click();
    await page.waitForTimeout(300);
  }

  const reachRate = 1 - missing.length / FLOW.steps.length;
  console.log(`语义可定位率 ${(reachRate * 100).toFixed(0)}%`, missing);

  // 第三层：有没有一段机器可读的成功回执
  await expect(
    page.getByRole(FLOW.success.role, { name: FLOW.success.name })
  ).toBeVisible({ timeout: 15000 });
});

再加一个 20 行的遮罩探测，专治断点一：

// 提交按钮真的可点吗：看该坐标上最顶层的元素是谁
const btn = page.getByRole('button', { name: '提交' });
const box = await btn.boundingBox();
const topEl = await page.evaluate(
  ([x, y]) => document.elementFromPoint(x, y)?.outerHTML.slice(0, 120),
  [box.x + box.width / 2, box.y + box.height / 2]
);
console.log('该坐标最上层元素：', topEl);   // 不是 button 就是被盖住了

判定标准：四个指标和它们的及格线

跑完之后用这四个数字对照，不要靠感觉：

• 流程完成率 AFCR = 走到确认页次数 ÷ 尝试次数。及格线 80%，我们样本平均 35%。
• 稳定通过率 = 5 次全通过的流程数 ÷ 流程总数。及格线 90%，我们样本 28%。
• 语义可定位率 = 能被 role/label 定位的关键控件 ÷ 关键控件总数。及格线 90%，低于 50% 基本可以断定流程走不通。
• 回执可读率 = 成功后存在纯文本确认语句的流程占比。必须 100%，这一项没有妥协空间。

及格线的来源说明：80% 和 90% 不是行业标准，是我们从样本分布反推的可用门槛——AFCR 低于 80% 意味着五分之一以上的智能体访问白跑，而可定位率 90% 是「所有关键控件里最多漏一个」的工程等价表述。你可以按自己的流量结构调整，但不要把及格线定在样本均值附近，那等于承认现状合理。

诊断时再看一个辅助数字：平均中断步位。我们样本的失败平均发生在第 3.8 步——不是最后一步，说明问题往往在中段的状态保持，而不是提交本身。

30 分钟修复清单：按投入产出比排序

按下面的顺序做，前四项不需要开发排期：

1. 关掉首屏自动弹窗，或延后到首次交互之后。收益最大、成本最低。
2. 给成功页加一段纯文本回执，含单号与后续动作说明，别只靠 toast。
3. 给所有自定义控件补 aria-label，把图标按钮从 <div> 换成 <button>。
4. 把非必要的必填项改成选填，条件显隐的必填项改成始终可见。
5. 开放游客下单 / 免注册询价，这一步通常要产品决策，但对下单流程完成率影响最大。
6. 多步表单每步给独立 URL，关键字段落 sessionStorage。
7. 验证码从全量强制改成风险触发，同时评估已验证机器人的放行策略。
8. 把上面的 Playwright 脚本接进 CI，语义可定位率低于 90% 就让构建失败。

第 8 条是长期价值所在：可操作性和性能指标一样会退化，一次改版就可能把辛苦补上的 aria-label 冲掉。

修完之后：把可操作性接回 AI 可见度监控

改完流程，还得知道它有没有换来结果。可操作性是漏斗的最后一段，前面两段依然要盯：AI提及率决定智能体会不会考虑你，AI引用来源决定它凭什么信你，AI搜索竞品分析告诉你同一个问题下豆包和 DeepSeek 更愿意推荐谁。

三段放在同一张表上看：

漏斗段	看什么	数据来源	本文对应
被提及	DeepSeek/豆包品牌推荐频次与位置、情感倾向	AI 舆情监控、定期提问抽样	—
被点开	AI 答案里链接指向哪个页面、点击损耗	GSC 分段对比	—
被走通	AFCR、稳定通过率、回执可读率	本文自测脚本	全文

中间那段最容易被误读：AI 答案出现之后流量下滑，到底是被 AI 摘走了还是排名本身掉了，两者的处置完全不同——如何在 GSC 里把 AI Overview 的点击损失和排名下滑分开给了可操作的拆分口径。如果三段你都还没开始做，30 天 AEO 启动计划是比本文更靠前的一步——本文这套 L3 检查，适合放在那份计划的第三、四周执行。

常见问题

AI 智能体现在真的会自己下单吗？

分场景。在封闭生态内（平台自有智能体调用自家交易接口）已经在规模化发生；在开放网页上由智能体代替用户完成陌生站点的支付，仍受限于风控、鉴权和责任归属，多数产品会停在「填好信息、由人确认支付」这一步。所以现阶段最该测的不是全自动支付，而是支付前一步是否能被走完——那是你真正能控制的部分。

无障碍做好了，是不是就等于智能体能操作？

高度相关，但不等价。无障碍解决的是 L2「可达」——控件有名字、有角色、能被辅助技术识别。L3「可完成」多出三样东西：多步流程的状态保持、动态弹窗的时序竞争、以及成功回执的机器可读性。这三样在 WCAG 里没有直接对应的条款，必须单独测。

为了让智能体走通，是不是该关掉验证码？

不应该。关掉验证码是拿安全换转化，得不偿失。正确做法是分级：低风险表单（询价、订阅、预约）本来就不该挂验证码；高风险动作保留，但走可验证机器人身份的放行机制，而不是对所有自动化一刀切。

用 Schema.org 的 potentialAction 标注有用吗？

有用但不是替代品。结构化数据帮智能体理解「这个页面能做什么」，属于意图层；页面本身能不能点得动，属于执行层。两层都要——只标注不修流程，智能体知道该下单却下不了；只修流程不标注，它可能压根没意识到这里能下单。

单页应用（SPA）需要特别处理吗？

需要，且失败率更高。我们样本里 SPA 站点的 AFCR 明显低于服务端渲染站点，主要卡在两处：路由切换后焦点不重置，智能体拿到的可访问性树还是旧页面的；以及异步渲染的表单控件在智能体读取快照时还没挂载。最低成本的修法是路由切换后把焦点移到新页面的 <h1>，并保证关键控件在首屏快照时已存在，不要靠懒加载。

这套方法对中文站点有额外注意点吗？

有两点。一是很多国内站点的可访问名写的是英文（aria-label="submit"）而页面显示中文「提交」，智能体按用户说的中文词找不到——可访问名要和可见文本一致。二是短信验证码在中文站点的普及率远高于海外，登录态断点的占比会更高；这也是为什么本文把「免注册询价」排在修复清单第 5 位而不是更靠后。国内 AI 搜索入口的信源偏好也不同，百度 AI 搜索的信源结构和 Google 完全是两套逻辑。

多久重测一次？

建议把语义可定位率检查放进 CI 每次构建都跑，成本几秒钟；完整的智能体实跑每季度一次，或每次涉及表单、结算、登录的改版之后立即执行。改版是可操作性回退的头号原因，我们样本里有 2 个站点是在测试期内的一次前端发版后从通过变成不通过的。