本文信息来源：tolki

在过去大约四周里，我尝试了所有新奇的、用于软件开发的人工智能工具。

先把几件事说明白：

• 学习如何在编码工作流中使用 LLMs 是很容易的。没有学习曲线。如果它们目前不适合你的工作流，你可以放心地忽略它们。
• LLMs 不会神奇地让你交付可投入生产的代码
  • 如果你无法阅读代码并发现问题，那么它们在概念验证阶段之后就很难继续使用
  • 它们的代码组织能力很差，即使在中等规模的代码库中也会迷失方向。在成熟、编写良好且文档完善的代码库中，它们表现更好。
  • 他们需要你明确知道自己的需求，才能获得最佳结果。
• 由于在除最流行的语言和框架之外表现特别差，LLMs 迫使你如果想高效，就必须选择非常主流的技术栈。
• 使用 LLMs 的确让我成为了更差的软件开发者，因为我不再像以前那样花大量时间读文档和思考。大多数经理不会写好代码并非没有原因。

LLM 驱动的编码

#

大约从一年前开始，“agents” 成了风靡一时的热词。

你要明白的是，agent 只是简单地：

• 调用一个 LLM，并给它一份可通过 JSON 有效负载查询的（本地）HTTP 服务器列表
• 它输出一个查询，而不是正常的文本回应
• 等待本地服务器响应
• 再次用与之前相同的上下文调用 LLM，并附上工具的响应

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

此外，所有“代理”都使用相同类型的工具：

• 代码导航（读取文件、grep 等）
• 文件 编辑
• 运行 shell 命令
  • 主要用于运行代码规范检查、类型检查和测试
• 网页搜索 / 获取 URL
• MCP 服务器

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

由于 LLMs 只是文本补全工具，文本格式越规范，结果越好。

这使得 MCP 对象非常有用，即便它们只是通往数据的桥梁——从技术上讲，LLMs 也可以通过 shell 命令或网络搜索获得这些数据。

产品

#

常见问题

#

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

随着公司意识到每月训练50个模型并通过出售访问来摊销成本行不通（因为不断有新模型和新硬件出现），它们正在对先前的定价承诺进行强烈的回撤。

你可能正依赖某个特定模型，结果你的供应商第二天就把它设为“高级”付费功能。

更糟的是，新工具和新模型几乎每周都会推出，要求你不断更新配置以充分利用它们。你需要修改提示词、更新 MCP、更新 LLMs 项目的上下文，诸如此类——因为它们的工作方式都有细微差别。

对于任何想要建立稳定、高效工作流程的人来说，这非常令人头疼。你无法完全依赖这些工具作为开发环境的一部分，因为你不知道它们会以现有形式持续多久，而且它们并不确定性高。

测试流程

#

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

• 使用 Python 开发
• 使用 TypeScript 开发
• 使用 Rust 开发
• 执行复杂重构，例如在 monorepo 中进行深度跨项目重构
• 制作一个 Flutter 应用

这些工具大体上如宣传所述那样工作，只有一项功能例外：

• 在 Flutter 中编写一个 Token Field。

这并不是一项特别难的任务，但这种组件比较少见，且需要大量的状态管理才能做到正确。

所有具代理性的 LLM 系统在这点上都失败了。我用 Claude Opus 4.1 和 GPT 5 试过，它们本应是那些新的、超级强大的最先进模型，但表现得很糟糕。

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

我认为这是一个很好的提醒：LLMs 在编写那些没有被重复写过数百万次的代码时总是会表现糟糕。一旦你稍微偏离常规，它们就会动摇。这也是为什么你总能看到那些老生常谈的演示，使用同样的标准组件。

Models

#

目前广泛使用的有三种模型：

• Claude 4 Sonnet
  • 如果你是百万富翁并且想尽可能多地造成污染，可以选择 Or 4.1 Opus and
• Gemini 2.5 Pro
• GPT 4.1 和 5

在执行具代理性的工作流程方面，Claude 4 远远优于另外两者。

Gemini 2.5 Pro 可能不错，但 Google 让它在任何有生产力的用途中都极其难用。

GPT 4.1 和 5 大多表现不佳， 但在严格遵循指令方面非常出色。借助大量工具，你可以从中获得相当不错的结果（见下文）。

本地模型也是一个选择，但目前它们确实无法与大型封闭模型竞争。大多数中小型模型在工具使用上表现很差，处理复杂功能也很差，而且速度会很慢。

我在本地模型上运行个人助理，但不幸的是，它们目前在生成代码方面仍然性能不足。

产品

#

Github Copilot

#

每月 10 美元，GPT-4.1 无限调用，附带相当数量的 Claude 4 调用，至 2025-08-08 也支持 GPT-5（计为高级请求）。

Github Copilot 是开创者，性价比很高。我在 2021 年参与了内测，当时令人震撼。

Github Copilot 最大的问题是它高度依赖于 VSCode，因为 Copilot Chat 扩展仅适用于 VSCode。这令人非常失望，最初 Github Copilot 在 nvim 和 Emacs 上都有运行。但自从加入聊天和智能代理功能后，他们就完全放弃支持其他 IDE。

他们的主体化工作流扩展还算不错，但随着不断往里堆叠更多功能，开始变得有些混乱：

• 经常无法正确编辑文件
• 键盘导航大多糟糕，与 VS Code 的其他部分整合也很差
• 有 3+ 模式和 5+ 模型，要在不频繁点击的情况下始终获得正确设置几乎是一团糟
• 随着每月 VS Code 更新，配置不断变化，而且一半选项根本不起作用

我认为 GitHub Copilot 是最可定制的，但这也正是它的致命弱点。

要它正确工作，你需要花数小时来设置文档欠缺的配置文件和有缺陷的选项。

情况在改善，至少他们不怕不断迭代，但要准备好每个月几乎都要复查一次你正在使用的所有功能。

Claude Code Pro

#

20 美元/月，Claude 4 Sonnet “无限”使用，但每 5 小时会重置一次限制。

Claude Code 是街区里的潮流孩子。每个人都在用 Claude Code。

所以我不得不亲自试一试。

我喜欢它完全基于终端这一点，这迫使人们建立干净且可重现的工具设置。

我不喜欢它完全基于终端的事实，因为界面非常乏味，“Vim 模式”对 Vim 用户来说是一种侮辱，在终端中阅读 Markdown 看起来也非常糟糕。

但它仍然只是 Claude 4 Sonnet。它与 GitHub Copilot 相同，但价格是后者的两倍，如果你真的只打算使用 Claude，它提供了更高的使用上限。

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

总体上还不错，我理解它为何成为市场领导者：因为它与 IDE 无关，并且大多数情况下都能完成任务。

Gemini CLI 和 Jules

#

他们的定价模式混乱得让人根本不想去试图搞清楚。

由于我参与了 Jules 的测试，我有他们的 Pro 计划。

Gemini 2.5 Pro 看起来是个不错的模型，但 Google 把一切搞得一团糟，实在难以评估：

• Jules 是一场灾难，它一次也没有在 Python 或 Flutter 仓库中成功提交过一个合适的功能，即便我付出了大量配置和努力
• Gemini Code 本应该对 1000 次请求免费 ，但你十分钟内就会触及限制。并且不知为何，它并不包含在“AI Pro”计划中

我甚至尝试通过他们的 API 访问这些模型，但它极其有漏洞且速度慢。

模型本身看起来不错，但 Google 的糟糕化已取得胜利，似乎再也没有称职的软件开发者了。我很清楚，我有很多朋友在那儿工作。

Kiro、Cursor、Windsurf 等

#

所有所谓的“AI 优先 IDE”都挺糟的。它们定价不透明，提示词和系统封闭且不开源，有时根本无法使用，因为它们试图提供会把自己搞垮的免费试用（看你，Kiro）。

我觉得用完整的 IDE 并不是使用 LLMs 的合适工具。

关于 LLMs 产品的结语

#

我理想中的 LLM 工具是一个超轻量的客户端，以终端作为 LLM 工具的主要交互界面，但侧边有一个 webview 供 LLM 显示信息/导航变更。

把 IDE 的所有界面都加进来对 LLM 驱动的工作流来说只是杂乱，但完全停留在终端对我来说又有点过于枯燥。

使用感想

#

语言表现

#

我想花一点时间强调一下 LLM 代理在编写 Rust 代码方面的出色表现。

由于 Rust 编译器非常注重可读性，它与 LLM 代理非常契合。编译器的输出总是指向修复问题的正确方法。

另一面，尽管 LLMs 在 Python 上有大量训练数据，Python 实际上并不太适合。要想让 LLMs 真正有用，你需要在整个 Python 代码中广泛设置强类型。

最佳使用场景

#

LLMs 在以下情况下对我帮助很大：

• 处理成熟的标准并实现它们
  • 例如，为 Markdown 的序列化和反序列化编写 Rust trait，并使用宏生成更新函数
• 编写集成测试
  • LLMs 擅长生成所有样板代码和用于高质量测试的初始数据
• 快速修复 Sentry 错误
  • 使用 Sentry MCP 时，我常常只需将一个问题的 URL 粘贴给代理，如果问题不太复杂，它就能修复该问题
• 使用新的技术栈
  • LLMs 非常擅长处理大量文档并据此实现功能，同时还能以 Markdown 文件的形式将这些信息以回顾的方式反馈给你
• 构建小型、私密且可替换的软件组件
  • 我为工作写了一个命令行日志查看与查询工具，非常有用，但如果我自己写的话大概需要几天时间（约 3k 行代码）

不足之处

#

LLM 代理在实现功能时常常加入不必要的复杂性，产生大量代码重复，并且会让你的开发水平变差。

每次我尝试在工作中用 LLM 实现应用程序的核心功能时，得到的实现都值得怀疑，而且我花在重写这些代码上的时间至少和从头编写它们所需的时间一样多。

在前端方面，agents 在编写良好、可维护、遵循 DRY 原则的软件上确实很挣扎。所有模型到处都使用魔数，即使被要求不要这么做，键盘交互实现得很差，有些控件要经过 5 次以上的提示才能做到位。

尤其是 Flutter，很难让 LLMs 正确地生成代码，尽管它是相当流行的语言。React 要好得多，但我不喜欢 LLM agents 促使你去使用最流行的语言和框架，而不论其质量如何。

结论

#

借助 agentic 工作流以及对检查和测试输出的访问，LLMs 在与强类型语言交互方面变得非常擅长。

它们在处理经过充分测试的后端应用时表现出色，因为强类型系统和对测试的重视让 LLMs 很难犯错。

关于前端，我的看法更为分裂。LLMs 非常适合基于流行语言和常见组件库创建简单界面。但如果你有明确的愿景，包含复杂的键盘交互和自定义组件，情况会很快变糟。

如果你觉得 LLM 工具适合你的软件开发工作流程，我目前的推荐是 GitHub Copilot。它性价比高，高度可定制，便于你尝试并了解其工作原理。

但也不要觉得你被逼着必须使用 LLM 来生成代码。它们在某些工作上是很好的工具，但自诞生以来仍存在许多未解决的缺陷，而以当前的方法看来这些问题难以解决。由于设计原因，它们的知识总会过时，而且总是对流行的、广泛使用的库有很大偏向。

我也真心希望炒作能平息，并且我们能很快运行更轻量、更专注的 LLM。当前“运行尽可能大的 LLM 并让它做所有事”的做法，在我看来是个可怕的主意。它消耗的能量远超所需，而且无论如何在大多数语言上的表现都很糟糕。

我就说到这里。别被炒作冲昏头脑，但也别忽视，它们有时确实是强大的工具。