附录：SEO-GEO 注册表的完整字段与落地取舍

💡 核心摘要：前七篇讲的是为什么和怎么判断，这一篇给可以直接抄的东西：两张表的完整字段、按阶段引入的顺序、落地格式的取舍、三条约束的检查方法。但请先接受一个前提——字段是原理的记录方式，不是起点。 拿着这份清单从第一天就建二十个字段，结果一定是大部分格子空着或者应付填。正确用法是先用第二节那五个字段跑起来，等某个判断真的因为缺字段而做不了，再回来查这份清单该加哪一个。

一、这份附录不做什么

先说清边界，避免误用。

它不是设计规范。 下面所有字段都是可选的，包括看起来很基础的那些。你的业务如果不需要区分漏斗位置，Funnel Role 这一栏就不该存在——空着的字段会持续消耗每个填表人的注意力。

它不替代判断。 字段能记下「这个提问的主人是哪一块」，但不能告诉你该选哪一块。选择依据在第五篇（看读完之后要做什么）。字段是判断的容器，不是判断的替代品。

它不是唯一写法。 字段名、枚举值、文件组织方式都可以按团队习惯改。真正需要保持的是三条约束（第七节），它们和字段名无关。

⚠️ 最常见的误用方式：把这份清单当成待办事项，花两周把所有字段建齐、所有记录填满，然后再也不看。第七篇讲过腐烂的三阶段，这种建法直接从第三阶段开始——因为它从来没有被使用过，谈不上被信任。

二、起步的五个字段

如果你现在什么都没有，从这五个开始。它们的共同点是不填就无法工作，而不是「填了会更完整」。

五个字段能支撑的工作：指定归属、避免重复、变更时找到要改的位置、区分「已声明未实现」和「已完成」。这已经覆盖了前七篇里最主要的几个动作。

SEO 侧同期只需要三个：Topic、Primary URL、Page Role。它让主题层的关联成立，也让第七节的约束二可检查。

先用这八个字段跑一个主题。 跑过一次变更传播和一次选题判断之后，你会自己知道下一个该加什么字段——那时候加的字段一定会被填，因为它是被需求逼出来的。

三、SEO 注册表：完整字段

按第一篇的三分法组织。决策类是主体，另两类是为了让决策可被复查和被推翻。

决策类——记录判断本身：

依据类——记录判断的理由，让它可被复查：

观测类——记录现实反馈，让决策可被推翻：

💡 三类的填写节奏不同。 决策类在页面建立前填，一次填好，很少改。依据类在有争议时填——没争议的记录留空是正常的。观测类定期回写，不需要每周更新。把三类混成一个「必填清单」是让人放弃填表的最快方式。

四、GEO 注册表：完整字段

原子是块，所以每一行是一个提问，而不是一个页面。

决策类：

依据类：

观测类：

两个字段容易被跳过但值得留意：

Restated In 是变更传播的唯一依据。 没有它，改完主答案只能靠全站搜索找复述处——而第七篇讲过搜索会漏掉「约六千次」这类写法。

Status 要包含「待删除」。 第三篇讲过提问表必须允许删除，因为你登记的是信念。只有增改没有删的表，会慢慢混入大量从未被验证的臆想。

五、事实清单：第三张小表

第四篇要求可核数字收敛到单一来源，这需要一张独立的小表。它很短，但作用很大。

关键设计是数字只存在这张表里，提问记录引用 Fact ID 而不是直接写数字。这样 datasheet 换版时，你改这张表的一行，然后按 Used By 找到所有要更新的块。

Conditions 这一栏不要省。第四篇那个「16 台 / 32 台 / 8 台」的案例，本质是三个数字各有条件但条件没被写清，于是看起来像互相矛盾。把条件写进事实清单，很多看似矛盾的数字会自己解释清楚。

六、落地格式：两种写法的取舍

形态问题在前七篇里一直被推到附录，这里给结论。

Markdown 表格的优点是人读友好、评审时能直接在 PR 里看 diff、不需要任何工具就能改。缺点是关系型字段（Restated In 可能有五个值）在表格里很挤，而且没有任何校验——填错枚举值不会有人提醒。

**结构化格式（YAML / JSON）**的优点是能表达嵌套和列表、能被脚本和 AI 消费、能做校验。缺点是评审时不如表格直观，非技术成员改起来有心理门槛。

推荐的组合是：

结构化格式做真相源  → 机器读它、校验它、推导站点结构靠它
Markdown 视图做评审 → 从真相源生成，人看它、讨论它

理由是第七篇的推导需求：目录、内链、聚合页、结构化标注都要从注册表推导，而推导需要机器可读。但如果你的团队现在还没有推导需求，直接用 Markdown 表格就够了——不要为了将来可能的自动化提前付复杂度。

⚠️ 不要维护两份真相源。 最糟的状态是结构化文件和 Markdown 表格都在手工维护，于是它们必然分叉，而你不知道该信哪个。要么只有 Markdown，要么 Markdown 是生成物。

关于文件组织，一个够用的划分是：SEO 侧一份、GEO 侧一份、事实清单一份，各自按主题分节。不要按页面拆成几十个小文件——注册表的价值在于横向比较（这个主题下所有提问放在一起看），拆散之后这个能力就没了。

七、三条约束怎么检查

前七篇散落了三条约束。它们是这套结构真正需要保持的东西，比字段名重要得多。

约束一：一个提问只有一个主人。

检查方法：按 Canonical Question 分组，看有没有两行的 Answer Owner 不同且都没填 Defers To。有就是归属分散（第四篇）。

约束二：答案主人必须是 SEO 表里已登记的页面。

检查方法：把 GEO 表所有 Answer Owner 的 URL 部分收集起来，逐个在 SEO 表的 Primary URL 里查。查不到的，就是在为 AI 造孤立页面（第六篇）。

约束三：SEO 表里的内容页应能反查到至少一个提问。

检查方法：反向查一遍，把没有任何提问指向的页面列出来。逐个判断是缺事实、缺登记，还是应豁免——豁免要显式标注，留空和「还没查」无法区分（第六篇）。

这三条都可以人工检查，几十条记录时十分钟能过一遍。规模上去之后值得写个小脚本，但请注意顺序：先手工检查几轮，确认这三条约束在你的业务里确实有用，再考虑自动化。 反过来先写脚本，通常会得到一个检查着无人关心的规则的工具。

八、字段的引入顺序

最后给一个按需引入的顺序，对应实际会遇到的问题：

起步            Topic / Canonical Question / Answer Owner
                Fact Source / Status（第二节那五个）

发现重复答案时   加 Defers To、Restated In
                → 能治理归属分散，能做变更传播

要排优先级时     加 Priority Score、Evidence Source
                → 能判断先做哪条，能识别没有证据的臆想

引用接不到询盘时 加 Funnel Role、Primary CTA、Page Purpose
                → 能看到引用落在漏斗哪一层（第六篇第四节）

页面开始臃肿时   加 Page Purpose、Intent Type
                → 能判断一页多块有没有变形（第五篇第六节）

要推导站点结构时 加 Schema Type、Tier、Links Up/Down
                → 能从表生成内链和标注（第七篇第二节）

开始用 AI 生产时 补全 Fact Source 和事实清单
                → 模型才有可核数字可用，不会自己编（第七篇第三节）

每一行的触发条件都是一个已经出现的问题，不是一个预期。这个顺序的意义就在于此：字段被加进来的时候，它要解决的问题已经在那里了，所以它一定会被填。

📌 核心收获

• ✓ 字段是原理的记录方式不是起点——从五个字段开始，被问题逼着加下一个。
• ✓ 字段分决策、依据、观测三类，填写节奏完全不同，混成一份必填清单会让人放弃。
• ✓ 事实清单是第三张表：数字只存在那里，提问记录引用它的条目而不是直接写数字。
• ✓ 结构化格式做真相源、Markdown 做评审视图，但不要手工维护两份。
• ✓ 三条约束比字段名重要：一问一主人、主人必须已登记、内容页应反查到提问。
• ✓ 先手工检查约束几轮，确认有用再自动化。

🚀 立刻行动

1. 用第二节那八个字段（GEO 五个 + SEO 三个）建一个主题，不要多加。
2. 建事实清单，把这个主题下所有可核数字连同条件和出处集中过去。
3. 手工过一遍三条约束，把发现的归属分散和孤立页面列成待处理。
4. 对照第八节，看你当前遇到的问题对应该加哪一个字段，只加那一个。
5. 如果已经在用 AI 生产内容，优先补全 Fact Source——它决定模型会不会编数字。

来源：系列原创整理 | 本文为「SEO-GEO 注册表体系」系列附录，原理部分见第 1-7 篇