原贴链接

很快我将能使用可运行大语言模型(LLM)的硬件。我的首要目标是搭建一个能迭代查看我项目中的代码并改进它们(即修复漏洞、提升性能、编写测试、简化代码和提高可读性)的东西。我设想有一个脚本,它能随机选取一个任务、项目或文件(我能想到单文件场景和整个项目场景下的任务),完成工作(理想情况下分多个步骤,如生成解决方案、评估它、改进它并重复),准备合并请求,然后无限重复这个过程。你能就达成这个目标的最佳工具和模型给我些建议吗?我的方法合理吗?有我能使用的现成解决方案吗?说实话,我有点迷茫。我读了很多关于Ollama(我已经试过了)、llama.cpp、mistral.rs、AutoGPT、LangChain等的内容,我甚至不确定我所看的工具是否适合我的用例。据我理解,我可以使用{Ollama、llama.cpp、mistral.rs}中的一个来运行本地AI服务器,然后在AutoGPT或LangChain中使用它?但然后,我如何向它提供我的项目知识呢?

编辑:

也许我一开始没说清楚。我现在想要以最明智的方式实现自动化,例如,不要重复造轮子,自GPT4发布以来我一直在做的事情,例如:

  1. 随机选取文件
  2. 使用模板,如“简化以下代码片段中的代码:{粘贴的文件}。仅输出可通过git apply应用的补丁文件”
  3. 运行git apply,构建代码,运行测试,收集输出
  4. 如果不行,收集输出,粘贴到模板中,如“它不起作用。这是输出:{…}。再试一次。”;回到3
  5. 可选:运行改进循环(将输出粘贴到模板中,如“解决方案可行。你认为它可以进一步简化吗?”。如果是,回到3
  6. git commit,git checkout -b new_branch,git push
  7. 报告合并请求
  8. git checkout master
  9. 回到1 这一切在GPT4和人工操作(例如我在ChatGPT浏览器标签、文本编辑器和终端之间操作)的情况下,大概五次中有三次可行。从那以后,我从Copilot得到了更复杂的帮助,OpenAI发布了o1 - mini,有mistral large,新的Claude,还有代理(agents)之类的,我不太清楚还有什么。直觉告诉我,这个话题已经被深入研究了,我想知道2024年末从哪里开始。我不期望它开发出需要深入理解整个代码库的完整功能。我也不期望它超级快。如果它在整个周末准备10个合并请求而我只接受1个,因为9个是幻觉,我也能接受。

讨论总结

原帖作者想要利用本地大型语言模型(LLM)持续处理自己的代码库,包括修复漏洞、提高性能等操作,对如何实现感到迷茫。评论者从不同角度进行回应,有建议用简单脚本解决的,有推荐Aider工具的,有质疑在未了解LLMs能力就投入硬件资源的,也有直接否定原帖作者想法认为目前AI无法做到这么自动化的,整体讨论氛围比较理性,大家各抒己见。

主要观点

  1. 👍 可以用简单脚本解决原帖需求。
    • 支持理由:可通过测试编译器错误输出判断有效性并反馈到循环中。
    • 反对声音:无。
  2. 🔥 推荐Aider工具可能满足需求。
    • 正方观点:Aider旨在实现相关功能。
    • 反方观点:目前可能需要LLM技术突破才能很好地满足需求。
  3. 💡 应先花费少量资金了解LLMs能力,再投入大量资金购买硬件。
    • 支持理由:避免盲目投入硬件资源。
    • 反对声音:无。
  4. 🤔 目前AI无法完全实现原帖作者所期望的对代码自动化处理的功能。
    • 正方观点:目前AI达不到AGI水平,缺乏关键能力。
    • 反方观点:无。
  5. 😎 本地LLM不如前沿模型好。
    • 支持理由:没有明确阐述,可能基于普遍认知。
    • 反对声音:无。

金句与有趣评论

  1. “😂 can’t you just do this with a simple script.”
    • 亮点:提出一种简单直接的解决思路,与原帖作者考虑众多模型工具形成对比。
  2. “🤔 Aider [https://github.com/Aider - AI/aider](https://github.com/Aider - AI/aider) aims to do that. Maybe after few ground shattering breaktroughs in LLM tech it’ll actually do that.”
    • 亮点:推荐了可能有用的工具并指出其局限性。
  3. “👀 有0种情况是不受监控的AI会使你的代码更快。”
    • 亮点:以比较绝对的表述强调AI需要监控才能提高代码速度的观点。
  4. “😏 Enough - Meringue4745: lol”
    • 亮点:用比较诙谐的表达开始否定原帖作者的观点。
  5. “🤨 Enough - Meringue4745: please stop smoking the "ai will do everything for me" drug, it’s still not feasible”
    • 亮点:形象地表达出原帖作者想法不切实际的观点。

情感分析

总体情感倾向为中性。主要分歧点在于原帖作者的设想是否可行以及在投入硬件资源前是否要先了解LLMs能力。可能的原因是大家对目前LLM技术的能力和发展程度有不同的认知,以及对资源投入的谨慎性考虑不同。

趋势与预测

  • 新兴话题:Aider工具随着LLM技术突破可能满足需求的发展方向。
  • 潜在影响:如果真的能实现这种自动化代码处理,将大大提高代码开发效率,对软件开发行业产生影响。

详细内容:

标题:探索本地 LLM 解决方案以优化代码库的热门讨论

在 Reddit 上,有一篇关于寻找本地 LLM 解决方案来持续优化代码库的帖子引起了广泛关注。该帖子的作者表示即将获得能够运行 LLM 的硬件,希望建立一个能自动处理代码优化任务的系统,比如修复错误、提升性能、编写测试、简化代码和增强可读性,并提出了一系列关于工具和模型选择的问题。此帖获得了众多回复和大量讨论。

讨论焦点主要集中在以下几个方面: 有人认为可以通过简单的脚本实现,只需测试编译器错误输出并反馈循环。也有人提到 Aider 可能有助于实现这一目标。还有人指出本地 LLM 不如前沿模型出色。

有人分享了有趣的经历,比如在使用相关工具处理一个简单的代码库时,出现了为解决问题而不断“简化”项目,甚至删除部分代码行的情况。

对于这个话题,存在不同的见解和观点。有人质疑为何在未充分了解 LLM 能力之前就投入硬件购买,而作者回应称自己清楚 LLM 的能力,目标是通过完成简单任务来优化代码库。

还有人指出,所描述的情况本质上是期望 LLM 像软件开发者一样独立处理任务,但当前技术还难以实现,因为在维护软件项目时要处理的上下文过多。尽管可以用 LLM 辅助完成单个任务,但仍需要开发者把控整体方向。例如 LLM 可能在代码优化中陷入反复修改的循环,因为难以全面考虑项目的上下文和复杂性。

有人以推迟 20 年学习正则表达式等待 AI 为例,调侃了对 AI 的过度依赖。也有人直言让大家别过度沉迷于“AI 能包办一切”的想法,目前这还不可行。

这场讨论反映出大家对于利用本地 LLM 优化代码库的期待和担忧。一方面,期待 AI 能在一定程度上协助提升代码质量;另一方面,也清醒地认识到当前技术的局限性以及仍需人工把控的重要性。未来,或许随着技术的发展,我们能更有效地利用 LLM 为软件开发带来更大的价值。