2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
您的文档与代码存放在一起。这就是“文档即代码”承诺的核心——版本控制、拉取请求审查、持续集成/持续部署流水线。这一切运行得非常完美。
直到您的代码仓库文件数量达到 10 万个。
一个无人提及的问题
我们的团队运营着一个文档门户，从数十个大型代码仓库中拉取内容。每次文档构建都需要从包含数十万个文件的仓库中获取少量标记语言文件和图像。 naive 的方法——git clone（Git 克隆）——速度慢得令人痛苦，且极其浪费资源。
我们尝试过稀疏检出。我们尝试过浅层克隆。我们直接尝试过 Git 提供商的应用程序接口。每种方法都有其自身的问题：
- 完整克隆：对于只需要 50 个文件的构建过程，却需要花费数分钟进行下载
- 应用程序接口文件下载：下载几百个文件后就会触及速率限制
- 稀疏检出：仍然需要进行 Git 历史记录协商，并且对基于应用程序接口的流水线没有帮助
讽刺的是？清单文件已经明确声明了需要哪些文件。docfx.json（或您的静态站点生成器使用的任何配置文件）列出了每个内容通配符模式和每个资源模式。我们只是没有尽早利用这些信息。
为何此事如今更为重要：人工智能代理
这不再仅仅是一个构建速度的问题。如果您正在构建人工智能代理来回答关于您产品的问题、帮助开发人员入职或协助内部流程——它们需要访问您的文档。不是您的代码。不是您的测试用例。而是文档。
挑战迅速扩大：
- 检索增强生成流水线需要从数十个仓库中摄取文档——克隆所有仓库是荒谬的
- 增量索引需要知道哪些文件是文档而非代码——清单文件已经告诉了您
- 多仓库知识库需要一种快速、有选择性的方式，仅从多个仓库中拉取内容文件
您从仓库中提取文档的速度越快、越精确，您的代理所掌握的知识就越新鲜、越准确。解决选择性获取问题，既能加速构建过程，又能提供可靠的人工智能驱动文档体验。
核心理念：在获取之前先解析
如果我们颠倒顺序会怎样？
不再是：克隆所有内容 → 构建 → 丢弃 99% 的文件
而是：获取文件列表 → 与清单匹配 → 仅获取匹配项
┌─────────────────┐ ┌──────────────────────┐ ┌─────────────────┐
│ Git 提供商 │ │ 选择性仓库获取工具 │ │ 文档流水线 │
│ (文件列表) │────▶│ (清单匹配 │────▶│ (仅构建 │
│ │ │ + 引用过滤) │ │ 匹配的文件) │
└─────────────────┘ └──────────────────────┘ └─────────────────┘
来自 GitHub、Azure DevOps 或 GitLab 的文件树列表只需一次廉价的应用程序接口调用——它返回的是元数据，而非文件内容。将该列表与您的清单模式进行匹配，您就能确切知道需要获取什么。
介绍 selective-repo-fetch
我们将此逻辑作为 TypeScript 库开源：selective-repo-fetch。它采用麻省理工学院许可证，且不与特定提供商绑定。
npm install github:microsoft/selective-repo-fetch
以下是核心工作流程：
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
