适用读者：知识付费/在线教育站的工程师与内容负责人。你的课程页面在生成式引擎优化（Generative Engine Optimization, GEO）体系里一直拿不到 AI 搜索的引用份额，而问题大概率不在课程本身，而在讲师这个实体上——本文讲怎么把一段文字简介改造成机器敢引用的结构化信号。

上周帮朋友排查一个职业教育站，Python 数据分析课质量不差，付费学员三千多人，但在 Perplexity、豆包、文心这些 AI 搜索里问「值得学的数据分析课」，来源列表里从来没出现过它。抓取日志看，AI 爬虫来过，课程页也抓了，就是不引用。后来把问题定位到讲师页：整页就是一段 300 字的自我介绍加一张头像，没有任何机器能核实的实体信号。AI 搜索回答「这个课靠不靠谱」时，判断来源可信度要查讲师的底细——查不到，就不敢把你的站放进来源列表。

花两天把讲师信息实体化，改完第九天开始看到引用。这篇把改造过程、字段取舍和踩过的坑完整记下来。

为什么 AI 搜索要「查讲师底细」

传统搜索引擎排序主要看页面级信号：链接、标题匹配、外链。AI 搜索生成回答时的逻辑不一样——它要把你的内容当「答案素材」拼进回答里，拼之前先做来源可信度判断。教育类内容尤其严格，因为 E-E-A-T（Experience, Expertise, Authoritativeness, Trustworthiness，经验、专业、权威、可信）框架里，教育主题的 Expertise 几乎完全落在「授课人是谁」这个实体上。

我抓过一次 Perplexity 回答「数据分析课程推荐」时的实际行为：它会优先找课程提供方（provider）和讲师（instructor），然后去找讲师的独立佐证——有没有行业主页、有没有可验证的资质、有没有获奖记录。你的站只给一段自我吹捧式的文字简介，等于所有佐证都自说自话，机器没有任何第三方锚点，直接跳过。

关键结论：AI 搜索不是不引用你的课程，是引用「有实体信号的讲师」。课程页写得再好，讲师实体是空的，可信度判断就断在这一环。

这就是 GEO 实操里最容易被忽略的一层：大家都在卷正文结构化、卷 FAQ，却没意识到对教育站来说，讲师 Person 实体才是可信度的承重墙。

Person 实体的三个关联点

把讲师做成 Schema.org 的 Person 类型，不是孤立放一段 JSON-LD 就完事，机器靠关联才能确认「这个 Person 和这门课有关系」。三个关联点缺一不可。

与 Course 的双向挂接

课程页的 Course 类型里，provider 指向机构，instructor 指向讲师。这里第一个坑就出现了：早期版本很多人把 instructor 填成 Organization，AI 引擎解析时直接把讲师当成了公司，可信度判断依旧失败。instructor 必须是 Person，而且要用 @id 做稳定标识，让课程页和讲师页指向同一个实体节点。

hasCredential 填 EducationalOccupationalCredential 的边界

hasCredential 是这次改造里收益最大也最容易翻车的字段。它能填的只有 EducationalOccupationalCredential——学位、职业资格证书这类第三方可核验的凭证。

我的朋友站上讲师简介写着「十年大厂经验」「金牌讲师」「年度最受欢迎讲师」，这些全是营销头衔，一个都不能塞进 hasCredential。判断标准很朴素：这个凭证能不能去发证机构官网核验。能核验的（比如 PMP 证书号、高校学位）才填；不能核验的，属于 award 或干脆不写。

填错了会怎样？把「金牌讲师」塞进 hasCredential，AI 引擎做可信度核验时发现凭证无法对证，反而给整个 Person 实体打上「信号不可靠」的权重，比不填还糟。

sameAs 关联行业主页

sameAs 是给机器发「这个人在别处的身份证」的数组。原则是：只链机器能独立访问和核对的页面，比如讲师在权威行业社区的主页、官方技术大会的演讲者页、开源平台的个人页。个人微信、需要登录才能看的后台页面链了等于没链。同名的干扰问题也靠 sameAs 消歧——搜「张伟 数据分析」有几千个同名结果，机器靠这组链接确认你说的是哪个张伟。

原理剖析：AI 引擎怎么消费 Person 实体

这一节讲机制。AI 搜索引擎在生成回答前有一个隐性的「实体对齐 + 佐证检索」阶段，流程大致如下：

flowchart LR
    A[用户提问课程类问题] --> B[候选文档召回]
    B --> C{文档含结构化实体?}
    C -- 是 --> D[提取 Course 与 Person 实体]
    C -- 否 --> E[降低来源权重]
    D --> F[解析 sameAs 关联外部主页]
    F --> G[核验 hasCredential 凭证]
    G --> H{凭证与奖项可对证?}
    H -- 是 --> I[提升来源可信度并引用]
    H -- 否 --> J[标记信号不可靠 降权处理]

拆开看三个关键步骤：

1. 实体对齐：AI 引擎把页面 JSON-LD 里的 @id、name、sameAs 和它自己的知识库对齐，确认「这个讲师是谁」。@id 不稳定（每次抓取都变），对齐就失败。
2. 佐证检索：顺着 sameAs 去外部主页交叉核对讲师身份和头衔。外部站点和你的描述越一致，可信度得分越高。这也是为什么 sameAs 必须链真实可访问的页面——核验 404 等于反向扣分。
3. 凭证核验：hasCredential 里每条 EducationalOccupationalCredential 的 credentialCategory（学位/证书分类）和 recognizedBy（颁发机构）是机器重点看的两个子字段，缺了 recognizedBy，核验链又断一截。

理解了这个流程就明白：GEO 做的从来不是「讨好爬虫」，而是把机器核验链条上每一环的材料备齐。讲师实体备齐了，引用才发生。

再看实体节点之间的关系，课程页和讲师页的挂接结构如下：

flowchart TD
    subgraph 课程页
        C[Course 节点]
        P[provider 机构 Organization]
        I[instructor 讲师 Person]
        C --> P
        C --> I
    end
    subgraph 讲师页
        P2[Person 实体节点 同一 @id]
        HC[hasCredential 凭证数组]
        AW[award 事实性奖项]
        SA[sameAs 外部主页数组]
        P2 --> HC
        P2 --> AW
        P2 --> SA
    end
    %% 两侧 @id 字符串完全一致，实体才对齐成功
    I -.@id 精确指向.-> P2
    %% sameAs 链向可公开核验的行业主页，供交叉核对
    SA --> EXT[(行业主页/大会讲者页)]

完整 JSON-LD 示例

改造后的讲师页 JSON-LD，环境是任意静态站点，直接嵌 <script type="application/ld+json"> 标签，无需依赖库；课程页另有 Course 实体通过 @id 关联过来。

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example-school.cn/instructors/li-ming#person",
  // @id 用带锚点的稳定 URI，抓取多次不能变化，否则实体对齐失败
  // URI 一旦上线就不要再改，改了等于换人，历史抓取全部作废
  "name": "李明",
  // name 与页面 h1 可见文本保持一字不差，机器会做一致性抽查
  "jobTitle": "数据分析讲师",
  // jobTitle 写职务事实，不写「金牌讲师」这类营销头衔
  "description": "十年数据分析从业经历，主讲 Python 数据分析系列课程。",
  // description 只做事实陈述，形容词越多核验越难对证
  "image": "https://example-school.cn/img/li-ming.jpg",
  // image 用独立可访问的 URL，别复用课程封面图
  "url": "https://example-school.cn/instructors/li-ming",
  // url 指向讲师实体页自身，给实体一个可回访的落点
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "bachelor degree",
      // credentialCategory 用 schema.org 规定的分类值，别自造中文
      // 学位类固定填 bachelor degree，证书类填 certification
      "name": "计算机科学与技术 学士",
      "recognizedBy": {
        "@type": "Organization",
        "name": "华东理工大学"
      }
      // recognizedBy 必填，写真实颁发机构，机器核验靠它
      // 机构名写官方全称，别写简称或缩写
    },
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "certification",
      "name": "PMP 项目管理专业人士认证",
      // 有证书编号可在 name 后附注，但别单独造字段
      "recognizedBy": {
        "@type": "Organization",
        "name": "Project Management Institute"
      }
      // 国际认证写颁发机构的英文名，与官网一致
    }
  ],
  "award": [
    "2024 年度平台最受欢迎讲师（颁发方：本平台，年度学员投票）"
  ]
  // award 只放事实性奖项并注明颁发方；营销头衔一个都不进来
  // award 条目控制在一两条，堆量反而稀释可信度
}

课程页里对应的挂接片段（只展示关联部分）：

{
  "@context": "https://schema.org",
  "@type": "Course",
  "name": "Python 数据分析实战",
  "provider": {
    "@type": "Organization",
    // provider 是机构主体，与 instructor 分开写，别混成一个节点
    "name": "示例在线学院"
  },
  "instructor": {
    "@type": "Person",
    // instructor 必须是 Person，用 @id 精确指向讲师页的实体节点
    // 早期版本有人填 Organization，会被引擎解析成公司当讲师
    "@id": "https://example-school.cn/instructors/li-ming#person",
    // 与讲师页的 @id 完全一致，多一个斜杠都关联不上
    "name": "李明"
  }
}

注意两个页面的 @id 字符串完全一致，一字不差。我第一次部署时课程页多打了个末尾斜杠，两个实体没对上，结构化检测工具照样报通过，但 AI 引擎侧的关联就是建立不起来——这种静默失败最坑，靠改回完全一致的 URI 才解决。

讲师实体页模板

JSON-LD 之外，页面可见内容要和结构化数据一一对应，机器会做一致性抽查。下面是我们讲师页的模板骨架：

<!-- 依赖：任意静态/SSR 模板引擎均可，此处以 Jinja2 语法示意 -->
<article class="instructor-page">
  <!-- h1 与 Person.name 保持一字不差，机器会做可见文本一致性抽查 -->
  <h1>{{ instructor.name }}</h1>
  <img src="{{ instructor.image }}" alt="{{ instructor.name }} 讲师照片" />
  <!-- alt 写人名加身份，别留空或堆关键词 -->

  <!-- jobTitle 与凭证摘要独立成块，别和营销文案混写在一段里 -->
  <p class="job-title">{{ instructor.jobTitle }}，{{ instructor.org_name }}</p>

  <section class="credentials">
    <h2>可核验资质</h2>
    <!-- 逐条列出 hasCredential 对应内容，含颁发机构，与 JSON-LD 对应 -->
    {% for cred in instructor.credentials %}
    <p>{{ cred.name }}（{{ cred.issuer }}颁发）</p>
    {% endfor %}
    <!-- 这里的条数必须与 JSON-LD 里 hasCredential 一致 -->
  </section>

  <section class="awards">
    <h2>获奖记录</h2>
    <!-- 每条 award 注明颁发方与年份，事实陈述不掺形容词 -->
    {% for a in instructor.awards %}
    <p>{{ a.text }}</p>
    {% endfor %}
  </section>

    <!-- sameAs 对应的可见外链，放在页面底部即可 -->
    <!-- 链接目标必须无需登录即可公开访问，否则核验等于失效 -->
    <footer>
    <a rel="me" href="{{ instructor.industry_homepage }}">行业主页</a>
    <!-- rel="me" 帮助机器确认这是本人声明的主页归属 -->
  </footer>
</article>

模板里所有变量都必须来自后台真实录入，录入表单同步加了校验：凭证字段强制要求填颁发机构，防止运营又把头衔当学历录进去。

改造前后的真实对照

站点本身没动，课程页没改一个字，只做了讲师实体化。以下是上线后按周记录的 AI 搜索引用数据（人工在 Perplexity、豆包、文心、Kimi 四个入口各问 10 次课程相关问题，统计来源列表出现本站的次数）：

另外两个执行细节值得记下来：

• knownFor 我们最后没用。它适合填讲师的代表性成果（比如开源项目、行业报告），当时评估站里没有可独立佐证的成果页，填了反而制造核验断点，宁可留空。
• 头像图加了 alt 和独立 URL，但没急着做作者照片的 ImageObject 细节，这个对引用率的影响在我们场景里测不出来，留待后面。

误区澄清与趋势预判

误区一：把营销头衔当凭证填。「金牌讲师」进 hasCredential 是本文见过最多的翻车点，核验失败连坐整个实体，务必守住「第三方可核验」这条边界。

误区二：讲师实体孤立存在。没有与 Course 的 @id 双向挂接、没有 sameAs 外部锚点的 Person，对机器来说只是一段穿了 JSON 外衣的文字简介，和原来的纯文本没有本质区别。

趋势预判：AI 搜索对教育类来源的核验只会越来越细，讲师实体的权重会从「加分项」变成「门槛项」。趁现在大多数竞品站还停留在一段文字简介的阶段，先把 Person 实体的地基打起来，引用份额是抢占式的——别人实体化了，你的空洞简介就再也排不进来源列表了。

如果你也在做课程站的 GEO 实体化，欢迎评论区交流字段取舍和核验细节。

参考与延伸

• Schema.org Person 类型定义：https://schema.org/Person
• EducationalOccupationalCredential 类型定义：https://schema.org/EducationalOccupationalCredential
• Google 搜索中心结构化数据文档：https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

讲师实体 · hasCredential · Person · Schema.org · GEO · AI搜索 · 知识付费