📌 本篇核心目标：建立"改完就验"的协作习惯。掌握内容型知识库项目的三套检查清单设计方法，学会自动化测试与手动验证的搭配策略，以及如何把验证步骤嵌入 Claude 的工作流中。
规则写了，Claude 就一定遵守吗？
你按前四篇的方法，搭了一套完整的规则体系------CLAUDE.md 主文件、6 份 docs/ 文档、frontmatter 规范、schema 定义、构建链路说明。
这套体系已经比大多数项目强了。但你很快会发现一个现实：
规则再完善，Claude 也会犯错。
不是因为它"不听话"，而是因为：
-
某些规则它确实看了，但在具体执行时遗漏了某一步
-
任务复杂时，它专注于主逻辑，忽略了边缘检查
-
你的规则覆盖了 90% 的场景，但这次刚好遇到了那 10%
-
规则写的是"不要做 X"，但 Claude 做了一个它没意识到等价于 X 的操作
这是所有 AI 协作的常态。即使是人类开发者，代码审查、单元测试、CI/CD 也不是因为"不信任开发者"，而是因为"人会犯错，系统来兜底"。
所以你需要的不只是"告诉 Claude 规则"，还需要"改完之后有一套机制来确认它做对了"。
这就是验证机制的作用。
内容型项目的验证和代码项目有什么不同
在代码项目中，验证的核心手段是自动化测试------单元测试、集成测试、E2E 测试。写一个函数，跑一遍测试套件，绿了就行。
内容型知识库项目的验证要复杂得多，原因有三：
第一，很多问题不是"代码报错"，而是"数据不对"。
frontmatter 缺一个字段，构建可能不报错------但列表页上这篇文章的摘要就是空的。category 拼错一个字，构建也不报错------但这篇文章从分类页上"消失"了。这类问题，自动化测试很难覆盖。
第二，"看起来正常"不等于"真的正常"。
详情页能打开，不代表搜索索引收录了这篇文章。列表页展示了这篇文章，不代表分类聚合页也展示了。你需要检查多个页面、多个环节，才能确认一次改动没有造成连锁问题。
第三，改动的影响范围不直观。
改一行代码，你大概知道影响哪几个函数。但改一篇内容的 category 字段，你不一定能立刻想到它会影响：分类聚合页的内容列表、侧边栏的分类计数、搜索索引中该文章的分类标记、可能存在的 RSS 分类过滤。
这三个特点决定了：内容型项目的验证策略，不能照搬代码项目的做法。
你需要的是：自动化校验 + 手动检查清单的组合。
三套检查清单
这是本篇最核心的交付物。三套清单分别应对三种场景：内容变更、结构变更、发布上线。
清单一：内容变更后检查清单
触发场景：新增一篇内容、修改一篇内容的正文或 frontmatter 字段、删除一篇内容。
这是最高频的场景。每次内容层面的改动，都应该走这套清单。
go
## 内容变更后检查清单
### 自动化检查（如项目支持）
- [ ] 运行 `npm run content:validate`（校验 frontmatter 完整性）
- [ ] 运行 `npm run content:build`（确认内容索引生成正常）
- [ ] 运行 `npm run lint` 和 `npm run type-check`（如改动涉及代码）
### 手动检查
- [ ] 目标内容的详情页可正常打开
- [ ] 详情页的标题、摘要、日期显示正确
- [ ] 列表页中该内容出现且展示正常
- [ ] 分类聚合页中该内容出现在正确分类下
- [ ] 标签页中该内容出现在对应标签下（如适用）
- [ ] 搜索结果中可找到该内容（如项目有搜索功能）
### 如果是修改已有内容
- [ ] slug 未被修改（除非明确被要求）
- [ ] category 和 tags 使用的是已有名称
- [ ] 未新增未定义的 frontmatter 字段
### 如果是删除内容
- [ ] 确认无其他内容的 related_articles 引用了该 slug
- [ ] 确认无页面硬编码了该内容的链接
- [ ] 构建后无 404 页面这套清单的设计逻辑：先跑能自动化的，再人工看不能自动化的。自动化解决"结构对不对"，手动检查解决"效果对不对"。
清单二：结构变更后检查清单
触发场景：新增或修改 frontmatter 字段、修改内容解析逻辑、修改页面模板的数据消费方式、调整分类或标签体系、修改搜索索引生成逻辑。
结构变更比内容变更影响范围大得多。一次结构变更可能影响所有内容文件的处理方式。
go
## 结构变更后检查清单
### 类型和定义
- [ ] 类型定义已同步更新（如 types/content.ts）
- [ ] 新增/修改的字段在类型定义中有明确的类型标注
### 解析和构建
- [ ] 内容解析函数正常工作
- [ ] 构建脚本正常执行（npm run build 无报错）
- [ ] 内容索引生成正常（npm run content:build 无报错）
- [ ] 搜索索引包含正确的字段
### 页面消费
- [ ] 详情页正常渲染（抽查 3 篇不同类型的内容）
- [ ] 列表页正常展示
- [ ] 分类聚合页数据正确
- [ ] 标签聚合页数据正确
### 兼容性
- [ ] 旧内容未因结构变更而失效
- [ ] 缺少新字段的旧内容有合理的默认值或降级处理
- [ ] draft 过滤逻辑仍然正常
### 文档同步
- [ ] docs/data-schema.md 已更新
- [ ] docs/content-rules.md 已更新（如涉及 frontmatter 变更）
- [ ] docs/build-process.md 已更新（如涉及构建逻辑变更）这套清单的设计逻辑：按影响链路逐层检查------类型定义 → 解析构建 → 页面消费 → 兼容性 → 文档同步。不放过任何一个环节。
注意最后的"文档同步"部分。这一步很多人会忘------改了代码但没更新文档，下次 Claude 读到的就是过期的规则。