从搜索缺口到自动发布的内容流水线

最初发布于 AIdeazz——此处为带 canonical link 的同步转载。

我第一次尝试搭建 AI 内容流水线时，连续三周都没能生成一篇有用的文章。问题不在 LLM、不在 orchestrator，也不在发布 API，而在于如何定义“内容缺口”。Google Search Console（GSC）显示，aideazz.xyz 有 15 个搜索查询获得了展示，却没有带来任何点击。我最初的想法是：这些就是内容缺口。于是，我构建了一个 Agent，让它选出展示量最高但零点击的查询，发送给 Claude 3.5 Sonnet，然后发布生成结果。这些文章在技术上没有问题，却无人点击。为什么？因为“缺口”不仅仅意味着缺少某个页面，也可能意味着没有匹配用户的搜索意图。

GSC 零点击陷阱：为什么“缺口”不只是缺少内容

aideazz.xyz 的 GSC 数据中出现了诸如“aideazz pricing”“aideazz contact”“aideazz reviews”之类的查询。这些属于导航型或交易型查询。搜索“aideazz pricing”的用户，并不想看到一篇名为《Aideazz Pricing Explained》的博客文章。他们想找的是定价页面，而不是文章。零点击率体现的并非内容缺口，而是形式缺口或转化缺口。我的 Agent 正在用毫不相关的博客文章，填补一个根本不存在的内容空白。

对于技术受众而言，真正的内容缺口存在于信息型查询中：你的网站本可以获得排名，却没有排名；或者虽然已有相关内容，但质量较弱。要找到这种缺口，需要比简单筛选零点击查询更加细致地分析 GSC 数据。

重新定义“缺口”：从零点击到意图错配

我调整了 GSC 分析 Agent 的方向。它不再专注于零点击查询，而是寻找以下几类机会：

• 低 CTR 的信息型查询：展示量大于 500、平均排名小于 20，且 CTR 低于 1% 的查询。这些数据意味着潜在的排名机会：现有内容可能缺乏吸引力，或者一篇针对性更强的新文章可能取得更好的表现。

• 展示量高但没有相关页面的查询：这一点更难自动化。它需要对现有内容进行语义搜索，以确认没有任何页面直接回应了该查询。目前，我的 Agent 使用一个保存现有文章 embedding 的向量数据库。如果某个查询的 embedding 与所有现有文章的相似度都低于阈值，例如余弦相似度小于 0.7，就会被标记为潜在缺口。

• 竞争对手关键词重叠（手动步骤）：这一步目前仍需人工完成。我使用 Ahrefs 查找竞争对手已有排名、但 aideazz.xyz 尚未覆盖的关键词，再用这些信息调整 GSC Agent 的筛选条件。

现在，这个 Agent 会通过 API 拉取 GSC 数据，按照上述标准进行筛选，并依据一个加权分数确定优先级：(impressions * (1 - CTR)) + (position_score * 0.5)。其中，position_score 的计算方式是 (20 - average_position) / 20，让距离搜索结果第一页越近的查询获得越高优先级。

多 Agent 内容生成流水线：从 Oracle Cloud 到 Dev.to

GSC 分析 Agent 确定主题后，会把它传给内容生成流水线。这是一个运行在 Oracle Cloud Infrastructure（OCI）上的多 Agent 系统，使用 OCI Functions 和 Container Instances。

Agent 1：研究与大纲 Agent

这个 Agent 会接收已排好优先级的查询。它的首要任务是生成一份详细大纲，过程中会结合多种技术：

• SERP 分析：它会针对目标查询实时执行 Google 搜索，抓取排名前 10 的结果，并提取标题、共同主题和实体。这一步对于理解当前已有排名内容以及识别子主题至关重要。

• 受众画像：系统预先配置了“持怀疑态度的技术创始人／开发者”画像，它会影响大纲的语气和内容深度。

• 约束注入：系统会明确要求它加入与 AIdeazz 有关的特定约束，例如“提及 Oracle Cloud”“讨论零 VC 融资”“强调交付生产环境 Agent”。

大纲中还包含给写作 Agent 的具体指令，例如：“以失败或约束开篇”“使用数字”“避免陈词滥调”。随后，大纲会由人工，也就是我本人，审核 5～10 分钟。这是内容创作过程中唯一需要人工参与的环节。

Agent 2：写作 Agent（Claude 3.5 Sonnet）

审核通过的大纲会交给写作 Agent。我试过多种 LLM，包括 GPT-4o、Llama 3 和 Mixtral，但在技术内容创作方面，Claude 3.5 Sonnet 始终能生成质量最好的初稿，尤其是在收到严格的格式和语气指令时。对于这一使用场景，它既能遵循复杂约束，又不容易产生 hallucination 或变得过度冗长，表现明显更好。

提供给 Claude 的 prompt 包括：

• 语气要求：“保持怀疑、直接、技术化，不说废话。”

• 硬性规则：“以失败／约束／数字开篇”“不要使用陈词滥调”“使用具体数字／报错信息／成本”“采用第一人称或中性的技术表达”“只输出 Markdown，使用 ## 章节，不要 H1”。

• 目标篇幅：1400～2400 词。

• 关于 FAQ 章节和署名的具体要求。

写作 Agent 运行在专用的 OCI Container Instance 上，并调用 Anthropic API。生成一篇 2000 词文章，平均需要 90～120 秒。

Agent 3：发布 Agent（Dev.to 与 Aideazz.xyz 缓存）

初稿生成后，会被传给发布 Agent。这个 Agent 有两项主要职责：

• Dev.to API 集成：它通过 Dev.to API 创建新文章，从初稿中提取文章正文（Markdown）、标题和相关标签。它最初还会设置 published: false，以便文章正式上线前，可以在 Dev.to 平台上进行最终审核。

• Aideazz.xyz 缓存：Markdown 内容的副本会被存入 OCI Object Storage bucket，作为 aideazz.xyz 的缓存。这样，即使 Dev.to 尚未发布，内容也能立即出现在我自己的域名上。另一个 OCI Function 会触发 aideazz.xyz 的静态站点重新生成，以拉取这份新内容。

从识别 GSC 查询，到文章可在 aideazz.xyz 上访问并进入 Dev.to 待发布状态，整个过程大约需要 11 分钟，其中包括 5～10 分钟的人工大纲审核。

效果指标：实施前与实施后

在采用这套经过改进的 AI 内容流水线、GSC 缺口分析和自动发布系统之前，我发布博客文章的节奏并不稳定，而且内容经常偏离目标。我每个月只发布 1～2 篇文章，来自自然搜索的平均 CTR 为 0.8%。

实施这套系统之后：

• 发布频率：每周 3～4 篇文章。

• 平均自然搜索 CTR：新文章整体提升至 2.1%。

• 发布时间：从手动操作的 4～8 小时，缩短至 11 分钟，即自动化流程加人工大纲审核。

• 新文章的 GSC 展示量：发布后前 30 天平均获得 1,200 次展示，高于此前的 350 次。

关键改进不只是速度或产量，而是相关性。通过更复杂的 GSC 分析来识别真正的搜索意图缺口，现在的内容能够直接回应目标受众正在搜索的问题，从而带来更高的互动率。

基础设施：为什么选择 Oracle Cloud，以及 Groq／Claude 路由

我选择在 Oracle Cloud Infrastructure（OCI）上运行 AIdeazz，原因有很多，其中最主要的是，它在 GPU 密集型工作负载方面兼具成本效益和性能优势。我的多 Agent 系统使用了：

• OCI Functions：用于 Agent 编排、调用 GSC API 和执行发布逻辑的 Serverless 计算服务。以目前的使用量计算，成本几乎为零。

• OCI Container Instances：用于运行写作 Agent（调用 Claude API）和执行 SERP 抓取。它能提供隔离环境，并高效扩展。

• OCI Object Storage：用于缓存文章和存储 GSC 数据。

• OCI Generative AI Service：虽然写作环节直接使用 Anthropic 的 Claude，但其他内部任务会使用 OCI 的 Gen AI service，例如摘要生成，以及从非结构化文档中提取数据，从而形成统一平台。

我会动态路由 LLM 调用。在写作任务中，由于质量更好，默认使用 Claude 3.5 Sonnet。对于速度要求更高、重要性相对较低的任务，例如快速改写或简单的数据提取，我会通过 Groq API 使用其 Llama 3 8B 或 70B 模型。这个路由决策由 OCI Function 根据传给 LLM orchestration layer 的 task_type 参数作出。

对于较小的模型，Groq 能提供低得多的延迟，通常只有几十毫秒。这对于交互式 Agent 或高吞吐、低复杂度任务至关重要。生成一篇 2000 词文章时，Claude 需要 90～120 秒，这个时间可以接受；但对于实时聊天 Agent 而言，Groq 不可或缺。

常见问题

问：如何避免 AI 生成的内容听起来千篇一律或不断重复？

答：关键在于详细的大纲和严格的 prompt engineering。大纲 Agent 会执行实时 SERP 分析，以确保内容具有新意；写作 Agent 的 prompt 则会明确禁止陈词滥调，并要求提供具体案例和数字，迫使它生成独特的内容。

问：运行这套流水线需要多少成本？

答：不包括 LLM API 成本——这部分会随使用量变化，内容生成平均每月需要 50～100 美元——用于 Agent、Functions 和存储的 OCI 基础设施，每月成本不到 10 美元。这得益于 OCI 慷慨的免费额度和高效的 Serverless 计费方式。

问：如何处理事实准确性和潜在的 hallucination？

答：研究 Agent 的 SERP 分析提供了事实基础。对于高度敏感的主题，还会加入人工审核初稿的环节，而不仅仅审核大纲。对于这个博客而言，审核大纲已经足够，因为相关主题都在我的专业领域之内。

问：为什么不使用一个更大的 LLM 处理所有事情？

答：因为成本和性能。使用一个更小、更专业的 Agent 来分析 GSC，比使用大型 LLM 更便宜、速度也更快。针对特定任务路由到 Groq，可以在需要时优化延迟，而 Claude 则负责写作这类重型任务。这种多 Agent、多 LLM 的方案效率更高。

— Elena Revicheva · AIdeazz · 作品集

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。