AI 编程越来越常见，但有一个问题经常被忽略：
模型开始写代码之前，必须先理解代码库。
这一步不是免费的。
劝退贴：V.PS的服务器千万别买
[AI Tools 精品 AI 工具导航] htmlvideo.ai — A Collection of Remotion Apps, Templates & Video Use Cases
Agent 需要知道哪些文件相关，哪些测试相关，哪些配置会影响结果。如果没有清晰的入口，它就只能自己搜索、读取、判断，再慢慢建立上下文。随着代码库越大，这个过程越容易变成主要成本并延缓整个工作。
事实上很多 token 并不是花在真正解决问题上，而是花在确认“该看哪里”。很多工具调用也不是为了修改代码，而是为了寻找上下文。很多返工也不是因为模型不会写代码，而是因为一开始看的地方就不对。
而代码索引工程的作用，就是提前把代码库整理成 Agent 可以查询的上下文入口。它不是把整个仓库塞给模型，也不只是关键词搜索。它更像是在代码库和 Agent 之间加了一层结构：当任务出现时，Agent 可以先知道哪些内容更相关，再开始阅读、修改和验证。
我们最近做了一个对比实验。
同一个 OpenClaw 开发任务，一边让 Codex 按普通方式自己搜索和读取代码；另一边让 Codex 先通过 ACE 调用 search_context 获取相关上下文，然后再开始工作。
有趣的是在普通流程里，Codex 完成任务用了 106 次本地命令和操作。接入代码索引后，同样任务只用了 30 次。
输入 token 也从 2,284,529 降到 786,671，减少了大约 65.6%。本地操作减少了 71.7%。换句话说，完成同样任务时，Agent 只用了原来 28.3% 的探索操作。
这就是代码索引的价值。
它不是让 AI 看起来更智能，甚至他没有对现有的工作流程做任何修改，而只是让 AI 少做无效探索，因此就节省了将近1.5m的token。
同样的，这对 subagent 也一样重要。
subagent 的准确率不一定差。多个 subagent 一起工作，有时确实能提高覆盖面。但如果没有代码索引，它们也会重复建立上下文，重复读取相同内容，重复消耗 token 和工具调用。
代码索引不是为了替代 Agent，也不是为了替代 subagent。它是为了让它们在更明确的上下文里工作。
13 个帖子 - 4 位参与者