LLM驱动的软件开发工具在主流语言和框架中表现较好，但对复杂代码库的组织能力较差，且无法自动生成生产级代码。使用LLM可能减少开发者阅读文档和深入思考的时间，导致技能退化。尽管LLM在编码工作流中易于上手，但其效果依赖于开发者对需求的清晰理解，且对非主流技术栈支持有限。

LLM驱动开发的现状

在过去四周里，我尝试了各种新的AI工具来辅助软件开发。以下是我的一些观察和总结：

LLM在编码中的应用

1. 学习曲线：将LLM（大语言模型）融入编码工作流并不复杂，几乎没有学习曲线。如果它们不适合你的工作流，可以忽略它们。
2. 局限性：
   • LLM不会神奇地生成生产就绪的代码。如果你无法阅读代码并发现问题，它们在概念验证阶段之后很难使用。
   • LLM的代码组织能力较差，尤其是在中等规模的代码库中表现不佳。它们在成熟、编写良好且有详细文档的代码库中表现更好。
   • 你需要明确自己想要什么，才能获得最佳结果。
3. 主流技术栈：LLM在非主流语言和框架中表现不佳，因此如果你希望高效使用LLM，最好选择主流技术栈。
4. 开发者技能下降：使用LLM让我减少了阅读文档和思考的时间，导致我的开发技能有所下降。

LLM驱动的编码

“代理”（agent）是当前的热门话题。代理的核心是： - 调用LLM并提供一个可以查询的本地HTTP服务器列表。 - LLM输出查询请求，而不是普通文本响应。 - 等待本地服务器响应。 - 再次调用LLM，将之前的上下文和工具响应一起传入。

代理使用的工具包括代码导航、文件编辑、运行Shell命令、网络搜索/URL抓取和MCP服务器。MCP服务器提供对现有数据的格式化访问，帮助LLM更好地处理文本。

常见问题

所有工具都存在稳定性问题。由于新模型和硬件的出现，公司正在大幅调整之前的定价策略。你可能依赖某个模型，但第二天它可能就变成了“高级”服务。此外，新工具和模型每周都在推出，需要不断更新你的设置。

测试流程

我在Python、TypeScript、Rust等语言中使用了这些工具，并进行了复杂的重构和Flutter应用开发。大多数工具表现良好，但在编写Flutter的Token Field组件时，所有LLM系统都失败了。这表明LLM在处理不常见的任务时表现不佳。

模型

目前广泛使用的模型包括Claude 4 Sonnet、Gemini 2.5 Pro和GPT 4.1/5。Claude 4在代理工作流中表现最佳，而GPT 4.1/5在遵循严格指南时表现良好。本地模型目前无法与大型闭源模型竞争。

产品

1. Github Copilot：价格实惠，支持GPT 4.1和Claude 4，但主要依赖VSCode，且功能逐渐变得复杂。
2. Claude Code Pro：终端操作，界面简陋，但优化了Claude 4的提示和工具。
3. Gemini CLI和Jules：定价混乱，模型表现良好，但Google的执行力差。
4. Kiro、Cursor、Windsurf等：这些“AI优先的IDE”大多表现不佳，定价不透明，且有时无法正常工作。

使用心得

LLM在编写Rust代码时表现出色，因为Rust编译器注重人类可读性。Python则表现较差，需要强类型支持。LLM在实现标准、编写集成测试、快速修复Sentry错误、处理新技术栈和编写小型私有软件时非常有用。然而，LLM在实现复杂功能时往往增加不必要的复杂性，导致代码重复，并可能使开发者技能下降。

结论

LLM在处理强类型语言和经过良好测试的后端应用时表现出色，但在处理复杂前端任务时表现不佳。如果你觉得LLM工具适合你的工作流，我推荐Github Copilot。但不要觉得必须使用LLM来生成代码，它们在某些任务中有用，但也有许多尚未解决的缺陷。希望未来我们能运行更轻量、专注的LLM，而不是依赖当前“越大越好”的方法。

总之，不要被炒作迷惑，但LLM确实是强大的工具。

评论主要围绕LLM（大语言模型）在编程工作流中的应用展开，观点分为支持和反对两派。

支持LLM的观点： 1. LLM在编程中的有效性：多位评论者认为LLM在特定任务中表现良好，尤其是在处理常见任务时。例如，kodisha提到LLM在生成部署文件时几乎无错误，且能大幅减少重复性工作。 - "With zero to none mistakes. Both claude and gemini are more than capable to do such task." - "It might look slow, but it actually cuts most boring and most error prone steps when developing medium to large k8s backed project."

2. LLM的适应性和学习曲线：部分评论者指出，虽然LLM的使用需要一定的适应过程，但通过调整工作流，可以显著提高效率。yogthos提到，LLM在处理常见操作时表现良好，但在处理特定业务逻辑时可能失败。
   • "Learning how to use LLMs in a coding workflow is trivial to start, but you find you get a bad taste early if you don't learn how to adapt both your workflow and its workflow."
   • "I’ve also found that writing the scaffolding for the code yourself really helps focus the agent."

反对LLM的观点： 1. LLM的局限性：一些评论者认为LLM在处理非主流语言或复杂任务时表现不佳，且存在一定的随机性。donperignon将LLM比作“老虎机”，认为其效果具有随机性。 - "LLM’s are basically glorified slot machines. Some people try very hard to come up with techniques or theories about when the slot machine is hot, it’s only an illusion." - "By being particularly bad at anything outside of the most popular languages and frameworks, LLMs force you to pick a very mainstream stack if you want to be efficient."

2. LLM的学习曲线被低估：多位评论者反驳了“LLM使用无学习曲线”的观点，认为LLM的使用需要经验和技巧，尤其是在处理非典型任务时。tptacek指出，LLM的使用并非直观，且需要深入理解。
   • "I have never heard anybody successfully using LLMs say this before. Most of what I've learned from talking to people about their workflows is counterintuitive and subtle."
   • "That right there is your learning curve! Getting LLMs to write code that's not heavily represented in their training data takes experience and skill and isn't obvious to learn."

其他观点： 1. LLM的工具选择：部分评论者提到不同LLM工具（如Claude、Gemini、Copilot等）的优缺点，并指出作者可能忽略了某些工具的功能。 - "OP did miss the vscode extension for claude code, it is still terminal based but: it show you the diff of the incoming changes in vscode ( like git )." - "There’s an IntelliJ extension for GitHub CoPilot. It’s not perfect but it’s okay."

2. LLM的长期影响：一些评论者认为LLM的应用需要更多的实验和调整，且不应过度依赖或完全否定其价值。jamboca指出，LLM应被视为工具，而非解决方案的全部。
   • "LLMs are like a lasso (and a better/worse one than traditional lassos depending on use case) but once you get your catch you still need to process it, deal with it progammatically to solve some greater problem."

总结：评论者对LLM在编程中的应用持不同看法，支持者认为其能显著提高效率，尤其是在处理常见任务时；反对者则指出其局限性和随机性，并强调LLM的使用需要一定的学习曲线和适应过程。