AI 代理会比任何人先读你的计划条款

你的联盟计划条款现在会先被软件读到，然后才被人读到。想把频道变现的创作者不再搜索"最好的 SaaS 联盟计划"然后打开十个标签页；他们向助理描述自己的受众，让它按预期收入给选项排序。助理只能给它读得到的东西排序：一个公开的 HTML 页面，上面的佣金比例、Cookie 有效期、锁定期和起付门槛是表格里的数字，而不是 PDF 里的散文或者登录之后才能看到的内容。用这种方式公布条款的计划会出现在答案里；没有这样做的计划就是不在，无论它的比例多好。这篇文章讲 AI 代理究竟会提取什么、机器可读的计划页长什么样、助理如何用算术比较两个计划、当代理开始行动而不只是阅读时会发生什么，以及你这周就能改的东西。

问题是怎么变的

一年前，找计划的创作者行为像搜索者。输入关键词、扫一遍结果、打开计划页、手动做一张表格。计划页也是为这样的读者写的：一张主视觉、一段关于合作的话、一个"申请"按钮，数字在更下面的某处或者在一个链接出去的 PDF 里。

现在同一位创作者打开助理，输入的更像一份需求："我做一个独立游戏开发的 YouTube 频道，大约四万订阅。哪些软件的联盟计划一年内能给我最多收入，各自有什么要求？"助理，不管是带浏览的 ChatGPT、Perplexity，还是带网页工具的 Claude 代理，会抓取页面，提取能找到的数字，套上创作者的假设，返回一份排好序的清单，每个计划附一句理由 [1][2]。

2026 年 3 月我们自己跑了几个这样的问题，有两点很明显。出现在答案里的计划，都是条款以纯 HTML 写在爬虫能到达的页面上的。条款是可下载 PDF、或者注册后才可见的计划没有出现；我们点名去问助理时，它回答找不到佣金比例。这是一次小规模的非正式检查，不是研究，我们不会给它加一个百分比。但机制并不微妙：代理没法给一个它读不到的数字排序。

AI 代理从联盟计划条款里提取的四个数字

在我们见过的创作者提问里，每次出现的都是同样几个字段。代理在填一张小表，它会先为找到的每个计划填完，再做比较。

注意这些联盟计划条款都不是秘密。每个计划都会把它们全部告诉通过审核的伙伴。出现在答案里和不出现的区别，只在于同样这些数字是否以解析器能提取的形式放在了公开页上。

机器可读的计划页长什么样

机器可读不是指 API。它指页面把条款当作数据来陈述，分三层，每一层都很便宜。

1. 第一屏放一个可见的 HTML 表格，上面的字段各占一行。抓取页面并提取文本的代理处理表格很在行，处理营销段落很糟糕。表格对人也有用；真的来访问页面的创作者会感谢你。
2. JSON-LD 结构化数据。Google 的文档说明了结构化数据如何被读取以及支持哪些类型 [3]；同样的标记也会被其他爬虫读取。对计划条款来说，一个 FAQPage 块，用"佣金比例是多少？"这样的问题配精确的答案，是最简单、理解最广泛的形状 [4]，而且它顺便回答了创作者会问的那些问题本身。
3. 给语言模型的纯文本摘要。llms.txt 约定提议在站点根目录放一个文件，列出模型应该读的页面并用 Markdown 做摘要 [5]。它不是一个有强制力的标准，但只要十分钟，而且有些代理会先抓它。确保 robots.txt 没有屏蔽计划页或这个文件 [6]。

RelayWonder 的联盟计划条款页从品牌创建计划的第一天起就是这样构建的。条款表格、JSON-LD 和 llms.txt 条目都从同一条计划记录生成，所以品牌把 Cookie 有效期从 60 天改成 90 天时，三处同时更新，明天抓取页面的代理看到的就是 90。

一个算例：两个计划，一位创作者

下面是助理会做的那种算术，写出来让你看到你的条款在哪些维度上被比较。一位创作者预计一年内为一个每月 $29 的产品推荐 50 位付费客户。有两个计划可选。

• 计划 A：20% 持续佣金付 12 个月，60 天 Cookie 有效期，30 天锁定期，$50 起付门槛，支持 PayPal 和 Wise。
• 计划 B：仅首付 30% 佣金，30 天 Cookie 有效期，60 天锁定期，$100 起付门槛，仅 PayPal。

不考虑流失，计划 A 一年付 50 位客户 x $29 x 20% x 12 个月 = $3,480。计划 B 付 50 x $29 x 30% = $435。用一个更现实的假设，被推荐的客户平均留存 8 个月，计划 A 付 50 x $29 x 20% x 8 = $2,320，仍然是计划 B 的五倍以上。助理还会指出，计划 A 的 60 天 Cookie 有效期适合观众需要几周才做决定的频道，而如果创作者在美国以外，Wise 很重要。

让人不舒服的是表格说明的最后一句。计划 A 在每个维度上都更好，但如果它的条款读不到，它会彻底输掉这场比较，因为助理不会说"计划 A 可能更好但我读不到"。它对计划 A 一个字都不会提。

不只是读：会行动的代理

读是第一步。下一步是助理在创作者授权下替他申请计划，或者在品牌这边，寻找并邀请伙伴。Model Context Protocol 是正在形成的标准，用来给助理一组带类型化输入输出的工具 [7]。我们正在为 RelayWonder 构建一个 MCP 端点，让持有范围密钥的助理可以读取计划条款、搜索伙伴、发布内容任务、邀请伙伴，每一项都是基于品牌控制台所用的同一份数据的工具调用。

我们有意划了一条线。代理不能批准打款，不能读取或修改银行信息，不能变更团队成员，不能轮换密钥。密钥分范围（读取、任务、邀请），每次调用都记录密钥、工具和参数，品牌能看到代理究竟替它做了什么。批次仍然由人批准，仍然从品牌自己的 PayPal 或 Wise 账户支付。代理可以做阅读和起草；钱在它够不到的地方。

对创作者来说，对应的场景是一个助理读完二十个计划的条款，筛出三个，起草一份申请由创作者审阅并发送。这正是条款必须可读的原因：创作者可能根本不会访问你的页面。代理访问了，然后汇报了。

这周就能改的事

这些都不需要新平台。只要你的联盟计划条款已经有一个页面，一个下午就能让它对代理可读。

1. 把四个数字放进公开计划页第一屏的表格里：佣金比例和月数、Cookie 有效期、锁定期、起付门槛。再加打款方式和接受的伙伴类型两行。
2. 把冗长的法律条款从 PDF 搬到 HTML 页面上，哪怕很长。PDF 有些代理能读、有些会跳过；HTML 所有代理都读。
3. 加一个 FAQPage JSON-LD 块，用精确数字回答"佣金比例是多少？""Cookie 有效期多长？""伙伴什么时候拿到钱？""谁可以加入？"。
4. 检查 robots.txt 和 CDN 里的机器人拦截。很多站点默认屏蔽 AI 爬虫，却没意识到计划页恰恰是它们最想被抓的那一页。
5. 加一个 llms.txt 文件，列出计划页和条款页，各配一行摘要。
6. 打开浏览功能，向助理问一个创作者会问的问题，看你的计划有没有出现、数字对不对。每次改条款之后都重复一次。

买家那一侧是同一套机制

上面说的都是创作者找计划。完全相同的机制决定买家能不能找到你的产品。买家问助理"做 X 该用什么"时，助理引用它读得到且信任的页面。我们的姊妹产品 InsightWonder 找出你所在品类里助理引用竞品、谁都不引用、或者引用你的那些买家问题；RelayWonder 通过 API 密钥每小时同步这些问题，你可以把它们变成给伙伴的内容任务简报 [8]。InsightWonder 不估算一个问题被问的频率，它告诉你这个问题现在谁被引用了。

RelayWonder 里的内容任务是一份简报、每条交付内容一笔奖励，加上后续成交的佣金。交付的 URL 会被追踪点击、成交和 AI 引用，品牌能看到创作者做的那条内容是否已经成为买家提问时助理引用的页面之一。可读的计划条款帮你拿到创作者；创作者的内容帮你拿到引用。这是同一个赌注下了两次。