你需要钢铁般的意志才能与人工智能代理合作

您需要有钢铁般的意志才能与 AI 代理一起工作这篇文章将主要关注 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 中也遇到过很多这样的问题。我不知道它们是否出现在最近发布的较新的人工智能模型中。我喜欢 Composer 2.5 的地方：它的使用限制和速度。为了进行比较，我们以两项 20 美元的订阅为例，一项用于 GPT，一项用于 Cursor。使用 gpt-6.1-sol，我的 5 小时限制在几次请求后就用完了。如果我要求它更改自述文件中的几行，则会占用 10% 的限制。如果我要求它更改大型代码库中的某些内容，则只需读取数十个文件即可耗尽整个限制，而无需编写一行代码。但 GPT 还提供 100 美元的计划，使用限额是五倍。那我能坚持多久？我处理复杂的 monorepo 项目。要对一项服务进行更改，代理必须读取其他服务中的数十个文件和多项技能。如果 20 美元的计划在读取 20 个文件后用完，那么 100 美元的计划在读取 100 个文件后也会用完吗？这就是为什么我不使用 Sol，而是使用 Luna。但速度非常慢。与 Composer 2.5 相比，慢了几十倍。这就是为什么我不使用 GPT Luna，而是使用 Composer 2.5。它非常快而且非常便宜。为了换取这种速度和节省，我最终浪费了时间并感到压力很大。我在 Deepseek 和其他开放模型中遇到过一些这样的问题。有些模型存在某些问题，但其他模型则没有。即使使用相同的模型，问题的数量和频率也会有所不同，具体取决于月相。下面列出了我在 Cursor 中使用 Composer 超过 100 小时所遇到的问题。删除 代理编写代码并更改数十个文件。我开始检查代码，然后发生以下对话： - 为什么这个函数在这里？ - 你说得对。这里不需要这个函数。 （删除该功能并对许多文件进行更改） — 为什么要删除它？ - 你说得对。我不应该删除这个功能。我把它放回去了。 （再次对许多文件进行更改）我仍然没有得到为什么需要该功能的问题的答案。现在，每当我想问它一些问题时，我都必须关闭代理模式或明确告诉它不要删除任何内容。但是当我忘记这样做时，它开始删除部分代码以响应一个简单的问题。有时我会花很多时间检查代码并要求它只更改一个功能。它会更改所有已审阅的文件。而且这些变化甚至与该功能无关。它甚至可能会删除在此聊天中完成的所有工作。而且不只是在这一个。我要求它进行提交，它会发现其他文件的更改混合在一起。它只是删除它们。尽管这项工作是在其他聊天中完成的。另外，如果我要求它重构代码——例如，重命名 50 个文件中的方法——它可能会删除在这些文件中找到的所有注释。这与重构方法完全无关。然而，它并没有删除我要求它删除的内容。更改方法名称时，它会保留旧方法并使用新名称添加新方法。这就是它的整个重构过程 - 因此它不必更改调用旧方法的所有文件。它只会将旧方法标记为已弃用并使其可访问。如果我指出这一点，它最终会进行重构，但在测试和文档中保留旧的方法名称。测试将失败，它会说任务已完成并且方法已重构，但测试失败。就代理而言，失败的测试并不能视为任务未完成的证据。此外，在处理任务时，它可能会从配置或与任务完全无关的方法中删除重要参数。当被问及为什么删除该参数时，代理声称它没有删除任何内容。你必须明确要求它检查 git diff，因为它不会认为自己会这样做。就像参考一样，我已经有一个工作服务，用于侦听事件，然后更新数据库中的值并将它们写入 Redis。我要求代理在另一项服务中做完全相同的事情。它做到了，但忘记写入 Redis。或者它不会更新数据库中的值。或者它对文件和类的命名完全不同。或者它将接口和类型放在错误的位置。之后，它说一切都完成了。我要求它检查所做的一切。它检查并再次坚持一切都已完成。当然，所有测试都是绿色的，这证实了一切都已完成的结论。我必须经过很多轮，指出每个错误，以便它能够修复。在修正一个错误的同时，它引入了新的错误。我问它