先说答案：结构是对读者的承诺
好的结构，会减少读者为了理解一篇文章而不得不自行拼接的部分。一个可靠的技术小节，应该让结论、证据、适用边界和下一步都容易找到。这也会给搜索与问答系统提供更清楚的材料，但没有哪一种标题、段长、摘要或 Schema 能保证文章被 AI 引用。
这个区别很重要。GEO 很容易被写成一套仪式：开头先给答案，把段落控制在某个字数，补上 FAQ Schema，然后等引用出现。Google 的公开说明却很克制：AI 搜索功能沿用常规搜索的基础 SEO 要求，不需要特殊的 AI 标记或内容格式。
因此，我更愿意按这个顺序改文章：
- 先解决一个真实的读者问题；
- 让推理和证据可以被检查；
- 满足已有文档明确写出的技术要求；
- 最后再测量发现量或引用是否真的变化。
这是「GEO 生成式引擎优化」系列的第 3 篇（结构化实战）。第 2 篇 区分了公开机制、观察和推断；这一篇把那种克制落实成我在 cubxxw.com 上能重复执行的编辑流程。
读者需要答案时，就把答案放在前面
不少技术文章迟迟不说关键句，是因为作者在复述自己发现问题的顺序。读者的处境通常不同：他已经遇到报错、构建缓慢，或者正等着做一个设计选择。
一种常见开头是：
关于 Hugo 的构建速度，往往有很多因素需要考虑。不同配置、内容规模和模板复杂度都会带来差异。要理解这个问题，我们应该先了解 Hugo 的构建流程。
这段话没有错，却推迟了读者真正需要的判断。更有用的版本会先给出有边界的诊断：
在这个 Hugo 站点里，构建变慢时我会先检查三类模板：反复遍历
.Site.Pages、重复处理同一张图片，以及在大集合上计算相关内容的模板。 改代码前，我会先看 Hugo 的 template metrics，因为真正昂贵的操作会随站点而变。
第二段的价值，不在于它更容易被机器原样摘走，而在于它同时交代了适用范围、检查对象和验证方法。
我现在用四个问题检查一段开头，而不是套固定字数：
- 答案：第一句是否回答了问题，或指出了要做的决定？
- 范围：是否交代版本、环境、读者或其他成立条件？
- 证据：读者能否检查命令、测量、来源、示例或取舍？
- 下一步：读完后是否知道该做什么？
一段定义也许 50 字就够，一次故障分析也许需要 500 字。它们不该被压进同一个模具。Google 也明确说明，无须为了 AI 搜索功能刻意制造大量小段落。段落边界应该服从语义和阅读，而不是计数器。
关于那组 Hugo 构建时间
旧稿写过一组数字：在约 1,100 页的双语站上，把一次全站遍历改成 where 加缓存后，构建时间从 18 秒降到 6 秒。它可以是一段有用的调试记忆，却不是受控基准：当时没有保留 Hugo 版本、预热次数、机器负载和可重复的测试夹具。
所以，我不该把这个比例写成普遍的 Hugo 性能规律。更可复现的做法是运行 hugo --templateMetrics --templateMetricsHints，一次只修改一个可疑热点，在相同条件下重复构建，并连同 Hugo 版本和 commit 记录中位数。缺少这些条件时，数字只能被标作个人案例。
只有真实的问题，才值得用问题式标题
问题式标题是很好的导航。搜索「Hugo 怎么生成 sitemap」的读者，看到同一个问题和紧随其后的答案，会更快判断这一节有没有用。但问号不是检索系统发放的通行证。
Google 确实在部分 AI 搜索体验中公开提到 query fan-out（查询扇出）：系统可能发起一组相关搜索来组织回答。它并没有说问题式标题可以“认领”这些子查询，也没有公开所谓更近的向量距离或额外排名入口。
我的编辑规则因此只服从语义：
- 小节直接回答真实问题时，用问题式标题；
- 概念、对比、叙事转折和案例复盘，用描述式标题；
- 一个标题只承担一个清楚的主题，但不围绕关键词扭曲自然语言；
- 单独读一遍标题大纲，它应该能显出文章的论证，而不是重复一组相似查询。
例如，Hugo SEO 太宽泛；写操作教程时，在 Hugo 中生成 sitemap 可能更好；写决策指南时，什么时候需要自定义 sitemap 又更准确。不存在脱离读者任务的最佳句式。
结构化数据描述页面，不会打开一条 AI 专用通道
结构化数据的价值，是准确描述页面上已经可见的内容，并满足某项搜索功能公开写明的要求。我的文章页已经输出 BlogPosting、WebSite、Person 和 BreadcrumbList 等类型，用来明确页面含义，并支持符合条件的搜索展示。
它的边界同样清楚：
Google 表示，AI Overviews 和 AI Mode 不需要特殊的 Schema.org 结构化数据。标记必须与页面可见内容一致；添加没有对应功能支持的标记，并不会创造一项有文档依据的 AI 引用优势。
FAQ 和 HowTo 正好能检验这条原则。Google 在 2023 年 8 月把 FAQ 富媒体结果主要限制在知名政府与医疗网站，并弃用了 HowTo 富媒体结果。这是搜索展示方式的变化，不是让发布者把 FAQPage 改造成“面向 AI 的 Schema”的证据。
对这个个人博客，我会采用下面的策略：
- 只有反复出现、又不适合放在其他章节的问题，才写 FAQ；
- 每个答案都必须真实显示在页面上；
- 仅在页面内容和 Google 当前文档都适合时添加
FAQPageJSON-LD； - 不承诺富媒体结果、AI 引用或排名提升；
- 标记一旦与正文不同步，就及时修正或删除。
Hugo 模板可以把可见的 FAQ 数据同步成 JSON-LD，但必须正确做 JSON 编码，也不该仅仅因为 front matter 里存在字段就输出：
{{ with .Params.faq }}
<script type="application/ld+json">
{{ dict
"@context" "https://schema.org"
"@type" "FAQPage"
"mainEntity" (apply . "partial" "schema/faq-item.html" ".")
| jsonify
| safeJS
}}
</script>
{{ end }}
这段示意仍然需要一个经过测试的 schema/faq-item.html partial，也需要检查最终渲染页面。它只是实现模式，不是给全站文章批量添加 FAQ 标记的建议。
一手资料：
把 llms.txt 和读者可见摘要当成两种工具
llms.txt 是一项向语言模型工具展示站点重要资源的提案，不是 Google Search 的要求。Google 当前的公开说明是不会使用这个文件。
涉及其他产品时，也应该坚持同一证据标准。“AI 开发工具都会读取 llms.txt”这个说法太宽：Cursor、Claude Code、Copilot、MCP 客户端、问答引擎和爬虫是不同产品，各自有不同的获取规则。只有当前一手文档明确说明某个产品会读取它，我才应该写出产品名，并测试对应的具体流程。
因此，维护决策可以很简单：
- 有明确记录的消费者、项目集成或自己的工具链在使用时，保留
llms.txt； - 不把它当成未经证实的排名信号；
- 像维护其他索引一样监控它，避免链接腐烂；
- 产品行为变化时，删除过时说法。
可见的 tldr 解决的是另一个问题：帮助匆忙的读者判断文章是否值得继续看，也把作者的核心判断放到台面上接受检查。搜索或问答系统可能处理这些文字，因为它们本来就是页面内容；但我不能从“五条摘要存在”直接推导出引用提升。
所以摘要应该写文章真实的结论和限制，而不是再堆一遍宣传关键词。
让证据容易检查，而不是让文字容易拆散
“可提取性”只有在不破坏上下文时才有价值。一段话被单独复制之后，如果成立条件随之消失，它反而更容易误导人。
我更在意的是可检查的结构：
- 命令和代码放进代码块，并在附近标明版本与环境；
- 只有在读者需要横向比较同一组字段时才用表格；
- 顺序确实重要时用有序列表，不把所有并列信息都列表化；
- 限定条件紧跟它所限制的结论；
- 一手来源放在对应陈述旁边；
- 区分个人测量、厂商基准和自己的推断；
- 后一节依赖前一节推理时，保留必要的过渡。
这样做也让维护更轻。当 API 变化时，我能直接找到带版本的结论和它的来源，而不是重新阅读一堵由断言砌成的墙。
普林斯顿团队的 GEO 论文很适合说明证据边界。论文实验在部分方法和领域中报告了最高约 40% 的可见度增益，但这不是普遍适用的引用率提升：研究使用自己的可见度指标、特定系统和查询集，效果也随领域变化。它支持的是继续测试，不是“加一句引语就固定提升 22%～41%”的写作公式。
应优先阅读原论文，而不是层层转述的营销摘要：GEO: Generative Engine Optimization 。
内链应围绕读者旅程，而不是制造权威感
内链帮助读者找到前置知识、更深解释和下一步行动，也帮助爬虫理解页面之间的关系。我把主题集群当作信息架构，而不是某个据说固定存在的“AI 引用因素”。
在这个系列里：
锚文本应该说清目标文章能补充什么。链接放在读者可能需要它的位置，而不是反复出现来制造“权威”。如果子文章已经不能回答链接承诺的问题，就更新或删除链接。
我在 cubxxw.com 上使用的编辑清单
下面这份清单可以执行，也可以审计：
- 在开头附近说清读者的问题和文章的适用范围；
- 延迟答案会浪费读者时间时，先给答案；
- 把证据、成立条件和限制放在结论旁边；
- 标题准确描述小节，无论它是不是问题句；
- 只有信息本身适合时，才使用列表、表格和代码块；
- 对照页面可见内容和最新官方文档验证结构化数据；
- 把
llms.txt当成集成文件，而不是排名技巧； - 用
tldr给人总结真实结论和限制； - 用描述性锚文本链接到下一页有用内容；
- 用记录完整的测试衡量 AI 可见度，不从排版推断成功。
做 AI 可见度测试时，我会固定一组问题并重复运行，记录平台、可获得时的模型或产品入口、日期、地区、被引 URL，以及页面是否真的支持那段回答。一次引用只是一次观察；要判断是否出现持续变化，还需要重复证据和对照时段。
常见问题
Answer-First 写法会提高 AI 引用吗？
它能让人更快找到并判断答案，但没有公开证据支持一个普遍适用的引用增益。应把它当成读者优先的编辑方法，再单独测试可见度。
这个博客应该给每篇文章都添加 FAQPage Schema 吗？
不应该。只有读者确实需要时才写 FAQ，答案必须在页面上可见，并且结构化数据要准确描述当前内容、遵守最新文档。Google 的 AI 搜索功能不要求特殊 Schema。
GEO 是否存在理想段落长度？
没有公开文档支持一个通用长度。一个段落应完整展开一个观点，并带上必要证据和限制；只有拆开更易理解时才拆，而不是达到某个数字就换段。
llms.txt 还值得保留吗？
只有在存在有文档依据的消费者、自己可控的工作流，或维护成本很低且实验目的明确时才值得。Google 表示不会使用 llms.txt，所以不应把它包装成搜索或 AI 引用杠杆。
小结与下一篇
结构化内容不是与不透明排序系统谈条件，而是对读者保持尊重：回答真实问题，摊开证据，保留限制，并把下一步说清。这样的内容也会给搜索和问答产品提供更干净的输入，但可见度是否提升，仍然必须测量。
下一篇会从页面结构走向信任：亲身经验、一手证据、作者身份、勘误机制和第三方引用。规则仍然一样——系统公开说过什么就写什么，自己的推断要标明，结论不能大过证据。
- 上一篇：AI 搜索如何检索与引用来源
- 下一篇（第 4 篇·信任与背书）：不制造共识，建立可以核验的权威
读者回响