与 AI 智能体协作需要钢铁般的神经：Cursor Composer 2.5 实测问题清单

本文将主要聚焦 Cursor 中的 Composer 2.5。这些问题在 opus-5.5 或 gpt-6.1-sol-pro-max-ultra-thinking-fast 中可能并不存在。但例如 gpt-6.1-luna，就存在这里列出的所有问题。我之前在 gpt-5.5 和 opus-4.6 中也遇到过其中许多问题。我不知道最近发布的新款 AI 模型中是否也存在这些问题。

我喜欢 Composer 2.5 的地方：它的使用限额和速度。

作为对比，我们拿两个 20 美元的订阅来说，一个用于 GPT，一个用于 Cursor。使用 gpt-6.1-sol 时，我的 5 小时限额在几次请求后就耗尽了。如果我让它修改 readme 文件中的几行，那就会用掉限额的 10%。如果我让它在一个大型代码库中修改某些内容，光是读取几十个文件就会耗尽整个限额，一行代码都还没写。

但 GPT 也提供 100 美元的套餐，使用限额是五倍。那能撑多久呢？我处理的是复杂的 monorepo 项目。要修改一个服务，agent 必须读取其他服务中的几十个文件以及若干技能。如果 20 美元的套餐在读取 20 个文件后就耗尽，那 100 美元的套餐会在读取 100 个文件后耗尽吗？

这就是为什么我不用 Sol，而改用 Luna。但它非常慢。与 Composer 2.5 相比，它慢了几十倍。

这就是为什么我不用 GPT Luna，而改用 Composer 2.5。它非常快，也非常便宜。而作为换取这种速度和节省的代价，我最终浪费了时间，还倍感压力。我在 Deepseek 和其他开源模型中也遇到过其中一些问题。有些模型存在某些问题，但没有另一些问题。即使使用同一个模型，问题的数量和频率也会变化，取决于月相。

以下是我在 Cursor 中使用 Composer 超过 100 小时所遇到的问题列表。

删除

agent 编写代码并修改了几十个文件。我开始审查代码，随后发生了以下对话：

— 这个函数为什么在这里？
— 你说得对。这里不需要这个函数。（删除该函数并对许多文件进行修改）
— 你为什么删掉它？
— 你说得对。我不该删除那个函数。我把它放回去。（再次对许多文件进行修改）

而我始终没有得到关于为什么需要那个函数这个问题的答案。

现在，每当我想问它一些事情时，我都必须关闭 agent 模式，或者明确告诉它不要删除任何东西。但当我忘记这样做时，它就会为了回答一个简单的问题而开始删除部分代码。

有时我花大量时间审查代码，然后让它只修改一个函数。它却修改了所有已经审查过的文件。而且这些修改甚至与那个函数无关。

它甚至可能删除此聊天中完成的所有工作。而且不只是在这一次聊天中。我让它提交，它发现混入了其他文件的更改。然后它就删掉了它们。尽管那些工作是在其他聊天中完成的。

另外，如果我让它重构代码——例如，在 50 个文件中重命名一个方法——它可能会删除在这些文件中找到的所有注释。而这与重构该方法完全无关。

然而，它并不会删除我要求它删除的内容。当更改方法名称时，它会保留旧方法，并添加一个使用新名称的新方法。这就是它的整个重构过程——这样它就不必更改所有调用旧方法的文件。它只会将旧方法标记为已弃用并保持其可访问。如果我指出这一点，它最终会进行重构，但会在测试和文档中保留旧方法名。测试会失败，而它会说任务已完成、方法已重构，但测试却失败了。就这个智能体而言，失败的测试并不算任务未完成的证据。

另外，在处理任务时，它可能会从配置或与任务完全无关的方法中移除一个重要参数。当被问及为何移除该参数时，智能体声称它没有移除任何东西。你必须明确要求它检查 git diff，因为它自己不会想到这么做。

就像参考实现那样做就行

我已经有一个可用的服务，它监听事件，然后更新数据库中的值并将其写入 Redis。我要求智能体在另一个服务中做完全相同的事情。

它做了，但忘了写入 Redis。或者没有更新数据库中的值。或者文件和类的命名完全不同。或者把接口和类型放错了位置。之后，它说一切都完成了。我要求它检查它所做的所有事情。它检查后再次坚称一切都完成了。当然，所有测试都是绿的，这证实了它关于一切完成的结论。我不得不经过许多轮，指出每一个错误以便它修复。在修复一个错误的同时，它又引入了新的错误。

我再次要求它通读代码并确保一切与另一个服务匹配。它更改了许多文件并说一切都完成了。我打开第一个文件，发现全是错的。我再次写信给它，它回复说一切都完成了。我打开下一个文件，还是同样的故事。更有甚者，我甚至可以指出单个文件中的特定函数，并解释它们与参考实现的差异。它修复一个，我们继续下一个函数，它也修复了那个。它甚至无法让单个文件与参考实现匹配。

让我们回到那个监听事件的服务。它有用于与消息代理交互的共享、可复用的方法。智能体甚至做对了一切，使用了那些方法而不是重复它们。但它忘了添加类型，我指出了这一点。而它没有添加接口，不知为何决定从共享方法中复制数百行代码。

测试

它在测试方面普遍有困难。我给它明确的指示：首先，添加一个测试；运行测试；确保它失败；告诉我它为什么失败；然后修复代码并再次运行测试，以便所有测试都通过。

AI 智能体的做法是：它立即更改代码。然后它创建一个不会失败的测试，并告诉我任务已完成。结果，我无法验证在代码修复之前测试是否会失败。或者代码是否真的修复了任何东西。

这种情况已经发生过太多次，以至于我专门为它创建了一个单独的命令。而且在 agent 开始遵循指令之前，我不得不对它进行了多次修改。但它仍然不能完美运行。在某个随机的时刻，取决于行星的排列，它又开始编辑代码，而不先创建一个测试。

有时，为了创建一个失败的测试，它会使用一个聪明的技巧。聊天中已经有一个关于 JSON 数据解析器的讨论。我发送一个新的、20 行的小型 JSON 输入，并要求它先写一个失败的测试。它将输入数据连同解析器的预期输出一起添加到测试中。而为了让测试失败，它只是简单地更改预期输出中的一个随机字段，并报告测试已失败，现在可以更改代码了。

该项目有一个完善的测试结构。每个解析器方法的测试夹具存储在单独的目录中。当我们需要向解析器添加一个新方法时，我们只需添加一个带有夹具的新目录并修改解析器代码。测试会遍历所有夹具并检查没有破坏任何东西。

所有这些都在 agent 的技能和规则中有所描述。当 agent 开始处理测试时，我可以看到它首先阅读这些技能。在大多数情况下，它遵循这个结构。但在某个随机的时刻，它停止遵循它，并直接将夹具添加到测试代码中。我必须指出这一点，然后它才将它们移到单独的文件中。在同一聊天中的几条消息之后，它又犯了同样的错误。

如果它向 API 请求添加一个参数，在运行测试时模式验证会失败。它使用另一个聪明的技巧：它只是禁用模式验证或允许模式中的任何未知参数。然后测试又通过了。

还有另一个案例。我要求 agent 编写一个通过 API 请求添加数据的测试。agent 花了很长时间试图让测试通过。于是它决定干脆在测试中跳过调用 API 路由，直接将数据写入数据库。测试确实开始通过了，数据也被添加到了数据库中，但实际上并没有发出任何 API 请求。

无法改变回复风格

近几个月来，我越来越频繁地注意到句子结构中的一种新模式。以下是一些例子：

“我读了文本”和“我理解了文本的含义”之间是有区别的。
我们太经常把“我习惯了”误认为“我喜欢”。
从“我害怕犯错”到“我准备好尝试”可能需要数年时间。

每个句子都包含两个引号中的短语，遵循相同的文体模式。我不知道这种模式从何而来，但我以前没见过。现在 AI 模型这样交流，我也在文章和视频中注意到这种风格。也许它是“不是 X，而是 Y”的改进版本？尽管这些并不完全是对偶。

无论我多么努力地改变 agent 的规则和技能，它们仍然使用这种技巧。更糟糕的是，Composer 将这两种技巧中最糟糕的部分结合在一起，现在这样对我写道：

这不是“API 无法启动”。而是“前端无法连接”。

它几乎在每次回复中都使用引号。引号被用在完全不应该用的地方。例如，这里：

我将 API“连接”到了服务。
服务“启动”了，但无法“处理”传入的请求。
我在发送请求之前添加了一个“状态检查”。

我受够了从 agent 那里读到这种文字。而如果我指出这一点，接下来的对话就会是这样：

— 规则禁止在文本中使用引号。你为什么又用了？
— 你说得对，我不该使用引号。既然你已经向我指出了这一点，我再也不会使用引号了。
— 但你的记忆不会在聊天之间保留。
— 你完全正确。为了确保我在新聊天中始终遵守这条规则，需要把它移到列表的最顶部。

好，我们把规则移到顶部。在下一次回复中，就在同一个聊天里，我又收到了带引号的文字。

文章结束

现在你知道如果你决定在 Cursor 中使用 Composer 2.5 会面临什么了。

而为了避免这些问题，你只需要使用几天前发布的新前沿模型，无论你何时读到这篇文章。

← 上一篇 Reddit 上的账号封禁