AI浏览器为什么是弯路？智能体读的是无障碍树，不是你那张页面截图

摘要：ChatGPT Atlas这款独立AI浏览器上线九个月就被关掉，8月9日彻底停止工作。真正值得琢磨的不是哪家公司砍了哪个产品，而是它暴露的方向问题：智能体读的是浏览器根据你的标记生成的无障碍树，不是渲染出来的那张图。一个用div拼出来的按钮，在这棵树里根本不是按钮，跟读屏软件撞的是同一堵墙。让机器盯着屏幕认按钮的视觉方案，是给坏掉的网页打的补丁，而且这个补丁的成本要在每一次访问里重新付一遍。本文讲清这套机制、怎么自查、以及该按什么顺序把语义还回去。

2026年7月9日，OpenAI宣布关掉ChatGPT Atlas。这款独立AI浏览器2025年10月带着“挑战Chrome”的口号上线，8月9日就要停止工作，浏览能力并回ChatGPT桌面应用和一个Chrome扩展里。官方帮助文档的标题写的是把Atlas演进成面向浏览器端智能体工作的ChatGPT，用词相当讲究——从宣布到停服大约三十天，这个节奏叫“演进”，确实是个宽厚的说法。

行业里第一反应大多是讨论OpenAI的产品策略。我觉得更值得看的是另一层：这个产品从设计前提上就走反了，而那个前提，恰好是很多网站正在花钱去迎合的那个。

九个月和六个月，这两个数字说明了什么？

Atlas不是孤例。视频应用Sora在2026年4月被砍掉，活了六个月，有报道说它的总收入只有几百万美元，相对于运行成本完全不成比例。两个产品都是在同一轮“守住核心业务”的收缩里被处理掉的，主导人是OpenAI的应用业务负责人。

一次关停可以解释成工程问题或者市场时机不对。同一家公司、在同一个方向上、在最有钱也最有分发能力的位置上，短时间内关掉两个，那更像是在告诉你这个形状本身有问题。

OpenAI给的官方说法是它没有放弃网页上的智能体能力，只是把这个能力从独立浏览器挪进了大家本来就在用的应用里。这话可能是真的。它也确实是一家公司砍产品时最标准的说辞——把撤退说成进化。你不需要判断哪个解释才对，因为更深层的原因不依赖于OpenAI承不承认。

技术摩擦是真的，但它不是根本原因

关于这类产品做不下去，最流行的解释是技术摩擦：验证码拦着、脚本墙挡着、页面结构随时变，任何想在现代网站上替人办事的程序都会被绊倒。

这些摩擦是真实存在的，我也踩过不少。但把它当成根本原因，会让你得出一个错误的结论——好像等这些摩擦被工程手段一个个磨平，让机器看屏幕这条路就通了。

实际上，让机器盯着为人眼设计的页面去认东西，从一开始就是次优解。往好里说，它是一座临时的桥，在网页还没为智能体准备好的这段时间勉强通行。往差里说，它是把一个本可以在源头解决的问题，挪到了每一次访问里反复解决。

视觉智能体这条路，为什么大家还在加注？

得承认，另一边的诱惑力很强。Perplexity的Comet、The Browser Company的Dia、Chrome里内置的Gemini都还活着，而它们底下有个更大的赌注正在变响：视觉智能体，也就是那种像人一样看着渲染后的屏幕、找到按钮点下去的模型。

卖点非常动人：它在任何网站上都能用，网站主什么都不用做。不用接口，不用采纳标准，不用清理历史包袱。你把它指向一个人类能看懂的页面，剩下的它自己搞定。

如果这真是未来，那么主张“网页需要变得机器可读”听起来就有点迂腐了，因为视觉智能体的全部魅力就在于它不需要你可读。这股潮流值得认真对待，不能一句“不看好”就打发。

但有件事得说清楚：视觉方案今天能用，恰恰是因为语义那一层坏得足够彻底，看屏幕成了唯一可靠的办法。“绕行方案是目前唯一管用的东西”，这句话是修路的理由，不是把绕行当终点的理由。

智能体到底是怎么“看”你的页面的？

这是整件事的关键，也是最多人搞错的地方。多数人想象中的智能体是这样工作的：截个图，用视觉模型识别界面元素，找到目标点下去。

实际情况通常反过来。智能体主要是在读，读的是文档结构，以及浏览器根据你的标记构建出来的无障碍树——这棵树上每个节点带着角色、名称、状态这些信息，告诉机器“这是一个提交按钮”“这是一个标价为多少的商品”“这是一个当前处于展开状态的折叠区”。

读这棵树比看图快得多、便宜得多、也稳定得多。图像里的一个蓝色圆角矩形，模型得推断它是不是按钮；无障碍树里的一个按钮节点，就明确写着它是按钮。这两者的确定性完全不在一个层级。

所以真正的顺序是：先读结构，结构读不通再退回去看像素。像素是兜底，不是主路。

这个顺序解释了一个让很多人困惑的现象：为什么同一个页面，有时候智能体表现得像个老手，一步到位；有时候又笨得像是第一次上网，反复点错地方。差别往往不在模型能力，而在它这次走的是主路还是兜底。结构清楚的页面走主路，结构混乱的页面被迫兜底，而兜底路径上的表现天生就不稳定——它是在猜，猜的准确率随页面复杂度下降。

换句话说，你在抱怨智能体不好用的时候，有相当一部分情况其实是你的页面把它逼到了那条更差的路上。

一个div拼出来的按钮，在机器眼里是什么？

这就是问题所在。过去这些年，网页是按设计优先的方式建起来的，语义在这个过程里被弄丢了，而丢掉它的原因不是懒，是激励结构：大家关心开发体验、关心组件复用、关心它看起来对不对，很少有人关心它在底层是不是那个东西。

于是一个按钮变成了加了点击事件的样式化div，一个表单控件变成了一堆嵌套元素，渲染出来一点毛病没有。对人来说这些都能用，因为人带着眼睛和一辈子的模式识别经验来读这个页面。

对机器来说，一个行为像按钮的div不是按钮，它就是个盒子。它根本不会作为按钮进入无障碍树，所以无论它在屏幕上多显眼，在机器读到的那份文档里它就是不存在的。

这张表里没有一条是新知识，它们在无障碍领域被讲了十几年，写进规范、写进教程、写进无数次没人参加的分享会。变的不是知识本身，是听众的构成，以及听众口袋里的预算。

为什么说AI智能体就是新一代读屏软件？

为缺失的语义买单的人，一直不是AI智能体，是那些用读屏软件和其他辅助技术上网的人。

读屏软件分辨不出那个样式化的盒子是结账按钮，智能体也分辨不出，因为两者读的是同一棵树。这不是比喻，是同一条技术路径上的同一个节点。区别只在于，过去撞这堵墙的是一群没什么议价能力的用户，行业把它当成合规打勾项；现在撞墙的是一群资金雄厚、声量巨大的机器，行业忽然就上心了。

这个转折说来有点讽刺，但它的实际意义是正面的：你现在做的每一项无障碍改造，同时在解决两拨用户的问题，而其中一拨是你老板会主动过问的那拨。过去无障碍要靠道德和法规去推，现在它有了一个能写进ROI表格的理由。站内那篇讲无障碍改造具体怎么落地的文章可以直接当施工清单用，见网站无障碍访问怎么做。

读屏软件和智能体读同一棵树，那两者有没有差别？

有，而且这些差别决定了你不能把无障碍合规当成智能体适配的全部。

读屏软件服务的是一个正在专注操作的人，它按顺序把内容念出来，用户自己决定跳到哪、点什么。智能体没有这个人在回路里，它要一次性把整个页面的意图理解完，然后自主决定下一步。这个差别带来三个实际后果：

• 智能体更依赖全局结构。读屏用户可以靠上下文和耐心补齐缺失的层级关系，智能体没有耐心，读不出从属关系就会做出错误判断。
• 智能体对信息一致性更敏感。同一个价格在页面上出现两处、数值还不一样，人会自动挑那个看起来更正式的，机器可能两个都取，然后给出一个自相矛盾的回答。
• 智能体会主动执行操作。读屏软件只是读，智能体要点、要填、要提交。所以状态标注对它来说不是可读性问题，是会不会做错事的问题。

所以正确的说法是：无障碍改造是智能体适配的必要基础，但不是全部。做完无障碍还得多问一句——一个没有人在旁边纠正的程序，靠这个页面能不能自己把事办对。

Chrome、ChatGPT、Perplexity各家的读法一样吗？

底层原理相通，具体行为差别不小，这也是让人头疼的地方。

差异主要出现在三个环节：会不会执行页面脚本、等待渲染的时间预算有多长、以及在结构读不通时退回视觉的门槛设在哪。有的引擎极有耐心，会等到页面基本稳定；有的抓完初始文档就走人；有的一发现结构混乱就直接切到看画面。

这意味着你没法针对某一家去优化，也不该那么做。可行的策略是按最保守的假设建设：假设对方不执行脚本、没有耐心、不会退回视觉兜底。满足这个假设的页面，在所有引擎那里都能读通。

这个思路跟做技术SEO时的老经验一致——不要赌爬虫的能力上限，要保证它的能力下限也能拿到关键信息。各家在抓取、渲染、提取这三段上的具体差异，站内那篇技术端拆解整理得比较全，见GEO技术端怎么优化才抓得到读得懂。

AI浏览器是突破，还是给坏掉的网页打的补丁？

把上面几层理清楚之后，AI浏览器的定位就变了。它不再是一个新品类的开端，而是一个绕行方案的外壳。

智能体读结构，不需要把页面渲染出来。那么一个你能看着它工作的浏览器窗口，多出来的东西是什么？是一扇给人看的窗户。不是给智能体的——它不渲染也能读；也不是给你的——你需要盯着智能体读网页的程度，大概跟需要盯着服务器处理请求的程度差不多。

这个“可观看”的属性从一开始就更接近表演。这话听起来刻薄，但它解释了很多现象：为什么这类产品总是在发布会上很惊艳、在日常里很少被打开；为什么它们的生命周期普遍很短。一个主要为了被展示而做的产品，寿命本来就有上限，而Atlas的九个月就是那张收据。

视觉方案的成本，为什么每次访问都要重付一遍？

这是我认为最实在的一个论点，因为它能算账。

让智能体从像素里重新推断页面的含义，意味着每一次访问都要把这个推断过程做一遍。页面本可以直接告诉它的东西，它得靠看图猜出来。而且这个猜测过程更慢、更贵、更容易出错，最要命的是永远不会变好——因为底下那层什么都没修。

而如果你的页面语义完整，智能体读一遍结构就完事了，这笔开销从此不用付。

最后一行值得注意。修语义这件事，收益是同时兑现给三拨对象的；而依赖视觉方案，只有智能体这一拨勉强受益，其他人什么都没得到。

你的站现在被收的这笔“视觉税”，能估出来吗？

严格的量化做不到，因为你看不见对方的模型开销。但可以做个相对判断，方法是让智能体在你的站上完成一个具体任务，比较它的表现。

找一个明确任务——比如“在这个站上找到适合初学者的入门款，看看有没有现货”——分别在你的站和一个结构干净的同行站上让智能体跑。观察三件事：它需要多少步、中途走没走错、最后给出的答案对不对。

差距通常很直观。在结构干净的站上，它三四步就完事；在结构乱的站上，它可能要反复回退，最后还把停产的型号说成有货。这个差距就是那笔税的体感版本。

更省事的自查是直接问：把页面URL给智能体，让它复述这个页面上有哪些可以操作的东西、主要卖点是什么、价格是多少。它复述得七零八落，说明你的页面在结构层就没把这些说清楚。这个方法糙，但特别有说服力，因为你可以把结果直接截图发给前端团队。

怎么自己查一遍机器读到的到底是什么？

不用买工具，浏览器自带的开发者面板里就有。打开无障碍功能面板，选中页面上任意元素，就能看到它在无障碍树上的角色、名称和状态，也能整棵树浏览一遍。

查的时候按这个顺序走，十分钟能过完一个模板：

• 先查关键操作元素。加入购物车、结算、筛选、切换规格这几个，逐个看它们在树上是不是正确的角色，有没有可访问的名称。名称为空的，机器知道有个按钮但不知道它是干嘛的。
• 再查表单。每个输入框有没有关联的标签，只靠占位符提示的那些要标出来改。
• 然后查标题层级。标题在树上是页面的骨架，层级跳跃或者干脆用样式假装的标题，会让机器读不出内容的从属关系。
• 接着查动态内容。展开折叠、切换标签页这类交互之后，状态有没有在树上更新。很多组件视觉上变了，树上还是老样子。
• 最后查关闭脚本之后还剩什么。这一步能立刻暴露出你的内容有多少依赖客户端渲染。

这套查法跟站内那篇页面结构审计的思路是通的，可以配着看，见页面结构分析怎么揪出层级与语义标签短板。

语义化不是玄学，具体该改哪几处？

“把语义还回去”这句话太抽象，落到代码上其实就是几类很具体的替换：

这七条覆盖了我见过的大部分问题，而且没有一条需要重构。它们是替换，不是重写，多数组件库里改起来是几行的事。真正的阻力从来不是技术难度，是没人认为这件事值得排进迭代。

需要提醒的是，别指望靠补属性来救。给一个div加上“我是按钮”的角色标注，能让它进树，但它仍然不能用键盘操作、不能获得焦点、行为上跟真按钮差着一截。属性标注是给原生标签补充信息用的，不是用来给假货贴标签的。想深入到标签层面的具体用法，站内有整理，见网页语义化HTML改造的8类标签。

这笔账该算在框架头上吗？

把责任推给某个前端框架是很省事的说法，但不太公平，也不解决问题。

主流框架本身都支持输出正确的语义标记，也都提供了服务端渲染的能力。真正的问题出在中间那一层：为了追求开发效率和视觉一致性，团队普遍会引入或自研一套组件库，而组件库的设计目标是“长得对、用起来方便”，很少把“底层是不是那个东西”写进验收标准。

一个封装好的按钮组件，外面看是个能传属性、能换主题、能带图标的完美积木，打开看里面是个div套span。用它的人不会去看内部实现，于是这个错误在几百个页面上被复制了几百遍。

这也是好消息：问题集中在组件库里，意味着修复也可以集中在组件库里。把最常用的十几个组件的底层元素换对，全站就跟着变了。这比一个页面一个页面去改省太多，前提是你们的组件确实是统一收口的。

如果没有统一收口，各个页面各写各的，那这次改造顺便就是一个收口的机会。这活儿谁都不爱干，但它的收益会在之后每一次改版里持续兑现。

把语义改对，会不会把设计做坏？

这是设计团队最担心的问题，答案是不会，而且这个担心本身反映了一个常见的误解——以为语义正确意味着要牺牲外观。

实际上原生元素的外观几乎都可以完全自定义。一个真正的按钮标签可以做成任何形状、任何颜色、任何动效，跟div做的在视觉上不会有任何差别。你放弃的只是默认样式，而默认样式本来就是要覆盖掉的。

会带来轻微差别的地方有两处：一是键盘焦点的轮廓，二是某些元素的默认交互行为。前者不该直接去掉，应该重新设计成符合品牌视觉的样式——焦点可见是一项基本功能，去掉它等于让键盘用户在黑暗里操作。后者通常是好事，你本来就要自己实现那些行为，现在浏览器帮你做了。

我遇到过的真实阻力反而不在设计侧，在排期侧：这类改动没有可展示的新功能，在需求评审会上永远排在最后。破解办法是把它捆在别的需求里做，比如下次改版某个模板时顺手把组件换掉，而不是单独立一个“语义化改造”的项目去申请资源。单独立项的这类项目，我见过的存活率相当低。

JavaScript那堵墙，到底挡住了谁？

语义修好了，还有第二道门槛：内容得先存在，才谈得上有没有语义。

如果你的页面在初始响应里几乎是空的，全靠脚本在客户端把内容拼出来，那么能不能读到你，取决于对方愿不愿意执行脚本、执行到什么程度、等多久。各家引擎和智能体在这一点上差异极大，有的完整渲染，有的只读初始文档，有的渲染但有严格的时间预算。

结果就是同一个页面，在不同智能体眼里可能是完整的、残缺的、或者一片空白。这种不确定性本身就是成本，因为你没法预期任何一次访问的结果。

处理办法不是“禁用JavaScript”这种极端做法，而是把关键内容放进首次响应里：产品名称、价格、库存状态、核心描述、主要操作入口。装饰性和交互增强的部分留给脚本没问题。判断标准很朴素——关掉脚本之后，这个页面还能不能把最重要的事情说清楚。渲染模式的差异和对被引用的具体影响，站内有专文拆过，见SPA站AI爬不到的真相。

结构化数据在这里扮演什么角色？

有人会问：既然要让机器读懂，那把结构化数据标全了是不是就够了？

不够，但很有用，它们解决的是不同层面的问题。语义标记解决的是“这个东西是什么、能不能操作”，结构化数据解决的是“这个东西在业务上意味着什么”——这是一款商品、它属于哪个品牌、价格多少、还有没有货。

两者的关系更像骨架和标签：骨架决定机器能不能站得住地读，标签决定它读完之后能不能准确归类。只做标签不修骨架，机器可能连标签挂在哪个部位都搞不清；只修骨架不做标签，它知道这是个可点击的东西，但不知道点下去意味着下单。

优先级上我建议先修骨架。原因是骨架的问题会导致读不到，而标签的问题只是读得不够准，前者是零和一的差别，后者是精度差别。关于结构化数据和实体信息怎么系统性补齐，站内有一套方法，见实体覆盖缺口怎么找。

这件事跟“被AI引用”是同一件事吗？

不是同一件，但共用地基，值得分清楚，不然容易把两件事的目标搞混。

被引用讲的是内容层：你写的东西够不够权威、事实够不够密、结论好不好抠出来当依据。智能体可用讲的是操作层：机器能不能识别页面上的元素、能不能完成一个任务、拿到的信息准不准。

第二行的差别最值得警惕。内容做得好但结构坏掉，你会遇到最尴尬的一类失败：机器认识你、愿意提你，但它读到的库存、价格、规格是错的，于是它一边推荐你一边散布错误信息。这比完全没被提到更伤，因为错误信息会被当成你的官方口径传出去。

两件事的地基是共用的：能读到才谈得上读得懂。所以顺序上先修结构，再做内容。想系统了解智能体如何感知网站的完整框架，站内有专文，见AI代理如何感知你的网站。

智能体来了之后，站点的数据会变成什么样？

这个问题现在还没有干净的答案，但有几个可以提前准备的动作。

首先是识别。智能体访问会以各种身份出现，有的老实标明自己，有的伪装成普通浏览器。你至少要在日志层把能识别的那部分单独打上标记，否则这部分访问会混进普通流量，把跳出率、停留时长这些指标搅浑——一个访问三个页面、零秒停留、不点任何东西的会话，看起来像最糟糕的用户，实际上可能是个正在替人比价的程序。

其次是归因。智能体促成的购买，最终下单动作可能发生在别的地方、别的时间，中间那段过程在你的分析里是断的。这一层短期内没有完美方案，但至少要意识到它的存在，别在看到“AI相关流量转化率极低”的时候直接下结论说这个渠道没价值。

第三是不要急着屏蔽。看到大量非人类访问，第一反应往往是拦掉。拦之前先分清楚它是来帮客户办事的还是来白嫖内容的，这两者混在一起拦，代价可能比收益大。

没有前端资源的小团队，能做什么？

如果你用的是成熟的建站平台，好消息是主体结构通常已经是对的——那些平台的默认模板在语义上比大多数自研站规范。问题往往出在两个地方：装的第三方应用和自己改过的模板。

可做的动作按性价比排：

• 先审第三方应用生成的内容块。倒计时、库存提示、评价展示这类插件是重灾区，它们往往用最省事的方式渲染，语义一塌糊涂。查一遍，能关的关，不能关的换一个。
• 再看自定义代码块。很多站在模板里塞了手写的HTML片段，那些片段一般没人审过。
• 把图片承载的关键信息挪成文字。这一步不需要技术能力，编辑就能做，收益却很直接——价格、规格、材质写在图上，机器一个字都读不到。
• 选主题的时候把这项纳入考量。挑主题时花十分钟用开发者面板看一眼它的按钮和表单是怎么做的，比看一百张演示图有用。

最后这条是我想强调的：这件事在建站选型阶段的成本几乎是零，在上线两年后的成本是一次重构。挑的时候多看一眼，比之后补三个月的课划算得多。

无障碍改造和SEO的收益，为什么这次终于对齐了？

过去这两件事在预算表上是分开的，甚至互相竞争。无障碍归合规和法务管，SEO归市场管，谁也说服不了谁。

现在它们指向同一批改动。正确的标题层级同时服务于读屏用户、搜索引擎的段落理解和智能体的内容定位；真实的按钮标签同时让键盘用户可操作、让智能体能完成任务；首屏就有的关键内容同时改善可访问性、抓取效率和智能体的成功率。

这个对齐是这轮变化里少见的好消息，因为它意味着你不用在两个方向上分别申请预算。一次改造，三份收益，这种事在这行不常有。前端和SEO怎么在这类改动上分工协作，站内有具体的动作清单，见前端工程师SEO协作的7个动作点。

为什么“大家一起采纳一个标准”这条路一直推不动？

每隔一段时间就会有人提议：干脆定一个专门给智能体用的标准接口，网站按标准输出，机器按标准读取，皆大欢喜。

这个想法很合理，也一直没成。原因不复杂：标准需要所有人同时动才有价值，而单方面先动的那个得不到任何回报。你的站按新标准输出了，如果模型侧还没支持，这份工作就是白做的；模型侧支持了，如果网站侧覆盖率低，它也不敢只依赖这条路。这是个典型的先有鸡还是先有蛋。

更关键的是，这条路已经有替代品了：语义化标记和无障碍树是既有标准，浏览器全都实现了，模型侧也全都能读。它不完美，但它的覆盖率是新标准短期内追不上的。

所以务实的路线不是等一个新标准降临，而是把已有的这套用对。历史上真正被广泛采用的机器可读方案，几乎都不是全新发明的，而是让已经存在的东西被正确使用。相关的演进和几种主流方案的取舍，站内有整理，见智能体AI优化的三层实战框架。

验证码、登录墙这些呢，要不要给智能体放行？

这是个需要业务判断而不是技术判断的问题，别指望有标准答案。

先分清两类智能体。一类是用户自己派来的——你的潜在客户让它去帮忙比价、查库存、整理选型建议，它带着一个真实的购买意图。另一类是各种批量抓取的程序，跟你的生意没关系甚至有害。

问题在于，从服务器的视角这两类不太好分。你能做的是分层处理：

最需要提醒的是第二行。有些站把价格做成需要交互才显示，本意是留资或者防比价，代价是智能体拿不到价格，于是在回答里要么跳过你，要么用一个从别处抓来的过期价格来描述你。这个副作用现在比过去大得多，因为那个错误的价格会被复述给一个正在做决策的人。

多语言站在这件事上有什么额外的坑？

出海站基本都是多语言的，这里有两个容易忽略的问题。

第一个是语言标注。页面的语言属性如果标错或者干脆没标，机器判断文本语言就得靠猜，而猜错的后果是它可能认为这个页面跟用户的提问语言不匹配，直接跳过。这个属性改起来是一行的事，但漏标的站多得惊人。

第二个是各语言版本的语义完整度不一致。主语言版本改造完了，其他语种因为是用另一套模板或者由第三方翻译工具生成的，语义结构完全没跟上。结果就是你的英文站智能体读得明明白白，德文站一片模糊，而德国市场恰恰是你想打的。

检查方法很简单：把自查流程在每个语种的同一个模板上各跑一遍，别只查主语言。这一步花不了多少时间，但漏掉它，前面所有工作在部分市场都等于没做。

出海独立站该从哪一步开始？

不用整站铺开，按这个顺序推，投入产出比最高：

• 先修交易路径上的关键操作元素。加入购物车、选规格、结算这几步，它们的失败成本最高。
• 再修产品页的关键信息呈现。价格、库存、规格参数必须是文本且在首次响应里，不能只画在图上或者等脚本拉。
• 然后修全站的标题层级和列表结构。这两项工作量小，收益覆盖面广。
• 接着处理筛选和搜索这类交互组件的状态标注。多规格商品站尤其要做。
• 最后才是补结构化数据和优化替代文本这类精修工作。

顺序背后的逻辑是先保证“能读到、能操作”，再追求“读得准”。很多团队反着来，先花两个月标了满站的结构化数据，结果智能体连结算按钮都识别不出来，那些标记也就没了用武之地。

改完之后怎么验证真的有效？

验证要分三层，缺一层结论都不硬：

• 结构层：在开发者面板里确认关键元素的角色和名称都对了。这是最基础的一层，改完立刻能验。
• 任务层：让智能体在你的站上跑三到五个真实任务，记录成功率和步数。改造前后各跑一轮，差距会很明显。
• 结果层：观察被引用、被推荐、以及来自智能体流量的转化情况。这一层周期长、噪声大，别指望两周见分晓。

三层里最容易被跳过的是任务层，但它恰恰是最有说服力的——因为你可以把改造前后的两段操作过程录下来放在一起。给非技术背景的人看这个，比给他们看任何指标都管用。想把这套验证做成常态化的自查，站内那份智能体就绪度打分表可以直接拿去用，见智能体就绪度自查打分表。

一个真实的改造顺序长什么样？

保哥去年帮一个做电吉他效果器的出海独立站看过这件事。他们的产品线是失真、延迟、混响这类单块效果器，SKU不多但每款有几个版本，用户在下单前会反复比参数。

起因是他们发现一个尴尬现象：客服后台里有人问“我让AI帮我查你们家某款有没有货，它说停产了”，而那款根本没停产，还是主推款。

查下来问题出在三个地方。库存状态是用一个彩色圆点加CSS样式表示的，绿点表示有货——在无障碍树上，那就是个什么都没有的空元素。价格是脚本在页面加载后从接口拉的，初始响应里没有。规格对比表是个自研组件，用div嵌了七层，标题是用加粗样式假装的。

第一轮改动很小：库存状态改成文本加状态属性，价格进首次响应，对比表的表头改成真的表格结构。前端估的工期是四天，实际做了六天，因为组件库里那个对比表被十几个页面复用，改完要逐个回归。

改完两周后重新做任务测试，用同样的问法问三家智能体，库存和价格的回答都对了。更意外的收获是有两家在回答“某某类效果器怎么选”这类不带品牌名的问题时，开始把他们的对比页列进来——之前从来没有过。

第二轮改的是标题层级和产品页的信息顺序，把原本埋在第三屏的核心参数提到了前面。这一轮的效果就没那么立竿见影了，两个月里看不出明显变化。诚实地说，第二轮到底有没有用，我们没有测出确定的结论，只能说它至少没有副作用，而且顺带把页面的可读性改善了。

值得记下的是他们没做的事：没有为智能体单独做一套接口，没有搞什么专门的机器版页面。所有改动都是在现有页面上把该有的语义补回去，人看到的界面几乎没变化。这也是我一直强调的——这不是新增一层给机器的东西，是把本来就欠着的东西还上。

还有个细节挺能说明问题。第一轮改完之后大约一个月，他们上线了一场促销活动，活动页是运营用页面搭建器拼的，没走组件库。两周后又有客服反馈说AI把活动价说错了。查过去一看，那个活动价是用一张banner图承载的，页面文本里根本没有这个数字，机器只能从别处找一个价格来填。

这件事让团队意识到，改造不是一次性的项目，是要进流程的。后来他们在活动页的上线检查清单里加了一条：关键数字必须以文本形式出现在页面上，图只是配图。就这么一条，之后再没出过同类问题。

反过来说一个反面的例子。同期我看过另一个做户外照明的站，他们把整套精力花在给全站补结构化数据上，标了三个月，覆盖率做到很高。但他们的加购按钮是个div、价格是脚本拉的、规格表用样式假装标题。结果是机器能准确说出这是一个什么品牌的什么品类产品，却答不出它多少钱、有没有货。标签做得再全，骨架读不通，这些标签就只是挂在半空中。

等智能体真的替人下单，还要补哪些准备？

现在多数智能体停在“帮你查、帮你比、帮你整理”这一步，真正走完付款的还少。但这条路上的下一步已经能看清轮廓，有几件事值得提前想。

一是流程的可完成性。你的结算流程如果依赖大量视觉判断——比如必须在弹窗里点某个位置、必须滑动某个控件、必须从图片验证里选出摩托车——那么即便前面所有信息都读对了，最后一步还是会断。这类设计当年是为了防机器，现在得重新评估：你要防的是恶意程序，不是客户派来的助手。

二是信息的确定性。人下单时看到含糊的运费说明会自己去问客服，机器不会，它会按最字面的理解做决定，或者干脆放弃。运费规则、交期、退换条件这些如果只写在一张需要展开三次才能看到的说明页里，机器很可能就当它不存在。

三是错误的可恢复性。机器操作出错的方式跟人不一样，它可能重复提交、可能在超时后重试、可能在中途状态丢失。这些在设计防御性交互时要考虑进去，否则一次失败可能变成三个重复订单。

这几条其实对人类用户也全是好事，只是过去没人有足够的动力去改。机器的到来在这里起的作用，跟它在无障碍那件事上起的作用一模一样——它没有提出新要求，它只是让旧要求变得贵得没法再忽略。关于智能体在网站上从发现到完成任务的完整链路，站内有更细的拆解可以配着看，见持续自主搜索来了，独立站怎么进那份提醒名单。

改造做完之后，多久要复查一次？

语义这东西会退化，而且退化得很安静。一次改造做完，半年后可能有一半又坏了，原因通常是这几个：新上线的活动页没走组件库、第三方应用更新之后换了渲染方式、有人为了赶一个需求临时用div拼了个东西然后就留在那了。

所以复查得是常态动作，不是一次性项目。给一个可执行的节奏：

• 关键交易路径每月查一次，就查那五六个核心元素，五分钟的事。
• 每次模板改版或者上新组件时，把语义检查列进上线前的检查项，跟兼容性测试放在一起。
• 每季度做一次任务级测试，让智能体跑三到五个真实任务，看成功率有没有退步。
• 装新的第三方应用时单独看一眼它渲染出来的东西，这类回退最常见也最容易被忽略。

把前两项写进上线流程比什么都管用。靠人记得去查，迟早会忘；写进流程之后，它就变成了跟别的检查项一样的常规动作。

反过来问，哪些改动这一轮可以先不做？

做减法比做加法更能保住排期，所以也把不着急的那部分列出来，免得清单长到没人愿意开工。

• 装饰性元素的语义完善。轮播图的指示点、背景动效、纯视觉的分隔符，这些机器读不读得到都不影响任何判断，别在上面耗时间。
• 历史文章的结构翻新。除非那批内容是你被引用的主力，否则老文章的标题层级问题优先级很低，新内容做对就行。
• 全站替代文本的精修。图片替代文本要写，但先保证关键信息不只存在于图上，比给每张配图写一段精美描述重要得多。
• 为个别引擎做的特殊适配。前面说过，按最保守的假设建设即可，针对某一家的特殊优化通常在下个季度就失效了。
• 访问统计层面的智能体识别。值得做，但不紧急，它不影响机器能不能读懂你，只影响你能不能看清楚。

把这五项从清单里划掉，剩下的工作量通常会缩到原来的三分之一，这个规模才有可能被排进迭代。一份没人能开始执行的完美清单，价值低于一份只有六条但下周就能动工的清单。

这轮变化里，哪些说法被夸大了？

说了这么多该做的事，也得把被吹过头的部分点出来，免得你为了不存在的威胁去花钱。

第一个被夸大的是紧迫感。有种说法是不马上适配智能体，明年你的生意就没了。实际情况是智能体促成的交易在多数品类里占比还很小，它在增长，但增长曲线没有那么陡。把这件事当成一项该做的基本功去排期，比当成救火去处理更理性。

第二个是“要为智能体单独做一套东西”。有服务商在推销专供机器读取的独立版本，说白了是让你维护两套内容。除非你的站结构已经烂到不可救药，否则修现有页面永远比维护第二套便宜，而且第二套一定会跟主站不同步，然后你就有了两个真相。

第三个是把某个具体产品的兴衰当成方向信号。某个AI浏览器火了不代表你要适配它，关停了也不代表智能体这条路不成立。产品会来会走，读取方式一直没变。

第四个是“结构化数据一标就灵”。它有用，但它解决的是分类和归属问题，解决不了机器读不到内容的问题。顺序搞反了，投入就打水漂。

下一个AI浏览器出来，要不要跟？

大概率不用。这类产品的发布和关停都比看上去的动静小得多——发布时说的浏览器大战没真的发生过，关停时也不过是一家公司收缩非核心业务，两件事都不该改变你的策略，因为它们从头到尾就跟你的网站没什么关系。

真正会发生的事是：智能体会以各种形态来到你的网站，可能装在独立浏览器里，可能装在桌面应用里，可能是个插件，也可能是明年某个还没被命名的东西。壳会一直换，读你页面的方式不会。

所以判断标准很简单：任何一个新产品出来，先问它是不是改变了机器读取网页的方式。如果只是换了个外壳，那它对你的待办清单没有影响。这几年绝大多数的所谓变革，都属于换壳。

这件事上最容易犯的判断错误

• 以为视觉智能体会一直兜底，所以不用修语义。它确实能兜底，但你要为这个兜底在每一次访问里付费，而且结果不稳定。
• 以为这是给AI做的新工作。这是十几年前就欠下的旧账，只是现在有了一个能说服老板的理由。
• 以为补属性标注等于修语义。标注能补充信息，替代不了原生元素带来的行为和可达性。
• 以为做了结构化数据就够了。业务标签解决不了骨架读不通的问题。
• 追着每个新出的AI浏览器做适配。壳会一直换，底层读取方式不会。
• 整站铺开做改造。从交易路径的关键元素开始，比全站扫一遍更快见效。

常见问题解答

智能体到底是看截图还是读代码？

主要是读。它读文档结构和浏览器根据标记生成的无障碍树，那里面直接写明了每个元素的角色、名称和状态。只有当结构坏到读不通时，才退回去看渲染后的画面，视觉是兜底手段不是主路。

用div加点击事件做的按钮，智能体真的用不了吗？

基本用不了。裸div不会以按钮的角色进入无障碍树，机器读到的只是一个没有角色的容器，不知道它可以点、也不知道点了会发生什么。读屏软件遇到的是完全一样的问题。

加上角色属性标注，是不是就等于改成真按钮了？

不等于。属性标注能让它以按钮的角色进树，但它仍然不能被键盘操作、拿不到焦点、行为上和原生按钮有差距。标注是给原生元素补充信息的，不是用来给替代品贴标签的。

我的站是单页应用，是不是必须改成服务端渲染？

不必须，但关键内容得进首次响应。产品名、价格、库存、核心描述和主要操作入口这几项不能只靠客户端脚本拼出来。判断方法很简单：关掉脚本看看这个页面还能不能把最重要的事说清楚。

无障碍改造和SEO要分别投预算吗？

这一轮不用了。正确的标题层级、真实的按钮标签、首屏就有的关键内容，这几项同时服务读屏用户、搜索引擎和智能体，一次改造三份收益，可以合并成一个项目去申请资源。

怎么快速判断自己的页面有没有这个问题？

打开浏览器开发者面板里的无障碍功能面板，选中结算按钮和几个关键输入框，看它们的角色和名称对不对。名称为空或者角色是通用容器的，就是问题所在。十分钟能过完一个模板。

要不要为智能体单独做一套简版页面？

多数情况不要。维护两套内容意味着它们迟早会不同步，然后你就有了两个互相矛盾的真相。除非现有站的结构已经烂到修不动，否则把现有页面的语义补对，永远比新做一套便宜，也更稳。

价格藏起来防比价，对智能体有什么影响？

影响很直接：机器读不到你的价格，就会从别处找一个来描述你，通常是过期的或者第三方渠道的。结果是它一边把你列进推荐一边报错价格，而这个错误会被复述给正在做决策的人，比不被提到更伤。

Atlas这类AI浏览器关停，对我的网站有实际影响吗？

几乎没有。产品的外壳会一直换，智能体读取网页的方式不会变。与其追着每个新产品做适配，不如把语义和渲染这两件基本功做扎实，任何形态的智能体来了都能读明白。

权威参考资料