Hacker News 中文摘要

RSS订阅

2025年夏季与LLMs编程——最新进展 -- Coding with LLMs in the summer of 2025 – an update

原文链接 | HN讨论 | 2025-07-20 23:44:13

文章摘要

到2025年，前沿的大型语言模型（如Gemini 2.5 PRO）将显著提升程序员的能力，帮助快速发现并修复代码中的错误，加速解决方案的探索，并通过与人类设计师的合作，结合直觉与模型的知识，提出创新思路，从而大幅提高工作效率。

文章总结

2025年夏季与LLMs编程的更新

前沿的LLMs（如Gemini 2.5 PRO）凭借其对多种主题的广泛理解能力，以及能在几秒内掌握数千行代码的能力，极大地扩展和增强了程序员的能力。如果你能够清晰地描述问题，并接受与LLMs合作所需的反复交流，你将能够取得令人难以置信的成果，例如：

  1. 在代码触及用户之前消除错误：在Redis的Vector Sets实现中，我最终会消除所有错误，但许多错误在Gemini/Claude的代码审查中立即被移除。
  2. 更快地探索想法：让LLM编写临时代码，尽快测试某个解决方案是否更高效或足够好。
  3. 参与配对设计活动：将你的直觉、经验和设计品味与LLM中的博士级知识结合，LLM有时会提出愚蠢的建议，有时则会提出非常聪明的想法，而你的任务是避免局部最优和错误。
  4. 加速工作：在明确的规范下编写部分代码。
  5. 使用不熟悉的技术：例如，使用LLM作为你大脑的延伸，编写68000汇编代码用于Amiga演示。

一年半前，我写了一篇名为《2024年初的LLMs与编程》的博客文章。那时，LLMs已经很有用，但在过去的1.5年中，它们的进步彻底改变了游戏规则。然而，为了充分利用LLMs的能力，与LLMs互动的人类必须具备某些品质并遵循某些实践。

拒绝“氛围编码”
目前，LLMs是优秀的放大器，但不是优秀的独立工作者。虽然LLMs可以在严格监督下成功编写部分代码，并显著加快开发速度，但在面对复杂目标时，它们往往会产生脆弱、复杂且次优的代码库。因此，人类与LLMs的结合才能达到最高的工作质量。

提供大量上下文
在与LLMs讨论实现或修复代码时，需要提供大量信息，包括论文、目标代码库的大部分内容（如果可能的话），以及你对任务的理解。这些信息应包括：

  • 关于可能看起来不错但实际上次优的解决方案的提示。
  • 关于潜在优秀解决方案的提示。
  • 明确的目标、所需的代码风格等。

使用正确的LLMs
最著名的LLMs并不一定是最好的。编程活动应主要使用Gemini 2.5 PRO和Claude Opus 4。Gemini 2.5 PRO在语义上更强大，能发现更复杂的错误，而Claude Opus有时在编写新代码方面表现更好。对于复杂问题，至少需要两个LLMs进行反复交流，以扩大你对设计空间的理解。

结论
尽管人们对能够独立编码的代理程序非常感兴趣，但目前，通过明确地使用LLMs并保持控制，你可以最大化作为软件开发者的影响力。未来，随着AI的进步，许多编码任务将由AI单独完成，但人类仍将决定“做什么”和“怎么做”。目前，保持控制权可以让你使用LLMs编写出最精炼的代码。

你可以在学习的过程中完成那些原本超出你知识/专业范围的任务，同时保持对代码和设计的深刻理解。尽管有时可以测试代理程序的能力，但当你觉得它们无法做得和你一样好时，回到终端，借助AI进行编码（当你觉得它能提高你的输出时）。当代理程序能够出色地完成工作时，我会是第一个切换的人，但在此之前，让我们跳过炒作，以最佳方式使用AI，即保持控制权。

评论总结

评论内容主要围绕LLM（大语言模型）在编程中的应用展开，观点多样且涉及多个方面。以下是主要观点和论据的总结：

  1. LLM与代码库的兼容性：

    • 有评论者提出疑问，探讨为LLM设计的代码库应如何构建，是否应由许多小函数组成（评论1）。
    • 另一评论者提到，LLM在处理大型代码库时可能表现不佳，尤其是在中等规模任务中容易出错（评论14）。

  2. LLM工具的选择与使用体验：

    • 有用户表示在编码时更倾向于使用Claude Sonnet而非Opus，认为Sonnet更直接高效（评论4, 评论6）。
    • 也有用户对Gemini 2.5 PRO和Claude Opus 4在抽象任务（如架构设计）中的表现表示认可，但在具体编码中则表现不稳定（评论6）。

  3. 对LLM依赖的担忧：

    • 有评论者表达了对程序员过度依赖付费LLM的担忧，认为这可能导致编程工具的开源性和自由度下降（评论10）。
    • 另一评论者批评了为获取资金或竞争而推出“AI”产品的行为，认为这背离了编程的本质（评论7）。

  4. 工作流程与工具优化：

    • 有用户建议在编码过程中保持手动操作，以确保对每个步骤的控制，并推荐使用CLI工具来提高效率（评论8）。
    • 另一用户询问是否有工具可以在不依赖复制粘贴的情况下，实现更高效的代码修改和检查点管理（评论12）。

  5. LLM在编程中的实际应用：

    • 有用户分享使用Claude进行GitHub操作的经验，认为其在小型任务中表现良好，但在中等规模任务中仍需人工干预（评论14）。
    • 另一用户表示目前仅将LLM作为高级版的Stack Overflow使用，并询问如何将其更好地集成到IDE中（评论15）。

  6. 对LLM能力的质疑与反思：

    • 有评论者对“PhD-level knowledge”这一表述提出质疑，认为博士研究的主要目的是培养研究能力而非积累知识（评论5）。
    • 另一评论者强调，讨论LLM在编程中的应用时，应考虑具体领域和编程语言的影响，避免泛泛而谈（评论13）。

  7. 工具与代码库的交互：

    • 有用户询问是否有工具可以帮助LLM更好地浏览和理解代码库，而不仅仅是简单的grep操作（评论16）。
    • 另一用户询问作者的具体工作流程，是否使用CLI工具或IDE（评论17）。

总结：评论中既有对LLM在编程中潜力的认可，也有对其局限性和依赖性的担忧。用户们分享了各自的使用体验，并提出了对工具和工作流程的优化建议。同时，也有评论者对LLM的能力和应用场景提出了反思和质疑。