我高效使用cursor的一些经验
2025年3月8日
作者：namanyayg
自从Cursor AI推出以来，我在构建我的SaaS时一直在使用它，并且有一些想法。
互联网似乎在“AI编码是奇迹”和“AI编码是垃圾”之间分裂。老实说，它介于两者之间。
有些日子，Cursor帮助我以创纪录的速度完成任务。其他日子，我却浪费了几个小时与它的建议作斗争。
在从我的错误中学习后，我想分享一些作为独立开发者对我真正有效的东西。
设置一个真正有用的.cursorrules文件
对我来说，最大的改变是创建一个.cursorrules文件。它基本上是一组指令，告诉Cursor如何为你的特定项目生成代码。
我的核心文件非常简单——大约10行，涵盖了我遇到的最常见问题。例如，Cursor总是给出注释而不是写实际的代码。我的规则文件中的一行永远解决了这个问题。
以下是我的文件开头的样子：
* 仅修改与特定请求直接相关的代码。避免更改无关的功能。
* 永远不要用占位符替换代码，如`// ... 其余的处理 ...`。始终包含完整的代码。
* 将问题分解为更小的步骤。在实施之前，分别思考每个步骤。
* 在进行更改之前，始终提供基于代码和日志证据的完整计划和推理。
* 清晰地解释你的观察，然后提供推理以识别确切的问题。必要时添加控制台日志以收集更多信息。
不要过度思考你的规则文件。从小开始，并在你注意到Cursor犯同样的错误两次时添加内容。你不需要任何冗长或复杂的规则，Cursor使用的是最先进的模型，已经知道大部分需要知道的内容。
我继续在“规则”文件的其余部分中详细介绍我的项目的技术概述。我描述项目的目的、工作原理、重要文件、使用的核心算法以及根据项目的其他细节。我过去是手动完成的，但现在我只需使用我自己的工具生成它。
给Cursor提供所需的上下文
我最大的“恍然大悟”时刻是意识到，当Cursor能够看到我已经写过的类似代码时，它的工作效果要好得多。
现在，我不再只是问“制作一个下拉菜单组件”，而是说“制作一个类似于u/components/Select.tsx中的Select组件的下拉菜单组件。”
这个小小的变化使建议的质量大大提高。AI突然“理解”了我的编码风格和项目模式。我甚至不需要告诉它确切的参考内容——只需指向类似的组件就能大大帮助。
对于较大的项目，你需要开始提供更多的上下文。要求它在.cursor/rules文件夹中创建规则文件，从不同的角度解释代码，比如后端、前端等。
我的日常Cursor工作流程
早上，当我头脑清晰时，我会在最少的AI帮助下规划复杂的功能。这确保了关键代码的稳固。
然后，我使用Agent模式逐个编写它们，按难度顺序进行。我确保使用“审查”按钮阅读所有代码，并保持更改小并进行实时测试，以查看它们是否真正有效。
对于创建标准组件或编写测试等繁琐任务，我非常依赖Cursor。幸运的是，软件开发中这种无聊的任务现在已经成为历史。
对于涉及安全、支付或身份验证的任务；我确保完全手动测试，并让Cursor编写自动单元测试，因为这些地方我希望完全放心。
当Cursor建议某些内容时，我经常问“你能解释一下为什么这样做吗？”这在它进入我的代码库之前捕捉到了许多微妙的问题。
避免我犯的错误
如果你是第一次尝试Cursor，这里是我希望我知道的：
- 对于身份验证、支付处理或安全功能的AI建议要非常谨慎。我逐字手动审查这些。
- 在使用Cursor调试时，始终要求它解释其推理。我曾经让它自信地“修复”错误，结果引入了更糟糕的错误。
- 保持你的问题具体。“修复这个组件”是行不通的。“更新onClick处理程序以防止表单提交”效果要好得多。
- 适时休息一下AI的帮助。我经常在没有Cursor的情况下编码，然后再回来，能更好地判断何时使用它。
继续使用AI工具
尽管有挫折，我仍然每天使用Cursor。它就像是你团队中一个有时很有帮助的初级开发者，工作非常快，但需要监督。
我发现，具体化、提供上下文和始终审查建议使Cursor从一个风险工具转变为我独立项目的真正生产力提升器。
对我来说，关键是设定界限。Cursor帮助我更快地编写代码，但我仍然是确保代码正确工作的责任人。
你呢？如果你正在使用Cursor或类似的AI工具，我很想听听在你的工作流程中什么有效或无效。