LLM 驱动开发现状深度分析

我在过去大约 4 周内试用了所有新的、花哨的 AI 软件开发工具。

让我们先把几件事说清楚：

学习如何在编码工作流中使用 LLM 是微不足道的。没有学习曲线。如果它们暂时不适合你的工作流，你可以安全地忽略它们。

LLM 不会神奇地让你交付生产级代码。如果你不能读懂代码并发现问题，那么它们很难在 PoC 阶段之外使用。它们代码组织能力糟糕，容易在中等规模的代码库中迷失方向。它们在成熟、编写良好、文档齐全的代码库上表现更好。它们需要你知道你想要什么才能获得最佳效果。

通过在最流行的语言和框架之外的任何东西上都特别差劲，LLM 强制你选择一个非常主流的技术栈，如果你想要高效的话。

使用 LLM 确实让我成为了一个更差的软件开发者，因为我没有像以前那样花费那么多时间阅读文档和思考。大多数经理写不好代码是有原因的。

从大约一年前开始，「agent」开始流行起来。

你需要理解的是 agent 就是：

调用 LLM 并给它一个（本地）HTTP 服务器列表，它可以用 JSON 有效负载查询

它输出一个查询而不是普通的文本响应

等待本地服务器响应

再次调用 LLM，使用与之前相同的上下文加上工具的响应

就这样。没有魔法在起作用，没有真正的反思，只是让 LLM 决定通过调用 API 来回答，然后把响应反馈给它们并重新启动这个过程。

此外，所有「agent」都使用相同类型的工具：

代码导航（读文件、grep 等）

运行 shell 命令，主要用于运行 linting、类型检查和测试

Web 搜索/URL 获取

MCP 服务器都大致拥有相同的功能：以格式化的方式提供对现有数据的访问。例如，它可以提供对 Github 仓库中搜索的结构化访问，或者一个小部件树。

由于 LLM 本质上是文本完成工具，文本格式化得越好，你获得的结果就越好。

这使得 MCP 非常有用，尽管它们只是通往 LLM 在技术上可以通过 shell 命令或 web 搜索访问的数据的桥梁。

下面的所有工具都有一个明显的问题：稳定性。

随着公司意识到每月训练 50 个模型并计划通过销售访问权限来分摊成本因为新模型和新硬件而行不通，他们正在大力回退之前的定价承诺。

你可能依赖于一个特定的模型，供应商可能在第二天把它变成「高级」的。

雪上加霜的是，新工具和模型每周都会出现，要求你更新你的设置以获得最佳效果。你需要改变你的 prompt、更新 MCP、更新 LLM 项目上下文，等等，因为它们的工作方式都略有不同。

对于任何试图建立稳定、高效工作流的人来说，这都非常烦人。你不能完全依赖这些工具作为开发设置的一部分，因为你不知道它们会保持当前状态多久，而且它们不是确定性的。

我在工作和个人项目中都使用过这些工具，其中包括：

使用 TypeScript

执行复杂的重构，例如 monorepo 中的深度跨项目重构

这些工具基本上按照宣传的方式工作，除了一个功能：

在 Flutter 中编写一个 Token Field。

这不是一个特别困难的任务，但它在组件方面处于相对罕见的一侧，需要大量的状态管理来正确完成。

每一个 agentic LLM 系统都在它上面失败了。我用 Claude Opus 4.1 和 GPT 5 尝试过，它们应该是那些新的、超级有能力的最先进的模型，但它们表现得非常糟糕。

小部件通常看起来很糟糕，键盘交互不一致，它们写的验证行为的测试没有验证任何东西。

我认为这是一个很好的提醒：LLM 总是会在编写没有被写过数百万次的代码上表现糟糕。一旦你稍微偏离主路，它们就会动摇。这就是为什么你总是看到相同的疲惫演示，有相同的库存组件。

目前广泛使用的有 3 个模型：

Claude 4 Sonnet，或者如果你是百万富翁并想尽可能多地污染的话用 4.1 Opus

Claude 4 在 agentic 工作流方面大大优于其他两个。

Gemini 2.5 Pro 可能不错，但 Google 使用它进行任何有成效的工作都令人难以忍受地困难。

GPT 4.1 和 5 基本上很糟糕，但在遵循严格的指导方针方面非常好。有了很多工具，你可以从它那里获得不错的结果（见下文）。

本地模型也是一个选择，但目前它们真的无法与巨大的闭源模型竞争。大多数小型-中型模型在工具方面表现糟糕，在复杂功能方面表现糟糕，而且速度会非常慢。

我用本地模型作为我的私人个人助手，但对于生成代码来说，它们目前太不强大了。

Github Copilot

10$/月，无限 GPT4.1 调用，很不错的 Claude 4 调用数作为额外，GPT 5 也是（自 2025-08-08 起计为高级请求）。

Github Copilot 是最初的，对于价格来说是巨大的价值。我在 2021 年是 alpha 的一部分，当时它令人震惊。

Github Copilot 的最大问题是它与 VSCode 高度绑定，因为 Copilot Chat 扩展是特定于 VSCode 的。这非常令人失望，因为最初 Github Copilot 在 nvim 和 Emacs 上工作。但由于添加了聊天和 agentic 功能，他们完全放弃了对其他 IDE 的支持。

他们的 agentic 工作流扩展还不错，但随着他们越来越多地将功能堆积到其中，它开始变得混乱：

它经常无法编辑文件

键盘导航大多很糟糕，与 VS Code 的其他部分集成得很差

有 3+ 种模式和 5+ 种模型，很难在任何时候不到处点击就获得正确的设置

配置每月随着新的 VS Code 发布而改变，一半的选项不工作

我会说 Github Copilot 是最可定制的，但这也是它的弱点。

要让它做正确的事情，你需要花费数小时设置文档不齐全和错误的配置文件和选项。

它正在变得更好，至少他们不害怕迭代，但准备好吧，每个月你基本上都需要审查你使用的所有功能。

Claude Code

20$/月，Claude 4 Sonnet「无限」，限制每 5 小时重置一次。

Claude Code 是块中的酷孩子。每个人都使用 Claude Code。

所以我不得不尝试一下。

我喜欢它完全是基于终端的这一事实，强制人们建立干净和可重复的工具设置。

我不喜欢它完全是基于终端的这一事实，因为界面非常不足，「Vim 模式」是对 Vim 用户的侮辱，在终端中读取 markdown 看起来很糟糕。

但它仍然只是 Claude 4 Sonnet。它与 Github Copilot 的相同，但价格是两倍，但如果你计划真的只使用 Claude，使用限制会更高。

我在 Claude Code 上修复问题的成功也比 Github Copilot 在某些情况下更多，尽管它们使用相同的模型。看起来 prompt 和工具对 Claude 4 的优化略有不同。

总的来说还不错，我理解为什么它是市场领导者，因为它与 IDE 无关，大多数时候都能完成工作。

Gemini CLI 和 Jules

他们的定价模式是如此的混乱，我甚至不会尝试理解它。

由于我参与 Jules beta，我有他们的 Pro 计划。

Gemini 2.5 Pro 看起来是一个不错的模型，但 Google 搞砸了一切，太糟糕了，以至于很难评估它：

Jules 是一场灾难，它在 Python 或 Flutter 仓库中都没有一次落地一个合适的功能，即使有我的大量配置和努力

Gemini Code 应该对 1000 个请求免费，除非你在 10 分钟内就达到限制。而且出于某种原因，它不是「AI Pro」计划的一部分

我甚至尝试通过他们的 API 访问模型，但它非常错误和缓慢。

这个模型看起来不错，但 Google 的 enshittification 赢了，看起来没有有能力的软件开发者留下了。我会知道，我的许多朋友在那里工作。

Kiro、Cursor、Windsurf 等

所有「AI-first IDE」都有点糟糕。他们有不透明的定价、闭源 prompt 和系统，有时根本不工作，因为他们尝试提供免费试用会毁掉他们（看你，Kiro）。

我觉得一个完整的 IDE 不是使用 LLM 的正确工具。

LLM 产品的结束语

我完美的 LLM 工具将是一个超轻量级的客户端，终端作为 LLM 工具的主要交互，但侧边有一个 webview 让 LLM 显示信息/导航变更。

添加 IDE 的所有界面对于 LLM 供电的工作流来说只是杂乱，但停留在 100% 的终端中对我来说也有点太干燥了。

语言性能

我想花一秒钟突出 LLM agent 在编写 Rust 代码方面有多好。

由于 Rust 编译器如此关注人类可读性，它与 LLM agent 完美匹配。编译器输出总是指向修复问题的正确方式。

另一方面，Python 是一个相当糟糕的匹配，尽管 LLM 有那么多的训练数据。如果你想让 LLM 真正有帮助，你需要在整个 python 代码中设置强类型。

LLM 一直帮助我的情况

使用良好建立的标准并实现它们，例如，编写一个 Rust trait 用于 Markdown 序列化和反序列化，带有生成更新函数的宏

编写集成测试，LLM 很擅长创建高质量测试所需的所有样板和种子数据

使用 Sentry 错误快速修复，有 Sentry MCP，我通常能够只粘贴一个问题 URL 给 agent，如果它不太复杂的话让它修复问题

使用新堆栈工作，LLM 非常擅长处理大量文档并基于它实现功能，但也将该信息传回给你在 markdown 文件中的摘要

制作小的、私人的、可替换的软件，我为我的工作做了一个 CLI 日志查看器和查询程序，这非常有用，但需要花费我几天来写（~3k LoC）

LLM agent 的缺陷

LLM agent 经常在功能实现中增加不必要的复杂性，它们创建大量代码重复，并让你成为一个更差的开发者。

每次我尝试为我在工作中开发的应用程序的核心功能使用 LLM 时，实现都是可疑的，我花费的时间重写代码至少和从头开始写代码一样多。

关于前端，agent 真的很难制作好的、可维护的、DRY 软件。所有模型到处使用魔数，甚至在被要求不这样做的时候，键盘交互实现得很差，某些小部件需要 5+ 个 prompt 来正确。

Flutter 特别难让 LLM 正确编写，尽管它是一种相当流行的语言。使用 React 要好得多，但我不喜欢 LLM agent 推动你只是使用最流行的语言和框架的方式，不管它们的质量如何。

有了 agentic 工作流和对检查和测试输出的访问，LLM 在与强类型语言交互方面变得非常好。

它们在使用经过充分测试的后端应用程序方面表现出色，因为强类型系统和对测试的关注使得 LLM 很难出错。

关于前端，我更分裂。LLM 在基于广泛语言和广泛组件库的流行语言创建简单接口方面很好。但如果你有一个明确的想法，具有复杂的键盘交互和自定义组件，它很快就会出问题。

最后的建议

如果你认为 LLM 工具非常适合你的软件开发工作流，我目前的建议是 Github Copilot。对于价格来说这是很好的价值，其高度的可定制性让你尝试事物以理解事物的工作方式。

但同样，不要觉得你被迫使用 LLM 来生成代码。它们是某些工作的好工具，但它们也仍然有许多自其成立以来就没有修复的缺陷，看起来用目前的方法也无法解决。因为他们的设计，他们的知识将永远过时，他们对流行的、广泛的库将始终有巨大的偏见。

我也衷心希望炒作消退，不久我们将能够运行更轻、更专注的 LLM。目前「运行最大可能的 LLM 并让它做所有事情」的方法，在我看来，是一个可怕的想法。它燃烧的能量比需要的多得多，而且在大多数语言上都表现很糟糕。

对我来说就这样了。不要被炒作所迷惑，但同时，它们有时确实是强大的工具。