你喂给AI的代码，80%都是它已知的垃圾

我们以为把整份代码塞进ChatGPT是"给足信息"，结果AI第一句回复往往是："我看到你用了jQuery 3.6.0、Bootstrap 5.3.0、Lodash 4.17.21……你的实际代码只占这份文件的12%。"

这不是段子。这是每个试图用AI辅助编程的人，都经历过的沉默暴击。

一个刚发布v1.1版本的开源工具repomeld，瞄准的正是这个被忽视的痛点。它的核心功能简单到近乎粗暴：自动过滤掉AI已经知道的公共库，只保留你的业务代码。但背后折射出的，是AI编程时代一个反直觉的真相——信息不是越多越好，精准投喂才是稀缺能力。

为什么你的"完整代码"在AI眼里是噪音

先还原一个典型场景。

你有一个React项目，目录结构看起来人畜无害：src文件夹里躺着组件、hooks、工具函数，外加node_modules里300多个依赖。总代码量？算上依赖大概150MB。你自己的代码呢？50KB。

你用某款代码合并工具，把整个项目打包成一个4.2MB的文本文件，信心满满地丢给Claude或GPT-4。然后你收到了那段著名的开场白——AI花了大量token识别出jQuery、Bootstrap、Moment.js等47个库，最后发现你的原创代码只有12%。

问题出在哪？

上下文窗口（Context Window，即AI单次能处理的文本长度）是稀缺资源。GPT-4o的128K token、Claude 3.5 Sonnet的200K token，听起来很大，但面对一个臃肿的前端项目，几轮对话就可能触顶。更隐蔽的损耗是：AI被迫在"识别已知信息"上浪费算力，留给"理解你的业务逻辑"的注意力被严重稀释。

repomeld的开发者算过一笔账：4.2MB的合并文件里，真正属于用户的代码可能只有1%。过滤后输出52KB，100%是有效信号。

这不是压缩技术，这是注意力管理。

200+库的黑名单，是怎么建起来的

repomeld的解决方案听起来不复杂：内置一份精心筛选的忽略清单，覆盖200多个常见公共库和vendor文件。运行工具时，node_modules里的jQuery、dist目录下的打包产物、package-lock.json这类锁文件，会被自动排除。

但真正值得琢磨的是这份清单的构建逻辑。

它不是简单的"忽略所有node_modules"——那样会误伤你自定义修改过的库。也不是按文件大小一刀切——有些小体积的配置文件同样无意义。repomeld的策略是语义识别：判断一个文件是否属于"AI训练数据中已充分存在的公共代码"。

这意味着清单需要持续维护。Bootstrap 5.3.0的minified版本和5.2.0有差异吗？对AI来说没有，都是它"学过"的东西。但如果你在Bootstrap里覆写了主题变量，那就另当别论。

所以v1.1版本加入了--force-include参数。你可以强制包含特定库，即使它在默认黑名单里。匹配规则是子字符串模式，--force-include bootstrap会解锁所有路径包含"bootstrap"的文件。

更灵活的是repomeld.ignore.json配置文件。你可以在项目根目录放置这个文件，追加自定义忽略项——比如团队遗留的legacy-library.js，或者CI生成的报告文件。

配置优先级也设计得清晰：命令行参数 > 本地配置文件 > 内置默认清单。这种分层设计，既保证了开箱即用的体验，又留足了边缘场景的出口。

从"代码打包"到"上下文工程"

repomeld的出现，让我意识到一个正在发生的范式转移。

过去我们谈"代码管理"，关注的是版本控制、依赖治理、构建优化。现在多了一层：面向AI的上下文工程（Context Engineering）。你的代码库不再只是给编译器看的，还要给大模型看——而这两个"读者"的需求截然不同。

编译器需要完整、精确、可复现。大模型需要精简、相关、有信息量。

这个差异催生了一系列新工具类别。除了repomeld，还有aider这样的AI结对编程工具，会自动选择相关文件构建上下文；有grep-ast这种基于AST的代码检索，比纯文本搜索更懂代码结构。它们共同指向同一个问题：当AI成为代码的主要消费者之一，我们的工具链必须重新设计。

repomeld的聪明之处，在于它没有试图解决"所有问题"。它不分析代码语义，不做智能摘要，只是干净利落地做减法。这种克制反而让它成为链条上的可靠一环——你可以把它和aider、Claude Code等工具串联使用，各自负责擅长的环节。

开发者社区的反应也印证了这种需求的真实性。项目在v1.0发布后迅速获得关注，v1.1的--force-include和自定义配置功能，明显是响应了早期用户的真实反馈：有人需要包含魔改过的库，有人有独特的项目结构。

谁该立刻试试，谁可以观望

如果你符合以下任意画像，repomeld值得加入工具箱：

——频繁用ChatGPT/Claude处理现有代码库，而非从零写新功能

——维护历史项目，依赖庞杂且文档缺失，需要AI快速理解业务逻辑

——上下文窗口经常告急，不得不手动删除大段代码才能继续对话

——团队协作中，需要把代码上下文分享给非技术背景的AI助手使用者

反之，如果你主要用AI写独立脚本、单文件工具，或者习惯用Cursor/Windsurf这类内置上下文管理的IDE，repomeld的增量价值有限。这些工具已经内置了类似的过滤逻辑，只是不透明、不可定制。

一个细节：repomeld支持多种输出格式，包括纯文本、Markdown、XML。Markdown格式特别适合直接粘贴到支持代码块渲染的对话界面，XML则便于程序化解析。这种格式灵活性，暗示了开发者对"AI交互工作流"的深入理解——不同场景需要不同的上下文封装方式。

这件事为什么重要

repomeld本身是个小工具。但它揭示的趋势很大：我们正在进入"人机协作编程"的深水区，而上下文质量决定了协作效率的天花板。

未来的代码库可能会有双重结构：一层给机器编译，一层给AI理解。repomeld这类工具是过渡态的探路者，它们用简单粗暴的规则，验证了一个核心假设——在信息过载的时代，精准剔除噪音比盲目堆砌数据更有价值。

对于每天和AI打交道的开发者，这个认知比工具本身更值钱。下次准备把代码丢给大模型前，先问自己：这里面有多少是AI已经知道的，多少才是真正需要它理解的？答案可能让你重新审视整个工作流。