原贴链接

我一直使用GPT-4进行多个项目开发，但编程能力有限。想知道是否有任何大语言模型（LLM）或AI编程系统能够分析和修改高达4000行代码的文件，因为我正在处理一个较大的项目。有这样的工具存在吗？

讨论总结

本次讨论聚焦于如何利用LLM（如Gemini和Claude）处理包含多达4000行代码的大型项目。用户们分享了多种工具（如Continue、Cursor、Repopack、Zed IDE和Codeium）的使用经验，并讨论了这些工具在代码编辑和性能优化方面的优劣。同时，部分用户对直接使用LLM分析大量代码的可行性表示质疑，建议先进行代码重构以提升模块化。整体氛围积极，用户们提供了丰富的实践建议和工具推荐。

主要观点

  1. 👍 Gemini的上下文长度优势
    • 支持理由：Gemini拥有200万个token的上下文长度，足以处理4000行代码。
    • 反对声音：实际使用中，基础版本可能简化代码至失去功能。
  2. 🔥 Claude在编程方面的表现
    • 正方观点：Claude 3.5 Sonnet在编程方面表现优异，200K的上下文窗口足够使用。
    • 反方观点：成本较高，可能不适合所有用户。
  3. 💡 工具推荐
    • Continue和Cursor支持自定义LLM，功能丰富。
    • Repopack和Zed IDE提供独特的代码处理方案。
  4. 🤔 代码重构的必要性
    • 需要全部4000行代码进行推理可能是代码结构不良的标志。
    • 重构代码有助于更好地理解和模块化。
  5. 🚀 Codeium的实用价值
    • 根据块注释自动编写代码，生成高质量单元测试。

金句与有趣评论

  1. “😂 Not sure how good gemini is in coding, but it has capability to read 4000 lines of code since it has 2million tokens context length.”
    • 亮点：简洁明了地指出Gemini的上下文长度优势。
  2. “🤔 Its actually quite good at coding, not Sonnet-level, but very good still.”
    • 亮点：客观评价Gemini的编程能力。
  3. “👀 I’d still default to Claude 3.5 Sonnet: it’s better at coding and its 200K context window will suffice in most cases.”
    • 亮点：明确推荐Claude，并说明理由。
  4. “🔧 PearAI 是一个 good Cursor alternative。”
    • 亮点：提供实用的工具替代方案。
  5. “📝 如果需要所有4000行代码来拟合上下文以进行有用推理，这是一个很大的红旗，表明代码没有以良好的模块化、封装和隔离来编写。”
    • 亮点：深刻指出代码结构问题。

情感分析

总体情感倾向积极，用户们乐于分享经验和工具推荐。主要分歧点在于对不同LLM工具的性能评价及代码重构的必要性。部分用户对直接使用LLM处理大量代码表示质疑，认为应先优化代码结构。

趋势与预测

  • 新兴话题：代码重构和模块化在LLM应用中的重要性。
  • 潜在影响：随着更多高效工具的出现，LLM在大型代码库管理中的应用将更加广泛，推动编程效率的提升。

详细内容：

标题：如何为大型代码库选择最佳的语言模型

在 Reddit 上，有一个关于如何为大型代码库选择最佳语言模型的讨论引起了广泛关注。原帖作者表示自己在项目中使用 GPT4 有一段时间了，但编程能力不是很好，询问是否有能够分析和修改多达 4000 行代码的语言模型或 AI 编程系统，因为正在进行一个较大的项目。此帖获得了众多回复和讨论。

讨论焦点与观点分析： 有人提到不太确定双子座（Gemini）在编码方面的表现如何，但它因具有 200 万的令牌上下文长度，所以有读取 4000 行代码的能力。有人指出 200 万令牌远远超过 4000 行代码。还有人说会去尝试一下，也有人认为除非代码库非常大，否则仍会默认选择 Claude 3.5 Sonnet，因为它在编码方面更出色，不过价格更贵。有人分享了一些相关的工具和扩展，如 Continue 扩展、Cursor、Repopack 等。有人提到 Zed 编辑器使用的 Claude 3.5 Sonnet 服务目前免费且无速率限制。有人称自己使用 Codeium 效果很好，能根据描述编写代码和编写优秀的单元测试。有人质疑原帖作者编程能力不好却要处理 4000 行代码的需求很疯狂，作者回应称正在进行计算机视觉项目，使用了一些开源代码，所以需要用语言模型处理部分开源代码。有人指出如果需要 4000 行代码都在上下文中以进行有用的推理，那说明代码编写的模块化、封装和隔离做得不好，应先重构代码使其更模块化。还有人建议尝试 Claude 的项目功能，并认为它是一个更好的编码模型。

在这场讨论中，大家对于不同语言模型的性能、适用场景和优缺点各抒己见，也有人从代码编写规范的角度给出了建议。但对于究竟哪种语言模型是处理大型代码库的最佳选择，尚未形成完全一致的意见。