Front-End-Checklist 中 ai-content 规则详解：如何审计与精炼 AI 生成内容

Front-End-Checklist 将「审计和精炼 AI 生成的内容」定义为一条独立的 SEO 规则（seo/content 子分类，优先级 medium，难度 intermediate，预计耗时 10 分钟）。本文基于该仓库中这条规则的完整参考文档 references/rule.md，完整继承其检查要点、代码示例、例外条款与验证清单，并结合仓库内的规则源文件 ai-content.mdx 与技能入口 SKILL.md，说明如何在实际站点中落地这条规则：识别「模型默认生成」的低原创度内容，补上人类专家信号，并给出一套可自动、可人工复验的验证流程。

一、规则定位：它审计什么，不审计什么

这条规则的官方描述是：「检测并审阅看起来主要是 AI 生成的内容，以确保其质量」（Detects and reviews content that appears to be primarily AI-generated to ensure quality）。它的核心立场可以从三个位置交叉印证：

• 规则参考文档开头即声明：AI 工具可以辅助写作，但最终产出仍须满足 Google 的 Search Essentials 要求，并提供 高质量内容 所期望的深度、真正对读者有帮助。
• 规则源文件 ai-content.mdx 的 frontmatter 中 whyItMatters 字段写道：「搜索引擎优先提供有用、可靠、以人为本的内容；未经编辑的 AI 内容往往缺乏高排名所需的深度和准确性」。
• 技能入口 SKILL.md 的 aiContext 字段给出了执行边界：「在审计与 AI 生成内容相关的元数据、可抓取性、结构化数据或可索引性时使用；应验证渲染后的 HTML 和 HTTP 响应，而不是仅依赖源文件」。

从源码结构看，这条规则的关键设计是验证对象是最终面向搜索的输出（rendered HTML + HTTP 响应头 + 元数据 + 结构化数据），而不是源文件本身。这意味着即使 .mdx/模板源码看起来没有问题，也必须以页面实际渲染结果为判定依据——这一点与仓库中其他 SEO 规则（如 quality.mdx 强调的「对每个页面应用 E-E-A-T」）一脉相承。

需要明确的是：这条规则并不要求禁止 AI 辅助写作。文档在「Exceptions」一节明确指出「AI 辅助起草本身不是失败；应标记的是无依据的断言、缺失的编辑审校或低原创度产出」。

二、核心审查要点：Quick Reference 与四段式提示词

技能入口 SKILL.md 将规则压缩为 Quick Reference 三条，规则源文件 ai-content.mdx 的 tldr 字段与之完全一致，可直接作为审计检查单：

1. 审阅 AI 生成内容的准确性、独特价值与类人语气（Review AI-generated content for accuracy, unique value, and human-like voice）；
2. 确认内容不是对现有排名靠前文章的简单改写（Ensure content isn't just a rewrite of existing top-ranking articles）；
3. 核实所有事实性断言，并包含原创研究或独到见解（Verify all factual claims and include original research or insights）。

规则源文件的 prompts 字段（ai-content.mdx）进一步把这组要点展开为面向执行者的四段式提示词，这也是本仓库「规则即提示词」的通用模式：

• check（检查）：审阅内容是否提供了 AI 模型默认无法生成的独特价值。
• fix（修复）：重写 AI 生成段落，纳入原创研究、个人经验和独特的品牌声音。
• explain（解释）：说明为什么 AI 生成内容需要人类监督才能满足 SEO 质量标准和用户预期。
• codeReview（代码审查）：审查与该规则相关的元数据生成、渲染 HTML、结构化数据和响应头；明确指出哪个路由或模板的搜索可见输出违反了规则，并描述如何验证最终页面输出。

codeReview 这一条把「内容审查」落到了工程层面：当某条动态路由或模板批量产出「模型味」文案时，问题定位到具体的路由/模板文件，并给出验证最终页面输出的方法，而不是停留在「文章写得不好」的模糊结论上。

三、代码示例：用元数据与署名传递人类专家信号

参考文档 references/rule.md 给出的判断是：不存在能直接「用代码检测 AI」的手段，但可以在元数据和署名中显式传递人类参与和专业知识信号。文档给出的完整 HTML 示例如下：

<article>
  <header>
    <h1>Advanced TypeScript Patterns</h1>
    <div class="meta">
      <span>By Jane Smith, Senior Engineer</span>
      <span>Fact-checked on October 20, 2023</span>
    </div>
  </header>

  <p>In this article, we'll explore patterns I've used in production at ScaleTech...</p>
</article>

这个示例传递了三个可落地的信号，可以在自己的内容站点中直接套用：

信号	示例中的体现	作用
具名作者 + 资历	By Jane Smith, Senior Engineer	展示 E-E-A-T 中的 Experience/Expertise，与仓库 quality.mdx 规则「具名作者 + 相关资质」的要求对应
事实核查时间	Fact-checked on October 20, 2023	表明有人类编辑介入并做过核查，同时兼作新鲜度信号（对应 freshness.mdx）
第一手经验表述	正文用「我在 ScaleTech 生产环境中使用的模式」而非模型腔	区分「人类撰写的原创经验」与「模型默认泛化输出」

四、Why It Matters：四个维度的质量风险

文档的「Why It Matters」一节从四个维度论证了人工审计的必要性，完整继承如下：

• 质量标准：Google 关于「创建有用、可靠、以人为本的内容」的指南，针对的正是不增加原创见解的低价值自动化内容。
• 准确性：AI 会「幻觉」出事实；对 YMYL 内容（Your Money or Your Life，涉及健康、财务等重要决策的内容），错误的建议可能造成实际伤害，因此人工验证是必需的。
• 独特性：防止你的站点变成「使用相同 AI 提示词的其他网站的翻版」（carbon copy）。
• 用户体验：经过人工编辑的内容通常更具吸引力、更细腻，也更擅长解决具体的用户问题。

文档还给出了一条实用的判断准则（references/rule.md）：如果草稿读起来泛泛而谈、缺乏支撑、或过于接近模型默认输出，应在决定是否发布前，将其与「薄内容风险」（thin-content risk）一并审阅。这条准则与仓库中的 word-count.mdx 规则形成呼应——篇幅薄 + 无原创信号，是这条规则最常见的失败组合。

五、Exceptions：三类不应误伤的情形

参考文档的「Exceptions」一节划定了三个例外边界，执行审计时需要逐条对照，避免把规则当成「禁止 AI 写作」的教条（references/rule.md）：

1. 必要的工具页/合规页可以有意识地简短。例如隐私政策、服务条款类页面不应套用排名导向内容的编辑深度标准；
2. AI 辅助起草本身不是失败项。审计对象应聚焦于：无依据的断言（unsupported claims）、缺失的编辑审校（missing editorial review）、低原创度产出（low-originality output）；
3. 优先级排序：当一个页面同时存在「信任信号问题」和「抓取/索引问题」时，应先让页面具备参与排名的资格（解决抓取与索引），然后再改善内容质量信号。

六、Standards 与 Verification：验收口径

Standards：以什么为判定标准

文档的「Standards」一节给出三条验收口径（references/rule.md）：

• 以文档中引用的参考资料作为最终搜索可见 HTML、元数据和抓取行为的标准；
• 在认定规则满足之前，先对照 Google Search Central 的 Search Essentials 检查实现；
• 在认定规则满足之前，先对照 Google Search Central 文档检查实现。

规则源文件 ai-content.mdx 的 sources 字段把这两条标准落到了具体出处上：Google Search Central: Search Essentials（authority: primary）与 Google Search Central documentation（authority: primary），并在 resources 字段列出了 Google Search Console 作为配套工具。也就是说，本仓库将「外部标准」结构化进了规则元数据，执行者可以按字段追溯权威来源。

Automated Checks：自动化检查

• 检查渲染后的 HTML 和 HTTP 响应头，确认预期的元数据或可抓取性信号存在（对应 aiContext 中「验证渲染 HTML 与 HTTP 响应，而非只依赖源文件」的要求）；
• 对受影响的 URL 使用 Google Search Console 或同等工具进行测试（如适用）；
• 部署后对一组有代表性的页面重新抓取。

Manual Checks：人工检查

• 确认变更没有产生相互冲突的 canonical-url、robots 或结构化数据信号——这与仓库中 canonical-url、robots-txt、json-ld-valid 等 SEO 规则构成联动，内容信号必须与索引信号保持一致。

七、相关规则与仓库内的规则组织方式

规则源文件的 relatedRules 字段（ai-content.mdx）声明了四条同属 seo/content 领域、通常被一起审阅的规则：word-count、freshness、citations 与 article-links。仓库内可直接对照阅读 word-count.mdx、freshness.mdx、citations.mdx。结合本文的规则逻辑，可以推断出一条完整的内容质量审阅链路：篇幅是否足够（word-count）→ 是否含原创引用与研究（citations）→ 是否保持更新（freshness）→ 是否有 AI 默认生成的低原创风险（ai-content）→ 整体 E-E-A-T 与意图满足度（quality）。

从源码结构看，这条规则在仓库中以「三层文件」组织，体现了 Front-End-Checklist「面向人与 Agent 双受众」的定位：

层级	文件	作用
规则源	ai-content.mdx	结构化 frontmatter（优先级、tldr、prompts、sources、relatedRules）+ 规则正文，是内容与审计的数据源
Agent 技能	SKILL.md	面向 AI Agent 的精简入口：Quick Reference、Check/Fix/Explain/Code Review 四段式操作指引
完整参考	references/rule.md	本文所依据的完整参考文档，含代码示例、例外、标准与验证清单

此外，仓库根目录 README.md 的 SEO 检查清单中也收录了该条目（Audit and refine AI-generated content，标记为 Medium 优先级），与规则源文件中的 priority: medium 一致，保证文档间口径统一。

八、落地清单

把上面的规则浓缩为一组可执行动作：

1. 盘点：列出站点中由 AI 工具参与生成的内容页，标记其模板或路由；
2. 审校：逐条核对 Quick Reference 三点——准确性、独特价值、类人语气；把「接近模型默认输出」的段落与薄内容风险一并处理；
3. 加注信号：在元数据与署名中补上具名作者、资质与事实核查时间（套用第三节的 HTML 模式）；
4. 排除误伤：对照 Exceptions 三条，工具/合规页豁免深度标准，AI 辅助本身不作为失败项；
5. 验证：按 Automated Checks 检查渲染 HTML、响应头与 Search Console 表现，部署后重抓代表性页面集；再按 Manual Checks 确认 canonical、robots、结构化数据无冲突信号。

完成以上步骤后，这条 medium 优先级的规则即可在约 10 分钟的审阅周期内闭环：既保留 AI 辅助写作的效率，又确保最终面向搜索的输出满足 Search Essentials 的质量要求。