Build 是第一个 reviewer
CI 不能判断解释是否真正有用，但可以在人工投入之前拦截大量可预测问题。把文档 build 当作质量门，而不仅是发布机制。
从确定性检查开始
构建站点、验证 frontmatter、检查内部链接和缺失 assets。只有团队真正认可时才增加风格与术语规则。
在风险值得时测试示例
Shell 命令、API request 和关键代码示例往往可以自动执行。
为 review 生成 preview
渲染页面能发现文本 diff 看不到的布局、导航和上下文问题。
CI 必须快速且可理解
二十分钟的 pipeline 和大量模糊 warning 最终会被绕过。
发布是最后一步
验证可靠后，可以从批准分支自动部署。每个已发布版本都应该能从明确的仓库状态重现。
实践示例
把《CI/CD 中的文档》当作一次小型评估，而不是功能列表比较。选择三类真实内容：简单页面、包含代码或结构化数据的页面，以及带有导航、复用或本地化要求的复杂页面。用同一种工具或方法处理三者，并记录哪些工作变简单、哪些新的维护成本出现。
重点检查团队会重复进行的工作：
- 作者是否容易理解源文件；
- 审阅者是否能看出有意义的差异；
- 构建失败是否指出可以修复的问题；
- 内容能否在无需大量手工清理的情况下移动、翻译和复用。
好的工具会减少写作、审阅和发布中的不确定性。如果复杂性只是转移到脆弱配置、插件或某个专家的记忆中，也必须把它计入成本。
快速编辑检查
- Build 是第一个 reviewer. CI 不能判断解释是否真正有用，但可以在人工投入之前拦截大量可预测问题。
- 从确定性检查开始. 构建站点、验证 frontmatter、检查内部链接和缺失 assets。
- 在风险值得时测试示例. Shell 命令、API request 和关键代码示例往往可以自动执行。
- 为 review 生成 preview. 渲染页面能发现文本 diff 看不到的布局、导航和上下文问题。
