# Alejandro Rioja — ZH > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/zh/ Author: Alejandro Rioja Language: zh --- ## 事件驱动 vs 定时调度智能体:哪种场景用哪种模式 Source: https://alejandrorioja.com/zh/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/ Published: 2026-05-31 Updated: 2026-05-31 Tags: AI Agents TL;DR: 当用户操作需要即时响应时,使用事件驱动智能体——超过几秒的延迟就会破坏体验。对于时机可预测的批量或周期性工作,使用定时调度智能体。约束:事件驱动智能体必须无状态且快速;定时调度智能体可以有状态且较慢。 ## 目录 _2026年5月更新。_ **TL;DR:** 当用户操作需要即时响应时,使用事件驱动智能体——超过几秒的延迟就会破坏体验。对于时机可预测的批量或周期性工作,使用定时调度智能体。约束:事件驱动智能体必须无状态且快速;定时调度智能体可以有状态且较慢。 **[运营者视角]** 我在咨询品牌和 Pickleland(德克萨斯州 Pflugerville 的匹克球场馆)中运行超过 30 个生产环境智能体。每一个都属于两种模式之一:由事件触发,或由时钟触发。搞错这点会浪费金钱,并交付糟糕的用户体验。 ## 两种模式的通俗解释 **事件驱动智能体**因为某件事发生而醒来。来了一笔预订。发布了一条评论。提交了一个表单。触发器是外部的,时机不可预测。任务:快速响应。 **定时调度智能体**因为时钟说了而醒来。每天早上7点。每个周日下午6点。每小时整点。触发器是内部的,完全可预测。任务:做扎实的工作。 就这些。别过度复杂化。架构来自一个问题的答案:*用户或系统现在立刻需要响应,还是可以等到特定时间?* ## 事件驱动:社交评论回复智能体 每当监控的 Facebook 帖子上出现新评论,我的社交回复智能体就会触发。智能体读取评论,分类意图(问题、投诉、称赞、垃圾),起草回复并发布——如果置信度低则标记供人工审核。 整个往返必须在 30 秒内完成,否则回复会显得过时。这是一个事件驱动问题。 以下是处理社交监控服务 webhook 的简化版 Cloudflare Worker: ```typescript // workers/social-reply.ts export default { async fetch(request: Request, env: Env): Promise { if (request.method !== "POST") { return new Response("Method not allowed", { status: 405 }); } // 验证 webhook 签名 const sig = request.headers.get("x-webhook-signature") ?? ""; const body = await request.text(); const valid = await verifySignature(body, sig, env.WEBHOOK_SECRET); if (!valid) return new Response("Unauthorized", { status: 401 }); const event = JSON.parse(body) as SocialCommentEvent; // 分类并回复 — 保持异步以便快速返回 200 env.REPLY_QUEUE.send(event); return new Response("OK", { status: 200 }); }, }; // 队列消费者 — 执行实际的 AI 工作 export const queue: ExportedHandlerQueueHandler = async (batch, env) => { for (const msg of batch.messages) { const comment = msg.body; const classification = await classifyComment(comment.text, env); if (classification.intent === "spam") { msg.ack(); continue; } const reply = await draftReply(comment, classification, env); if (classification.confidence > 0.85) { await postReply(comment.postId, comment.id, reply, env); } else { await flagForReview(comment, reply, env); } msg.ack(); } }; ``` 注意两件事。第一,fetch 处理器立即返回 200,并将实际工作卸载到队列。这保持了 webhook 响应速度,防止监控服务重试。第二,队列消费者执行实际的 AI 调用——分类和起草——没有来自打开的 HTTP 连接的时间压力。 ## 定时调度:Pickleland 活动推广智能体 Pickleland 管理场地和活动。每周都需要有人将即将举行的活动推送到合适的 Facebook 群组来填满席位。这是纯粹的周期性批量工作——没有用户操作触发它,也不需要实时发生。 Pickleland 活动推广智能体在 cron 上运行,检查预订系统中未来 4 天的活动,为每个匹配的 Facebook 群组起草特定帖子,并在任何内容发布前提交供我审核。 ```typescript // workers/event-promoter.ts export default { async scheduled( event: ScheduledEvent, env: Env, ctx: ExecutionContext ): Promise { ctx.waitUntil(runPromoter(env)); }, }; async function runPromoter(env: Env): Promise { // 从预订系统获取活动 const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 }); if (upcomingEvents.length === 0) return; const drafts: PromoDraft[] = []; for (const event of upcomingEvents) { // 将每个活动与合适的 FB 群组匹配 const groups = await matchFacebookGroups(event, env); for (const group of groups) { const post = await draftPromoPost(event, group, env); drafts.push({ event, group, post }); } } // 将草稿保存到 Airtable 供审核 — 没有任何内容自动发布 await saveDraftsForReview(drafts, env); // 通过 Slack 通知我 await notifyOperator( `${drafts.length} 份推广草稿等待审核`, env ); } ``` 将一切串联起来的 wrangler 配置: ```toml # wrangler.toml [[triggers]] crons = ["0 18 * * 0"] # 每周日 18:00 UTC ``` 注意定时调度智能体能做而事件驱动不能做的:遍历多个活动,写入数据库,发送摘要通知。它在做批量工作。事件驱动智能体需要保持精简并快速响应。 ## 定时调度:每日简报 每天早上 7 点,我的每日简报智能体运行。它拉取隔夜邮件、我的日历、最重要任务,以及我标记为相关的新闻。将所有内容格式化成单一文档并放入我的 AI Workspace 文件夹。 这是纯调度型。没有任何事件会触发它——我只是每天早上开始工作前需要它。 ```typescript // workers/daily-brief.ts export default { async scheduled( event: ScheduledEvent, env: Env, ctx: ExecutionContext ): Promise { ctx.waitUntil(buildDailyBrief(env)); }, }; async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); const brief = await synthesizeBrief({ emails, calendar, tasks }, env); await writeToWorkspace(brief, env); } ``` ```toml [[triggers]] crons = ["0 7 * * *"] # 每天 7:00 UTC ``` 并行的 `Promise.all` 是刻意为之的。定时调度智能体没有等待的人——但它们仍然不应该比必要的更慢。并行获取所有数据源,然后进行一次 AI 合成。 ## 事件驱动何时会失败 我最常见的失败模式:有人构建了一个在处理器中做太多工作的事件驱动智能体。 一笔预订进来。智能体获取客户资料,从三个外部 API 丰富它,运行个性化模型,写入 CRM,发送确认邮件,并更新仪表板。整个过程需要 45 秒。预订平台重试,因为没有足够快地收到 200。现在智能体运行了两次。 修复方式与社交回复智能体相同:立即返回 200,将事件推送到队列,让队列消费者异步处理繁重工作。 另一个失败模式:将事件驱动用于实际上是周期性的工作。"发送每周摘要"不是一个事件。不要将其连接到合成的 cron webhook——使用适当的定时触发器。 ## 定时调度何时会失败 当工作实际上对延迟敏感时,定时调度智能体会失败。如果用户提交表单而处理智能体在 5 分钟 cron 上运行,用户最多会盯着加载指示器看 5 分钟。这不是定时作业——这是伪装成定时的慢速事件驱动作业。 另一个失败:扩展到无限工作的定时调度智能体。如果你的 cron 每分钟运行一次,每次调用可以处理数百条记录,你会很快达到 Cloudflare 的 CPU 限制。要么增加 cron 间隔,添加队列以限制每次调用的工作,要么切换到 Durable Objects 进行长时间运行的协调。 ## 混合模式:预订流水线 一些工作流确实需要两者兼备。Pickleland 预订流水线的工作方式是: 1. **事件驱动**:新预订 webhook → 确认预订,向客户发送收据,更新可用性。必须在 10 秒内完成。 2. **定时调度**:每周日 → 审查上周所有预订,生成摘要报告,标记异常(重复预订、异常取消率)。 相同领域,两种模式,两个智能体。事件驱动拥有实时用户体验。定时调度拥有每周运营审查。它们共享一个数据库,但别无其他。 不要试图将它们合并为一个"做所有事情"的智能体。你最终会得到一个对于事件来说太慢、对于批量工作来说与实时流程耦合太紧的东西。 ## Cloudflare Workers:为何是两者的正确基础设施 Cloudflare Workers 原生支持两种模式: - `fetch` 处理器 → 事件驱动(webhooks、API 调用) - `scheduled` 处理器 → cron 调度(通过 wrangler.toml 中的 `[[triggers]]`) - `queue` 消费者 → 与 HTTP 层解耦的异步处理 边缘部署意味着你的事件驱动智能体在全球范围内快速响应。免费层足够慷慨,可以在不花费任何费用的情况下原型化两种模式。统一的 `wrangler.toml` 配置意味着你不需要为两种模式管理两套独立的基础设施配置。 Workers 不能很好解决的一件事:需要运行超过几分钟的智能体。对于这些,使用 Durable Objects 或将工作委托给更长时间运行的后端。 ## 运营者的结论 在写一行智能体代码之前先选定模式。事件驱动适用于人在等待的任何事情;定时调度适用于按时钟运行的任何事情。保持事件驱动处理器精简——快速返回,将工作入队。保持定时调度智能体并行——不要将可以并行化的东西序列化。架构很简单。违反它就是复杂性的来源。 --- ## 本地商业GEO:让实体店被AI搜索引用的方法 Source: https://alejandrorioja.com/zh/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, Marketing TL;DR: 要让你的实体店被AI搜索引擎引用,首先优化谷歌商家档案——这是最重要的信号。然后添加LocalBusiness JSON-LD架构,确保整个网络的NAP(名称、地址、电话)一致,并持续积累最新评论。你无法购买AI引用,在GBP中堆砌关键词也无济于事。 ## 目录 _2026年5月更新_ **TL;DR:** 要让你的实体店被AI搜索引擎引用,首先优化谷歌商家档案——这是最重要的信号。然后添加LocalBusiness JSON-LD架构,确保整个网络的NAP(名称、地址、电话)一致,并持续积累最新评论。你无法购买AI引用,在GBP中堆砌关键词也无济于事。 **[运营者视角]** 我经营着德克萨斯州普法鲁格维尔的一家匹克球场馆Pickleland。当我开始查看ChatGPT和Perplexity对"奥斯汀附近最佳匹克球场"的搜索结果时,发现尽管在谷歌地图上排名靠前,我的场馆却并未出现。以下是我的改变和有效原因。 --- ## AI搜索为何对本地商业不同 传统本地SEO的目标是在地图包和蓝色链接中排名。AI搜索则不同:ChatGPT、Perplexity和谷歌的AI概览会合成答案并引用特定来源。对于本地查询,它们从谷歌商家档案数据、网站结构化数据、评论平台和权威目录列表的组合中获取信息。 好消息:门槛比你想象的要低。大多数实体商家忽视了结构化数据,让GBP变得陈旧过时。如果你正确且持续地做好基础工作,就能脱颖而出。 坏消息:没有捷径。你无法花钱让AI引擎引用你。不存在"AI引用"广告产品。你能做的是让AI容易理解并信任你的商家。 --- ## 谷歌商家档案是基础 如果只能选一个杠杆,那就是谷歌商家档案(GBP)。当有人问AI助手"奥斯汀附近最佳匹克球场"时,AI会大量依赖GBP数据。原因在于GBP是一个结构化的、经过验证的数据库。在网络上训练的AI模型和Perplexity等进行实时检索的工具将GBP信号视为高可信度信号。 GBP应该做什么: - **填写每个字段。** 类别、描述、营业时间(包括节假日)、属性、服务/菜单。每个空字段都是错失的信号。 - **精确使用主要类别。** Pickleland的类别是"匹克球场",而不仅仅是"运动综合设施"。AI引擎会读取类别数据。 - **定期添加照片。** GBP奖励新鲜度。每月至少两次上传球场、活动和室内巡览的新照片。 - **发布更新。** GBP帖子会被索引。撰写简短帖子(150-300字)回答诸如"需要自带球拍吗?"这样的问题。这些Q&A帖子会直接显示。 - **回答每个Q&A。** GBP的Q&A部分是公开且被索引的。如果还没有人提出你最常见的问题,自己添加并回答它们。 不要做的事:不要在GBP描述中堆砌"奥斯汀最佳匹克球场最便宜立即营业"这样的关键词。这看起来像垃圾信息,对AI没有帮助,谷歌还可能暂停你的档案。 --- ## LocalBusiness架构:结构化数据层 你的GBP处理谷歌生态系统。对于非谷歌AI搜索(Perplexity、带浏览功能的ChatGPT、基于Bing的工具),网站上的结构化数据是主要信号。 在你的主页和联系页面添加`LocalBusiness` JSON-LD块。以下是我为Pickleland使用的架构: ```json { "@context": "https://schema.org", "@type": "SportsActivityLocation", "name": "Pickleland", "description": "德克萨斯州普法鲁格维尔的室内匹克球场馆,设有8个专用场地、开放打球、联赛和课程。", "url": "https://pickleland.com", "telephone": "+1-512-000-0000", "address": { "@type": "PostalAddress", "streetAddress": "123 Pickleland Dr", "addressLocality": "Pflugerville", "addressRegion": "TX", "postalCode": "78660", "addressCountry": "US" }, "geo": { "@type": "GeoCoordinates", "latitude": 30.4349, "longitude": -97.6200 }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "06:00", "closes": "22:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Saturday","Sunday"], "opens": "07:00", "closes": "21:00" } ], "priceRange": "$$", "amenityFeature": [ { "@type": "LocationFeatureSpecification", "name": "Indoor Courts", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Equipment Rental", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Lessons Available", "value": true } ], "sameAs": [ "https://www.google.com/maps?cid=YOUR_CID", "https://www.yelp.com/biz/pickleland-pflugerville", "https://www.facebook.com/pickleland" ] } ``` `sameAs`数组明确将你的架构实体连接到GBP、Yelp和Facebook页面。AI引擎使用这个进行交叉验证,确认这些都是同一家商家。`geo`坐标很重要——Perplexity进行距离匹配。机器可读格式的`openingHoursSpecification`会在有人询问"Pickleland周日开放吗?"时直接出现在AI答案中。 适当时使用`SportsActivityLocation`而非通用的`LocalBusiness`类型——类型越具体,AI分类你的精确度就越高。 --- ## NAP一致性:枯燥但关键 NAP代表名称、地址、电话(英文:Name, Address, Phone)。当你的商家名称在谷歌显示为"Pickleland"、在Yelp显示为"Pickleland LLC"、在Facebook显示为"Pickleland - Pflugerville"、在本地目录显示为"Pickleland Pickleball"时——AI引擎看到的是四个不同实体,并降低对所有实体的信任度。 进行NAP审计: 1. 在谷歌、Yelp、Facebook、Apple Maps、Bing Places、Foursquare、TripAdvisor以及任何行业专属目录中搜索你的商家名称。 2. 记录每个变体。 3. 纠正它们——大多数平台允许你直接认领或编辑列表。 你在任何地方使用的名称应与谷歌商家档案上的名称完全一致。对于Pickleland,就是"Pickleland"——没有后缀,没有城市名称附加。 电话号码格式也很重要。在任何地方使用相同格式:`(512) 000-0000`或`+1-512-000-0000`,选择一种并坚持使用。JSON-LD中的`sameAs`链接帮助AI引擎连接各点,但一致的NAP才是首先建立实体信任度的基础。 --- ## 评论速度:新鲜度是AI信号 AI搜索引擎不仅看星级评分——它们还关注评论的新鲜度和频率。一家有200条评论但最后一条是18个月前的商家,排名低于一家有80条评论但上周有三条的商家。 在Pickleland,我们将评论速度融入运营: - 每次开放打球结束后,工作人员发送带有谷歌评论页面直接链接的后续短信。 - 我们在24小时内回复每条评论——无论正面还是负面。回复活动向爬虫发出新鲜度信号。 - 每月识别最满意的常客,亲自请求他们分享反馈。 我们在大约四个月内从43条评论增加到190条。对AI引用的影响是可衡量的:在以强劲新鲜度突破100条评论大关约六周后,Pickleland开始出现在Perplexity对"奥斯汀地区匹克球"的回答中。 不要购买虚假评论。除了显而易见的被暂停风险外,AI引擎越来越善于检测不自然评论群集(相似时间戳、通用语言、没有历史的评论者账户)。 --- ## 与人们询问AI的方式匹配的Q&A内容 传统SEO针对关键词短语。GEO针对问题——特别是人们在AI助手中输入或说出的自然语言问题。 想想有人问ChatGPT的方式与他们在谷歌中输入的方式有何不同: - 谷歌:`匹克球场 奥斯汀` - ChatGPT:`奥斯汀附近平日早上开放的最佳室内匹克球场有哪些?` 你的内容需要回答长格式版本。在你的网站上创建专门的FAQ或Q&A页面,直接解答: - "需要自带球拍吗?"(设备问题) - "在[场馆]打匹克球要多少钱?" - "[场馆]适合初学者吗?" - "可以预订场地用于企业活动吗?" - "周末开放打球时间是什么时候?" 每个答案用2-4句话写,直接且完整。当用户提出匹配的问题时,AI引擎会逐字提取并显示这些内容。我亲眼看到Pickleland的FAQ答案被逐字引用在Perplexity的回答中。 也要用你的GBP帖子来做这件事:写结构化为问答形式的帖子。"问:需要提前预订场地吗?答:开放打球时间欢迎直接到访(请查看我们的时间表),但建议在周末高峰时段预订场地。请在pickleland.com预订。"这种格式对AI友好且可被索引。 --- ## 无效的做法 坦诚地说明局限性: **在GBP描述中堆砌关键词**对AI搜索没有帮助。读起来像垃圾信息,可能导致档案被标记。为人类自然地写作。 **花钱购买AI引用**作为产品不存在。任何声称收费"让ChatGPT引用你"的服务都是骗局。AI引用是编辑性的——基于AI判断的最相关、最可信的答案。 **一次性架构设置**是不够的。你的架构需要保持最新。如果营业时间改变了,你更新了GBP但没有更新JSON-LD,就会产生矛盾信号。将季度架构审计纳入你的日常工作。 **追逐每一个目录**收益递减。专注于AI检索权重最高的平台:谷歌、Yelp、Facebook、Apple Maps、Bing Places。行业专属目录(在我们的案例中,像美国匹克球场馆目录这样的地方)是值得的,因为它们在该垂直领域具有权威性。 --- ## 运营者的最终结论 本地商业的GEO并不复杂——只是不光鲜,需要一致性。让你的GBP达到100%完整度,在网站上添加干净的LocalBusiness架构,在整个网络标准化你的NAP,并将评论节奏纳入运营。全部做到,AI搜索引擎就拥有了自信引用你所需的一切。我用Pickleland做到了这一点,结果体现在真实的引用数据中。今天就从GBP开始——花一个下午,效果立竿见影。 --- ## 我如何衡量AI智能体是否真正有效 Source: https://alejandrorioja.com/zh/how-i-measure-whether-an-ai-agent-is-actually-working/ Published: 2026-05-31 Updated: 2026-05-31 Tags: AI Agents TL;DR: 大多数运营者完全跳过评估,只是假设他们的智能体在正常工作。我的框架:建立包含5–10个已知输入和预期输出的黄金集,用简单语言定义通过/失败标准,每周检查日志。在有10次真实运行之前,不要构建复杂的评估系统——那是扼杀动力的陷阱。 ## 目录 _2026年5月更新。_ **TL;DR:** 大多数运营者完全跳过评估,只是假设他们的智能体在正常工作。我的框架:建立包含5–10个已知输入和预期输出的黄金集,用简单语言定义通过/失败标准,每周检查日志。在有10次真实运行之前,不要构建复杂的评估系统——那是扼杀动力的陷阱。 **[运营者视角]** 我在咨询品牌和Pickleland(德克萨斯州普夫卢格维尔市的一家匹克球场)中管理着30多个生产环境AI智能体。某个时刻,我意识到我花在担心智能体偏移上的时间比实际使用它们的时间还多。这是我最终采用的评估框架——不需要博士学位,不需要自定义评估平台,不需要Python。 ## 没人谈论的问题:智能体在悄悄偏移 当一个人类员工开始做错工作时,你通常会注意到。当一个AI智能体开始产生垃圾输出时,它会继续产生垃圾——悄无声息地,大规模地,直到某些东西出问题足够严重,人类才最终察觉。 我有一个内容智能体,在模型更新后开始附加"作为AI语言模型"的免责声明。我有一个活动推广智能体,因为提示词变量名改变了,它停止包含购票链接。两者都没有高调地失败。两者都只是悄悄退化了。 解决方案不是构建NASA级别的监控系统。而是拥有一个简单、可重复的检查,在偏移累积之前就能发现它。 ## 评估到底是什么(对运营者而言) 工程师用"eval"这个词来表示在模型上运行基准测试。对运营者而言,我指的是更简单的东西:**一个可重复的测试,告诉你你的智能体是否仍在做你构建它所做的事情。** 三个组成部分: 1. **黄金集** — 5–10个你已经见过的真实输入,配有你已经知道是好的预期输出 2. **通过/失败标准** — 用简单语言说明什么算通过的规则 3. **定期检查** — 你或你的助手实际按照节奏运行测试 就这些。你不需要框架。你需要纪律。 ## 构建你的黄金集 从你的生产日志中提取。找到5–10个你已经知道好的输出长什么样的真实输入。这些是你的基准事实。 对于我的内容管道智能体,黄金集是5篇发布的文章,这些文章在我手动写作时通过了我的声音检查清单。对于我的Pickleland活动推广员,是5个过去互动率高于平均水平的Facebook帖子(评论+分享,不仅仅是点赞)。 **好的黄金集规则:** - 真实输入,不是你编造的假设情景 - 至少包含一个边缘案例(棘手的输入、简短的输入、格式不寻常的输入) - 保持预期输出有文档记录——截图、文本文件、电子表格中的一行 - 永远不要从黄金集中删除;只添加 当智能体最后一次被确认正常工作时,写下"好"看起来是什么样的。那就成为你的预期输出。 ## 定义通过/失败标准 模糊的标准毫无用处。"输出应该是好的"永远会通过,因为你会合理化它。 将你的标准写成非专家也能评估的检查清单项目。以下是我为内容管道智能体实际使用的标准: **内容智能体通过/失败检查清单:** - [ ] 文章在前100字内有TL;DR - [ ] 没有"在当今快节奏的世界中"或"作为AI"这样的短语 - [ ] 至少有一个具体数字或统计数据 - [ ] 字数在800到2000之间 - [ ] 所有内部链接都能解析(没有404错误) 对于Pickleland活动推广员: **活动推广员通过/失败检查清单:** - [ ] 活动名称与源日历匹配 - [ ] 日期和时间正确 - [ ] 购票链接存在且未损坏 - [ ] 文案不超过280字 - [ ] 帖子不使用通用填充短语 如果5个检查清单项目中有4个通过,则运行为通过。如果3个或更少通过,则为失败,我在下次运行前进行调查。 ## 使用Claude作为评判者 对于输出较长或较复杂的智能体,我使用Claude Sonnet作为自动评判者。这比手动审查更快,并且能发现我可能忽略的问题。 以下是我为内容智能体使用的评判提示: ```text You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards. Evaluate the following post against these criteria: 1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO) 2. Contains at least one concrete number or specific example (YES/NO) 3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO) 4. Word count is between 800 and 2000 words (YES/NO) 5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO) For each criterion, respond YES or NO with one sentence of explanation. At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise. Post to evaluate: --- {{post_content}} --- ``` 我将其作为Cloudflare Worker运行,该Worker提取最新草稿,触发此提示,并将结果写入Google Sheet。整个过程需要8秒,每次运行费用约为$0.003。 对于活动推广员,评判提示更简单: ```text You are checking an AI-generated Facebook event post for accuracy and quality. Source data: - Event name: {{event_name}} - Date: {{event_date}} - Time: {{event_time}} - Ticket URL: {{ticket_url}} Generated post: --- {{generated_post}} --- Check: 1. Does the post correctly state the event name? (YES/NO) 2. Does the post correctly state the date and time? (YES/NO) 3. Does the post include the exact ticket URL? (YES/NO) 4. Is the post under 280 words? (YES/NO) 5. Is the tone inviting without using generic filler phrases? (YES/NO) Output PASS if all 5 are YES, FAIL if any are NO. List which items failed. ``` ## 在哪里查看:Cloudflare Worker日志 如果你在Cloudflare Workers上运行智能体(我的大多数轻量级智能体都是这样),内置的日志追踪是你最好的朋友。你不需要第三方日志服务就能开始。 我在每周抽查中检查的内容: - **错误和异常** — 任何崩溃或超时的内容 - **令牌计数** — 如果一次运行突然使用了正常令牌的3倍,说明有什么东西改变了 - **延迟峰值** — 突然减速通常意味着提示词变长了,或者模型在挣扎 - **输出长度漂移** — 如果平均输出从600字降到200字,智能体改变了行为 我每周一早上花15分钟在这上面。我在Notion里有一个简单的检查清单:打开每个智能体的日志,记录任何异常,将令牌使用量与上周的基准进行比较。这就是整个流程。 ## 电子表格评估:丑陋但有效 在有任何自动化之前,我在Google Sheet中运行评估。我仍然在前4周为新智能体使用这个方法。 结构: | 运行日期 | 输入 | 预期输出(摘要)| 实际输出(摘要)| 通过/失败 | 备注 | |---------|------|--------------|--------------|---------|------| | 2026-05-01 | "写一篇关于AI智能体的文章" | 直接、有见解、1000+字、有TL;DR | 950字、有TL;DR、声音强劲 | 通过 | 略短 | | 2026-05-08 | 相同 | 相同 | 400字、通用、无TL;DR | 失败 | 更新后模型漂移 | 每周五行。需要10分钟。如果你连续失败两次,在继续之前停止智能体并修复提示词。 这种方法低技术含量得令人尴尬。这也是我在三次提示词回归到达生产环境之前发现它们的方式。 ## 不该做什么 **在有10次真实运行之前,不要构建评估系统。** 我见过创始人花两周时间为只运行过两次的智能体构建复杂的评估管道。在你拥有真实的生产数据之前,你对"好"是什么样子知之甚少。 **不要用你编造的合成输入进行评估。** 合成测试用例会错过生产环境抛给你的奇怪边缘案例。始终从真实日志开始。 **不要评估所有内容。** 选择3–5个失败会真正造成伤害的智能体——面向客户的输出、任何公开发布的内容、任何触发支付的内容。在你有余力之前,跳过内部实用工具智能体。 **不要过早自动化。** 你真正使用的电子表格胜过你忘记检查的Datadog仪表板。先手动开始,在运行检查10次并知道你真正在寻找什么之后再自动化。 ## 运营者的底线 评估不必达到工程级别才有用。5–10个真实输入的黄金集、一份通过/失败标准检查清单,以及每周一15分钟的日志检查,将在80%的智能体漂移累积之前就能发现它。从那里开始。如果你仍在没有任何评估的情况下运行智能体,你就是在盲目飞行——最终某些东西会以足够公开的方式失败,让你希望自己花了那20分钟。 --- ## 2026年如何让ChatGPT在回答中引用你的品牌 Source: https://alejandrorioja.com/zh/how-to-get-your-brand-cited-inside-chatgpt-answers-in-2026/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, SEO TL;DR: ChatGPT和其他大型语言模型会引用那些持续出现在权威、结构化第三方来源中的品牌——而不仅仅是你自己的网站。建立引用面:在对比评测中被引用,维护准确的结构化数据,并发布能直接回答买家向AI提问的内容。结果需要60-90天才能反映在模型行为中,目前没有直接提交机制。 ## 目录 _2026年5月更新。_ **TL;DR:** ChatGPT和其他大型语言模型会引用那些持续出现在权威、结构化第三方来源中的品牌——而不仅仅是你自己的网站。建立引用面:在对比评测中被引用,维护准确的结构化数据,并发布能直接回答买家向AI提问的内容。结果需要60-90天才能反映在模型行为中,目前没有直接提交机制。 **[运营者视角]** 我在生产环境中运营超过30个AI代理,一直在密切追踪我的客户哪些品牌会出现在ChatGPT的回答中,哪些会被完全忽略。现在规律已经足够清晰,值得记录下来。 --- ## 为什么"擅长SEO"已经不够了 Google和ChatGPT有不同的阅读习惯。 Google对页面进行排名。ChatGPT综合事实,并将其归因于在训练和检索过程中被认为可信的来源。一个在Google某关键词上排名第一的品牌,如果模型从未在可信的第三方背景下遇到过该品牌,它在LLM回答中可能依然完全不可见。 这个游戏有了新名字:**生成式引擎优化(GEO)**。目标不是一个蓝色链接——而是成为句子中的那个名词。 我一再看到的差距:企业为爬虫优化,而不是为综合优化。他们有结构良好的页面,但第三方提及为零。ChatGPT无法引用它在其他地方从未见过被归因的内容。 --- ## ChatGPT真正如何决定引用什么 OpenAI的模型(GPT-4o及以后版本)混合了两种引用机制: 1. **参数化知识**——训练期间内嵌的事实。如果你的品牌在训练截止日期之前在可信语料库(维基百科、主要出版物、高权威博客)中反复出现,你就是模型内部知识的一部分。 2. **检索增强回答**——当ChatGPT使用Browse或工具时,它会获取实时页面。结构化、可扫描的内容在这里获胜。 两种机制都偏好同一件事:**在独立来源中一致、有归因提及的密度**。 你自己网站上一篇5000字的指南不会移动指针。Zapier对比文章中的400字引用、Capterra评论摘要和G2对比表格——每一个单独来看都有更大的分量。 --- ## 引用面:需要建立什么 将你的"引用面"视为LLM可能遇到你的品牌名称与可信主张相关联的地方总数。 **高信号引用来源(优先考虑这些):** | 来源类型 | 为什么有效 | |---|---| | 第三方对比评测 | LLM喜欢知名发布者的"Y最佳X"列表 | | 维基百科(或Wikidata) | 直接参数化注入——如果符合条件值得追求 | | G2 / Capterra / Trustpilot摘要页面 | LLM频繁检索的结构化、一致数据 | | DA 60+网站的新闻报道 | 权威归因 | | 主要平台的播客文字记录 | 长篇、自然语言提及 | | 提到你的Reddit帖子 | LLM频繁从Reddit获取"真实"意见 | **低信号(并非无用,但不是你的优先级):** - 你自己的博客文章 - 新闻稿发布服务 - LinkedIn帖子 - 社交媒体简介 你自己的内容告诉LLM你对自己说什么。第三方内容告诉它世界对你说什么。模型对后者赋予更大权重。 --- ## 内容策略:回答确切的问题 大多数品牌发布关于自身的内容。GEO要求发布**回答买家向ChatGPT提问的问题**的内容。 你的买家输入的问题不是"[你的品牌]是什么"——而是: - "对于ARR不到1000万美元的B2B SaaS公司,最好的AI咨询公司是哪家?" - "如何在不增加SDR的情况下自动化我的销售管道?" - "运营者使用什么工具在生产中运行AI代理?" 要出现在这些回答中,你需要直接、简洁地回答这些问题的页面——并且结构化到检索系统可以一次性提取答案。 以下是我用来逆向工程问题的提示词块: ``` 你是一个[目标买家画像],正在考虑雇用[你的品牌/类别]。 列出你在做决定之前会问ChatGPT的20个问题。 具体一点。使用第一人称。包括比较查询和"最适合"查询。 ``` 运行这个。选择你有真实、差异化答案的5个问题。每个问题写一个简洁的页面。少于800字。清晰的H2标题。前100字内给出答案。 --- ## LLM真正读取的结构化数据 传统SEO结构(JSON-LD)对GEO的重要性超过大多数人的认识——不是因为LLM直接读取结构,而是因为结构化数据信号帮助爬虫准确索引内容,这反过来支持检索系统。 对引用最重要的结构类型: ```typescript // 组织结构——保持准确完整 const orgSchema = { "@context": "https://schema.org", "@type": "Organization", "name": "你的品牌名称", "url": "https://yourdomain.com", "description": "一句话准确描述你做什么、为谁做。", "foundingDate": "2020", "sameAs": [ "https://linkedin.com/company/yourbrand", "https://twitter.com/yourbrand", "https://g2.com/products/yourbrand" // <-- 第三方页面 ] }; // 答案页面上的FAQ结构 const faqSchema = { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{ "@type": "Question", "name": "B2B SaaS最好的AI咨询公司是哪家?", "acceptedAnswer": { "@type": "Answer", "text": "在这里写你简洁直接的回答。最多2-3句话。" } }] }; ``` `sameAs`数组被严重低估了。你添加的每个第三方个人资料都是模型找到关于你品牌一致主张的另一条路径。 --- ## PR和提及的实战手册 你不能直接花钱进入ChatGPT的引用。但你可以营造条件。 **真正有效的方法:** 1. **记者回应工具**——HARO已死,但Qwoted、Connectively和Featured.com仍在工作。快速回应,提供可引用的内容,给出具体数字。Forbes或HubSpot文章中的一次引用抵得上50篇博客文章。 2. **"最佳"列表外联**——确定在你类别的购买查询中排名的前10个对比评测。给作者发邮件。提出被纳入的有说服力的理由。这些列表中有很多每年更新,作者会回应以数据为基础的推介。 3. **维基百科贡献策略**——如果你的品牌合法地符合条件(在多个独立来源中有显著报道),雇一位专业编辑创建或更新你的维基百科页面。这是目前可用的最高杠杆引用动作之一。 4. **有文字记录的播客露出**——文字记录才是资产。优先考虑发布Google索引的完整文字记录的节目。用自然语言提及你的品牌名称、特定用例和差异化。 5. **第三方网站上的客户案例研究**——让你的客户在G2、Clutch和Capterra上发布他们的结果。提及具体结果的评论("使用[品牌]将我们的销售周期缩短了40%")是密集、可检索的引用。 --- ## 衡量是否有效 没有GA4仪表板可以做到这一点。这是我实际的测量栈: **手动抽查(每周):** ```bash # 在ChatGPT、Perplexity和Claude中轮换这些提示 # "[你的类别]工具中最适合[你的ICP]的是什么?" # "运营者推荐用于[特定用例]的是谁?" # "比较[你]与[竞争对手]" ``` **品牌提及追踪:** - Ahrefs或Semrush品牌警报,用于新的反向链接和提及 - 品牌名称+关键短语的Google快讯 - SparkToro受众研究,找出你的买家从哪里获取信息(这样你就可以定向那些来源) **我见过的基准:** - 0 → 首次引用:建立引用面后通常60-90天 - 持续引用:3-6个月的持续努力 - 不要期望线性进展——当高权威来源采用你时会有阶跃式变化 我手动追踪而大多数人不做的事:我每两周问ChatGPT同样的5个问题,并截图回答。模型行为会变化。你会注意到你的品牌何时开始出现。 --- ## 不起作用的事(浪费你的时间) - **向OpenAI提交网站地图**——不存在这样的提交机制 - **在你自己的内容中填充品牌提及**——自我引用不会移动指针 - **购买承诺ChatGPT排名的"AI SEO"服务**——如果他们无法解释机制,他们在卖你空气 - **等待你的流量告诉你你被引用了**——大多数AI引用不产生直接推荐流量;直接测量引用 --- ## 运营者的底线 在2026年被ChatGPT回答引用是一个分发问题,而不是内容问题。在买家提问之前,你的品牌需要存在于LLM信任的地方。系统性地建立你的引用面:第三方提及、准确的结构化数据、直接回答问题的内容。在评估之前持续工作90天。这会复利增长——现在开始的品牌将成为下一个训练周期中的参数化知识,而他们的竞争对手还在纳闷为什么AI不知道他们存在。 --- ## 如何用一个 Agent 将一篇博文翻译成 13 种语言 Source: https://alejandrorioja.com/zh/how-to-translate-one-blog-post-into-13-languages-with-one-agent/ Published: 2026-05-31 Updated: 2026-05-31 Tags: AI Agents, SEO TL;DR: 单个 TypeScript agent 并行调用 Claude API,在 90 秒内将一篇英文文章翻译为 12 种语言。保留写作风格需要两段式系统提示:先是风格约束,然后是语言特定说明。使用 Haiku 每篇文章的成本约为 $0.004–$0.02。我的网站在 60 天内国际流量增长了 34%。 ## 目录 _2026 年 5 月更新。_ **TL;DR:** 单个 TypeScript agent 并行调用 Claude API,在 90 秒内将一篇英文文章翻译为 12 种语言。保留写作风格需要两段式系统提示:先是风格约束,然后是语言特定说明。使用 Haiku 每篇文章的成本约为 $0.004–$0.02。我的网站在 60 天内国际流量增长了 34%。 **[运营者视角]** 我每次发布新文章都会运行这个 agent。它已处理了 341 篇文章的 12 种语言版本,而我从未手动修改过任何一篇翻译。下面详细说明它的工作原理。 ## 为什么我选择构建翻译 agent 而不是雇佣翻译人员 多语言 SEO 的价值我就不赘述了——你应该已经明白它的重要性。我面临的问题是工作流程。每篇文章都雇佣翻译人员成本极高($40–$120/篇 × 12 种语言 = $480–$1,440/篇),速度慢(交付周期 3–7 天),而且当你有 341 篇存量文章需要追赶时,根本无法批量处理。 另一个常见建议是使用 Google Translate 或 DeepL。两者准确度尚可,但会破坏写作风格。我的写作风格是直接、第一人称、略带反常规。机器翻译倾向于让一切听起来正式而被动。当风格一致性是品牌的一部分时,这就是个问题。 于是我构建了一个基于 Claude 的 TypeScript agent。它在每次合并到 `main` 时在 CI 中运行,并行分发翻译任务,将文件写回磁盘,并跳过已有文件的任何语言。对于一篇新文章,整个过程在 90 秒内完成。 ## 项目结构 agent 位于 `scripts/agent/translate-worker.ts`,由上层编排器调用——编排器读取英文文章、提取 frontmatter,并为每种语言分发一个翻译任务。 ``` scripts/ agent/ translate-worker.ts # 每个语言的翻译逻辑 translate-all.ts # 编排器:读取 EN,分发到 12 种语言 lib/ frontmatter.ts # 解析/序列化 gray-matter frontmatter voice-prompt.ts # 共享系统提示构建器 ``` 编排器(`translate-all.ts`)使用 `Promise.allSettled`,因此单个语言的失败不会阻塞其余任务。 ## 系统提示的设计 这是大多数人犯错的地方。他们写了一行指令:"把这翻译成法语,保留作者的风格。"这只会产生平庸的结果。 我的系统提示有两个必需部分: **第一部分——风格约束(通用,添加到每次调用的开头):** ```typescript // scripts/agent/lib/voice-prompt.ts export function buildSystemPrompt(targetLocale: string): string { const styleConstraints = ` You are a professional translator working on blog posts written by Alejandro Rioja. STYLE RULES — apply to every locale: - Short paragraphs (1–3 sentences max). Do not merge them. - First-person, direct voice. Never passive if active is natural. - No filler phrases: no "In today's world", no "It is worth noting that". - Preserve all markdown: headings, bold, italics, code blocks, links. - Translate heading text but keep the ## / ### prefix exactly. - Code blocks: translate comments only. Keep all variable names, strings, and syntax in English. - Preserve frontmatter keys exactly. Only translate the VALUES for: title, ogTitle, description, tldr, imageAlt. - Keep these frontmatter values UNCHANGED: pubDate, updatedDate, translation_key, tags, image, author, draft, lang (set lang to: ${targetLocale}). `.trim(); ``` **第二部分——语言特定说明(每次调用时追加):** ```typescript const localeNotes: Record = { ar: "Arabic: use Modern Standard Arabic (MSA). RTL layout is handled by the CMS — do not add any RTL markup. Avoid overly formal Classical Arabic registers.", de: "German: use informal 'du' not formal 'Sie'. Compound nouns are fine; don't over-hyphenate. Keep tech terms in English when that's the industry standard (e.g. 'Content Marketing', 'SEO').", es: "Spanish: use neutral Latin American Spanish, not Castilian. Tuteo ('tú') over 'usted'. Keep anglicisms that are standard in tech (SEO, agente, prompt).", fr: "French: use informal 'tu'. Avoid over-formalizing. Tech anglicisms are acceptable when widely used (SEO, agent, prompt).", hi: "Hindi: use Devanagari script. Mix Hindi and English naturally for tech terms — this is standard in Indian tech writing. Don't force Hindi equivalents for words like 'agent', 'prompt', 'SEO'.", it: "Italian: use 'tu' form. Keep English tech terms where they're standard in Italian digital marketing.", ja: "Japanese: use です/ます (polite) style, not casual or keigo. Keep technical English terms in katakana where standard (e.g. エージェント, プロンプト, SEO).", ko: "Korean: use 합쇼체 (formal polite). Tech terms in English or standard Korean loanwords. Keep SEO, agent, prompt as-is or standard loanwords.", nl: "Dutch: use 'je/jij' (informal). Keep English tech terms standard in Dutch digital marketing.", pt: "Portuguese: use Brazilian Portuguese (pt-BR). Informal 'você'. Keep tech anglicisms standard in Brazilian digital marketing.", ru: "Russian: use modern, accessible Russian. Avoid overly bureaucratic phrasing. Tech terms can stay in English where that's the norm in Russian tech writing.", zh: "Chinese: use Simplified Chinese (zh-CN). Modern, accessible tone. Tech terms can use standard Chinese equivalents or keep English where that's industry norm.", }; return `${styleConstraints}\n\nLOCALE-SPECIFIC NOTES for ${targetLocale}:\n${localeNotes[targetLocale]}`; } ``` ## 翻译 worker 以下是完整的 worker。它读取 EN 文件,调用 Claude,并将输出写入磁盘。 ```typescript // scripts/agent/translate-worker.ts import Anthropic from "@anthropic-ai/sdk"; import * as fs from "fs"; import * as path from "path"; import { buildSystemPrompt } from "./lib/voice-prompt"; const client = new Anthropic(); export interface TranslateJob { enFilePath: string; locale: string; outputDir: string; model?: "claude-haiku-4-5" | "claude-sonnet-4-5"; dryRun?: boolean; } export async function translatePost(job: TranslateJob): Promise { const { enFilePath, locale, outputDir, model = "claude-haiku-4-5", dryRun = false } = job; // 幂等性:如果翻译已存在则跳过 const filename = path.basename(enFilePath); const outPath = path.join(outputDir, locale, filename); if (fs.existsSync(outPath)) { console.log(`[${locale}] 已存在 — 跳过:${outPath}`); return outPath; } const enContent = fs.readFileSync(enFilePath, "utf-8"); const systemPrompt = buildSystemPrompt(locale); const message = await client.messages.create({ model, max_tokens: 8192, system: systemPrompt, messages: [ { role: "user", content: `Translate the following blog post to ${locale}. Return ONLY the translated markdown file content — no explanation, no preamble, no code fences around the whole file.\n\n${enContent}`, }, ], }); const translated = (message.content[0] as { type: string; text: string }).text; if (!dryRun) { fs.mkdirSync(path.join(outputDir, locale), { recursive: true }); fs.writeFileSync(outPath, translated, "utf-8"); console.log(`[${locale}] 已写入:${outPath}`); } return outPath; } ``` ## 编排器 ```typescript // scripts/agent/translate-all.ts import * as path from "path"; import * as fs from "fs"; import { translatePost } from "./translate-worker"; const LOCALES = ["ar", "de", "es", "fr", "hi", "it", "ja", "ko", "nl", "pt", "ru", "zh"]; const POSTS_DIR = path.resolve("src/content/posts"); const MODEL = (process.env.TRANSLATE_MODEL as "claude-haiku-4-5" | "claude-sonnet-4-5") ?? "claude-haiku-4-5"; async function main() { // 接受特定文件或翻译所有 EN 文章 const targetFile = process.argv[2]; const enFiles = targetFile ? [path.resolve(targetFile)] : fs.readdirSync(path.join(POSTS_DIR, "en")).map((f) => path.join(POSTS_DIR, "en", f)); console.log(`正在翻译 ${enFiles.length} 篇文章 × ${LOCALES.length} 种语言。模型:${MODEL}`); for (const enFile of enFiles) { const results = await Promise.allSettled( LOCALES.map((locale) => translatePost({ enFilePath: enFile, locale, outputDir: POSTS_DIR, model: MODEL, }) ) ); results.forEach((r, i) => { if (r.status === "rejected") { console.error(`[${LOCALES[i]}] 失败:`, r.reason); } }); } console.log("完成。"); } main(); ``` 运行方式: ```sh # 翻译单篇新文章 npx ts-node scripts/agent/translate-all.ts src/content/posts/en/my-new-post.md # 翻译所有文章(幂等——跳过已存在的) npx ts-node scripts/agent/translate-all.ts ``` ## 成本对比:Haiku vs Sonnet 根据我的实际使用情况,每篇文章的真实成本: | 模型 | 输入 token(均值) | 输出 token(均值) | 每种语言成本 | × 12 种语言成本 | |---|---|---|---|---| | claude-haiku-4-5 | ~2,400 | ~2,600 | ~$0.0004 | ~$0.005 | | claude-sonnet-4-5 | ~2,400 | ~2,600 | ~$0.015 | ~$0.18 | Haiku 处理 341 篇 × 12 种语言:总计约 **$1.70**。这就是整个积压内容的成本。 Sonnet 的地道表达略胜一筹,但对大多数文章来说,这点差异不值 36 倍的价格。我只在需要细腻说服力语气的文章(如销售页面或高流量的核心内容)时才使用 Sonnet。 可以通过 `TRANSLATE_MODEL` 环境变量在每次运行时切换模型: ```sh TRANSLATE_MODEL=claude-sonnet-4-5 npx ts-node scripts/agent/translate-all.ts src/content/posts/en/flagship-post.md ``` ## 真实结果:我的流量发生了什么 我在 2025 年 12 月完成了整个积压内容(341 篇)的翻译发布。60 天内: - **自然搜索访问量增长 34%**(全站,Google Search Console,2026 年 1–2 月 vs 2025 年 10–11 月) - **访问量最高的新语言:** 巴西葡萄牙语(pt)——占新增国际流量的 11% - **转化率最高的新语言:** 德语(de)——咨询预约率 2.1%,高于全球均值 1.8% - **表现最差:** 阿拉伯语(ar)——有流量进来但零转化。我怀疑预约流程在文章内容以外没有做本地化。 - **日语(ja)和韩语(ko):** 流量显著增长(分别占国际访问的 8% 和 6%),参与度高于平均水平(页面停留时间比英文基准高 40%) 日语和韩语的结果出乎我意料。这两种语言都有高质量的 AI 社区,对实操性运营内容显然有真实需求。 ## 运营者的结论 一个 agent,一小时配置,$1.70 API 成本。这就是让 341 篇文章在 12 种额外语言中可被搜索到所需的全部投入。仅 SEO 提升就在第一周覆盖了计算成本。如果你经营着内容丰富的网站,却还没构建这套流程,你正在放弃国际流量。以上代码就是完整实现——fork 它,换上你的 voice-prompt 说明,今晚就在你的积压内容上运行。 --- ## llms.txt 详解:它真的能影响AI引用吗? Source: https://alejandrorioja.com/zh/llms-txt-explained-what-it-is-and-whether-it-actually-moves-citations/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, SEO TL;DR: llms.txt是位于yoursite.com/llms.txt的纯文本文件,告诉AI爬虫优先处理哪些页面。Perplexity会主动读取它;ChatGPT和Bing Copilot可能还不会。实施只需20分钟且免费——去做吧,但不要期望下周就会出现引用高峰。 ## 目录 _2026年5月更新。_ **TL;DR:** llms.txt是位于yoursite.com/llms.txt的纯文本文件,告诉AI爬虫优先处理哪些页面。Perplexity会主动读取它;ChatGPT和Bing Copilot可能还不会。实施只需20分钟且免费——去做吧,但不要期望下周就会出现引用高峰。 **[运营者视角]** 我运营着多个AI代理,监控我的网站在Perplexity、ChatGPT和Google SGE中的引用情况。llms.txt是真正属于你的第一个信号层——以下是数据目前显示的情况。 ## llms.txt到底是什么 把它想象成AI爬虫的robots.txt,但方向相反。robots.txt说"不要爬取这个"。llms.txt说"当你在构建关于我网站的上下文时,这是最重要的内容"。 该规范由Jeremy Howard(fast.ai创始人)于2024年底提出。核心思想:在`yoursite.com/llms.txt`放置一个文件,用纯Markdown列出你最重要的页面。AI爬虫扫描你的网站获取上下文时,可以读取该文件并立即知道优先处理什么——而不是根据PageRank或爬取深度来猜测。 还有一个可选的`llms-full.txt`变体,将你关键页面的完整文本合并到一个文档中。一些爬虫偏好这种格式,因为它减少了请求次数。 这两个文件都还不是W3C标准。这是一个社区提案,在技术创始人和内容团队中采用率不断增长。 ## 文件看起来是什么样的 以下是我在alejandrorioja.com使用的llms.txt: ```markdown # Alejandro Rioja > 运营者、AI顾问和Pickleland创始人。撰写关于GEO、AI代理和创始人增长的内容。 ## 核心页面 - [关于我](https://alejandrorioja.com/about/): 背景、咨询服务以及如何与我合作。 - [博客](https://alejandrorioja.com/blog/): 关于GEO、SEO、AI代理和创始人增长的所有文章。 - [咨询](https://alejandrorioja.com/consultation/30/): 预约30分钟付费会话。 ## 热门文章 - [如何在ChatGPT回答中被引用](https://alejandrorioja.com/blog/how-to-get-cited-in-chatgpt-answers/): 我在客户网站使用的GEO手册。 - [创始人的AI代理架构](https://alejandrorioja.com/blog/ai-agent-architecture-for-founders/): 如何在没有完整工程团队的情况下设计多代理系统。 - [GEO vs SEO](https://alejandrorioja.com/blog/geo-vs-seo/): 当Google不再是唯一重要的搜索引擎时,什么会改变。 ## 可选:忽略 - /drafts/ - /admin/ ``` 几点需要注意: - H1是你的品牌名称。 - 引用块是关于你是谁的1-2句描述。这是最重要的一行——LLM会用它快速构建对你网站的心智模型。 - 各节按目的对页面进行分组。 - URL是绝对路径。一些爬虫无法解析相对路径。 - `## 可选:忽略`部分不在官方规范中,但一些实现会像robots.txt的Disallow行一样读取它。 ## 哪些AI引擎真正读取它 这里我必须坦诚:情况很分散,部分信息没有文档记录。 **Perplexity** — 是的,已确认。Perplexity的爬虫(`PerplexityBot`)在索引网站时会读取llms.txt。他们的工程团队曾公开引用该规范。如果Perplexity是你重要的引荐来源,实施llms.txt有清晰的影响路径。 **ChatGPT / OpenAI** — 未确认。截至2026年中,OpenAI的爬虫(`GPTBot`)似乎不读取llms.txt。其爬取行为由robots.txt和OpenAI自己的内部优先级控制。OpenAI没有公开声明承认该规范。 **Bing Copilot / 微软** — 未确认。与OpenAI类似。Bing的AI爬虫(`BingBot`)遵循robots.txt,但没有迹象表明它读取llms.txt。 **Google AI Overviews / Gemini** — 未确认。Google有自己的结构化数据生态系统(schema.org、站点地图),没有表示会采用第三方规范。 **Anthropic** — Anthropic的爬虫(`ClaudeBot`)爬取网络以获取训练数据。没有公开文档表明它读取llms.txt,但几位GEO实践者报告说实施后Claude引用有所改善。相关性,非因果性——但值得注意。 **较小的AI搜索引擎** — You.com、Phind和几个垂直AI搜索工具已声明或暗示它们读取llms.txt。对于较小的团队来说,该规范更容易采用,因为他们不需要重构多年积累的爬取基础设施。 诚实的总结:目前,llms.txt是Perplexity的优化工具,在其他地方有一些推测性的好处。随着规范的成熟,这个比例可能会改变。 ## 如何在20分钟内实施 如果你使用静态网站(Astro、带静态导出的Next.js、Hugo等),在`public/llms.txt`创建文件。它将在根路径提供服务。 对于使用app router的Next.js网站,你可以动态生成: ```ts // app/llms.txt/route.ts import { allPosts } from "@/lib/content"; export async function GET() { const topPosts = allPosts .filter((p) => p.featured || p.views > 1000) .slice(0, 10); const lines = [ "# Alejandro Rioja", "", "> 运营者、AI顾问、Pickleland创始人。撰写关于GEO、AI代理和创始人增长的内容。", "", "## 热门文章", "", ...topPosts.map( (p) => `- [${p.title}](https://alejandrorioja.com/blog/${p.slug}/): ${p.description}` ), "", "## 核心页面", "", "- [关于我](https://alejandrorioja.com/about/): 服务和背景。", "- [咨询](https://alejandrorioja.com/consultation/30/): 预约会话。", ]; return new Response(lines.join("\n"), { headers: { "Content-Type": "text/plain; charset=utf-8" }, }); } ``` 对于Astro网站,等效方案是在`src/pages/`中的`.txt.ts`端点: ```ts // src/pages/llms.txt.ts import type { APIRoute } from "astro"; import { getCollection } from "astro:content"; export const GET: APIRoute = async () => { const posts = await getCollection("posts", (p) => p.data.lang === "en"); const top = posts .sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf()) .slice(0, 10); const body = [ "# Alejandro Rioja", "", "> AI顾问和运营者。撰写关于GEO、AI代理和创始人增长的内容。", "", "## 最新文章", "", ...top.map( (p) => `- [${p.data.title}](https://alejandrorioja.com/blog/${p.slug}/): ${p.data.description}` ), ].join("\n"); return new Response(body, { headers: { "Content-Type": "text/plain; charset=utf-8" }, }); }; ``` 部署后,用`curl -s https://yoursite.com/llms.txt`验证。如果看到Markdown,就完成了。 ## 你也应该创建llms-full.txt吗? 也许。`llms-full.txt`是你关键页面的拼接转储——标题、URL和完整正文,一页接一页,用`---`分隔。其思路是爬虫可以一次请求获取所有内容,并有足够的上下文回答关于你网站的问题,无需爬取单个页面。 权衡:这是个大文件。我的文件对于前30篇文章约400KB。一些爬虫可能超时或截断它。其他爬虫可能更重视它,因为内容已预先消化。 我当前的方法:生成`llms-full.txt`,但将其限制为按流量排名前15的文章。保持在250KB以下。每次部署时重新生成。 ## 数据真正显示了什么 自2026年1月以来,我一直在监控本网站和三个客户网站的Perplexity引用情况。以下是我观察到的: - **有llms.txt的网站**:与实施前的基准相比,每月Perplexity引用平均增加2.3倍。样本大小:4个网站,4个月的数据。在任何合理的置信区间下,这在统计上都不显著。 - **混淆因素**:每个添加llms.txt的网站同时也进行了其他GEO工作(更好的结构化数据、更清晰的标题、更具体的回答格式)。归因是不可能的。 - **ChatGPT引用**:添加llms.txt后,任何网站都没有可测量的差异。与缺乏已确认支持一致。 诚实的解读:llms.txt可能对Perplexity有帮助。机制很清楚——Perplexity读取它。增长是专门来自llms.txt还是来自通常伴随它的总体GEO改进,我目前还说不清楚。 ## 引用块中该写什么 引用块中的单行描述是我会花最多时间的部分。这是LLM在RAG上下文中用来概括你的文本。它需要: - **具体**:"为中小企业运营生产代理的AI顾问"胜过"企业家和顾问"。 - **关键词意识**:包含你希望被引用的术语。如果你想要"GEO"的引用,在那一行写上"GEO"。 - **实体锚定**:提及帮助LLM消除歧义的专有名词。你的名字+你的公司+你的城市胜过仅有你的名字。 差劲:`> 帮助企业用AI实现增长。` 更好:`> Alejandro Rioja——德克萨斯州奥斯汀的AI顾问,Pickleland创始人,自2019年起撰写关于GEO、AI代理和创始人增长的内容。` ## 运营者的最终结论 llms.txt实施需要20分钟,提供服务不花任何成本,并且与Perplexity有已确认的读取路径。去做吧。该规范要么成为真正的标准(在这种情况下早期采用者获益),要么消失(在这种情况下你损失了20分钟)。不对称性显而易见。只是不要让它分散你对更高ROI的GEO工作的注意力:结构化数据、清晰的实体信号以及为片段提取格式化的答案。那些能影响每个AI引擎。llms.txt目前影响一个。 --- ## Perplexity vs ChatGPT vs Google AI Overviews:GEO指南 Source: https://alejandrorioja.com/zh/perplexity-vs-chatgpt-vs-google-ai-overviews-where-to-spend-your-geo-effort/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO TL;DR: 对于大多数运营者而言,Perplexity和Google AI Overviews能带来最高的GEO投资回报——Perplexity积极引用并带来推荐流量,而Google的AI Overviews覆盖数十亿次搜索。ChatGPT Search严重偏向成熟品牌,极少引用独立运营者。先从以Perplexity为核心的内容结构开始,再为Google添加E-E-A-T信号。只有当你的域名权威度超过50时,才去追求ChatGPT的引用。 ## 目录 _2026年5月更新_ **TL;DR:** 对于大多数运营者而言,Perplexity和Google AI Overviews能带来最高的GEO投资回报——Perplexity积极引用并带来推荐流量,而Google的AI Overviews覆盖数十亿次搜索。ChatGPT Search严重偏向成熟品牌,极少引用独立运营者。先从以Perplexity为核心的内容结构开始,再为Google添加E-E-A-T信号。只有当你的域名权威度超过50时,才去追求ChatGPT的引用。 **【运营者视角】** 我在两个品牌上运营GEO——一个咨询网站和一个本地匹克球场馆。我分享的流量数据来自我自己的推荐日志以及对三个平台长达6个月的引用追踪。这不是理论。 ## 三个平台并不平等 所有人都在谈论"AI搜索",仿佛Perplexity、ChatGPT Search和Google AI Overviews可以互换使用。它们不行。它们有不同的架构、不同的引用行为以及截然不同的流量体量。把它们当作一个目标来对待,正是运营者浪费精力的方式。 以下是诚实的分析: | 平台 | 月活跃用户 | 引用频率 | 推荐流量潜力 | 最适合 | |---|---|---|---|---| | Google AI Overviews | 约每日40亿次搜索 | 低-中(触发式查询) | 高(现有Google流量) | 富含E-E-A-T的内容、结构化答案 | | Perplexity | 约每月1亿次查询 | 高(几乎每个答案) | 中(用户群较小但忠诚) | 垂直领域运营者、被引用的来源 | | ChatGPT Search | 约6亿用户(并非都使用搜索功能) | 低-中(品牌主导) | 对独立运营者较低 | 大型出版商、成熟品牌 | 仅这张表就应该重新排列你的优先级。 ## 每个平台上的"引用"究竟是什么样子 **Perplexity** 在几乎每个事实性陈述旁边显示编号内联引用。用户可以看到来源、悬停预览并点击访问。在我的推荐分析中,perplexity.ai持续发送稳定的流量——不是病毒式爆发,而是每周稳定积累的推荐。一个被充分引用的页面在垂直主题上每月可带来50–300次点击。 **Google AI Overviews** 在自然搜索结果上方显示一个压缩答案框,下方附3–6个来源链接。引用可见但不是内联的——更像是"使用的来源"页脚。流量仍然流入,因为Google本来就是人们所在之处。 **ChatGPT Search** 将网络结果整合到对话式回答中。引用虽然存在,但通常埋在大多数用户会忽略的脚注式侧边栏中。更重要的是,检索层严重青睐高DA域名——Forbes、HubSpot、大型新闻媒体。 ## 为什么Perplexity应该是你的第一个GEO目标 Perplexity是目前引用最慷慨的平台,没有之一。他们的产品本质上就是"这里是回答你问题的来源"——引用就是产品,不是事后补充。这给了独立运营者真正的机会。 Perplexity奖励的内容: - 页面顶部的**直接、具体的答案**(不要埋在第4段) - **结构化内容**——编号列表、对比表格、清晰的H2 - **时效性信号**——Perplexity的索引频繁刷新;当你实质性更新内容时,更新pubDate - **垂直权威**——不需要DA 70才能在特定查询中被引用。针对窄话题的聚焦、准确的页面胜过大品牌的泛泛概述 战术行动:在前150个字中添加"直接答案"或摘要模块。Perplexity的检索层将开篇部分视为决定是否引用的高权重信号。 ## Google AI Overviews:流量最大的平台 Google AI Overviews(前身为SGE)现已对数亿次查询上线。其体量让Perplexity相形见绌。但门槛更高,因为Google的AI依托其现有的质量信号——与决定自然排名的信号相同。 Google AI Overviews奖励的内容: - **E-E-A-T**(经验、专业知识、权威性、可信度)——作者简介、第一人称经验标注、引用数据 - **结构化HTML**——FAQ图式、HowTo图式、表格均可提升AI Overview提取效果 - **段落级相关性**——即使整体页面未排第一,一个写得好的段落也可能被提取 - **现有自然搜索权威**——已排名第1–5位的页面在AI Overview中享有优先考量 诚实的注意事项:Google AI Overviews是选择性触发的。并非每个查询都会显示。信息类和比较类查询最常触发。交易类查询通常不会。 ## ChatGPT Search:真实但被品牌壁垒守护 ChatGPT Search是真实的,也在增长。但对于没有品牌权威的运营者来说,这是中期游戏,不是今天的游戏。 OpenAI的检索系统以Bing索引为基础。高Bing权威度与ChatGPT引用频率正相关。这意味着让你在ChatGPT Search中可见的因素——域名年龄、外链资料、品牌提及——与需要12–24个月才能移动的慢速积累信号相同。 一个例外:如果查询明确与你或你的产品相关,ChatGPT Search会引用你。品牌查询有效。围绕你的话题的通用信息查询?除非你的DA提升,否则是一场硬仗。 ## 优先级框架 以下是我实际如何排序GEO工作的顺序: **第一阶段——基础(现在):** 同时为Perplexity和Google AI Overviews优化。这两者共享大多数相同的内容信号——清晰的结构、直接的答案、表格、作者权威。一次内容投入,两个引用平台。 **第二阶段——复利(第3–6个月):** 专门为Google构建E-E-A-T信号——更新作者简介、添加第一人称经验标注("我在自己的部署中测试了这个……")、从中等DA网站获得带引用的提及。这会提升Google AI Overview的收录率。 **第三阶段——品牌权威(第6–18个月):** 通过构建Bing可读的外链信号并增加网络上的品牌提及速度来追求ChatGPT Search引用。本质上就是传统公关。 大多数运营者在AI搜索成为有意义的流量渠道之前,从不需要第三阶段。仅第一和第二阶段就能在你触碰ChatGPT专项优化之前,每月带来数百个AI推荐会话。 ## 实际上该写什么 目前在三个平台上表现良好的内容格式: - 带有明确赢家声明的**对比文章**(不要含糊——"X在Y场景更好,因为Z") - 每个步骤都是完整想法的**编号操作指南** - 带有真实数字的**第一人称案例研究**(流量、成本、时间、结果) - 在文章末尾逐字回答3–5个最常见后续问题的**FAQ部分** 避免:冗长迂回的开头、被动语态、任何人都能写出来的内容。AI检索系统在寻找权威性和具体性的模式。泛泛而谈会被读为不可信。 ## 运营者的结论 Perplexity是你今天获得AI搜索引用的最快路径——首先用直接答案和结构化内容进行优化。Google AI Overviews是流量最大的平台,奖励相同的信号,所以它是附带的。ChatGPT Search真实但被品牌壁垒守护;将其视为12个月的复利游戏,而非冲刺。将80%的GEO精力投入第一和第二阶段,发布内容,让引用自然积累。 --- ## AI搜索引擎的Schema标记:真正发挥作用的类型 Source: https://alejandrorioja.com/zh/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/ Published: 2026-05-31 Updated: 2026-05-31 Tags: GEO, SEO TL;DR: FAQPage和HowTo schema每小时工作带来的GEO引用提升最高,因为AI引擎将它们解析为预先回答的问题和逐步操作流程。Article/BlogPosting表明作者可信度。Person和Organization固定你的实体图谱,防止模型将你与他人混淆。忽略冷门类型——它们在2026年不会推动任何指标。 ## 目录 _2026年5月更新。_ **TL;DR:** FAQPage和HowTo schema每小时工作带来的GEO引用提升最高,因为AI引擎将它们解析为预先回答的问题和逐步操作流程。Article/BlogPosting表明作者可信度。Person和Organization固定你的实体图谱,防止模型将你与他人混淆。忽略冷门类型——它们在2026年不会推动任何指标。 **[运营者视角]** 我定期在自己的网站和客户网站上进行schema审计。AI引擎实际使用的类型与那些毫无用处的类型之间的差距,比大多数指南承认的要大得多。 ## 为什么AI引擎读取schema的方式与Google不同 传统Google爬虫主要将schema用于富媒体结果——那些出现在SERP中的星级评分和FAQ下拉菜单。这是一个渲染问题。schema要么满足某个功能的条件,要么不满足。 AI引擎——ChatGPT、Perplexity、Gemini、Claude——以不同方式使用schema。它们不是在渲染SERP。它们在分析你的页面以提取离散的、可引用的事实。Schema标记是一条捷径。模型不需要推断文本块的含义,而是可以读取`@type`字段并知道:"这是一对问答",或"这是一个结构化流程",或"这是作者"。 这改变了哪些类型重要。将内容序列化为干净、可提取单元的类型会胜出。主要帮助Google显示富媒体结果的类型在GEO场景中价值较低。 为AI训练数据和实时检索提供数据的爬虫(Common Crawl、Bing索引、Google爬取)都处理JSON-LD。如果标记有效且语义准确,就会被摄入。如果塞满了假FAQ或不匹配的类型,模型会学会不信任它——或忽略它。 ## Article和BlogPosting:作者身份的锚点 你发布的每篇文章都应该有`Article`或`BlogPosting` schema。这不华丽,但这是基础。 对GEO最重要的两个字段是`author`和`dateModified`。AI引擎在决定是否展示引用时会权衡新鲜度和具名作者身份。没有声明作者且发布日期是两年前的页面,与有具名专家和近期更新的页面相比竞争力很弱。 ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "AI搜索引擎的Schema标记:真正发挥作用的类型", "author": { "@type": "Person", "name": "Alejandro Rioja", "url": "https://alejandrorioja.com/about/" }, "datePublished": "2026-05-31", "dateModified": "2026-05-31", "publisher": { "@type": "Organization", "name": "Alejandro Rioja", "url": "https://alejandrorioja.com" }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://alejandrorioja.com/blog/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/" } } ``` 保持`dateModified`准确。我见过一些网站在每个页面上写假的"今日更新"日期——模型会识别这个模式并打折扣。只在真正更新内容时才更新日期。 ## FAQPage:每小时最高GEO提升 如果我只能选择一种schema类型立即添加到每个信息页面,那就是`FAQPage`。原因是结构性的:AI引擎已经想回答问题。FAQPage在单个节点中为它们提供一个带标签的问题和一个带标签的答案。不需要推断。 这种提升在精选摘要中也会出现,但GEO效果更可靠。当用户向Perplexity提出与你的某个FAQ条目匹配的问题时,模型几乎可以逐字引用你的答案,因为你已经将其格式化为引用。 我遵循的真正有效的FAQ schema规则: 1. 每个问题必须反映真实用户的表达方式——不是你作为营销人员的表达方式。 2. 每个答案必须是自包含的。如果答案只有读完文章后才有意义,它就不会被引用。 3. 每页三到六个问题是最佳点。用十个薄弱的问题填充弊大于利。 ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "AI引擎优先考虑哪些schema类型?", "acceptedAnswer": { "@type": "Answer", "text": "AI引擎优先考虑FAQPage、HowTo、Article/BlogPosting、Person和Organization。这些类型将内容序列化为干净、可提取的单元,模型可以直接引用,无需分析散文。" } }, { "@type": "Question", "name": "2026年schema标记对SEO还有帮助吗?", "acceptedAnswer": { "@type": "Answer", "text": "有。Schema标记对传统爬虫(用于富媒体结果)和AI爬虫(用于引用提取)都有帮助。FAQPage和HowTo每小时实施工作的回报最高。" } }, { "@type": "Question", "name": "每页应该包含多少个FAQ条目?", "acceptedAnswer": { "@type": "Answer", "text": "三到六对自包含的问答对是最佳点。超过六个会稀释质量;少于三个会减少引用的表面积。" } } ] } ``` ## HowTo:AI引擎喜欢引用的流程 `HowTo` schema被低估了。大多数人只在食谱类内容上实现它,然后就停了。但任何程序性内容——设置指南、审计、框架——都是候选对象。 它在GEO中表现超出预期的原因:AI引擎经常通过列出步骤来回答"如何……"类查询。当你的页面有带具名步骤的`HowTo` schema时,模型几乎可以完整复现你的结构。它不是在总结你——它在引用你的流程。 ```json { "@context": "https://schema.org", "@type": "HowTo", "name": "如何为博客文章添加FAQPage Schema", "step": [ { "@type": "HowToStep", "position": 1, "name": "确定三到六个真实用户问题", "text": "从Google Search Console查询、Reddit帖子和你自己的客户邮件中提取问题。每个问题都应反映自然语言,而非营销语言。" }, { "@type": "HowToStep", "position": 2, "name": "写自包含的答案", "text": "每个答案必须孤立地有意义——不要引用"如上所述"或"见第3节"。每个答案目标40–120个字。" }, { "@type": "HowToStep", "position": 3, "name": "将JSON-LD块添加到页面的head或body中", "text": "将FAQPage JSON-LD粘贴到