我如何使用本地 LLM 为 10,000+ 页面生成 SEO 内容
Source: Dev.to
关于使用 AI 进行内容创作的热度很高。大多数讨论都集中在更快地撰写博客文章上。虽然这没问题，但它忽略了更大的机会：将 AI 作为 程序化内容管道 的一个组成部分，生成成千上万的独特页面。
我运营一个股票对比站点，拥有 287 000 个页面，覆盖 12 种语言。每个页面都有 AI 生成的叙述性章节——不是普通的填充文字，而是针对每对股票的具体分析。AI 并不负责整页的写作；它只负责需要呈现人类感受的部分，而结构化数据则处理其余所有内容。
下面是系统的工作方式以及我在制作 Google 真正接受的 AI 内容时学到的经验。
为什么要使用本地 LLM（以及为何选择 Llama 3）
每个人都会问的第一个问题： 为什么不直接使用 OpenAI API？
| 因素 | 本地 Llama 3 实例的优势 |
|---|---|
| 成本 | 287 k 页 × 500‑800 token ≈ 按 GPT‑3.5 计费约 $200‑$400，仅首次生成就已如此。模板更新、多语言变体以及迭代改进的重新生成费用会迅速累积。 |
| 速度 | API 速率限制会把这变成数天的排队请求。使用配备合适 GPU 的本地 Llama 3 可以每小时生成数千页，完全不受速率限制或宕机影响。 |
| 可控性 | 可以微调提示词、调整生成参数，并在不担心成本的情况下重新运行整个批次。我经历了约 15 次提示模板的迭代，才得到始终通过质量检查的输出。 |
| 隐私 | 将财务数据传输至第三方 API 并不理想。本地运行可让所有数据保持在本地。 |
话虽如此，云 API 仍有其用武之地——例如一次性内容、复杂推理任务，或在少量页面上需要最高质量时，GPT‑4 或 Claude 更为合适。但若是大规模批量生成，使用本地方案才是最佳选择。
模板 + AI 混合
关键概念： AI 并不编写整个页面；它在结构化模板中编写特定章节。
页面结构（简化）
[Header — ticker names, logos, prices] ← Structured data
[Key Metrics Table — P/E, market cap, etc.] ← Structured data
[AI Comparison Summary — 2‑3 paragraphs] ← AI generated
[Dividend Analysis] ← Mix of data + AI narrative
[Growth Metrics Chart] ← Structured data
[AI Investment Considerations] ← AI generated
[FAQ Section] ← AI generated from data
[Schema Markup] ← Auto‑generated注意： 每个页面约有 60‑70 % 的内容是由模板渲染的结构化数据。AI 填补其余 30‑40 % 需要自然语言的部分——摘要、分析和常见问题。
混合方法的优势
- 独特性： 每个页面都有不同的数据 以及 不同的叙述，因此 Google 不会将其标记为重复内容。
- 准确性： AI 根据提示中传入的实际财务数据生成文本，而不是基于其训练数据。这使内容以事实为依据，降低幻觉的可能性。
提示架构
我不能分享我的确切生产提示（它们在完整蓝图中），但以下是总体思路。
1. 上下文注入
每个提示都以该特定股票对的实际数据开头。AI 并不是从零开始生成——它是在分析并叙述已经提供给它的数据。
You are analyzing {STOCK_A} vs {STOCK_B}.
Here is the current financial data:
- {STOCK_A} P/E: {pe_a}, Market Cap: {mcap_a}, Dividend Yield: {div_a}
- {STOCK_B} P/E: {pe_b}, Market Cap: {mcap_b}, Dividend Yield: {div_b}
Write a 2‑paragraph comparison focusing on...2. 变体指令
为防止所有页面听起来都一样，我会加入随机化的风格指令：变化句子长度、交替以股票 A 或股票 B 开头，并使用不同的比较框架（价值 vs 成长、收益 vs 增值 等）。
3. 输出约束
- 字数限制
- 格式要求（例如 markdown 标题、项目符号列表）
- 明确的“禁止包含”规则（正文中不出现金融建议免责声明、不出现 “作为 AI” 的自我引用、不要使用通用填充短语）
4. 质量门槛
生成后，每段内容都会通过自动检查：
- 与其他生成页面的最低唯一性得分
- 可读性得分（例如 Flesch‑Kincaid）
- 与源数据的事实一致性
- 关键词密度检查
Google的有用内容更新对本页的意义
Google 官方立场: AI 生成的内容并非自动算坏。低质量内容就是坏的，无论它是如何生成的。
我在 287 k 页面中的观察
| 已索引页面的特点 | 未索引页面的特点 |
|---|---|
| 独特的数据点 | 通用叙述，适用于任何股票组合 |
| 与这些数据相关的具体分析 | 仅重复数字的薄弱分析 |
| 正确的 schema 标记 | 页面之间模式过于相似 |
| 回答人类可能输入的真实搜索查询 | 未明确对应任何搜索意图 |
教训: AI 内容必须真正说出具体内容。
- 薄弱: “股票 A 的市盈率高于股票 B。”
- 有用: “股票 A 的市盈率为 35，表明市场预期其将实现显著增长，这与其上季度收入增长 40 % 相符；而股票 B 的市盈率为 12，则反映出其业务更为成熟，增长稳定但较慢。”
当叙述提供上下文、解释和可操作的洞见时，Google 会将其视为有用内容。
多语言生成
程序化 SEO 最大的优势之一是以低成本实现多语言化。以下是我的做法：
| 组件 | 方法 |
|---|---|
| 模板字符串（标题、标签、按钮文字） | 由人工翻译一次并存储在语言文件中（每种语言约 200‑300 条字符串）。 |
| AI 叙述部分 | 直接在目标语言中生成（而非从英文翻译）。提示词使用英文，但我指示模型以目标语言输出并注入数据，从而产生更自然的内容。 |
| 数据 | 在各语言之间保持一致（数字、股票代码、百分比）。格式化（日期格式、数字分隔符）由基于语言的模板处理。 |
结果： 12 种语言，单语言工作量极小。主要工作在于构建系统；每新增一种语言通常只需 2‑3 天的工作。
成本细分
如果您想了解经济情况：
| 项目 | 成本 |
|---|---|
| 本地 GPU（一次性，二手 RTX 3090） | ~ $700 |
| 生成运行的电费 | ~ $5 / batch |
| Supabase（免费层 + 小额付费） | $25 / mo |
| 托管（DigitalOcean Spaces） | $5 / mo |
| Cloudflare CDN | Free tier |
| 域名 | $12 / year |
每月经常性总计： ~ $30 / mo
与大规模支付 API 调用费用或雇佣写手相比，本地 LLM 在生成约 5 k–10 k 页内容后即可收回成本。
我犯的错误
- Starting with too many pages – I generated content for 287 k pages before confirming Google would index them. I should have begun with ~5 k, gotten them indexed, then scaled.
- Not enough variation in prompts – The first pass used identical prompt structures for every page. The output was technically unique but structurally identical, which Google flagged. Adding randomized style directives in the second pass made a big difference.
- Ignoring readability – Early AI output was dense and clinical. Real financial analysis varies between technical detail and accessible explanations, so I had to explicitly prompt for this variation.
- No quality gate initially – I generated everything in batch and published it all. Implementing automated quality checks before publishing (catching the bottom 10 % of AI output) prevents thin‑content flags.
今日系统
在多次迭代后，我当前的流水线如下：
- 数据刷新 – 通过
yfinance拉取最新的金融数据（每日定时任务）。 - 内容生成 – 对陈旧或缺失叙述的页面运行 Llama 3（每周一次）。
- 质量检查 – 自动化评分，评估唯一性、可读性和事实准确性。
- 构建 – Astro 为所有页面生成静态 HTML。
- 部署 – 推送至 CDN。
整个流程在一台机器上运行。每周人工时间总计：约 2 小时的监控和偶尔的提示词微调。
如果你想了解完整的技术细节——精确的提示模板、质量评分系统、Astro 项目结构以及完整的部署流水线——请查看 Programmatic SEO Blueprint。其中包含可用于你自己项目的 MIT 许可证代码示例。
关注我，获取更多关于规模化构建 AI 驱动内容系统的分享。