过了 50 篇文章，Astro 内容站会有看不见的漂移——跨语种 slug 重复、translationKey 对不上、改名页留下的死内链、draft 文件悄悄上线。手动读每个文件不是答案。这篇讲怎么用 AI 把你的 frontmatter 契约写成脚本、按严重度分批修、把脚本接进 prebuild 让漂移再也回不来。
这篇讲什么
可复用的 Astro 内容站 AI 审计工作流——抓坏 slug、缺翻译、死内链、draft 泄漏、配置漂移。产出不只是问题列表，是一个每次 build 都跑的脚本 + 按严重度排好的修复计划。
本文涉及的工具 / 概念：
- Astro: 面向内容站的现代静态 / 混合渲染前端框架。内容集合在
src/content/，通常是带 YAML frontmatter 的 MDX。 - Frontmatter 契约: 每个内容文件必须有的字段（urlSlug、translationKey、lang、draft 等）。多数 Astro 审计从把它形式化开始。
- 漂移: 新加的内容慢慢违反你 6 个月前定的契约。没强制就必然发生。
这篇适合谁看
Indie 开发者 / 内容工程师，Astro 内容站超过 50 篇——尤其是双语 / 多 locale 站，翻译配对会引入额外不变量需要验证。
什么时候适合用
上线前。重构后。季度。从别的平台迁内容后。任何要验证”加内容没把已有的弄坏”的时候。文章级审计跑通后，把同一套打法上挪一层，对照 AI Category 页审计教程——Category 页是大多数团队忽视的面，安静地拖 SEO。
开始前准备
- 工作树干净。有些修复是批量改名，要能 revert。
- 选有文件访问的 AI：Claude Code / Codex（最好），或 Cursor agent 模式。纯聊天 AI 也行但复制粘贴成本真的很高。
- Build 命令在本地能跑（
npm run build）。审计最后要把脚本接进 prebuild，要有绿色基线。
具体步骤
- 发现形状。
find src/content -name "*.mdx" | wc -l确认数量。把文件清单作为上下文喂 agent：“这是我所有 MDX。” - 让 Claude Code / Codex：“随机读 5 篇 MDX，告诉我 frontmatter 契约——哪些字段必填、哪些可选、
lang/category/subcategory允许什么值。” - 复核契约。把 AI 标成可选但实际必填的字段收紧。
- 生成审计脚本。Prompt：
写 scripts/audit-content.mjs，遍历 src/content/**/*.mdx
并标出：
- 按上面契约缺必填字段
- 同 lang 内 urlSlug 重复
- translationKey 在一个 lang 有但另一个 lang 没有
- draft: true 文件（只 warn）
- 内链（/en/articles/... 或 /zh/articles/...）解析不到已有 urlSlug
输出：每行一条发现，前缀 SEVERITY（BLOCKER / WARN /
INFO），末尾按类别汇总计数。- 跑脚本，捕获输出（
node scripts/audit-content.mjs > audit.txt）。 - 把审计输出喂回 AI：“N 条发现，按根因分组，每组提最小修复。”
- 每个 blocker 组让 AI 写真实补丁（frontmatter 编辑、文件改名、链接重写）。小批量应用，每批后重跑脚本。
- 把脚本接进
package.json的prebuild——未来漂移在部署前就让 build 失败。
第一次实操怎么跑
- 跑审计但先不修。只读报告。
- 挑最常见的那条发现（通常是 translationKey 不匹配或 urlSlug 重复）。只修这一类，然后重跑。
- 确认计数恰好降了你修的那么多。没降说明脚本有 bug——先修脚本再修内容。
- 再处理下一类。迭代比一次全干好，因为每个修复都可能引入新发现。
完成后检查
- 脚本标的发现能用
grep手工验证吗？如果你 grep 了 slug 但脚本说的不成立，脚本有误报。 - 多次运行结果确定吗？结果顺序随机可以，结果数量随机就是 bug。
- 你故意种的一个已知坏案例（比如临时把已发布文章设
draft: true）脚本抓到了吗？没抓到说明规则没在检查你以为的东西。 - 跑得够快上
prebuild吗？1000 个文件 3 秒内正常；更久就是 I/O 低效。
怎么复用这套流程
scripts/audit-content.mjs入版本控制。别每次重生成——演进它。- 发现新漂移模式就增量加规则。脚本会随站的生命周期变强。
- 大批量加内容前（比如要加 50 篇之前）也跑一次，不只之后跑，让你从已知干净状态开始。
建议的操作流程
列 MDX → 发现 frontmatter 契约 → 生成审计脚本 → 跑 → AI 分组 + 提修复 → 小批量改 → 每批后重跑 → 接 prebuild。frontmatter 和 slug 收拾干净后，再叠一层按你的技术栈生成的 SEO checklist，让 render mode、hreflang、schema 这些项一起被检查。
容易踩的坑
- 人工逐文件读——漏，而且下季度跑不动。
- 一次改完——build 挂了说不清是哪条修的。小批量。
- 不接 prebuild——下月再漂移，因为没东西在防它。
- 让 AI 凭空写规则——给它 3-5 个已知坏文件；从真实案例长出来的规则更准。
- 把 WARN 当 BLOCKER——你永远发不了。诚实分流。
- 修完没 commit 就重跑脚本——未提交状态会让下一轮混乱。
FAQ
- 哪种 AI 最合适？: Claude Code / Codex 有直接文件访问。纯聊天 AI 也行但复制粘贴多，会侵蚀流程。
- 双语站？: 把每个 lang 当一次独立审计 + 末尾一次配对 key 审计（每个
/en的 translationKey 在/zh都有对应）。 - 非 MDX 内容？: 同流程，换 glob。JSON 内容文件、Astro markdown、YAML 数据文件，都受益于”契约 → 脚本”的做法。
- 多久跑一次？: 季度起步。任何大批量内容导入前。任何 content schema 重构后。
- 1000+ 文件审计脚本爆内存。: 流式读文件清单，不要一次全加载。或把审计按 category 分批跑。