企业官网建设流程全解析

一、事件

2026 年 9 月 21 日周日晚起，亚马逊开始阻断 Meta 的 AI 智能体 Muse 代用户在 Amazon.com 购物，下单环节弹提示称这是"未经授权的 AI 代理持续访问"，违反使用条件。

三条理由：

1. 未获接入通知——据 The Verge、TechCrunch、IT之家、The Decoder 四家媒体 2026 年 9 月 21 日的报道，亚马逊称事先未收到 Muse 的接入告知。
2. 浏览时不表明 AI 身份——IT之家、The Decoder、The Verge 的报道均提到亚马逊对这一点的关切。
3. 疑似采集保存客户账号凭证——"疑似"二字要留着。多家报道都以它限定，亚马逊并未公布已确认的技术证据。

二、为什么技术团队要在意

主流解读是"AI 代理时代来了，赶紧让 AI 读到你的内容"。这个读法漏了一半：亚马逊做的不是迎接，是拒绝——它把一个代理挡在门外，还要求对方把自己从服务列表里删掉。多数站点的位置更接近亚马逊，你是被敲门的一方。先建的能力不是让 AI 更容易读到你，而是想清楚让谁进、怎么进、什么时候不让进。顺序错了，后面全错。

三、AI 代理不是升级版爬虫

爬虫的麻烦是偷偷来，AI 代理的麻烦是它带着真人的授权来。据 The Verge、IT之家、The Decoder 的报道，Muse 是 Meta 面向个人用户的 AI 助手，用户让它代自己办事，包括买东西。来访的是客户派来的代表，不是无主机器。

三个层面的变化：技术上它带着真实登录态，难与真人区分，封 IP 收效有限；商业上拒绝它可能等于拒绝自己的客户；法律上它代表谁、责任归谁没有共识，亚马逊对是否诉诸法律拒绝置评。

代表和爬虫不该被同一套规则对待，而多数站点的 robots.txt 里只有一句User-agent: *。

四、三条理由对应三个工程字段

框架是授权 → 身份 → 数据，任何一条不成立门就不该开。只要有后台、有用户数据，这三个问题今天就在。

五、步骤一：先画准入清单

别先改文件。技术加业务一起把表填出来，填不出来，改 robots.txt 就是瞎改。

没有技术团队的话，"靠什么识别代理"不是半天能解决的，涉及 UA 白名单、IP 段、行为特征。中小团队更现实的做法是先列清开关清单，识别能力从"能认出常规爬虫"起步。

六、步骤二：分级准入配置

以下是示例，不对应任何一家公司的真实文件。

# 分组1：公开抓取类，只放开产品/价格/FAQ User-agent: GPTBot User-agent: ClaudeBot Allow: /product/ Allow: /pricing/ Allow: /faq/ Disallow: /account/ Disallow: /admin/ Crawl-delay: 2 # 分组2：代用户操作的代理，默认不放行，走白名单登记 User-agent: Muse Disallow: / # 分组3：兜底 User-agent: * Disallow: /account/ Disallow: /api/

再配一份 llms.txt：robots.txt 回答"能不能来"，llms.txt 回答"先看哪几页"。只写前者，代理进来后会自己乱挑。

# /llms.txt > 站点名：一行说清你是谁、做什么 ## 可摘要 - /product/：产品与规格 - /pricing/：价格区间与计费方式 - /faq/：常见问题 ## 不摘要 - /method/：方法论原文，引用需署名 - /tools/：需登录使用

七、步骤三：身份判定与日志

声明优先，猜测兜底。UA 里有明确 token 的按白名单走，没有的进打分。

DECLARED={"gptbot":"readonly_crawler","claudebot":"readonly_crawler","muse":"delegated_agent"}defclassify(ua,ip,rate_1m,has_session,has_pointer_events):fortoken,kindinDECLARED.items():iftokeninua.lower():returnkind,0.95# 自报身份，直接采信score=0.0ifrate_1m>60:score+=0.35ifis_datacenter_ip(ip):score+=0.25ifhas_sessionandnothas_pointer_events:score+=0.20return("likely_agent"ifscore>=0.6else"unknown"),min(score,0.9)

关键在最后一行：打分不出结论。置信度不够就标unknown并按只读放行，别因为score > 0.5拦掉一个真客户，误杀的代价高于漏放。

日志里补几个字段，出事才复盘得了：

{"ts":"2026-09-21T21:14:03+08:00","path":"/product/x200","ua":"Muse/0.9 (+bot-policy-id)","agent_class":"delegated_agent","identity_confidence":0.95,"session_owner":"user_88213","auth_mode":"delegated_token","rate_1m":34,"scope":"read_only","decision":"allow_readonly"}

auth_mode区分主登录态与委派令牌，scope记当时允许它做什么。能说清"它当时只有只读权限"和说不清，是两回事。

八、凭证隔离：别让代理用主人的钥匙

对应第三条理由。工程上四件事：委派令牌与主登录态分开签发，scope 显式声明且默认只读；TTL 压到分钟级，代下单这类高权限动作单独二次授权；令牌绑agent_class；令牌可撤销，撤销在网关层立即生效。

难点不在实现，在很多站点根本没有委派令牌这一层——代理直接复用用户 Cookie，后台看到的就是"一个正常登录的用户"。这种情况下你既没有数据证明"疑似采集凭证"，也没有数据反驳它。

九、两个反面

门关上之后内容优化会失效。内容侧优化的全部作用建立在"AI 能读到你的内容"上，前提不成立方法归零。"大量站点把 AI 锁在门外"这个说法也要谨慎：常见统计口径是 robots.txt 里存在任意一条 Disallow 规则，这类规则拦的多是参数路径和后台路径，公开产品页往往是开放的。更准确的说是大量站点对开放边界没有清晰规划。

全开会被自己反噬。内容全开、答案全前置之后，用户还需要访问你的站点吗？AI 把价格、服务、优势完整答了，漏斗前端就被抽走。判断原则是区分"可被摘要走的结论"和"必须亲临的价值"：公司是谁、做什么、价格区间、常见问题，开放成本低、收益明确；深度方法论、诊断过程、可操作的工具、一对一判断，这是真正的货，不该被压成摘要送人。开得越准越好。

十、实测验收

curl 逐条验返回码。改 robots.txt 最常见的翻车是写了Disallow，因为路径前缀不匹配，页面照样进得来。

# $SITE 换成你自己的站点地址，带协议前缀forpin/product/x200 /pricing/ /account/ /api/order;doprintf"%-16s %s\n""$p""$(curl-s-o/dev/null-w'%{http_code}'-A'Muse/0.9'"$SITE$p")"done

用外部 AI 反向验证。找几个人在主流 AI 里问三个只有你官网才答得准的问题，看它引用了谁。验收标准不该是"内部看着挺好"，而是"外部 AI 有没有读到"。

十一、两条限制

读不到不等于做错了。内容可读只是被引用的必要条件，不是充分条件，三步做完 AI 依然可能引用行业媒体或比你早做三年的人。

先发生变化的通常不是引用量，而是站点从"说不清自己是谁"变成"说得清"——客服重复咨询变少，新人上手变快。这些收益在被引用之前就已经到账。

小结

亚马逊这次做的是拒绝。多数团队第一件事是治理准入：授权 → 身份 → 数据，按序补齐；第二件事才是边界内的内容优化。文件改错可以回滚，顺序错了全是白做。