repo2txt：把 GitHub 仓库压成一段提示词文本，代价是什么

它填的是提示词拼装这道工序

把代码贴进对话窗口这件事，做一次很轻松，做十次就开始烦。你要打开文件、复制内容、加上路径注释、判断哪些文件不该贴（node_modules、构建产物、锁文件），然后手动估算这段内容会不会超上下文。repo2txt 把这一串动作收进一个页面：输入仓库地址或选择本地目录，用扩展名、.gitignore 和自定义模式过滤，最后一次性导出为 .txt。

目标用户写得很直白，README 里的措辞是面向 AI 辅助开发。也就是说，它假设你已经在用 LLM 读代码，缺的只是把代码整理成模型能吃的形状。它不分析代码，不建索引，不做语义检索，输出就是带文件分隔的纯文本。这一点决定了它的能力上限，也决定了它的实现可以很轻。

数据不经过服务器，代价是浏览器扛下全部工作

README 把隐私列成首要特性：100% 浏览器端，无服务端上传，GitHub token 只写入 sessionStorage。这个设计选择有实际后果。取仓库内容走的是 GitHub 的公开 API，带 token 时速率上限从每小时 60 次提到 5000 次，README 明确列出了这两个数字。文件内容拉回浏览器后，过滤、分词、拼接、打包下载全在本地完成。

好处是代码不出设备，私有仓库也不需要你信任一个中间服务。代价是内存和 CPU 的账由你的机器来付。项目为此做了几件事：用 TanStack Virtual 做虚拟滚动，README 称可处理 10000 个以上文件；用 Web Worker 把 tokenization 挪到后台线程；提供渐进式加载，文件内容边拉边显示；再加一层缓存控制内存占用。这些机制说明作者清楚瓶颈在哪，但浏览器终究是浏览器，超大仓库仍然会受制于标签页可用的内存，README 没有给出内存上限的具体数字。

多来源接入与过滤链

输入侧支持五条路径：GitHub（公开与私有，带 token）、本地目录选择器、zip 拖拽上传、GitLab（标注为 Beta）、Azure DevOps（同样标注 Beta）。后两者带 Beta 标签，说明作者自己也不认为它们和 GitHub 路径一样成熟，生产使用前应当先在目标平台上跑一遍。

过滤是这类工具真正的价值所在。README 列出四种手段：按扩展名勾选、自动遵循 .gitignore、自定义忽略模式、目录级挑选。配合文件树预览，你可以只保留 src 下的一两个目录。GitHub 路径还支持几种 URL 形式，包括带分支的 tree 链接、带子目录路径的链接，以及名字里含斜杠的分支（README 举例 feature/test/branch-name）。最后一步是导出：复制到剪贴板，或下载为 .txt。

需要说清楚的是，过滤规则的具体语法在提供的材料里没有展开。自定义模式是 glob 还是正则、多条模式之间是并集还是覆盖，README 没说，仓库里也没有可查的示例。这一块只能自己试。

本地跑起来

在线版本挂在 abinthomas.in/repo2txt 上，README 说无需安装。要本地运行，命令是标准的 Vite 流程：先 git clone 仓库并 cd 进去，然后 npm install，再 npm run dev，开发服务器默认在 http://localhost:5173/repo2txt/ 这个带子路径的地址上，注意别漏掉路径后缀。生产构建用 npm run build，README 说产物在 ./dist。

技术栈在 README 里列得很全：React 19、TypeScript、Vite 5、Tailwind CSS 3、Zustand 做状态、JSZip 处理压缩包、gpt-tokenizer 做分词、TanStack Virtual 做虚拟滚动，测试用 Vitest 加 Playwright，CI 走 GitHub Actions。贡献流程里给出的测试命令是 npm run test:unit 和 npm run test:e2e，仓库还带了 CONTRIBUTING.md 和一份 AGENT.md，后者按 README 的说法是给 LLM agent 看的设计文档。

有一个配置项值得单独提：GitHub token。README 只说明它用于私有仓库和提升速率上限，并强调存在 sessionStorage 中。sessionStorage 随标签页关闭而清空，这一点比 localStorage 更保守，但也意味着每次新开标签页都要重新粘贴。

token 计数是估算，不是承诺

token 计数器是 repo2txt 的核心卖点之一：README 说它做实时 GPT token 计数，并给出每个文件的 token 数和行数。实现依赖 gpt-tokenizer。问题在于，不同模型的 tokenizer 并不一致，Claude、Gemini 或本地部署的模型各有各的分词方式。用一个针对 GPT 系列的分词器去估算别的模型的上下文占用，误差是结构性的，不是随机噪声。

实用建议是把计数器当成粗筛：用它判断某个目录是不是明显太大，而不是用它卡到接近上下文上限的精确值。README 没有说明是否支持切换 tokenizer，材料里也看不到相关配置项。如果你的工作流要求精确控制上下文预算，这一点需要在采用前自己验证。

它不做的事，以及更合适的替代

repo2txt 输出的是一份扁平的、按文件拼接的文本。没有符号表，没有 import 图谱，没有函数级切分。模型看到的是一堆文件内容，而不是一个可导航的代码库。如果你的任务是跨文件追踪一次调用的完整链路，或者在大仓库里定位某个类被谁引用，这个输出形态帮不上忙。

更合适的做法是换一类工具。检索式的代码问答方案（例如基于向量索引或 AST 索引的仓库检索工具）会先把代码切成块、建索引，提问时只把相关片段送进上下文。两者的取舍很清楚：repo2txt 把选择权交给你，你决定贴哪些文件，输出可复现、可检查、无外部依赖；检索方案把选择权交给索引，覆盖面更广，但引入了索引构建、向量存储和检索质量这些新的失败点。仓库小、你对结构熟悉、只需要一次性把上下文喂进去，repo2txt 更直接。仓库大、问题开放、需要反复追问，扁平文本会迅速撞上上下文上限。

另一条路是自己写脚本调 GitHub API。repo2txt 相对脚本的优势在于过滤界面、token 估算和跨来源支持；如果你只需要固定几个目录，脚本反而更可控。

维护成本与许可

仓库未归档，最近一次推送时间在 2026 年 8 月。没有检索到任何 release，也就是说版本管理走的是默认分支，没有带 tag 的发布记录可以对照。对采用者来说，这意味着升级路径是拉取 master，没有变更日志可供回滚参考，README 里指向的 Changelog 链接实际指向 Releases 页面，而该页面目前是空的。

依赖面不小：React 19、Vite 5、Tailwind 3、Zustand、JSZip、gpt-tokenizer、TanStack Virtual，加上 Vitest 和 Playwright。作为纯前端项目，运行时没有服务端组件要维护，升级压力主要来自构建工具链和框架大版本。React 19 与 Vite 5 都属于较新的主版本，长期跟进需要有人盯着上游的破坏性变更。

许可方面，README 顶部放了 MIT 徽章，正文也写明 MIT License 并指向 LICENSE 文件，但仓库元数据里的 license 字段是空的。徽章和正文都指向 MIT，实际条款仍应以仓库根目录的 LICENSE 文件为准。MIT 属于宽松许可，通常允许商用和修改，但这不是法律意见，涉及分发或二次授权时请自行核对原文。

编辑结论

repo2txt 适合这样一类人：需要把某个仓库的选定文件拼成一段文本喂给 ChatGPT、Claude 或其他模型，但不想写脚本、不想把代码传到第三方服务器。私有仓库用 GitHub token 即可，token 按 README 的说法只存在 sessionStorage 里。反过来，如果你的目标是让模型理解整个代码库的调用关系，repo2txt 帮不上忙，它产出的是扁平文本，没有符号索引，也没有跨文件引用。采用前先确认三件事：LICENSE 文件里的实际授权条款（README 徽章写 MIT，但仓库元数据未标注）、目标仓库文件规模能否落在 10000+ 文件的虚拟滚动范围内，以及你是否能接受 gpt-tokenizer 与模型真实分词器之间的计数偏差。

官方来源

1. abinthomasonline/repo2txt on GitHub
2. Issues
3. Project website
4. README