DEFINE
建立问题沙盘
和业务、销售或客服一起整理目标客户会问的问题，覆盖认知、推荐、比较、采购和风险。记录原文、意图、地区和优先级。
为什么先做它：没有问题集，就无法判断品牌究竟缺席在哪个决策阶段，也无法进行公平复测。
先把“为什么没有被提到”拆开，
再决定该改网站、内容还是证据。
GEO 不能直接控制第三方模型，但可以把品牌公开信息做得更容易发现、更容易理解、更值得采用，并用相同问题和条件观察变化。
THE METHOD
问题沙盘 → 事实工程 → 复测闭环
我们不从“发多少篇”倒推工作量，而从客户怎样提问、AI 当前怎样回答开始。每一个动作都要能对应一个问题、一个证据或一个可复核的技术缺口。
BASELINE
确认事实与当前答案
由企业确认可公开的品牌事实；按约定模型、日期和模式保存答案、引用与竞品情况。所有数据保留原始证据。
为什么不能只看一次：模型输出会波动，单张截图只能说明那一次回答，不能代表所有用户。
DIAGNOSE
沿三层信息链找断点
分别检查能否被抓取和索引、品牌能否被正确理解、关键主张是否有足够证据。技术、内容和信源问题分开归因。
为什么结构化数据不单独售卖：JSON-LD 能提供语义线索，但不能让不可访问的页面被发现，也不能让空泛主张变得可信。
BUILD
按影响和可验证性执行
通常先修事实错误与访问问题，再建设高价值决策页面、原创证据和外部一致性。每项任务都有负责人、依据和验收方式。
为什么不追求铺量：同质内容会稀释主题、消耗维护成本，也不能替代只有企业自己能提供的一手经验。
VERIFY
同口径复测并解释变化
复用原始问题和接近的测试条件，分别报告提及、引用、准确性和业务信号。改善、无变化与异常样本都进入记录。
为什么保留边界：平台和竞争环境也会变化，不能把所有波动归因于项目，更不能据此承诺永久排名。
三层判断框架
| 层级 | 我们检查什么 | 常见误区 |
|---|---|---|
| Retrieve · 被找到 | 状态码、robots、sitemap、索引、HTML、内部链接与移动体验 | 首页能打开就等于所有页面可被获取 |
| Understand · 被理解 | 品牌事实、页面主题、语义 HTML、Organization/Service/Article JSON-LD | 加一段 Schema 就能解决全部 GEO |
| Cite · 被采用 | 原创经验、可核验数据、作者与日期、来源、第三方一致性 | 同一软文铺十个平台等于十个独立证据 |
证据规则
我们如何避免“自己证明自己”
固定能固定的变量
- 同一问题文本与意图分类
- 明确模型、联网状态和测试日期
- 保存原始回答和来源链接
- 多个时间点采样
坦诚不能固定的变量
- 模型版本和后台检索策略
- 个性化、地区与会话上下文
- 外部网页和竞争对手变化
- 生成过程的随机波动
对热点保持判断
阅读本期算法观察听说“算法更新”，先问证据在哪里。
平台公开规则、官方产品说明、可重复观察和服务商推断不是同一层证据。我们会利用结构化数据、原创内容和多源一致性这些稳健做法，但不会把未经官方证实的阈值包装成确定规律。
验收时，你应该能独立回答三件事
- 项目发现了什么问题，证据在哪里？
- 具体修改了什么，为什么这样改？
- 复测发生了什么变化，还有什么不能确定？