九月初接了个空压机厂商的活儿，甲方姓周，技术部经理。他甩过来一句话我记到现在：「我们手册做得可认真了，两百余页，全彩印刷，怎么客户问 AI，AI 给的答案里压根没有我们？」我让他把官网手册栏目打开看了一眼——三十多个 PDF，最大的一个 48MB，挂在「资料下载」下面，点进去直接浏览器下载。这事儿说白了就是：你把最值钱的技术内容锁在 AI 爬虫（AI Crawler）啃不动的容器里，还指望别人引用你，白费劲。

这篇写的是我们后来的改法：把手册从 PDF 附件改成可抓取的 HTML 文档页，用 schema.org 的 TechArticle 加上 proficiencyLevel、dependencies、articleSection 这几个字段做结构化描述，.NET 8 服务端渲染，一套模板批量出页。两个月跑下来，自建监测口径下，主流 AI 搜索引擎对我们文档页的引用条数从 0 涨到了两位数。生成式引擎优化（Generative Engine Optimization, GEO）这件事在制造业 B2B 场景里，落地起来其实没有多少玄学，主要靠架构选对。

PDF 附件模式到底卡在哪

先讲清楚问题，再讲方案。PDF 对 AI 搜索不友好，卡点有四个：

1. 抓取成本高。48MB 的 PDF，爬虫要解析文本层、处理分栏和表格，很多 AI 爬虫对大文件直接设了体积上限。
2. 结构信息全丢。PDF 里的「3.2.1 更换滤芯」到了纯文本层就成了一行字，层级、步骤、警告框这些语义全没了。
3. 没有元数据。AI 引擎判断「这段内容是给谁看的、需要什么前置技能」，PDF 给不出任何线索。
4. 引用粒度太粗。AI 引用网页时可以精确到一个锚点小节，引用 PDF 时基本只能整个文件丢给用户，体验差，被选中的概率自然低。

周经理的团队之前不是没试过，他们让外包把三本手册转成了网页，结果转出来是整页大图配 JS 翻页插件，服务端渲染（Server-Side Rendering, SSR）基本没有，爬虫拿到的 HTML 里正文是空的。等于钱花了，事没成。

文档中心站点架构：三层分工

我们的方案是单独起一个 docs 子域，跟主站解耦。架构分三层：

flowchart LR
    A[(Pandoc/手工<br>Markdown 源库)] --> B[元数据管道<br>解析+补齐+校验]
    B --> C[.NET 8 文档站<br>Razor SSR + JSON-LD 模板]
    C --> D[静态化 HTML 输出<br>docs.example.com]
    D --> E[传统搜索引擎]
    D --> F[AI 爬虫与 AI 搜索]
    C --> G[(Sitemap + 索引 now API)]

• 内容源层：手册正文统一收成 Markdown，进 Git 仓库管版本。老工程师用 Word 写了十几年的习惯改不动，就保留 Word，配一个 Pandoc 转换脚本进库。
• 元数据管道：这是后面重点，手册的设备型号、适用人群、前置条件这些字段都是从这里补出来的。
• 输出层：.NET 8 文档站负责服务端渲染，每篇文章输出带 JSON-LD 的完整 HTML，同时生成 sitemap，内容更新后通过索引推送接口主动通知搜索端。

为什么不直接在主站 CMS 里发？因为手册的元数据模型（型号、版本、技能等级）跟新闻、产品页完全是两套，硬塞进通用 CMS，后面每一步都要绕。docs 子域还能单独配爬虫策略和缓存策略，省事。

元数据从哪来：三层来源拼接

手册页要变成 AI 能理解的东西，光有正文不够，得有结构化的「说明书元数据」。我们的字段来源分三层，用一张表说清楚：

这里有个细节值得说。管道里第一版我们放了个 LLM 自动分类，跑了两周发现「故障排查」和「维保」混着分，错分类率接近两成。后来改成 LLM 只做初筛建议、编辑在后台点确认，错误率降到 3% 以下，人也轻松了——因为候选答案已经给出来了，点一下就行。

流程上是这样串的：

sequenceDiagram
    participant G as Git 仓库
    participant P as 元数据管道
    participant E as 编辑后台
    participant S as 文档站
    G->>P: push 手册 Markdown
    P->>P: 解析型号/章节/版本
    P->>E: 生成待确认工单
    E->>P: 确认 proficiencyLevel 等字段
    P->>S: 写入元数据库并触发渲染
    S->>S: SSR 输出 HTML + JSON-LD

TechArticle 的三个关键字段，别都用默认值

schema.org 的 TechArticle 类型自带几个面向「技术内容」的字段，很多站点直接空着不用，我觉得这是最可惜的地方。AI 搜索引擎在决定「引用谁、引用哪段」时，这些字段就是它判断内容匹配度的抓手——这个词在这儿是中性的，就是「抓手」，不是黑话。

proficiencyLevel 特别想多说两句。空压机手册里「日常检查」和「主机大修」是两篇文档，受众完全不同。以前 PDF 时代这两篇长得差不多，AI 分不清。我们把前者标 Beginner，后者标 Expert，并且在正文开头放一句明示：「本文面向持证维保人员，日常巡检请看另一篇」。九月改完，十月中我们抓 AI 搜索的回答日志（自建监测口径：每天对二十个典型问题手工提问并记录引用来源），发现「空压机异响怎么办」这类新手问题开始稳定引用日常检查那篇，而大修文档只在专业问法下出现。受众分流起效了。

dependencies 的用法也顺带提一下：维保文档的 dependencies 里挂上「断电操作规程」的链接，AI 组织回答时经常把两篇内容拼在一起给出，这对用户是加分的，对引用方（就是我们）等于多占了一处来源位。

模板怎么渲染：一份 JSON-LD 模板服务四类文档

输出层是 ASP.NET Core 8，Razor 做服务端渲染，JSON-LD 从一个模板服务里统一生成。环境：.NET 8 / C# 12，无第三方依赖。

// TechArticleJsonLdBuilder.cs — 统一生成 TechArticle 结构化数据
// 环境：.NET 8 / C# 12 / Newtonsoft.Json 13，无其他第三方依赖
public sealed class TechArticleJsonLdBuilder
{
    private readonly ISkuCatalog _sku; // 产品库，校验型号真伪

    public JObject Build(DocMeta meta, IReadOnlyList<Section> sections)
    {
        // 型号必须能在产品库里找到，找不到直接抛错，不让脏数据上线
        _sku.MustExist(meta.Sku);

        var json = new JObject
        {
            ["@context"] = "https://schema.org",
            ["@type"] = "TechArticle",
            // proficiencyLevel 用五档枚举，别自己发明字符串
            // AI 引擎靠它分流受众：新手问法会压低 Expert 级文档权重
            ["proficiencyLevel"] = meta.Level switch
            {
                DocLevel.Operator => "Beginner",
                DocLevel.Maintainer => "Intermediate",
                DocLevel.Electrical => "Expert",
                // 兜底给 Beginner，宁可保守也别误导新手
                _ => "Beginner"
            },
            // 前置文档全量 URL，AI 会沿着链路取多篇拼接回答
            ["dependencies"] = new JArray(meta.PrereqUrls),
            // 章节锚点 URL，AI 引用可以落到具体小节而不是整篇
            ["articleSection"] = new JArray(
                sections.Select(s => new JObject
                {
                    ["name"] = s.Title,
                    ["url"] = $"https://docs.example.com/{meta.Slug}#{s.Anchor}"
                })),
            // 作者统一挂组织，不写个人，避免人员变动导致署名失效
            ["author"] = new JObject
            {
                ["@type"] = "Organization",
                ["name"] = meta.BrandName
            }
        };
        // 返回后由 Razor 模板塞进 <script type="application/ld+json">
        return json;
    }
}

上线前我们还有一个 CI 自检脚本，专门防 JSON-LD 低级错误：

# 环境：Linux CI / curl 8.x —— 文档页上线前三项自检
# 这三项全是血的教训换来的：JSON-LD 少个括号我们曾三天没发现
# 第一项：确认 HTML 里真的输出了 JSON-LD（期望输出 1）
curl -s https://docs.example.com/docs/ktr-120/2.3/maintenance | grep -c 'application/ld+json'
# 第二项：确认老版本路径 301 到当前版（期望输出 301）
curl -s -o /dev/null -w "%{http_code}" https://docs.example.com/docs/ktr-120/2.1/maintenance
# 第三项：确认 sitemap 收录了新版 URL（期望输出 1）
curl -s https://docs.example.com/sitemap.xml | grep -c 'ktr-120/2.3/maintenance'
# 三项任一不符合预期，流水线直接标红拦下，不允许人工放行

页面渲染时把这个 JObject 直接塞进 <script type="application/ld+json">，同一份数据也用于面包屑和 Open Graph，保证页面上各处信息一致。校验用 Schema.org 官方的验证工具跑一遍再上线，别信自己手写的 JSON 没毛病——我们第一次上线时 dependencies 少了个中括号，愣是三天后才被抓出来。

版本怎么管：URL 带版本，老版本 301

手册是会改版的。2.1 版的维保周期跟 2.3 版不一样，这种内容 AI 引用了旧版是要出安全事故的。我们的规则简单粗暴：

• URL 永远带版本：/docs/ktr-120/2.3/maintenance，无版本的路径 301 到当前版。
• 非当前版本页加 noindex，JSON-LD 里照常输出但 sitemap 不收录。
• 版本页头部放变更摘要，AI 爬虫拿到的正文第一屏就是「本版改了什么」。

周经理原话：「以前客户拿 2.1 的手册来投诉，我们售后都不知道他看的是哪版。现在 URL 一看就知道。」这算是顺带把售后的老毛病也治了。

底层机制：AI 引擎拿到这些字段后干了什么

原理这一节讲讲我自己的理解，不一定对，但跟观测结果对得上。

AI 搜索的检索链路大概是这样：爬虫抓页 → 抽取正文与结构化数据 → 切块并向量化 → 用户提问时先粗排召回、再按「问题-受众-粒度」匹配精排。TechArticle 的字段其实在两个环节起作用。

切块环节，articleSection 的锚点让切块器有天然的分界线。没有它，切块只能按 token 数硬切，「更换滤芯」的步骤三可能跟步骤七落在同一块里，AI 引用出来就是一锅粥。有锚点切块，每块自成一个完整操作单元，引用时可以整块搬走。

精排环节，proficiencyLevel 和 dependencies 相当于给内容打了「受众标签」和「上下文标签」。用户问「空压机报警 E03 怎么处理」，这是个新手问法，精排会压低 Expert 级文档的权重；问「E03 报警下做绝缘测试的合规流程」，就轮到 Expert 级上。GEO 圈里天天说「内容要可引用」，落到工程上，可引用就是切块粒度对 + 受众标签对，没有更多秘密。

还有一层常被忽略：AI 引擎对自相矛盾的内容（同站两个版本说法不一）会整体降权。版本管理那套规则不只是给用户看的，更是给 AI 看的一致性声明。

上线两个月的观察数据

口径先说死：以下全部是我们自建监测口径——每天固定二十个典型客户问题，对三家主流 AI 搜索产品手工提问，记录是否引用 docs 子域、引用到哪一节。不是任何第三方统计，样本小，看趋势，别抠单日数字。

另外有个意外收获：传统搜索引擎那边，文档页的自然搜索进站比 PDF 下载页翻了三倍不止。结构化这一套对传统 SEO 也是顺手的红利，不只是给 GEO 做的。

还没解决的问题

别以为这是一篇成功学。三个坑现在还开着：

1. Word 转 Markdown 的表格还原还是半手工，复杂管网图转出来直接废，这部分内容暂时保留 PDF 双轨。
2. AI 引用没有回传通知，我们只能靠手工监测猜。哪天有引擎愿意做引用上报的开放接口，这行当会好干很多。
3. 多语言手册的 proficiencyLevel 翻译口径还没统一，英文站目前沿用的还是中文五档硬翻，效果未验证。

文档中心这个方向，我的判断是制造业 B2B 迟早都得走：客户问 AI 的比例只会涨，PDF 附件模式的占比只会跌。早改早受益，晚改就是看着别家被引用。

参考与延伸

• schema.org TechArticle 类型定义
• Google 搜索中心：结构化数据标记指南
• web.dev：结构化数据与搜索体验
• MDN：JSON-LD 与 SEO 实践

GEO · AI搜索 · TechArticle · proficiencyLevel · JSON-LD · Schema.org · 设备手册数字化