Schema 实施

1. 部署阶梯：先做什么，后做什么

Schema.org 定义了几百个类型，但面向 AI 搜索部署时，大约只需用到其中六个。实施顺序比数量更重要，因为各级带来的回报相差很大。Organization、Person 和 sameAs 声明你是谁，这些身份信息还可与外部知识图谱核对；其余类型说明这一页是什么，而合格的解析器通常已经能从 HTML 中判断页面类型。按级别依次实施，做到不再产生回报的一级即可停止。

级别	要部署什么	为什么排在这个位置	工作量
第 0 级：实体主干	Organization、Person、sameAs、@id	只有这一类标记声明身份，并且可与外部知识图谱核对	全站一次
第 1 级：页面类型声明	Article／NewsArticle、WebSite、BreadcrumbList、author 关联	以机器可读的方式说明页面类型、作者、日期及其在站内的位置，消除解析歧义	每套模板一次
第 2 级：素材与答案形态	ImageObject、VideoObject、FAQPage、HowTo、speakable	有条件才做：页面上确实存在这个素材或这种形态时才加	每类页面一次
第 3 级：垂直类型	Product、Recipe、Event、LocalBusiness	这类标记服务于电商和 SERP 功能，而不是 AI 检索；应按功能需要实施，不应以增加引用为目的	不在本流程内

在编写第一行 JSON 之前，应先明确预期，因为这项工作的回报上限并不高。Ahrefs 追踪了 2025 年 8 月至 2026 年 3 月新增 JSON-LD 的 1885 个页面，并以约 4000 个条件相近的页面为对照，采用双重差分分析。结果显示，AI Overviews 的引用量变化为 −4.6%，AI Mode 为 +2.4%，ChatGPT 为 +2.2%，后两项在统计上均与零没有区别。他们的结论是：「Adding schema produced no major uplift in citations on any platform.」（加 schema 在任何平台上都没有带来明显的引用提升，Ahrefs，2026）Google 现行指引也得出了相同结论，并把过度看重标记列为常见误区：「Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add.」（结构化数据对生成式 AI 搜索不是必需的，也没有什么专门要加的 schema.org 标记，AI optimization guide）

这并不表示部署标记没有意义，而是说明它的作用范围十分明确。标记能提高解析的可靠性，也能帮助机器识别对应实体；现在建立这些信息成本很低，事后补充却很昂贵。但标记不会增加页面在答案中的出现机会。还必须明确另一项限制，因为下面这组数字经常被误用：实践者常引用的 GEO 基准（Aggarwal 等人，KDD ‘24，arXiv:2311.09735 · 论文摘要）测试的是内容实质与结构层面的改写，例如补充引用、统计数据和引述，并未把 schema 标记作为测试变量。因此，不能用这组数字为一轮标记改造提供依据。

2. 开始部署前：四个决定

下面四项决定会影响后续每一步。交付层一旦选错，即使标记完全正确，爬虫也无法获取。

决策	选项	经验法则
范围	一套模板／某一类页面／整站	按模板部署，不要按页面；手写单页 JSON-LD 最容易造成内容偏离
交付层	构建期／服务端渲染／CMS 插件／标签管理器／前端 JS	在生成可见 HTML 的环节输出（§6）；只通过标签管理器注入是最常见的失误
身份来源	你打算把哪些外部 URL 写进 sameAs	写标记之前先把这份名单定下来：它是一句关于身份的事实声明，不是一项配置（§3.3）
唯一事实源	由页面数据生成／手写／插件默认值	用渲染页面的同一份数据生成；手写的块迟早会和页面对不上

开始前先把以下资料备齐：一次不执行 JS 的抓取所返回的页面 HTML；机构官方账号与注册标识的权威清单；一份作者名册，其中每位作者的身份都应真实可查；以及一份模板清单，写明现有布局及各布局可用的数据。

适合实施的时机：新站或新模板上线；CMS 或框架迁移；机构实体发生变化（改名、合并、品牌重塑）；署名方式发生变化（例如开始为文章添加作者）；或者 GEO 审计 发现标记缺失、无效或与页面不一致。如果站点上的标记并非由你部署，来源也不明确，应先完成一次清点，见 Schema 审计。

3. 第 0 级：实体主干

这一级能带来实际回报，值得优先投入精力。

3.1 Organization：站点级的身份块

全站输出一个块，配一个稳定的 @id，让其他所有节点都指向它，而不是各自再生成一份。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Co",
  "legalName": "Example Company Ltd.",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/assets/logo.png",
    "width": 512,
    "height": 512
  },
  "description": "Short factual description matching the About page.",
  "foundingDate": "2019-03-01",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.wikidata.org/wiki/Q000000",
    "https://www.linkedin.com/company/example-co",
    "https://github.com/example-co"
  ]
}

Google 的 Organization 文档明确说明，这里没有任何必填项：「There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.」（没有必填属性，建议把与你这家机构相关的属性尽量补全，Organization structured data）如果现有资料中列有一份「必填字段」清单，那只是资料编写者自行设定的要求，并非 Google 的规定。各字段实际声明的内容如下：

字段	它声明了什么	不写的代价
@id	一个稳定标识，本页和其他所有页面都能指向它	每个页面各自生成一个互不相干的机构节点
name／legalName	对外的商号，以及注册的法定名称	只有商号，和工商登记信息对不上
url	这个实体的官方主页	这个实体没有一个明确的主域名
logo	与这个实体关联的图片	无法控制知识面板或卡片使用哪张图片
sameAs	「这个实体就是这些 URL 上的那一个」	与任何外部身份都没有显式连接（§3.3）
iso6523Code／naics	注册与行业标识	少了这两个属性，而 Google 明说过后台是用它们来区分机构的

@id 有一处最容易被误解，值得单独讲清：它是一个标识符，不要求是一个能打开的页面。把它写成真实页面上的一个 URL 片段（https://example.com/#organization）没有额外成本，查看源码时便于排查，也能避开 §8 里那种 @id 冲突。

3.2 Person：让作者成为可被识别的身份

写法和上面相同，通过引用连到机构，而不是把机构信息再抄一遍。

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/authors/jordan-lee#person",
  "name": "Jordan Lee",
  "url": "https://example.com/authors/jordan-lee",
  "jobTitle": "Principal Engineer",
  "worksFor": { "@id": "https://example.com/#organization" },
  "knowsAbout": ["structured data", "search infrastructure"],
  "sameAs": [
    "https://www.wikidata.org/wiki/Q000001",
    "https://orcid.org/0000-0000-0000-0000",
    "https://github.com/jordanlee"
  ]
}

关键判断应在编写代码之前完成。如果某个署名在公开网络上没有任何可查信息，却仍为它编写 Person 块，声明的身份就无法得到外部佐证。这样只是增加了一个节点，引擎却无法将它与任何公开身份对应起来。正确做法只有两种：作者确实拥有可查的公开身份，并通过 sameAs 逐条列出；或者将文章署到 Organization 名下，并删除 Person 块。虚构作者无法通过外部佐证，与伪造署名性质相同，都会损害信任：信任信号为何这样起作用，见 E-E-A-T；身份匹配的具体判定方式见 实体识别。

3.3 挑选 sameAs 的对象：这是一句事实声明

插件无法代替人工完成这项工作，因为 sameAs 不是普通配置值。每一条都在声明该实体就是对应 URL 所表示的实体，而这种身份关系可以核验。

sameAs 的对象	它带来什么	准入门槛
Wikidata 条目	一个通用标识，很多实体匹配流程都在用它	条目必须已经存在，绝不能填一个占位链接
Wikipedia 条目	如果已有条目，它能提供最有力的佐证	受收录门槛限制，是否能够建立条目并非由你决定
官网、文档站、招聘页	确认该域名的运营主体	必须属于同一法律主体，不能是关联品牌
已认证的社交与职业账号	验证成本低，且覆盖范围广	账号应已认证且仍在更新；废弃账号只会增加噪声
注册与领域标识（Person 用 ORCID，机构用行业注册号）	本领域内认可的佐证	只在该领域确实通行时才写

这份名单应满足三项要求。每个对象都必须指向同一个实体，不能指向关联实体或母公司。仅凭主观判断添加、又无法核实的链接，比名单较短更糟：一旦与外部信息不符，后续仍需自行纠正。名单内容也不能与已经公开的外部信息相互矛盾。

需要准确判断文档赋予 sameAs 的作用，因为业内说法已经超出证据所能支持的范围。Google 的 Organization 页面只把它描述为*「指向另一个网站的 URL，那个网站上有关于你这家机构的补充信息页面」；同一页在说明哪些属性会「在后台用来把你这家机构和其他机构区分开」*时，列出的是 iso6523 和 naics，并不包括 sameAs。对于作者，Google 则明确说明，区分作者身份时会用到 sameAs（Article structured data）。因此，sameAs 用于 Person 有明确依据，用于 Organization 则属于合理推断，但 Google 从未明确作出这种表述。两种情形都建议添加，因为成本极低，而且它声明的是可核验的身份关系；如果需要申请预算，则应以 Google 明确点名的两个注册标识作为依据。

还应提前明确一项限制：sameAs 只能建立一条连接，不能凭空创建另一端的节点。如果你的机构在 Wikidata 上没有条目，无论添加多少 sameAs 都无法生成条目。Wikidata 的收录政策规定，条目必须满足以下三项条件之一：在维基媒体项目上有有效的站点链接；「指向一个清晰可辨的概念实体或实物实体，且能用严肃、公开可查的资料加以描述」；或者用于满足结构上的需要（Wikidata:Notability）。如何建立这个节点属于另一项工作，相关概念见 知识图谱存在度。

4. 第 1 级：页面类型声明与 @graph 接线

第 1 级需要说明页面是什么，以及作者与发布方是谁。Article（或 NewsArticle、TechArticle）最重要的有四个字段：headline、指向某个 Person @id 的 author、datePublished、dateModified。与 Organization 相同，Google 说明 Article 没有任何必填属性，所有属性都只是建议项（Article structured data）。

日期需要特别注意。Google 关于发布日期的指引要求：日期必须描述页面本身，而不是页面所述事件；不能使用未来时间；还必须与用户看到的日期一致。原文是*「Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values.」*（确保用户可见的日期与结构化数据里的日期一致，Article publication dates）如果 dateModified 直接使用构建时间戳，就会声明一次从未发生过的修改，并且每次构建都会造成一次与可见页面的矛盾。这种情况在静态站点配置中比多数团队预想的更常见，因为构建时间戳往往是默认值。

WebSite 用来关联站点级身份，可以和机构信息写在同一个块里。BreadcrumbList 声明页面在层级结构中的位置；如果站点结构本身十分扁平，只能勉强生成面包屑，就应跳过。这两项成本都很低，但单独来看并不关键。

要让这套结构易于维护，可以为每个页面设置一个 @graph，节点之间通过 @id 相互引用，不在各处重复内容：

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Co",
      "url": "https://example.com",
      "sameAs": ["https://www.wikidata.org/wiki/Q000000"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "Example Co",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/authors/jordan-lee#person",
      "name": "Jordan Lee",
      "url": "https://example.com/authors/jordan-lee"
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/deploying-json-ld#article",
      "headline": "Deploying JSON-LD at build time",
      "isPartOf": { "@id": "https://example.com/#website" },
      "author": { "@id": "https://example.com/authors/jordan-lee#person" },
      "publisher": { "@id": "https://example.com/#organization" },
      "datePublished": "2026-07-02T09:00:00+00:00",
      "dateModified": "2026-08-04T11:30:00+00:00",
      "mainEntityOfPage": { "@id": "https://example.com/blog/deploying-json-ld" }
    }
  ]
}

每个实体分别使用一个块也同样合规，Google 对两种写法一视同仁，生产环境中也有不少站点采用这种方式。默认推荐 @graph，考虑的是维护成本，而不是正确性：实体主干在一套模板中只定义一次，文章节点通过引用关联它，身份发生变化时只需修改一处。

将这套结构绑定到模板，才能避免内容逐渐偏离：

模板	它输出哪些节点	数据从哪来
基础布局（所有页面）	Organization、WebSite	站点配置，一个文件，一个来源
文章／博文布局	Article、Person 引用、BreadcrumbList	页面 frontmatter：标题、作者标识、日期
作者页	Person（完整节点）	作者档案：姓名、职务、各账号 URL
商品／垂直布局	第 3 级类型	商品数据，不在本流程内

5. 第 2 级：素材与答案形态标记

第 2 级全部是有条件的：页面上确实有对应的素材或形态，才加这一段标记。

素材类：对于图片、视频和音频，真正起作用的是承载文字的字段，因为答案引擎最终传给模型的是文字，而不是像素。

素材	标记	真正起作用的字段	必须与什么一致
图片	ImageObject	caption、description	页面上可见的图注与周边正文
视频	VideoObject	transcript、description	页面上的文字稿，如果有的话
音频／播客	AudioObject、PodcastEpisode	transcript、description	已发布的节目说明或文字稿

装饰性图片不需要 ImageObject，给它加标记只会多出一处要校验的地方，却什么也没有声明。引擎在非文字素材上究竟读什么，见 多模态信号。

答案形态类：FAQPage 和 HowTo 声明的结构，解析器原本就能识别；对 Google 而言，这两类标记现在也不再带来回报。FAQ 富结果自 2026 年 5 月 7 日起不再出现在 Google 搜索结果中；Google 当月发布弃用通知，并在 2026 年 6 月删除整份 FAQ 富结果文档，同时下线 Search Console 报告和 Rich Results Test 的相关支持（Search Central 变更日志 · Search Engine Land）。HowTo 富结果移除得更早，时间是 2023 年（Google，2023）。

部署结论很明确：已有的 FAQPage 标记仍然符合 Schema.org 规范，可以保留，无须急于清理。但现在新增标记已无法从 Google 获得任何回报，也不会使对应问答更容易被引用；能否被引用取决于可见正文如何撰写，见 可引用性。只有当页面确实包含这组问答或这套步骤，并且标记直接由这些内容生成时，才应添加这两个类型；不得为了标记而虚构页面原本不存在的结构。

speakable 仍在测试阶段，只覆盖英文出版方和美国的 Google Home 用户（Google）。可以了解这项功能，但不应据此制定任何计划。

这一级有几项明确的禁忌：编造无人会问的 FAQ 条目；给没有操作步骤的页面添加 HowTo；给装饰性图片添加 ImageObject；把 speakable 当作语音搜索策略。

6. 交付：输出到每个爬虫都能看见的地方

如果标记由前端 JavaScript 注入，除了 Googlebot，几乎没有爬虫能够看到。Googlebot 会执行渲染：「Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.」（资源允许时，一个无头 Chromium 会渲染页面并执行 JavaScript，JavaScript SEO basics）但根据目前的观察，GPTBot、ClaudeBot、PerplexityBot 都不会渲染。因此，如果标记只通过标签管理器注入，原本希望覆盖的这批爬虫反而看不到。

交付层	标记怎么输出	不渲染 JS 的爬虫看得见吗	内容偏离风险
构建期／静态生成	构建时按页面数据写进 HTML	看得见	低，与页面同源
服务端渲染／中间件	随 HTML 一起按请求输出	看得见	低
CMS 插件／模板片段	由 CMS 在服务端渲染	如果由服务端渲染，就能看见	中，插件默认值容易在无人察觉时偏离
标签管理器	页面加载后由前端注入	看不见	高，既不可见也不进版本管理
应用包里的前端 JS	水合之后写进 DOM	看不见	高

确认标记是否已经交付只需一条命令，但插件式部署最容易让人跳过这一步：

# 统计不渲染 JS 的爬虫实际能拿到几个 JSON-LD 块
curl -sL https://example.com/your-page | grep -c 'application/ld+json'

# 把每个块打印出来，确认都能解析成合法 JSON，全程不执行 JS
curl -sL https://example.com/your-page \
  | python3 -c "import sys, re, json; \
      [print(json.dumps(json.loads(b), indent=2)) \
       for b in re.findall(r'<script type=\"application/ld\+json\">(.*?)</script>', \
                           sys.stdin.read(), re.S)]"

如果结果是 0，后续所有步骤都失去前提。服务端与前端渲染之间更完整的取舍，见 面向 AI 爬虫的 SSR；各爬虫的渲染行为见 AI 爬虫。

7. 校验：发布前的四道关

四项检查必须按顺序完成。每项检查能证明的内容，其他三项都无法代替；因此，只完成其中一项就认定校验结束，是最常见的失误。

检查	它能证明	它不能证明
Schema Markup Validator	词汇符合 Schema.org 规范	Google 会不会据此展示某项功能
Rich Results Test	页面有资格进入 Google 某一项具体的富结果功能	标记在技术上是否正确
不执行 JS 的 curl 抓取（§6）	标记确实已随响应交付给不渲染 JS 的爬虫	这个块是否有效
Search Console 富结果报告	全站范围内随时间变化的状态，且要等索引之后	一小时前刚发布的页面当前处于什么状态

两个校验器经常被误认为可以相互替代，实际并非如此：一个判断内容是否符合 Schema.org 格式规范，另一个判断 Google 是否会展示某项功能。Search Console 用于持续监测，不是发布前检查。它呈现的是*「structured data (and its validity) found on your site」*（站点上找到的结构化数据及其有效性），而且按条目而非页面计数。因此，一处模板缺陷可能表现为成百上千条无效条目，实际根源却只有一个。

人工逐项比对是第四项检查，也是任何工具都无法代替的一项。将输出的块与渲染后的页面并排对照，逐项确认标记声明的每个事实都确实出现在页面上，包括作者名、日期、价格、评分和机构简介。这项检查能发现真正代价高昂的失误（§8），每套模板只需两分钟。

不要采信那些不公开算法、只给出 0 到 100 分的所谓 schema 评分。不说明方法的数字只是道听途说，不能视为测量结果；这与 可引用性审计 对可引用性评分的判断相同。最终应交付的是上述四项检查逐项通过或不通过的结果。

表中仍有两项缺口，可以用第五个工具补上：免费的 Schema 标记检测工具会通过一次不执行 JavaScript 的抓取确认交付情况，并检查页内实体图的关联是否完整。这正是两个验证器都不检查的问题；工具会逐项给出证据，不提供综合评分。

8. 反模式与回滚原则

下面列出的都是部署层面的失误；若问题在于词汇选择，可参考 面向 AI 的 Schema.org。

反模式	看上去像	为什么会出问题
标记声明的事实，可见页面上找不到	完整、周全的标记	会触发 Google 的结构化数据人工处罚；实时抓取的 AI 会把标记与可见内容都当作文字读取，从而得到两个相互矛盾的事实
编造的 Organization 或 Person	一个已被识别的实体	无法得到外部佐证：站外没有任何来源能确认所声明的身份
只挂在标签管理器里	「schema 已经上线了」	对每一个不渲染 JS 的 AI 爬虫都不可见（§6）
手写的单页块	精确、可控	页面内容首次改动后就会与标记不一致，而且不会有任何环节发现
dateModified 接到构建时间戳	内容很新	声明了一次并未发生的修改，而且和页面上的可见日期矛盾
跨模板出现重复或冲突的 @id	实体关联十分完整	下游工具会合并毫无关系的实体，而且不会报错提醒你
插件默认值没人复核	不费力就有的覆盖率	输出错误的机构信息、编造的 FAQ 条目，或者一个 404 的 logo
页面上每个元素都标	做得周全	只增加校验噪声和对不上的风险，没有任何好处

@id 冲突需要单独检查，因为整条工具链都不会为此报错：

// 有问题的写法：同一个 @id 被两个不同的实体占用
[
  { "@type": "Organization", "@id": "https://example.com/#id", "name": "Example Co" },
  { "@type": "WebSite",      "@id": "https://example.com/#id", "url": "https://example.com" }
]

// 修好之后：每个实体一个 @id，后者引用前者
[
  { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Co" },
  { "@type": "WebSite",      "@id": "https://example.com/#website",
    "url": "https://example.com",
    "publisher": { "@id": "https://example.com/#organization" } }
]

上述失误中，只有标记与页面不一致这一项，Google 明文规定了处罚。其结构化数据指引清楚说明了后果及其边界：「A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search.」（结构化数据的人工处罚意味着页面失去富结果的展示资格，但不影响它在网页搜索中的排名，General Structured Data Guidelines）实时抓取的引擎遇到同一处矛盾时，产生的结果不同，也更加直接，因为它们并未把这段内容作为结构化标记解析。Mark Williams-Cook 在 2026 年 5 月演示了这套机制：他制作了一个虚构公司的页面，地址只写在一段故意写错的 JSON-LD 中，@context 和类型也都是编造的，结果 ChatGPT 和 Perplexity 仍然输出了该地址。他的解读是：「they were not parsing it as schema. They were doing what LLMs always do: reading the visible-ish text of the page, picking out the bit that looked like an address, and presenting it.」（它们并没有把它当 schema 解析，只是按照 LLM 一贯的方式，读取页面上大致可见的文字，选出看起来像地址的部分并加以呈现，Williams-Cook，2026）这与更早的受控测试结论一致：实时抓取的对话引擎不会把 JSON-LD 作为结构化数据取值（searchVIU，2025）。另一项独立观察也得出相同结果，即使 schema 无效，引擎仍会输出其中的值（Search Engine Roundtable，观察）。

结论很明确：对于实时抓取的模型，JSON-LD 只是一段以特殊标点组织的页面文字。其中任何与可见页面矛盾的内容，都会形成同一事实的另一个版本。

回滚原则：无效的、或者和内容对不上的标记，比根本不加更糟。当一个块怎么都没法和页面对齐时，该删掉的是这个块，不是页面上的那个事实。

9. 上线清单与复验节奏

这份清单可以直接使用。

• 第 0 级已全站输出，且来自同一个事实源
• 每个 @id 都唯一、稳定，靠引用而不是重复
• sameAs 名单已逐条核实，没有仅凭主观判断添加或用作占位的链接
• 作者要么身份可查，要么文章署到 Organization 名下
• 第 1 级已按模板接好，dateModified 反映的是真实的修改时间
• 第 2 级只出现在确实有该素材或该形态的页面上
• 不执行 JS 的 curl 抓取能取到每一个该有的块
• Schema Markup Validator 无报错
• 针对你要争取的功能，Rich Results Test 无报错
• 每套模板都做过人工逐项比对
• Search Console 富结果报告已纳入监测

复验应由事件触发，而不是按日历固定安排。触发事件包括模板或主题改动、CMS 或插件升级、机构实体变化（改名、品牌重塑）、作者名册变动，以及框架或渲染方式迁移。其余情况可通过季度抽查覆盖，重点检查价值最高的几套模板。

对于任何包含构建步骤的站点，都值得增加一项简单检查：在 CI 中为每套模板选择一个代表性 URL，验证必要的 @type 是否齐全、每个块能否正常解析。仅这一项检查，就能发现插件升级后实体主干在无人察觉时消失的情况，也就是 §8 所述整条工具链都不会报错的内容偏离。

10. 延伸阅读

• 概念层：面向 AI 的 Schema.org 说明各类型向引擎声明的内容，以及标记为什么不是提升引用的杠杆；JSON-LD 说明格式、关键字、放置规则与出错方式
• 实体层：实体识别 说明身份声明如何被判定；知识图谱存在度 说明 sameAs 所指节点的含义，以及如何建立该节点
• 相邻流程：Schema 审计 用于清点已经上线的标记；GEO 审计 中有关结构与机器可读性的检查，针对的正是这里部署的内容
• 交付：面向 AI 爬虫的 SSR 与 AI 爬虫 说明哪些引擎会执行 JavaScript
• 素材：多模态信号 说明引擎如何读取图片、视频和音频
• 投入重点：可引用性 与 面向 AI 引用的写作；真正决定页面能否进入答案的，是段落本身的写法