放弃全量 Embedding 吧，用 Grep 优化代码库搜索才是 AI 编程的正确姿势

在开发 AI 编程助手时，很多人的第一反应是把整个代码库做全量 Embedding 向量化，或者寄希望于模型越来越长的上下文窗口，试图把所有相关文件强行塞给 LLM。但实际开发体感是，这种做法不仅 Token 成本高得离谱，而且响应速度慢到让人抓狂。最近 YC S26 的 Bullet 团队在 SWE-bench Verified 上的表现给了我很大启发：通过极致的工程链路优化，其实可以反超那些依赖超长上下文的方案。

在最新的 SWE-bench Verified 测试中，Bullet 在单次尝试中解决了 479/500 个问题，而平均每个任务的耗时仅为 119 秒。这个速度比之前的 mini-SWE-agent 快了 35% 到 67%。这种量级的提升并不是靠升级模型参数，而是把“速度”与“精准度”这两个矛盾点进行了工程拆解。

最让我感兴趣的是他们对上下文管理的处理。Bullet 实际上放弃了全量索引，转而通过优化 Grep 搜索和强制清理上下文来提升效率。在实际操作中，他们采取了非常激进的限制措施：限制工具输出的长度，自动删除过时的截图，并且最关键的一点是——不再重复读取已经加载的文件。

这解决了 AI 编程中一个非常痛的点：当模型在反复迭代代码时，上下文窗口会被大量的冗余信息和重复的文件内容迅速填满。这会导致模型出现典型的“注意力漂移”，甚至在简单的逻辑修改上产生幻觉。通过 Grep 这种精准的文本检索代替模糊的向量搜索，模型能够更快速地定位到具体的代码行，而不需要在海量的 Embedding 结果中筛选，从而保证了上下文的纯净度。

除了搜索层面的优化，Bullet 在执行链路上的压缩也非常激进。传统的 AI 编程助手通常采用“搜索 → 修改 → 验证 → 再搜索”的循环模式，这种模式导致了大量的往返次数（Round-trips），不仅增加了延迟，还浪费了大量重复的 Prompt Token。

Bullet 将工作流改为了一种更线性的处理方式：先批量进行独立调查 → 执行一次外科手术式的精准修改 → 最后进行一次集中验证。这种处理方式将往返次数降低了 16%，直接导致整体成本下降了 27%。这意味着 AI 不再是每改一行代码就跑一次验证，而是在充分调研后一次性完成修改，极大地提高了执行效率。

此外，他们在模型路由上做了一层分流，不再盲目信任单一的旗舰模型。他们会根据任务复杂度进行分流，将琐碎的简单任务交给像 Claude 3.5 Sonnet 这种响应速度更快的模型处理，避免用昂贵且慢的大模型去跑简单的代码格式化或文档查询。

这种思路给我们的启示是，在 AI 驱动的软件工程领域，单纯堆 Prompt 或依赖模型窗口大小已经进入了边际效用递减阶段。真正决定用户体感速度的，是工程链路的精简程度。对于开发者来说，响应时间从几分钟缩短到一两分钟，这不仅仅是数字的变动，而是决定了这个工具能否真正进入实时编程的工作流。与其追求一个能读完整个仓库的“全知模型”，不如构建一个能快速定位、精准修改且懂得自我清理的“高效工具”。