原贴链接

我有一个大型的TypeScript项目（单仓库），目前使用Claude - dev针对我的代码库提问或进行修改。是否有办法将我的整个代码库提供给一个大语言模型（LLM）以便我能与之聊天？我曾想过进行索引并为整个代码库创建嵌入的方法。Claude的项目接受的文件很少，如果我选择整个代码库，continue.dev的API经常失败，而且总体上限制太多。我更希望它是开源的。当前的技术水平如何呢？

讨论总结

原帖寻求一种能让大型代码库被大型语言模型（LLM）吸收以用于聊天的开源方案。评论者们给出了多种建议，包括continue.dev、Seagoat项目、Aider等开源或技术相关的解决方案，也针对不同大小代码库给出了不同的应对策略，整体氛围较为积极地提供解决方案。

主要观点

  1. 👍 推荐continue.dev为开源中的优秀选择。
    • 支持理由：在开源领域属于顶尖的存在。
    • 反对声音：无。
  2. 🔥 推荐github上的Seagoat项目以解决将整个代码库用于聊天的需求。
    • 正方观点：直接提供了项目名称，可能满足需求。
    • 反方观点：无。
  3. 💡 推荐Aider为开源替代方案。
    • 正方观点：通过提供存储库映射处理项目上下文，可连接多种LLM包括本地模型。
    • 反方观点：无。
  4. 💡 小代码库可尝试Gemini模型。
    • 正方观点：可用于小代码库处理。
    • 反方观点：无。
  5. 💡 大代码库的一种解决办法是嵌入向量存储再聊天。
    • 正方观点：是一种处理大代码库的可行方式。
    • 反方观点：无。

金句与有趣评论

  1. “😂 continue.dev would be amongst the top of the line in what you can get in Open Source”
    • 亮点：对continue.dev在开源中的地位给予肯定。
  2. “🤔 If your codebase is still relatively small - use tools like repopack for full in - context editing”
    • 亮点：针对小代码库给出了工具推荐。
  3. “👀 Try taking a look at Gemini APIs, they have very large context window.”
    • 亮点：指出Gemini APIs的上下文窗口大的优势。

情感分析

总体情感倾向为积极，主要是大家都在积极地提供解决方案。没有明显的分歧点，可能是因为大家都聚焦于解决原帖提出的技术问题，没有涉及到争议性较大的话题。

趋势与预测

  • 新兴话题：构建自己的检索增强生成（RAG）之前先在NotebookLM上验证概念可能会引发后续讨论。
  • 潜在影响：这些方案如果被广泛采用，可能会提高代码库与LLM交互的效率，对相关的软件开发和代码管理领域产生积极影响。

详细内容：

《探索能否将整个代码库融入 LLM 以实现聊天互动》

在 Reddit 上，有一则引发广泛关注的帖子，标题为“Is there an LLM that can assimilate an entire codebase for chatting?”。该帖子称，发帖者拥有一个大型的 TypeScript 单仓库项目，目前使用 Claude-dev 来询问关于代码库的问题或进行更改，但遇到了诸多限制。比如 Claude 的项目能接受的文件数量很少，continue.dev 的 API 在选择整个代码库时经常出错。发帖者希望能找到一种方法将整个代码库喂给 LLM 以便进行聊天，还提到曾考虑过对整个代码库进行索引和创建嵌入的方式。此帖获得了大量的点赞和众多评论。

在讨论中，各种观点精彩纷呈。有人指出 continue.dev 在开源领域算是顶尖的，如果代码库相对较小，可以使用像 repopack 这样的工具进行全上下文编辑。也有人推荐结合 ollama 后端与 qwen2.5 或 deep seek，如果 GPU 能够承受。还有人建议试试 Seagoat 项目。

有人表示，如果要导入整个代码，模型需要有大于整个代码库的上下文长度，对于小项目可以尝试使用 Gemini 模型。比如在https://docs.codes/，会使用 Gemini Flash 1.5 来处理整个库源并生成文档。

另外，有人提到如果代码库较大，有两个选择。一是使用嵌入模型将代码库嵌入向量存储，然后进行聊天，其在https://www.patched.codes/有相关实现。二是使用短期记忆，让 LLM 在推理/聊天期间能够访问它，通过开源的优化推理代理 optillm 中的内存插件实现了短期记忆，并在大型上下文基准测试中取得了良好的结果。

还有人推荐了 Aider，称其通过向 LLM 提供仓库地图来处理项目的上下文，并且在回答问题时添加特定文件到聊天上下文，还可以连接到 LiteLLM 支持的所有 LLM，包括本地模型。

有人建议试试 Gemini APIs，或者使用 Cursor。有人分享将每一行代码编译为 txt 并上传到 notebooklm 的方法。也有人觉得 Cursor 的@codebase 非常好。有人提到 continue.dev 的默认上下文只有 8k，可以尝试调高。

还有人提出在构建自己的 RAG 之前，先在 NotebookLM 上验证概念。有人指出将源代码文件嵌入并用于自然语言处理可能很棘手，Codeium 通过生成并添加类似人类的代码描述来缓解这个问题。

在这场讨论中，大家对于如何解决将整个代码库融入 LLM 以实现聊天互动的问题各抒己见，既有针对不同情况的实用建议，也有对技术难点的深入探讨。但目前尚未形成统一的最佳解决方案，仍需根据具体情况进行尝试和探索。