XERJ：让 AI Agent 停止"读全书"，改为"查目录"

项目：xerj-org/xerj
仓库：https://github.com/xerj-org/xerj
语言：Rust | 协议：Apache-2.0 | 今日 Star：+725

一、一个反直觉的事实

你的 AI coding agent 很笨。

不是模型笨。是它找信息的方式笨。当你问"这个项目里 WAL segment 怎么轮转的"，agent 的第一反应是 grep -r "WAL"，把命中的每个文件整个塞进上下文——一个 50 万行的代码库，grep 一次可能拉进 106 万 token，然后模型还得自己从这堆文件里找答案。

这就像你问图书管理员"量子力学里薛定谔方程怎么推导"，管理员不查目录，而是把整个物理学书架的书全搬到你桌上说"自己翻吧"。

XERJ 做的事情很简单：它先读完全库一次，建好索引，之后你问任何问题，它只返回你需要的那一段，带文件名和行号。

二、数据说话

XERJ 官方做了一个受控实验：8 个编程任务，4 种语言，每题跑 16 次，用真实的 claude -p token 计数。三组对照：

grep 已经比纯记忆好 10 倍，XERJ 再比 grep 好 2.7 倍。最夸张的单个 Java 任务，XERJ 比 grep 少用 278 倍 token。

关键不是省了多少钱，是解决率没掉——16/16 和 16/16 一样。XERJ 不是用"少给信息"换"少花 token"，是用"给对信息"同时省 token。

三、Reference Coding：最被低估的概念

XERJ 最有意思的用法不叫"搜索"，叫 reference coding（参考式编程）。

流程是这样的：你给 agent 一个任务，比如"实现一个 RTSP 流媒体解析器"。agent 做的第一件事不是写代码，而是：

1. 找到 GitHub 上和 RTSP 解析最接近的开源项目
2. clone 下来，用 XERJ 建索引
3. 查"他们是怎么处理握手包的""他们怎么管理缓冲区"
4. 拿到带 file:line 的精确段落
5. 然后才开始写自己的代码

这就像一个初级工程师在动手前先翻同类项目的源码——只不过 agent 翻得快，几秒钟就能把一个陌生项目的关键逻辑提取出来。

XERJ 官方在 Rust 库上做了一个极端测试：一个模型从没见过的 Rust 库，用 XERJ 检索辅助完成 9/9，纯靠记忆做 0/9。这个差距说明了一件事：模型的"记忆"是有限的，但"查资料"的能力是无限的。

四、autoindex：一个命令索引一切

XERJ 的工程亮点是 xerj autoindex <folder>。一个命令，它自动：

• 嗅探每个文件的类型（代码、文档、日志、PDF、SQLite、CSV）
• 用 tree-sitter 解析代码的符号和行号（不是当纯文本处理）
• 为每个数据集创建独立的类型化索引
• 跳过垃圾文件和无关文件

一次完整的 autoindex 日志长这样：

phase A: 593 datasets inferred, 1955 junk/skipped files
phase B: indexing 25329 files with 8 workers
done in 158.1s, 593 datasets, 83103 records live, 790 junk records

2.5 万个文件，8 线程并行，158 秒建完索引。之后所有查询都走这个索引，不需要重新读文件。

五、Elasticsearch 兼容：一个聪明的工程决策

XERJ 用 Rust 写，但对外暴露的是 Elasticsearch API。这意味着：

• 所有现有的 ES 客户端、仪表盘、工具链直接能用
• 不需要学新 API
• 不需要迁移工具链

这是一个被低估的工程决策。很多新项目喜欢发明自己的 API 格式，然后花几年时间说服生态迁移过来。XERJ 选择了"做兼容层"而不是"做替代品"——它想当你的搜索引擎，但不想当你的工具链。

六、Field Report as Membership Card

XERJ 的社区模型很反常规。项目 Apache-2.0 开源，免费使用，但有一个请求：用完之后提交一份 field report。

"你加入 XERJ 的方式是运行它，然后发回一份简短的 field report：你把它指向了什么，用它做了什么，你的真实评价。负面评价也是好 report。"

这像学术界的同行评审——你用别人的方法做了实验，不管结果好坏，都有义务报告出来。field report PR 免签 CLA，一个 markdown 文件丢进 user-feedback/ 目录就行。

这个设计的精妙之处在于：它把"用户反馈"从"客服工单"变成了"社区成员资格"。你不是在帮作者 debug，你是在证明这个工具在真实场景里有用（或没用）。一份负面 report 和一份正面 report 对项目同样有价值——因为它告诉下一个人"这个工具在这个场景不 work"。

七、诚实的边界

XERJ 的 README 里有一段很少见的话：

"The value is gated by memorisation: it wins on private, internal, niche or post-cutoff code, and is neutral to harmful on popular public libraries the model already knows."

翻译：如果你的代码是 React、Vue 这种模型已经背得滚瓜烂熟的流行库，XERJ 帮不了你，甚至可能有害（因为检索结果可能不如模型记忆准确）。它只在三种场景赢：

• 私有代码（模型没见过的）
• 冷门代码（模型训练数据里没覆盖的）
• cutoff 之后的代码（模型训练之后才发布的）

这种诚实很罕见。大多数项目会告诉你"它在所有场景都更好"，XERJ 告诉你"它在这些场景更好，在那些场景可能更差"。

八、为什么这件事重要

AI coding agent 的 token 消耗不是一个"省钱"问题，是一个"架构"问题。

当 agent 把整个文件塞进上下文时，它不仅浪费 token，还降低准确率——上下文越长，注意力越分散，模型越容易跑偏。XERJ 的价值不是"省了 2.7 倍 token"，是"让 agent 只看到它需要的那一段，从而更准确地回答"。

这指向一个更大的趋势：AI agent 的未来不是更大的上下文窗口，是更精准的检索。当你有 1M token 的上下文窗口时，往里塞 100 万 token 不是优势，是负担。真正的优势是只塞 1000 token，但这 1000 token 是对的。

XERJ 做的就是这件事：从"读全书"到"查目录"。看起来只是效率提升，实际上是认知模式的转变——从"给模型更多信息"到"给模型对的信息"。

链接

• 仓库：https://github.com/xerj-org/xerj
• 主页：https://xerj.org
• 案例研究：https://xerj.org/docs/case-study