我觉得我对Cursor的新Composer-1编码LLM过于轻视了。确实，它在某种意义上比GPT-5高效版和GPT-5-Codex差得多，因此在我架构和实施重要代码项目时，我并不认为它在我的工作流程中有位置。 另一方面，它的速度极快（不知道他们是怎么做到的；他们是在使用Groq或Cerebras硬件吗？还是因为模型非常小且高效？不太确定），仅此一点就为当代码不是那么关键，或者当你开始一个新项目而不必担心破坏现有代码时，解锁了许多新的工作流程和工作技巧。 与任何版本的GPT-5相比，它的成本也便宜得多。速度更快和成本更低的结合在使用模型的方式上创造了一些质的差异，这是我之前没有完全意识到的。当迭代的成本在时间和金钱上都如此低时，你可以进行更多的迭代。 这降低了“一次性正确”的价值；也就是说，像GPT-5 Pro这样的模型能够在没有错误的情况下第一次就完成复杂编码任务的能力（尽管即使是那个模型在这个非常严格的测试中也常常失败）。 但是如果你能关闭调试循环，并快速将错误/警告反馈到模型中，每次迭代的时间只需20秒到一分钟（而使用GPT-5高效版至少需要5到10倍的时间），那么你可以迅速解决它第一次（甚至第二、第三或第四次）所犯的所有粗心错误，并且仍然能比使用GPT-5更快地完成工作代码。 如果你在浏览器中开发某些东西，你现在可以真正通过Cursor的新浏览器标签关闭整个循环，这是我在任何编码工具中见过的最好的这种实现（远远超过使用Codex或Claude Code的Playwright MCP！）。我今天一直在使用这个提示，效果很好： “使用浏览器标签系统地探索这个应用程序，并以自然的方式使用界面；在此期间，注意开发控制台中的任何警告或错误。当你看到一个时，开始互动并迭代地诊断和修复错误和问题，然后刷新应用程序，验证错误或警告是否完全解决。在修复问题时，专注于确定错误的真正根本原因，而不是应用虚假的“创可贴”修复！” 然而，这种方法在概念和规划阶段确实会出现问题，在那里你要弄清楚要制作什么以及以高层次的最佳方式实施它。在那里，缺乏深思熟虑和探索可能会让你走上一个难以恢复的错误道路。 当你正在处理的任务远离常见编码任务的“数据流形”时，这一点更加明显。如果你正在制作另一个简单的CRUD网站，那么你可能不会太注意。如果你试图在人工生命模拟或类似的奇怪事物中开辟新天地，你会注意到这一点。 但有一种很好的混合方法效果很好：将最聪明的模型用于规划，与这些快速且便宜的模型结合，用于快速迭代。 因此，在浏览器应用中使用GPT-5 Pro来制定你的计划和初步实现，然后将其粘贴到Cursor中，开始迭代、修复和改进。它在修改现有强大基础方面要比建立该基础本身要好得多。 这一切真正闪耀的地方是，当你在一个没有截止日期或期望的新项目中玩耍和探索时。在这种情况下，速度是一个真正的游戏改变者。 这让我想起了IBM在80年代早期进行的那项研究，研究了计算机系统的延迟，发现当延迟低于某个神奇水平，比如50毫秒时，你会看到行为发生重大变化，因为人类大脑感知到它正在处理一个“实时系统”。 相反，当延迟超过甚至是一个令人惊讶的适度水平，比如500毫秒时，你会得到更少的参与感，这在心理上是有压力和令人沮丧的。当延迟飙升到几秒钟或更长时间时，人们往往会在心理上放弃，保持参与变得困难。 看到编码模型在几秒钟内做出反应，并在不到15秒内进行10次编辑，完全是与等待5分钟让GPT-5高效版有条不紊地处理某些事情的体验截然不同。 ...