想要啥在 prompt 定制就好了，让模型自己做，甚至可以让模型在生成repo map的内容中加入各个文件、各个类、各个函数的简要说明，而不是仅仅只有文件名、类名、函数名、参数名、类型。
你说的没错。但是你给我看的 project 里用的 prompt 确实很简陋，建的索引的内容很少呀。
从treesitter里捞出来的那点东西在我看来还远远不够
同意。但是这个是非 LLM 解决方案里一个很有意思的方案了。用 LLM 建索引，消耗 token 会多很多。
建索引这个任务太简单了，现在的 LLM 都能胜任的很好，模型能力提升不会提升索引的效果。还是得看怎么设计索引能够最高效的让 LLM 利用好。
我指的是如果要把建索引的任务交给 LLM 去做。建索引这个任务对于 LLM 当然是一个非常简单的任务。因为就是一个总结任务， LLM 做总结已经没有什么缺点了。未来模型进步不会在这方面有什么提升了。
往理想的说窗口大了、推理速度快了、token费用继续指数下降，甚至不需要进行索引和检索，所有文件直接扔给模型就好了，不需要rag各种折腾。
谷歌的 gemini 已经达到 100 万 token 了，100 万 token 基本上中型项目整个丢进去已经没有问题了。但是目前 LLM 的问题在于，在 100 万这个级别上虽然做检索/大海捞针的能力已经基本没有问题了，但是综合长文本上下文时，对复杂指令的遵循和创作能力会严重下降。我的经验是当 token 数来到几万时，对复杂指令的遵循能力就开始严重下降了。为什么 aider 评测认为 o1 写代码还没有 claude 好，我认为就是因为 o1 虽然推理能力最强，但是当代码库的上下文太长时，对上下文的综合运用能力下降太快。