我要评论这是 cursor 的设计主管在 x 上发布的 cursor 使用建议
地址：https://x.com/ryolu_/status/1914384195138511142
访问不了的可以直接看下面的截图
第一条，提前编写 cursor rules
set 5-10 clear project rules upfront so cursor knows your structure and constraints. try /generate rules for existing codebases.
提前设定 5-10 条清晰的项目规则，这样 cursor 就能了解你的结构和限制。尝试使用/generate 规则来处理现有代码库。
提前写好 cursor rules ，如果是新项目， 在项目开始之前你就要把 cursor rules 编写好，就像给 cursor 一份“项目章程”。这样做可以从一开始就引导 ai 生成更符合项目需求的代码，减少后续的修改工作。
如果说你用 cursor 打开的是一个已有的项目代码时，可以使用 /generate rules 让 cursor 尝试从现有代码中推断这些规则。
使用这个命令之后 cursor 就会基于你的项目为你定制一些具体的规则，这一步的作用就是给 ai 设定明确的编码规范和项目约束。
比如让 cursor 知道你的代码风格（缩进、命名约定）、禁止使用的库、特定的设计模式、错误处理方式等。
第二条，提示词要具体
be specific in prompts. spell out tech stack, behavior, and constraints like a mini spec.
提示词要具体，详细列出技术栈、行为和限制，就像一个迷你规范一样。
模糊的指令会导致模糊的输出，我们在给 cursor 任务指令的时候，要尽可能清晰、具体。
不要只说“创建一个登录页面”，而要说“使用 react、tailwind css 和 firebase auth 创建一个登录页面，包含邮箱和密码输入框，一个登录按钮，以及忘记密码链接。登录成功后跳转到 /dashboard，失败则显示错误信息。”
这就像给开发者写一个小型需求文档 (mini spec)，当你给 cursor 一个指令的时候，你要想想假如他是一个人类开发者，他能不能听的明白。
一个小技巧：
可以在 ask 模式下，把我们说的自然语言转换成结构化的提示词
然后再切换到 agent 模式，把刚才得到的结构化提示词粘贴进去
所以我们尽量要把提示词的详细具体，你的提示词越接近一个清晰的需求文档，cursor 生成的代码就越接近你的期望。明确技术栈（如 python django, react, vue.js）、期望行为（用户操作流程、功能逻辑）和任何限制条件（如性能要求、特定库版本）。
第三条，处理维度尽量小
work file by file; generate, test, and review in small, focused chunks
直译：按照单个文件维度一个一个去处理，用小而集中的模块为单位进行生成、测试和审查
意译：按照单个文件维度推进工作，将代码生成、测试验证和审查环节都控制在专注的小功能模块范围内，确保每个环节的质量可控。
我们在使用 cursor 的时候，不要试图让 cursor 一次性生成整个应用程序或一个非常复杂的功能。而是要把任务分解成更小的、可管理的部分，最好是逐个文件或逐个小模块进行。每生成一小部分代码，就立即进行测试和审查。
我们可以采用增量开发的方式。例如，先让 cursor 生成一个数据模型，审查通过后，再让它生成相关的 api 接口，再到前端组件。这种小步快跑、及时反馈的方式更容易控制代码质量，也更容易定位和修复问题。
第四条，测试驱动开发
write tests first, lock them, and generate code until all tests pass.
直译：先编写测试用例并锁定，随后生成代码直至全部测试通过。
意译：遵循测试驱动开发(tdd)原则：首先明确需求并编写自动化测试用例，将这些测试用例作为验收标准锁定后，再通过迭代编码持续满足测试要求，最终确保所有测试用例100%通过。
这是测试驱动开发 (tdd) 的理念在 ai 辅助编程中的应用。先编写单元测试来定义代码应该如何工作（即“锁定”期望的行为），然后让 cursor 生成实现这些功能的代码，直到所有测试都通过。
比如说你想实现一个功能，那你一开始就可以让 ai 帮你想一些测试场景，然后把测试用例作为验收标准，让 cursor 去生成代码，最后生成的代码要保证所有的测试用例都能通过。这样的话，cursor 就有一个非常明确的目标，当所有测试用例都通过时，ai 生成代码的正确性也会大大提高，也可以显著减少手动调试和验证的时间。
第五条，人工审查并提供范例
always review ai output and hard‑fix anything that breaks, then tell cursor to use them as examples.
直译：始终审查ai生成内容，对发现的问题进行人工修复，并将修正后的案例作为示例提供给cursor。
意译：建立ai代码质量闭环机制：1) 系统审查cursor生成的代码 2) 对发现的问题进行人工修正并记录 3) 将修正后的标准案例记录到文档中或者 project ruels 中 4) 引导cursor学习优化
cursor 生成的代码可能会出现幻觉或者不符合你的意图，这个时候人工审查就至关重要了，当你发现问题并手动修正后，关键还要让 cursor 从你的修正中学习，将这些修正作为后续代码生成的“正面教材”。
你纠正 cursor 错误之后，要明确告诉它：“下次遇到类似情况，请参考我刚才的修改。” 这样可以逐步提升 cursor 在你特定项目中的表现，使其越来越懂你的偏好和项目需求。
案例：
我现在让 cursor 帮我创建一个 index.html 页面，它创建出来的 h1 标签一般都这么写，但是我觉得这么写不符合我的要求，我希望的 h1 标签是「欢迎来到 hepingfly的网站」
那么我就可以把这个生成 index.html 的规则写在 project rules 中
现在我再让 cursor 生成一个 index2.html 页面，你会发现它的 h1 标签内容就是「欢迎来到 hepingfly的网站」
如果说你希望这个规则不仅在当前项目中使用，在以后所有的项目中都使用这个规则的话，你就可以把这个 project rules 升级一下，升级成 user rules
以后只要你打开 cursor ，它就会应用这个规则
第六条，限定上下文
use @ file, @ folders, @ git to scope cursor’s attention to the right parts of your codebase.
通过@file（文件）、@folders（目录）、@git（版本库）指令限定cursor的代码关注范围
通过 @ 符号 cursor 提供了很多种限定上下文的方式，比如说文件、文件夹、git 提交记录等等
有了限定范围之后， cursor 生成的内容也会更加的精准
简单来说 @ 符号来引用项目中的特定文件、文件夹或 git 历史记录，cursor 会将其注意力集中在相关的上下文上，这样就避免了 ai 在整个庞大的代码库中漫无目的地搜索，提高了响应速度和相关性。
第七条，擅用 .cursor目录
keep design docs and checklists in .cursor/ so the agent has full context on what to do next.
把设计文档和检查清单放在 .cursor 目录下，这样 agent 就能有足够的上下文来知道下一步该做什么
这一条其实就是让你把相关的需求文档和设计文档放在 .cursor 目录下，有点类似于 project rules，但是 rules 中主要是去做一些限制，而我们的需求文档和设计文档是告诉 cursor 应该干什么，开发什么内容，有哪些功能需要开发
这里需要注意的是，不要一次性让 cursor 把你列的清单全部都开发完，而是要一个一个的去完成，然后一个一个的去做阶段性的测试，测试完成给 cursor 反馈，然后再继续下一个任务。
发表评论