GEO 意图注册表的一行是「问题→主答块」的绑定，主答块精确到 slug+anchor 而非页面。标准答案字段只存一句话（80词内），句中数字通过 fact_refs 指回产品事实层。其余页面上的同一条答案是复述块，必须从主答块派生。表中还需要 self_answerable 标记，明确哪些问题不该由自己站上回答。

GEO 意图注册表设计：问题、答案块与一致复述约束

上一篇的结论是：关键词注册表装不下 AI 搜索里的问题，因为两者的唯一性约束方向相反。这篇设计那张新表。

如果你只读这个模块的一篇，读这篇。它和中央关键词注册表设计在各自那半边是对等的地位——那篇定义了词的归属规则，这篇定义问的归属规则。

先把两个词定义死

后面所有字段都从这两个定义长出来，先说清楚。

记录单位：问题，不是关键词

一行记录一个完整的问句，带着它原本的约束条件。

❌ sulfuric acid pump material
✅ What pump material should I use for 60% sulfuric acid at 80°C?

不要在录入的时候顺手把它“整理”成关键词形态。整理一次，就把上一篇讲的粒度信息扔掉一次——而那些约束条件正是这句话值钱的原因。

归属对象：答案块（answer unit），不是页面

一行绑定一个主答块，位置精确到锚点：

❌ /products/cp-100/
✅ /products/cp-100/#max-operating-temperature

为什么必须带锚点，值得多说一句。

一个 SKU 页上有八个问答、一张参数表、三段正文。说“这个问题归 /products/cp-100/”，等于说“它在这十二块里的某一块”。这句话有三个地方用不了：

• 审计时无法定位——脚本不知道该去页面的哪里找这条答案，只能全文搜索关键词，误判率极高
• 复述时无法比对——三个页面都写了这条答案，哪一份是基准？没有锚点就没有基准
• 修改时无法定位——事实层的数字变了，要改哪几个位置？

带上锚点之后，“这条答案在哪、落地没有、和别处一不一致”从三句空话变成三个能用脚本回答的问题。这是整张表能被自动审计的前提。

完整字段规范

每个字段都给了存在理由。如果一个字段你说不出它被谁用、什么时候用，就不要加。

下面挑五个需要解释的说。

canonical_answer：为什么只存一句

这是最容易被做错的字段。看到“标准答案”四个字，第一反应是把整段答案存进去。别这么做。

存全文的两个后果：

第一，它会变成第二个 CMS。页面上的正文和表里的正文，两边一改就分叉，你从此要维护两份内容——而这张表本来是为了消灭分叉才建的。

第二，它会把这张表撑爆。八十个问题、每个三百词，这份文件没人愿意打开，更没人愿意维护。

只存首句的两个理由：

第一，RAG 提取时首句权重最高（模块化 FAQ 设计那篇讲过：最关键的信息、数字、结论必须放在第一句）。一句写对，后面的展开各页可以自由发挥，不影响被引用的概率。

第二，一句话是可比对的。三个页面的首句是不是同一句，脚本一比就知道；三段三百词的正文是不是“一致”，没法判定。

写法示例：

❌ 太长，还夹了展开：
The CP-100 centrifugal pump operates at temperatures from -20°C to 120°C
in its standard configuration. For applications exceeding 120°C, the
CP-100 HT version with upgraded mechanical seals is rated to 180°C, and
we generally recommend specifying the HT variant whenever...

✅ 一句，带主体名、带数字、带工况、带双单位：
The CP-100 centrifugal pump operates from -20°C to 120°C (-4°F to 248°F)
in its standard configuration.

后面那段关于 HT 版本的展开，写在页面上就好，不进表。

fact_refs：三张表的接口

canonical_answer 里出现的每一个数字，都要在 fact_refs 里指回产品事实层的具体字段。事实层的完整设计会在后续模块展开，这里先把它当作意图注册表必须遵守的上游接口。

qid: Q-017
canonical_answer: >
  The CP-100 centrifugal pump operates from -20°C to 120°C
  (-4°F to 248°F) in its standard configuration.
fact_refs:
  - products.cp-100.temp_min
  - products.cp-100.temp_max
confidence: datasheet
evidence:
  - "Supplier datasheet v3, p.2"

这条约束做了三件事：

1. 堵住编数字的路。 后面的AI 边界会完整说明这条规矩：散文交给模型，数字只准从事实层搬运。写 canonical_answer 的时候，模型只能填占位符，值从事实层取
2. 让“事实变了要改哪些答案”变成可查询的。 供应商换版、参数修订时，反查 fact_refs 就知道哪些答案要重写。没有这个字段，这件事只能靠记性
3. 让审计能做数值对账。 脚本扫全站答案里的数字，和事实层比，不一致直接报 error

没有对应事实层字段的答案怎么办？ 比如“磁力泵和机封哪个长期成本低”这类权衡型问题，答案里没有硬参数。那 fact_refs 就留空，但 evidence 必须填——你凭什么这么说，得有个来源。两个都空的行，是一条没有依据的断言，不该进表。

confidence：对外说话的确定性不能超过手上事实的确定性

这里先使用四级可信度；每一级如何入库、如何保留出处，会在什么才算一条产品事实中完整展开：

在 GEO 语境里这条规矩多了一层意义。

传统 SEO 里，措辞太满最多是个文案风格问题。在 AI 搜索里它是一个信任信号——LLM 在选择引用来源时，会倾向于标注了来源和条件的内容（行业标准引用策略那篇讲过这个机制）。一句 “rated at 120 m³/h per ISO 9906 Grade 2 testing” 比一句斩钉截铁的 “delivers 120 m³/h” 更容易被引用，因为它自带出处。

所以在 GEO 里，诚实标注可信度不是道德要求，是有效性要求。

反过来的红线也要写清楚：verbal 和 estimated 级的内容，宁可不答。答了一个没依据的数字，最好的结果是没人引，最坏的结果是被引用之后客户按它下单——这属于事实层的两种死法里“漏出去”的变种。

restate_on 与一致复述的三条规矩

这是这张表和关键词注册表最不一样的地方，也是整个模块的机械核心。

为什么需要复述

上一篇讲过：RAG 检索是块级的，用户可能从任何一页进来。一个在看型号页的人、一个在看应用页的人、一个在看对比文章的人，都会问“这个泵最高能上多少度”。

三个页面都该有这条答案。只有型号页写了，另外两页的读者提问时，被引用的就是别人。

在 SEO 里，同一条内容出现在三个页面叫内耗；在 GEO 里，这叫覆盖。

三条规矩

规矩一：主答块唯一。 一个 qid 只有一个 answer_unit。它是这条答案的基准版本，其余全是它的派生。

规矩二：复述必须派生，不能各写各的。 restate_on 里列出的每一块，它的首句必须和 canonical_answer 一致。允许的差异只有排版和上下文衔接，不允许数字、工况、措辞确定性有差异。

规矩三：数字必须指回事实层。 就是上面的 fact_refs。这条保证了即使有人手改了某一处，对账脚本也能发现。

三条都不做的后果

不是“不够严谨”，是具体的失败：

/products/cp-100/           标准配置最高 120°C
/applications/chemical/     最高工作温度 120°C (248°F)
/blog/high-temp-pumps/      可以做到 125°C 左右    ← 八个月前写的

LLM 一次检索拿到三个 chunk，三个数字不完全一致。它会随便挑一个、含糊地说“说法不一”、或者挑了那个错的。第三种最坏——GEO 覆盖审计那篇已经点过：被引用但信息错误，比完全不被引用更该优先处理。

复述不该靠人复制

写到这里必须补一句实现层面的判断，否则前面三条规矩会变成纪律要求，而纪律一定会失守。

三个页面手抄同一句话，三个月后必然分叉。正确做法是标准答案存一处，页面通过组件引用，而不是复制粘贴。

判断你有没有做到，用一个问题：

改一条标准答案，你要动几个文件？

答案是 1 → 你用架构解决了这件事。答案是 3 → 你在用纪律维持它，迟早失守。这就是事实层的两种死法里“用架构代替纪律”的原则，从事实层搬到了答案层。

具体在 Astro 里怎么做（内容集合 + 组件引用），收在本模块的工具箱那篇，正文不展开。

self_answerable：一张敢承认输的表

这是全表最反直觉的字段，也是最能防止它退化成愿望清单的字段。

有一批问题，你不该在自己站上回答：

Who are the most reliable centrifugal pump manufacturers in China?
Is AquaFlow Industrial a trustworthy supplier?
Best pump suppliers for chemical processing

不是因为你答不好，是因为你答了也没用。 LLM 在组织“谁最靠谱”这类答案时，会系统性折价来源方的自我评价——你的 About 页写一万字“我们值得信赖”，它不会引用。它引用的是第三方：行业媒体、目录站、论坛里别人提到你的那句话。

所以这类问题在表里的正确处理是标记 self_answerable: false，然后明确交给站外——E-E-A-T 在 AI 搜索时代那篇讲的品牌提及、跨平台叙述一致性、真实社区参与，那才是这批问题的战场。

为什么要把赢不了的问题也登记进来

三个理由：

1. 防止有人去建那个页面。 不登记，半年后总会有人想“我们该做一个 best pump manufacturers 的页面”，然后浪费三周
2. 它是站外工作的输入清单。 做品牌提及不该是漫无目的的“多刷点存在感”，而该是针对一份具体清单
3. 它让这张表诚实。 一张只记录“我们要赢的问题”的表，是愿望清单；一张同时记录“我们赢不了的问题”的表，才是地图

判据：这个问题的最佳答案，是不是必须由第三方说出口才可信？ 是 → self_answerable: false 否 → 我们自己答

seo_keyword_ref 为空，是信号不是缺口

这个字段关联到关键词注册表里的词。它经常是空的，而且空得有道理。

上一篇讲过：带完整约束条件的提问，在关键词工具里显示零搜索量。所以你表里最有价值的那些行——条件选型型的问题——seo_keyword_ref 大多是空的。

看到空值的正确反应不是“这里缺了个词，得去补一个”，而是：

这是一条同行的关键词工具里看不见的问题。

竞品扒 Ahrefs 扒不出它，做关键词研究做不到它，只有真正接过这类询盘的人才知道它存在。这类问题在表里的占比，某种程度上就是你相对同行的信息壁垒。

反过来，如果你表里 90% 的行都有 seo_keyword_ref，说明你是照着注册表倒推问题的——那只是把词换了个写法，没有引入新信息。这时候该回去做从 Reddit 挖真实用户问题那篇讲的事。

多语言怎么处理

一条意图是跨语言的，答案是每语言一份。

推荐做法：一行一个 qid，target_locale 列出要覆盖的语言，answer_unit 和 restate_on 按语言分组。不要给每种语言开一个新 qid——那样同一个意图会散成五行，改一次要改五处。

qid: Q-017
question: What is the maximum operating temperature of the CP-100?
target_locale: [en, de]
answer_unit:
  en: /products/cp-100/#max-operating-temperature
  de: /de/produkte/cp-100/#max-betriebstemperatur

这里有一个具体的坑：机翻会让术语分叉。同一个“机械密封”在英文页写 mechanical seal、德文页写成三种不同说法，对客户是三种东西，对 LLM 是三个弱信号。

术语的一致性归事实层管（什么才算一条产品事实那篇把术语表放在事实层，不放在文案环节），不归翻译环节。这张表只需要在生成多语言 canonical_answer 时强制引用术语表。

hreflang 的配置本身不在这张表的职责范围内，见多语言架构与 hreflang 配置。

边界：这张表不管什么

和事实层一样，一张表的价值有一半来自它拒绝管的东西。

不管的：

• 页面标题、H1、URL —— 关键词注册表管，见注册表作为 AI 协作接口
• 答案的正文和排版 —— FAQ 模块设计管格式，这里只管首句
• 关键词 —— 有 seo_keyword_ref 做关联就够了，不要在这张表里重建一份词库
• 产品参数的值 —— 事实层管，这里只放引用路径
• 客户和订单 —— 那是 CRM

最需要警惕的一种退化：往 canonical_answer 里塞越来越长的内容，直到它变成一个 FAQ 数据库。判断你有没有滑向这一边，看一个数：canonical_answer 的平均长度。超过 80 词还在涨，说明它正在变成 CMS。

起步：20 行就够

和注册表设计那篇一个口径——第一版不需要完整。

建议的起步顺序：

1. 把上一篇自查动作产出的原始问题清单拿出来（客户问过的、销售被追问的、论坛见过的）
2. 挑 20 条 priority 最高的——判断标准是“答对了能推进一单”，不是“搜索量大”
3. 每条填五个必填字段：qid / question / intent_class / answer_unit / canonical_answer
4. restate_on、citation_status 这些先全部留空，等第 77 篇的流程跑起来再补

存储选型沿用注册表那篇的结论：小团队 Notion 起步，开发者直接 YAML 进 Git。这张表比关键词注册表更适合放进 Git——因为 canonical_answer 需要 diff（一句话改了没有，一眼就能看出来），而 Notion 看不出这个。

小结：这张表的承诺

关键词注册表的承诺是三句话。这张表的承诺也是三句：

这个问题，全站只有一个主答块。 这条答案，出现在几处就必须一模一样。 这里的每个数字，都能追回事实层。

三条都做到，AI 检索到你的任意一块，拿到的都是同一份、可核对的信息。做不到任何一条，你就是在给 LLM 提供互相矛盾的证据——它的处理方式是不引用你，或者更糟，引用那个错的。

下一篇讲 intent_class 那六个值：为什么 AI 里的提问不能照抄 SEO 三仓，以及六类问题各自该怎么答。

→ GEO 意图分类：为什么不能照抄 SEO 三仓