营销增长
AX 是什么：品牌从「AI 提到你」到「AI 用得起来」还差五步
GEO 解决的是 AI 会不会提到你、提得对不对；AX 解决的是 AI 选中你之后，能不能真的用起来你的产品把事情办完。这篇文章给出两者的分界、五个可自检的环节、归属划分和一条最小验证路径。
一轮 GEO 做完，报告上提及率涨了、引用量够了、回答正确率也过了线。然后业务负责人问一句：这些带来了多少单？
大多数团队答不上来。不是因为 GEO 没效果，而是因为那份报告只测到了链条的前半段。
AI 提到了你的品牌，和用户能不能通过 AI 把事情办成，中间还隔着五步。这五步就是 AX。
AX 是 Agent Experience 的缩写，指 AI 智能体体验。它和 UX（用户体验）、DX（开发者体验）并列，问的不是页面好不好看，而是一个替人办事的 AI 能不能用你页面上的东西把事情办完。Mathias Biilmann 在 2025 年初提出这个概念时，把外部 AI 智能体当成产品的一类新用户；到 2026 年，微软给出了一个更便于业务讨论的区分：先看智能体有没有发现并选择某项技术，再看它选中之后有没有用对。
前一半和 GEO 有交集，后一半把评价延伸到了执行结果。
这篇文章面向已经或正在准备投入 GEO、且需要判断下一阶段做什么的市场与品牌负责人。 你会拿到一份五环节自检清单、一张归属划分表、一条可复现的验证路径，以及当前证据的边界说明。
一个能自己复现的场景：AI 找到了你，然后卡住了
假设有人对智能体说：帮我找一款适合十人以下团队的邮件服务，把测试环境搭起来。
这个任务是一条链：发现候选 → 比较条件 → 获取权限 → 调用功能 → 检查结果。
你的品牌很可能在第一步就出现在了推荐列表里——这是 GEO 的功劳。但后面四步，任何一环掉链子，任务都不会落到你身上：
- 定价页写”按月计费”却没说清最小席位和年付折扣，智能体判断不了是否符合预算条件；
- 注册流程要邮箱验证加人工审核，智能体没有可交接的授权路径；
- 文档停留在上一个版本，接口字段对不上，调用报错；
- 调用完了没有状态返回，智能体不知道成功没有，也不知道失败了该重试还是交给人。
结果是：用户拿到了一份推荐清单，你的名字在上面，但最后成交的是另一家。更麻烦的是，你从自己的监测报告里看不出这件事发生过——提及率依然是涨的。
SEO、GEO/AEO、AX：分界线在”可观察的结果”
这三个词经常被混着用，也经常有人说后者会取代前者。与其争论名词，不如看各自能被观察到什么——这才是能写进项目验收单的东西。
| 工作视角 | 主要追问 | 可以观察的结果 |
|---|---|---|
| SEO | 搜索系统能否发现和呈现网页？ | 收录、排名、搜索访问 |
| GEO / AEO | AI 回答能否准确使用品牌信息，并在合适的问题中提及或推荐？ | 提及、引用、描述准确性、推荐适配性 |
| AX | 智能体能否理解并使用品牌的产品或服务，完成用户交办的任务？ | 任务正确完成率、失败位置、人工介入、时间与成本 |
关键在于：这三件事是相接且重叠的，不是接力替换的。 内容仍然要能被发现，事实仍然要值得引用，而执行还需要业务系统的支持。
图 1｜三层工作的分界不在技术手段，而在能被观察到什么结果。
五环节自检：你的品牌卡在哪一步
把智能体完成一次任务的过程拆开，可以分成五个环节。每个环节都有对应的问题、常见卡点和主要归属。
| 环节 | 品牌需要回答的问题 | 常见卡点 | 主要归属 |
|---|---|---|---|
| 进入 | 合理授权的智能体能否到达目标内容或功能？ | 公开产品页被误拦；登录无法顺利交接 | 技术 / 运营 |
| 理解 | 它能否得到准确、完整、当期有效的信息？ | 价格缺计费周期；政策只写在图片里；文档版本冲突 | 内容 / 营销 |
| 判断 | 它能否判断产品是否满足用户条件？ | 只有宣传语，缺限制条件、适用对象或可核验依据 | 内容 / 营销 |
| 操作 | 它能否查询状态、选择配置并提交允许的操作？ | 库存过期；字段含义不清；接口漏了必要功能 | 产品 / 工程 |
| 确认与恢复 | 它能否知道结果，失败后能否继续或交给人？ | 没有订单状态；失败原因不明确；重复提交产生重复记录 | 产品 / 工程 |
对照着看，你会发现一件很实际的事：前两个半环节属于内容和信息架构，营销团队自己能改；后面两个半环节需要产品、工程和业务运营参与。 这个划分比任何一个技术细节都重要，它决定了 AX 这件事该怎么立项。
图 2｜五环节中，只有前两个半由营销独立完成；后半段必须跨部门。
这些事，营销团队可能很难独立完成
GEO 之所以能在市场部立项，是因为它的大部分工作——建立事实库、做带条件的问答内容、建知识库、铺分发渠道、做监测——营销团队自己就能推动。
AX 不一样。走到”操作”和”确认与恢复”，你要动的就不是文案了：
- 电商：商品事实、实时库存、变体规则和售后政策必须互相一致。智能体读到”有货”但下单失败，比一开始就没读到更糟。静态商品目录和实际可交易状态之间，隔着大量细节。
- SaaS：文档必须和真实 API、真实启用流程一致。文档过时是智能体掉链子最常见的原因之一。
- 预约型服务：智能体需要能确认时间、确认条件，并拿到明确的预约结果。只回一句”我们会联系您”，任务就断了。
AX 不是内容优化的外延，它需要产品侧配合。 如果你的 AX 项目立项时只挂在市场部，大概率会在第四、第五个环节停滞。所以，如果是 GEO项目，市场或营销部门自己就能推动；如果是 AX 项目，建议是市场部协同产品部，或者直接作为一把手项目才更好推动。
三个容易走偏的做法
以为加了结构化数据就等于完成 AX
Schema 标记、语义化 HTML、清晰的标题层级，这些确实有用——它们主要解决”理解”和”判断”两个环节。但从”判断”到”操作”，中间隔着一整个业务系统。
以为提供一个格式或文件就够了
Cloudflare 用内容协商提供 Markdown，可以减少页面包装带来的处理开销。这是有价值的基础设施实践，但它说明的是”你提供了一个入口”，不等于”智能体会用，用了就会成功”。
把”全程无人介入”当目标
减少不必要的阻碍有价值，但涉及敏感操作时，权限范围、确认点和可追溯记录本身就是体验的一部分。应该把细粒度权限和高风险操作的人类确认纳入 AX 的一部分。
所以”我们的流程已经完全不需要人”不该成为统一目标。恰当的交接点，才是好的 AX。
怎么验证有没有变好：一条最小路径
不要一上来就做全面改造。先按下面五步跑一轮，成本很低，但能告诉你真实情况。
- 选两三个真实任务。 例如带限制条件的价格查询、两款产品的比较、获取试用、预约演示。指定品牌和不指定品牌的任务都要留，这样能区分”没被发现”和”被发现但没用成”。
- 留下改造前的基线。 在固定的模型、工具和权限条件下重复运行，记录任务结果和失败发生在哪一步。
- 只修观察到的问题。 智能体读到旧文档就更新来源；表单标签不清就改标签；动态状态确实拿不到，再考虑开接口。每个新增的文件或工具都要有明确用途，不要为了”做 AX”而堆接口。
- 复测质量和完成成本。 同时看四件事：事实是否正确、操作是否成功、还需不需要额外人工补救、耗时和成本。渠道确实能归因时，再往业务转化上接。
- 模型或流程变了再测一轮。 把结论限定在你测过的条件内，并且区分”正常授权确认”和”失败后接管”——后者才是要修的问题。
图 3｜先跑通一轮再谈投入，比一开始就全面改造划算得多。
如果你已经在做 GEO，这套动作可以直接加在现有流程上：在品牌提及和事实准确性之外，加进产品比较、信息核验和关键业务任务的执行测试。交付物也会从”内容建议”延伸成”失败轨迹、数据缺口和流程修复清单”——后者对业务部门的说服力，通常比提及率高得多。
常见问题
AX 会取代 GEO 吗？ 不会。GEO 管的是”有没有被选中、提得对不对”，AX 管的是”选中之后用不用得对”。两者相接且重叠。你做过的 GEO 工作不会白费，它覆盖的是链条前半段。
我们连 GEO 都没做，要不要直接上 AX？ 不建议跳。链条前半段没打通，后半段做再多也没有入口——智能体根本走不到”操作”那一步。合理的顺序是先让信息可被找到、可被准确引用，再谈可被执行。
做 AX 要不要新开一个项目？ 看环节。前两个半环节（理解、判断）可以并进现有内容项目；后两个半环节（操作、确认与恢复）需要产品工程参与，通常要单独立项或设立跨部门小组。
中小团队从哪开始？ 先跑上面那条验证路径的第一、二步：选两三个真实任务，在固定条件下跑一遍，记录失败位置。这一步能直接告诉你该改什么。很多团队会发现，先要修的是文档版本和字段标签，而不是缺一个接口。
下一步
如果你手上已经有 GEO 的监测报告，可以做一件十分钟的事：从报告里挑三个你们表现最好的问题，把”智能体能不能顺着这个回答把事情办完”当成新问题再问一遍。
也欢迎来和我交流 AX 实践。