我正在尝试使用Cursor来全职为我自己的需求构建应用程序（在该领域有多年经验）。这可能很困难，但你能看到未来的迹象。在早期几周，我不断要想出新方法来减少意外。通过dotfile（一组Dos和Donts）进行提示注入，强制LLM在有问题的文件中为自己编写jsdoc @instructions，想出项目概述，说明不同部分的目标和职责。这一切都很不稳定，但有希望。我认为现在是时候掌握LLM作为助手，并弄清楚如何使用这个超锋利的工具发挥自己的最佳水平。我的看法是，工程师仍需要在流程中参与才能构建任何有意义的东西。要塑造代码库的橡皮泥，却不得不放弃这么多控制权，这真的很难。我看到其他人无法验证LLM的垃圾话，当使用像Composer这样的多文件编辑功能时，他们很快就陷入困境。…
源讨论作弊就是你需要的一切原帖 114 条评论 · 导入时统计这些LLM代码助手的狂热爱好者真的使用过它们吗？它们在自动补全和编写类型方面还行。但它们还不能在任何可发布的代码中编写出"80%的代码"。它们经常忽略一些小但关键的细节。那些更加热情的，比如Windsurf，会微妙地重构代码——删除或更改功能，这会让你感到困惑。编程是一个构建心理模型的过程。LLM试图取代工程中一个根本性的部分。也许它们会改进，但编写代码从来就不是困难的部分。我认为LLM更可能带来的结果是整体标准的降低，而不是所有人5倍的生产力。
完整原文把你的经验，加入这段讨论。
我也使用Cursor作为我各种项目的主开发环境。在当前AI热潮中，这听起来可能很老套，但使用Cursor获得良好结果的关键是正确管理上下文和对话长度。 对于大型项目，我发现一个良好的基准是大约300-500行的输出，以及大约12个500行的文件作为输入。在这些限制内，Cursor似乎表现得不错，但如果超出上下文窗口（即使在所谓的支持限制内），Claude Sonnet 3.5往往会忘记输入的重要属性。 另一个关键点是保持对话简短。不要将同一个对话用于多个任务，并尝试设计提示以最小化编辑的数量/大小。 我确实同意Cursor并不是万能的，但它是我发现的用于启动大型项目最好的工具之一。…
完整原文我也使用Cursor，完全理解你所说的关于未来景象的感受。Composer和自动补全功能在编写孤立的功能单元（即纯函数）方面表现不错，尤其是当这些函数很简单并且之前已经写过的时候。我很感激它节省了我搜索Google或花时间在重复工作上的时间。 我不禁想知道，LLM需要多复杂才能真正擅长多文件或跨文件的整个代码库编辑。我没有办法真正量化这一点，但我怀疑这比人们想象的要复杂得多，而且即使如此，可能还需要一种截然不同的软件开发方法。这让我想起了那些试图用视频AI制作完整电影的人——很酷的技巧，但谁想坐下来观看1.5小时的这种视频呢？这些视频与真正的电影之间的差距是巨大的，就像生产代码库与...…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。