我觉得我之前对 Cursor 的新 Composer-1 编码语言学习模型 (LLM) 评价过低了。当然，它肯定比 GPT-5 High Effort 和 GPT-5-Codex 差，所以从这个意义上讲，在设计和实现重要的代码项目时，我并不认为它适合我的工作流程。 另一方面，它的速度非常快（不知道他们是怎么做到的；他们使用的是 Groq 还是 Cerebras 硬件？是因为模型非常小巧高效吗？不确定），仅此一点就解锁了许多新的工作流程和工作技巧，适用于代码并非至关重要，或者当你开始一个新项目而不必担心破坏现有代码的情况。 它也比任何版本的 GPT-5 都便宜得多。速度更快、成本更低的双重优势，使得模型的使用方式发生了质的飞跃，而我之前并没有充分意识到这一点。当迭代的成本（无论从时间还是金钱方面）都如此之低时，你就可以进行更多次的迭代。 这降低了“一次性正确性”的价值；也就是说，像 GPT-5 Pro 这样的模型能够一次性正确完成复杂的编码任务而不出现任何错误（尽管即使是该模型也经常在这个非常严格的测试中失败）。 但是，如果你能够闭合调试循环，快速将错误/警告反馈给模型，并且每次迭代只需 20 秒到 1 分钟（而不是像使用 GPT-5 那样投入大量精力至少需要 5 到 10 倍的时间），那么你就可以快速解决它在第一次（甚至第二次、第三次或第四次）中犯的所有低级错误，并且仍然比使用 GPT-5 更快地完成可运行的代码。 如果你正在浏览器中进行开发，现在可以使用 Cursor 的全新浏览器标签页功能，真正实现完整的闭环开发。就我目前见过的所有编码工具而言，这绝对是此类功能的最佳实现（远胜于 Codex 的 Playwright MCP 或 Claude Code！）。今天我一直在使用这个提示，效果显著： “使用浏览器标签页系统地探索此应用，并以自然的方式使用界面；同时，请留意开发者控制台中的任何警告或错误。一旦发现，请开始交互式地、迭代地诊断和修复错误和问题，然后刷新应用并验证错误或警告是否已完全解决。修复问题时，请专注于确定错误的真正根本原因，而不是应用虚假的“创可贴”式修复！” 然而，这种方法真正的缺陷在于概念和规划阶段，在这个阶段你需要从宏观层面思考要做什么以及如何最好地实现它。缺乏深入思考和探索会让你一开始就走上一条难以挽回的歧途。 当你的任务偏离常见编码任务的“数据流形”时，这一点就更加明显了。如果你只是在做一个简单的CRUD网站，那你可能不会太在意。但如果你尝试在人工智能生命模拟或其他类似领域开辟新天地，你就会对此深有体会。 但有一种很好的混合方法，效果非常好：将最智能的规划模型与这些快速廉价的迭代模型结合起来。 所以，先用浏览器应用里的 GPT-5 Pro 制定计划和初步实施方案，然后粘贴到 Cursor 里，开始迭代、修复和改进。它更擅长修改现有的坚实基础，而不是从零开始搭建基础。 当你在一个全新的项目中，以轻松有趣的方式探索和尝试，而没有截止日期或预期目标时，这一切的优势就真正显现出来了。在这种情况下，速度至关重要。 这让我想起了 IBM 在 20 世纪 80 年代初进行的一项关于计算机系统延迟的研究，该研究发现，当延迟低于某个神奇的水平（例如 50 毫秒）时，行为会发生很大的变化，因为人脑会感知到它正在处理一个“实时系统”。 反之，即使延迟超过一个出乎意料的适中水平，比如 500 毫秒，用户参与度也会大幅下降，而且会让人感到精神疲惫和沮丧。当延迟飙升到几秒甚至更长时，人们往往会精神恍惚，难以集中注意力。 看到编码模型在几秒钟内做出响应，并在不到 15 秒内快速完成 10 次编辑，这与等待 GPT-5 高努力值模型 5 分钟有条不紊地完成某项任务完全是两种不同的体验。 总之，玩这个东西真的太有趣了。对我来说，它比任何电子游戏都更有趣、更吸引人。
正在加载线程详情
正在从 X 获取原始推文，整理成清爽的阅读视图。
通常只需几秒钟，请稍候。