近日，一个网友利用Cursor短短数周就开发了一个名叫Junk Mail Cleaner的垃圾邮件清理工具，并因此获利，通过口碑传播和 Google 广告，它的月经常性收入（MRR）已经快达到 1500 美元了。
他将使用过程中的的经验总结为以下七条心得：
- 提示要“自顶向下”：开发新功能时，向大型语言模型（LLM）提供提示要遵循“自顶向下”的原则。先从宏大的构想和用户目标入手，接着梳理所需的数据模型及它们之间的关系，再到具体的 API 端点和业务逻辑，最后才是用户界面组件和交互设计——这样一来，LLM 就能充分理解整个上下文，并能更智能地做出与整体架构相符的实现细节决策。
- 测试先行：引导 LLM 最有效的方式之一，就是先编写全面而完善的测试。当你有一套坚实的测试套件，能清晰地定义预期行为时，你只需将 LLM 指向那些失败的测试，并告诉它“让这些测试通过”，而无需费力地用文字描述复杂的业务需求。这样做能让你对生成的代码充满信心，确保它确实能工作并满足你的规范。
- 制定清晰的“规则”：一个好的规则文件应该涵盖你的语言/框架所有重要方面——比如如何编写整洁代码、使用哪些库、命名规范、测试方法和架构模式——并分门别类，条理清晰。内容要注重实用，多用实际例子而非抽象理论。同时，务必指明所用工具的具体版本以及代码库遵循的任何自定义模式，以确保团队成员步调一致。切忌冗长复杂，力求简洁明了。
- 善用工作区：将前端和后端代码放在同一个 Cursor 工作区中，绝对是颠覆性的体验。因为 LLM 能够一眼看清并理解你的整个技术栈。它可以追溯从 UI 组件到服务器端点的 API 调用，发现客户端数据模型和服务器响应之间的不一致，并协同调整两端代码，省去了你不断解释它们之间关联的麻烦。
- MCP 服务器：用得其所，切勿滥用：MCP 服务器通过连接外部实时数据和工具，让 Cursor 如虎添翼。我使用 Context7 来获取最新的文档，用 Task Master 来进行任务组织，其他服务器则可以连接到 GitHub、数据库和开发工具，这样 LLM 就能获取真实数据并执行除代码编写之外的操作。
- 混搭模型，各取所长：进行功能规划和架构决策时，我偏爱 Claude 4；而需要快速生成大量代码、且需要巨大上下文窗口支持时，则会选择 Gemini 2.5 Pro。至于那些真正复杂的难题，就交给 o3 了。
- 坚持最佳软件工程实践：在使用 LLM 时，务必坚守经典的软件工程原则。将问题分解成小而集中的块，保持清晰的关注点分离，并设计模块化的组件。当模型一次只解决一个特定且定义明确的问题时，它的表现会远远优于试图通过一个巨大的单一提示来构建整个功能。
最后，他建议大家关注交付效率和交付质量而非固定的工具和模式，拥抱变化，享受新工具带来的变化乐趣。没有完美的工具，小步快跑，持续迭代才是最大的秘诀。
公众号进群“入群”讨论。