在技术文档的写作与发布流程里，内容审校向来是一件性价比极低但又不得不做的事：人工逐字挑错费时费力，而直接拿通用 AI 或云端大模型去纠错，又极容易踩雷——模型分不清技术边界，随手就把代码注释改崩、把行内参数名翻译掉，或者把 API 网关 自作聪明改成 API 网管。更不用说在很多正式发版前，包含未公开架构的文档根本过不了公网 API 的数据安全合规。
过去这一年，为了在我们内部一个近 38 万字的技术文档库里安全落地自动化审校，我折腾了一套“本地优先、轻量小模型推理、带代码结构保护”的审校系统。
在上一篇文章分享完架构思路后，收到一些朋友关于源码的询问。其实它最初只是个内部“能跑就行”的粗糙脚本，算不上什么高大上的系统。为了能拿出来供有类似需求的朋友参考，这几个月花时间把代码重新脱敏整理，补齐了 Web 界面、Docker 和测试用例。
今天，把这套工具开源出来，希望能给大家提供一点参考。
DocSifter 正式开源，采用 MIT 协议。
想先看它怎么工作，可以直接打开交互式产品演示。
工作文件越积越多，本地存储不够用，商业云盘又放不了敏感内容。最后在旧主机上跑了 Nextcloud：想加多少盘就加多少，出门用 VPN 拨回来就连上，即使文件改坏想回溯也非常方便，后来顺手接进本地 AI RAG 系统，能做的事比最初想的多得多。
摘要：AI 大模型可以快速生成看起来完整的产品文档，但这些内容是否符合真实用户路径、是否经过验证、是否适合对外发布，仍然是一个高确定性问题。本文记录了一次真实的文档工程化实践：我们如何从单次 AI 聊天生成 + 人工修补，升级为由 Rules、Skills、验证 Harness 和人工审阅共同组成的可验证、可复用文档生产流。通过这套流程，文档团队不仅提升了复杂软件文档的对客质量，也进一步将工作重心从内容编写延伸到文档平台工程、知识结构设计和开发者体验优化。
上一篇文章《技术文档 AI 审核实践：从本地轻量校验到 Codex Code Review》中，我简单提到过，在引入 Codex 做更深入的内容 Review 之前，我先做过一套本地 AI 文档纠错系统，用来处理错别字、术语误写、基础病句和部分格式异常。
当时只是顺手带了一句，没想到有读者对这块更感兴趣。所以这篇文章就单独展开聊聊：为什么要做一个本地中文 AI 文档纠错系统，它和直接调用大模型有什么区别，以及从一个能跑的 Demo，到一个团队里真的能用的 Web 工具，中间需要补上哪些工程设计。
当技术文档全面采用 Doc-as-Code 并托管在 GitHub 之后，Review 流程也开始越来越像代码协作，面临越来越高的质量压力。过去半年里，我围绕文档审查做了一次比较完整的演进：先用本地轻量校验处理错别字和基础文本问题，再引入 Codex 的本地与云端 Code Review，并通过 AGENTS.md 把审查规则逐步沉淀下来，最终形成一套轻量、本地、云端三层配合的内容审查流程。
这篇文章想分享的，不只是工具体验，而是这套流程为什么值得做、怎么设计，以及它的边界在哪里。