摘要：AI 大模型可以快速生成看起来完整的产品文档，但这些内容是否符合真实用户路径、是否经过验证、是否适合对外发布，仍然是一个高确定性问题。本文记录了一次真实的文档工程化实践：我们如何从单次 AI 聊天生成 + 人工修补，升级为由 Rules、Skills、验证 Harness 和人工审阅共同组成的可验证、可复用文档生产流。通过这套流程，文档团队不仅提升了复杂软件文档的对客质量，也进一步将工作重心从内容编写延伸到文档平台工程、知识结构设计和开发者体验优化。

挑静态博客框架期间，对比看过 Hexo、Hugo 等主流方案，最后定了 Docusaurus，主要是刚好满足了几个需求：偶尔写点技术内容、想把博客和文档放在一起、又不打算为了样式从头写 CSS，积累的经验也可以复用至工作中的技术文档项目。

从 Fork 模板开始，到改成现在这个样子，前后断断续续一两周。这篇文章把整个过程整理一遍，省得自己以后忘了，也给打算自己搭一个的朋友做个参考。完整代码在这里：heywalter/FlowingDocs，欢迎 Fork 或 Clone 直接复用，然后按照本文的步骤把站点信息和外部服务凭证换成自己的就能跑起来。

上一篇文章《技术文档 AI 审核实践：从本地轻量校验到 Codex Code Review》中，我简单提到过，在引入 Codex 做更深入的内容 Review 之前，我先做过一套本地 AI 文档纠错系统，用来处理错别字、术语误写、基础病句和部分格式异常。

当时只是顺手带了一句，没想到有读者对这块更感兴趣。所以这篇文章就单独展开聊聊：为什么要做一个本地中文 AI 文档纠错系统，它和直接调用大模型有什么区别，以及从一个能跑的 Demo，到一个团队里真的能用的 Web 工具，中间需要补上哪些工程设计。

当技术文档全面采用 Doc-as-Code 并托管在 GitHub 之后，Review 流程也开始越来越像代码协作，面临越来越高的质量压力。过去半年里，我围绕文档审查做了一次比较完整的演进：先用本地轻量校验处理错别字和基础文本问题，再引入 Codex 的本地与云端 Code Review，并通过 AGENTS.md 把审查规则逐步沉淀下来，最终形成一套轻量、本地、云端三层配合的内容审查流程。

这篇文章想分享的，不只是工具体验，而是这套流程为什么值得做、怎么设计，以及它的边界在哪里。

作为一名内容传播从业者，我的工作就是把复杂信息转化为清晰、可操作的内容。久而久之，我养成了“职业病”：走到哪儿都忍不住审视周围的信息呈现方式。这不，最近遇到几个典型案例，拿出来分享，换换口味，不讲严肃的原理，一起来看看我们是怎么被信息误导的，也提醒自己在内容设计时避免犯错。

你好，我是 Walter，欢迎来到我的博客 Flowing Docs / 知流小记。

其实想写博客已经很久了，只是一直拖着没动手。这次终于下定决心，先写篇文章立个 flag，免得自己又半途而废。写博客对我来说，就是找个地方把零散的想法整理出来，分享出去。我总觉得，如果一篇技术文章能让读者少走一些弯路，那这篇文章就发挥了它最大的价值。