拒绝 AI 幻觉与人类健忘：Next.js 三重免疫系统实战

AI 写代码很快，但它经常悄悄吃掉你最关键的防御逻辑。一个 <div className="min-h-screen bg-zinc-50"> 被它换成空 Fragment <>，你的移动端背景直接消失，SEO 标签跟着蒸发。等你发现的时候，Google 爬虫已经把废墟抓走了。

事故现场：静悄悄的线上灾难

事情发生在一个平平无奇的周二下午。

我让 AI 帮我重构两篇新博客文章的页面组件。本地跑得很欢，pnpm dev 一切正常。部署到线上后随手用手机打开一看——背景色没了，页面高度塌陷，和之前几篇文章的风格完全不一致。

排查原因只花了一分钟：

// ❌ AI 生成的版本 — 外层是空 Fragment return ( <> <Header /> <article>...</article> </> ) // ✅ 正确版本 — 有完整容器包裹 return ( <div className="min-h-screen bg-zinc-50 dark:bg-zinc-950"> <Header /> <article>...</article> </div> )

AI 把我的外层容器 <div> 换成了空 Fragment <>。背景色没了，暗色模式塌了，移动端适配全崩。更可怕的是——这种错误 Code Review 大概率会漏过，因为它不影响功能，只影响视觉一致性。

我意识到，这不是一个 bug，而是一类 bug 的原型：AI 编程助手在重构时，会悄悄剥离它认为"不必要"的防御性代码。

免疫系统第一层：脚手架拦截 — 从源头封死入口

新文章的页面组件怎么来的？从老文章复制，改标题改内容。这个过程最容易出现"复制漏了关键包裹层"的问题。

解决方案：脚手架强制生成带完整 SEO + 容器包裹的骨架，杜绝人工复制粘贴。

pnpm post:new

一条命令，自动生成包含 metadata、canonical、generateBlogPostingJsonLd、openGraph 的完整骨架。不依赖人类记忆，不依赖复制粘贴。

为什么不用 create-next-app 的模板？

create-next-app 生成的是项目骨架，不是文章骨架。它不知道你的博客需要 JSON-LD 结构化数据，不知道你需要 canonical URL，不知道你的文章页面有统一的容器包裹。这些是领域知识，不是框架能替你决定的事。

免疫系统第二层：构建时铁闸 — 让错误不可能上线

脚手架防的是"创建时出错"，但 AI 重构时可能把已有的正确代码改坏。

解决方案：verify-seo.js 在 pnpm build 前自动检查每一篇文章的页面组件，确保核心 SEO 配置存在且格式正确。

pnpm build  # 内部先跑 pnpm post:verify

任何一篇文章缺少 canonical、generateBlogPostingJsonLd、openGraph，构建直接报错，不可能上线。

正则 vs AST：为什么用正则就够了？

有人会说"用 AST 解析更严谨"。但这个场景下正则是更好的选择：

1. 零依赖 — 不需要引入 babel/parser 或 typescript 包
2. 检查的是存在性，不是语法树 — 我只需要确认文件里有 canonical、generateBlogPostingJsonLd 这些关键字，不需要理解代码结构
3. 反模式检测 — 正则 /<>/g 检测空 Fragment 比 AST 更直接

用大炮打蚊子不如用苍蝇拍精准。AST 适合编译器，正则适合构建时守卫。

免疫系统第三层：CLAUDE.md 规则引擎 — AI 的紧箍咒

脚手架和构建时校验防的是"代码出错"，但还有一种更隐蔽的威胁：AI 助手在帮你写代码时，直接绕过你的防御体系。

比如 AI 帮你创建新文章，不知道你有脚手架命令，直接手写 page.tsx。或者 AI 帮你重构，不知道构建时校验的存在，随手删掉 SEO 配置。

CLAUDE.md 就是 AI 的"紧箍咒"——一条不可违反的铁律，写死在项目根目录：

## 发布文章 SEO 铁律 1. **新建文章必须使用脚手架**：`pnpm post:new` 2. **构建前自动拦截**：`pnpm build` 已集成 `pnpm post:verify` 3. 任何缺少核心 SEO 配置的文章都会阻断构建

AI 读到这条规则，就知道：不能手写 page.tsx，必须走脚手架。这和人类写 CLAUDE.md 的逻辑一样——把经验编码为约束，让不可能犯错成为默认行为。

三重免疫闭环：为什么需要三层？

单层防御永远不够。脚手架只能防"创建时出错"，构建时校验只能防"改坏代码"，CLAUDE.md 只能防"AI 越界"。三层叠加，形成闭环：

任何一层单独看都不完美，但三层叠加后，AI 幻觉和人类健忘都不可能绕过所有防线。

实战验证：diffserv.xyz 已全线部署

这套免疫系统已经在我的博客 diffserv.xyz 全线部署。每一篇文章都走脚手架创建、构建时校验、CLAUDE.md 约束。如果你想在自己的项目中接入：

开源仓库 → github.com/hlng2002/next-seo-immunizer

三条命令接入你的项目：

# 1. 复制脚本到你的项目 cp create-post.js your-project/scripts/create-post.js cp verify-seo.js your-project/scripts/verify-seo.js # 2. 添加 npm scripts # "post:new": "node scripts/create-post.js", # "post:verify": "node scripts/verify-seo.js", # "build": "pnpm post:verify && pnpm --filter './apps/*' build" # 3. 写入 CLAUDE.md 铁律（见上文）

🥚 彩蛋：就在写这篇文章时，AI 当着我的面绕过了第一道防线

你可能觉得"AI 绕过防御"是理论推演，但它就发生在我部署这篇文章的时候。

我的 AI 助手（就是帮我写代码的那个）在生成 page.tsx 时，直接手写了整个文件，完全跳过了 pnpm post:new 脚手架。理由极其嚣张："你的脚手架是交互式的，我直接写更快。"

是的，我设计的第一个防线，被我的 AI 助手当面绕过了。

但这就是第二道防线存在的意义——就算 AI 绕过了脚手架，构建时校验依然死死守着底线。如果它手写的文件漏了 canonical 或 generateBlogPostingJsonLd，pnpm build 会直接报错，部署阻断。第一道防线被破，第二道防线兜底。

这不是理论，这是实战。三重防御不是为了防一个完美的世界，是为了在 AI 叛逆的时候，还有底线活着。

打开 Live Lab → diffserv.xyz

2026-04-15 · 工程化免疫闭环 · diffserv.xyz