文档工程化整理：大家在 CI 中是如何对 Markdown / MDX 代码片段做自动化校验防腐的？

整理最近几个项目的文档时，感触最深的一点是：技术文档最大的隐形维护成本，往往在于**「代码防腐化（Code Rot）」**。主工程改了一个小小的破坏性 API，文档和 README 里的代码示例就悄悄失效了，对新手的挫败感极强。

梳理了一下目前社区里常见的几种防御思路和工具链：

1. 语言级原生集成：最经典的典范是 Rust 的 cargo test / rustdoc，写在注释和文档里的代码块直接作为测试用例跑，体验极为丝滑；
2. 文档代码提取与断言（Doc-testing）：
   • Python 生态里的 doctest 或 sybil；
   • Node.js / 前端生态里的 eslint-plugin-mdx（做 Lint 校验）或 jest-runner-markdown、code-runner；
3. 单一真实源（Single Source of Truth）嵌入：
   • 不在 Markdown 里手打代码，而是直接写真实用例并跑 CI，文档中通过语法片段标记（如 VitePress / Docusaurus 的 Code Snippets 引用机制）将其 transclude 进来。

想向大家请教一下：大家目前的开源项目在 CI 里落地了哪种方案？

尤其是遇到**「为了文档可读性，需要隐藏冗长的前置 Setup 代码，只向读者展示核心 3 行」**的场景时，大家是如何平衡“保证片段可独立测试”与“保证排版清爽”的？欢迎分享你们踩过的坑和推荐的工具。