Repomix：把代码仓库打包成 AI 可读的单文件

把整个代码仓库交给大模型，手工做起来很碎：挑出要看的文件、跳过依赖目录和二进制、再估一遍 token 有没有超过上下文窗口。Repomix 把这些动作收进一条命令，跑完在项目目录里留下一个文件，里面是仓库的文本内容，按模型容易读的格式排好。

Repomix 是一个用 TypeScript 写的命令行工具，把本地或远程代码仓库打包成单个 AI 友好文件，输出 XML、Markdown 或纯文本，供大语言模型直接阅读。

典型场景是让 Claude、ChatGPT、DeepSeek、Gemini、Llama 这类模型先读完整份代码，再做重构、审查或解释。除了命令行，它还有网站 repomix.com、Chrome 与 Firefox 浏览器扩展，以及社区维护的 VSCode 扩展 Repomix Runner。仓库地址是 https://github.com/yamadashy/repomix，采用 MIT 许可证，主要语言为 TypeScript。

主要功能

• 一条命令打包整个仓库：在项目目录执行 repomix，默认生成 repomix-output.xml。不想安装可以用 npx repomix@latest。
• 限定打包范围：repomix path/to/directory 只打包某个目录；--include "src/**/*.ts,**/*.md" 用 glob 模式挑选文件；--ignore "**/*.log,tmp/" 排除指定文件或目录。
• 打包远程仓库：repomix --remote https://github.com/yamadashy/repomix，也支持简写 --remote yamadashy/repomix。用 --remote-branch main 指定分支、标签或提交哈希，分支 URL 与 commit URL 也能直接识别。
• 从文件列表打包：把其他命令的输出通过 --stdin 传进来，例如 git ls-files "*.ts" | repomix --stdin，也可以用 find、rg、fd、fzf 生成列表。
• Token 统计：为每个文件和整个仓库给出 token 数量，用来判断内容是否超出模型的上下文限制。
• Git 感知的忽略规则：自动遵循 .gitignore、.ignore 与 .repomixignore，不需要额外配置。
• 密钥检测：集成 Secretlint，命中已知凭据格式的文件会被排除在输出之外。
• 代码压缩：--compress 使用 Tree-sitter 提取关键代码元素，减少 token 的同时保留结构。
• 多种入口：网站 repomix.com 支持 XML、Markdown、纯文本三种格式与即时 token 估算；浏览器扩展在 GitHub 仓库页加一个 Repomix 按钮；MCP 服务器从 v1.18.0 起支持沙箱模式，把可用范围限制在单个工作目录。
• 版本里新增的细粒度控制：v1.16.0 加入 output.patterns 逐文件包含级别、--skill-project-name 选项；v1.17.0 加入自定义文件处理器（可在匹配文件被处理前执行外部命令）与远程仓库配置的交互式确认。

同类项目对照

下表列出 Repomix 与两个相关项目的位置差异。vercel/ai 由站点标注为同类项目，ECC 为已收录项目。ECC 的部署方式与限制在本次素材里没有说明。

| 项目 | 适合谁 | 部署方式 | 主要限制 | 什么情况下选它更合适 | 项目地址 |

| --- | --- | --- | --- | --- | --- |

| Repomix | 需要把整份代码交给大模型读的开发者，习惯用命令行或把它挂进脚本流程 | npm install -g repomix、npx、Homebrew，另有网站与浏览器扩展 | 打包远程仓库时需要联网访问 GitHub；输出会把源码集中到单文件，敏感内容要自己先核对 | 目标是产出一份可直接粘贴进对话的仓库上下文文件时 | Repomix |

| vercel/ai | 用 TypeScript 写 AI 应用、需要在代码里直接调用模型的开发者 | 作为 npm 依赖装进项目 | 不负责读取和打包仓库，文件挑选与拼接要自己写 | 需要在运行时调用模型、处理流式输出与工具调用时 | vercel/ai |

| ECC | 同时挂多个编码智能体、想统一调优 harness 的团队 | 未逐一核实 | 未逐一核实 | 关注点在多智能体协作流程而非上下文打包时 | ECC |

这三者的目标并不重合。Repomix 只负责把仓库变成一份可粘贴的上下文文件，不参与模型调用；要在应用里跑推理、管流式输出和工具调用，该用 vercel/ai，它提供的运行时能力 Repomix 完全没有。ECC 处理的是多个编码智能体之间的协作调优，和打包上下文不是一回事，放在这里只是给同类选型的人一个参照。

它的实际表现

• Star：28607
• Fork：1552
• Watcher：75
• 开放 Issue：147
• 创建时间：2024-07-13
• 最近一次提交：2026-09-29
• 最近一个版本：v1.18.1，发布于 2026-09-21
• 仓库体积：29573 KB
• 主要语言：TypeScript，占 95.0%；其余为 Vue 3.8%、JavaScript 0.3%、Shell 0.3%、Dockerfile 0.3%、CSS 0.2%
• 许可证：MIT

这些数字说明什么

28607 个 star 与 1552 个 fork 摆在一起，说明它不只是一批人点过收藏，还有相当数量的人把仓库复制走，改造成自己的版本或长期挂在流程里。75 个 watcher 相对偏低，这类人群通常只是想跟踪更新，不能拿来衡量使用规模。

项目创建于 2024-07-13，最近一次提交是 2026-09-29，跨度两年多之后仍有提交记录，维护没有停。最近一个版本 v1.18.1 在 2026-09-21 发布，属于补丁版本，修的是 CLI 里 git 处理的安全问题、Windows 上 .gitignore 崩溃以及一批贡献者提交的修复，说明补丁发布和安全问题处理走在同一条节奏上。

147 个开放 Issue 对一个两万多 star 的项目来说不算低，能看出提问和需求都很密集，其中一部分是功能请求，不全是故障。TypeScript 占 95.0%，Vue 占 3.8%，对应仓库里同时放着命令行、网站和浏览器扩展，属于单一主仓多产物维护的结构；29573 KB 的体积与这种结构相符。

数据看不到的部分

star 数、fork 数和提交时间都反映不了代码质量，也判断不出它在你手上那套代码库里跑出来的效果。这些指标同样回答不了两个具体问题：输出文件在你的项目上会不会超出上下文窗口，以及它的文档有没有跟着版本更新。README.md 有 84.1 KB，内容量很大，但仓库里没有说明它会与每个版本严格同步，遇到具体参数时以对应版本的行为为准。

开放式 Issue 列表里的记录，是这些指标看不见的真实摩擦。下面几条来自实际用户，按评论数排在前列：

• 在 Mac（Apple Silicon M4 芯片）上执行 bunx repomix 会报 “Not implemented” 错误，16 条评论，已解决。
• 开启移除注释后出现大段代码丢失，14 条评论，已解决。
• .gitignore 中使用反斜杠转义模式时 Repomix 直接失败，10 条评论，已解决。
• 把输出拆成多个文件的需求，12 条评论，仍待解决。
• 自定义或去掉 File Summary 头部的需求，10 条评论，仍待解决。
• 面向 RAG 引擎的输出格式、多级压缩以减少 token，都还停在待解决状态。

把代码打包上传给第三方模型这件事本身有边界。--remote 可以抓取公开仓库，但把他人代码、尤其是私有仓库或带版权限制的代码打包后交给外部模型，可能触碰授权范围与平台条款。这套工具只应用于自有资产或已明确获得授权的目标，误用带来的纠纷要自己承担。

所以值不值得试

值得试的情形：你需要频繁把整份代码交给大模型阅读，手工挑文件已经占掉可观的时间；你的项目以文本代码为主，并且已经在用 .gitignore 管理忽略规则，那么 npx repomix@latest 一条命令就能看到效果。

先别急的情形：代码里有不能外发的密钥或客户数据，而你没有先打开输出文件核对内容，内置的 Secretlint 只覆盖已知凭据格式；你要的是在应用运行时调用模型，这个方向要看 vercel/ai；仓库规模在数千文件以上，切分输出与分级压缩都还是未完成的需求，单文件可能直接顶破上下文限制。

适合它的是手上有大模型、又需要把整个代码库作为上下文一次性交出去的开发者，以及把仓库快照接进自动化脚本或 CI 流程的团队。不适合它的是只想在应用里调用模型的人、对代码外发有严格合规要求又不打算做本地核对的团队，以及期待开箱即用的多文件拆分与 RAG 索引的人。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 10.0 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。