背景
当初在设计 AutoCoder 的时候，为了让 AutoCoder 保持 AI Native, 我其实做了很多艰难的设计决策。其中一个非常有挑战但是我最终坚持下来的就是项目索引采用大模型而不是采用以前的各种语法分析器，从而可以一套方案就能支持几乎所有语言的索引。
这个决策虽然好处很明显，但是缺点在当时（所谓当时，其实也就两三个月前）也很明显，那就是索引构建/查询的速度和费用。
接下来我们看看为啥速度和费用会成为很大的阻碍。
速度和费用
要根据用户的需求迅速找到相关的上下文（我们设计是以文件为粒度）是一件非常困难的事情（RAG 方式不足以解决问题），所以必须要构建索引，并且能够根据索引，“智能”的根据用户的需求找到合适的一个或者多个文件作为上下文。
为此我们设计了三个级别的索引：
文件名索引
文件符号索引
文件依赖索引
因为AutoCoder 主打的是老项目的迭代，而很多老项目是很庞大的，其中第二级索引，需要对每个文件做符号抽取，这意味着如果你的整个项目所有的代码有一千万token ，那么就至少需要消耗1000w token输入和可能几十万甚至百万的token输出。
与此同时，当用户使用索引时，AutoCoder 会把用户的query以及这个索引也作为上下文也一起给到大模型，让大模型“智能”的挑出和用户query相关的文件。而这个最后的索引文件可能也比较大，导致用户每一次项目迭代可能都要消耗几万甚至几十万token.
可以看到，我们整个使用过程很 AI Native 也很暴力，导致这种量级tokens的项目，很多个人和公司其实都难以承担，其次是对于几万甚至十几万token的输入，一般模型也会很慢，不仅仅是费用的问题。
对于速度，我们通过并行化可以有效的解决，但是费用这个问题，一直让我脑袋疼，所以我多次发朋友圈说：
从算各个模型的账，到自己也感受到了费用的压力，到最后期待有个模型100万token能降到1块钱的心理路程。
百万token 一块钱时代来临
目前国内有三个模型特别亮眼：
QwenMax 无论开源还是SaaS版本综合效果好，但贵，中国的 Meta
DeepSeek 把价格做到极致，中国的 Mistral
Kimi 把窗口做到极致，而且文案能力很棒，中国的 Gemini?
DeepSeek 这次就成为了 AutoCoder 索引能力的救世主，我原先使用做了很多尝试，最终采用 Haiku 做所以构建，速度快，但费用依然有挑战：输入token 百万约1.5-2元，输出百万token 则高达8-9元, 而且 Haiku 能力有限，但整体而言在构建索引方面是可以的。
之前还试过 Yi ，因为他的模型只有 30多B, 所以价格也比较便宜，可惜效果太差，没办法用。
DeepSeek 目前在保证效果的情况下，当前的价格完全满足 AutoCoder 的索引需求，解决了辅助编程里最大的痛点,我快速的把自己的项目索引构建都切换到了DeepSeek去。
AGI到来之前，多模型组合是王道
需要多模型组合的主要原因如下：
价格不同
能力不同
每个模型在某些方面都有自己独到的能力
经过消耗至少 2000多万token的探索之后，我总结在 AutoCoder中 辅助编程的最佳模型组合：
索引构建 DeepSeek/Haiku
索引查询/AutoCoder 功能驱动 GPT3.5
代码生成 Claude Opus
知识库构建 OpenAI Embedding （Small）
此外，因为代码生成的token消耗量也很大， AutoCoder 提供了独有的 human_as_model 功能，允许你使用 web 版本的模型来完成代码生成，相当于包月，避免海量token的计费。
总结
一切来的太快。
