很多人第一次用 Cursor，会让 Agent 直接“把这个功能做完”。它往往真能改出一堆文件，但你很难判断哪一处是对的，哪一处只是看起来像对的。
我更建议把第一次任务当成一次小型交接：选一个能看见、能测试、能回退的改动。Cursor 负责读代码、提出修改和执行已有检查；人负责限定边界并确认结果。
先选一件小事
不要从“重构登录系统”开始。一个好起点是修正文案、补一个已有函数的测试，或调整一个已经定位到的交互问题。
任务要写出结果，不只写动作。比如，不说“优化列表页”，而说“把空状态文案改为明确的下一步，并运行这个项目已有的检查”。这样 Agent 知道终点，人也知道怎么验收。
打开项目后，先让 Cursor 解释相关文件，不要让它立刻编辑。官方的快速入门也是从一个小任务开始，并把查看 diff 和运行项目已有检查放在改动之后。Cursor Quickstart
可以直接把下面这段发给 Agent：
先不要修改文件。阅读和这个任务有关的代码，告诉我：
1. 当前行为在哪里实现；
2. 需要改哪些文件；
3. 可能影响哪些检查；
4. 你准备如何验证结果。
这一步像让新同事先复述需求。它不能保证答案正确，但能很早发现“改错地方”的问题。
把项目习惯写成规则
同一个项目里，反复解释测试命令、目录边界和命名方式很浪费。Cursor 的 Project Rules 存在 .cursor/rules，可以跟着代码进入版本控制，并能按文件路径生效。Cursor Rules
规则不需要写成长篇制度。它只保留 Agent 经常犯错、而代码本身又不能清楚表达的约束。下面是一份可以从小项目开始用的例子：
---
description: "Safe changes for application source files"
globs: ["src/**/*"]
alwaysApply: false
---
- Read the existing implementation before editing.
- Keep the change limited to the requested behavior.
- Do not change generated files or lockfiles unless the task requires it.
- Run the repository checks that cover the change.
- Report changed files, commands, and any failed check.
这份规则的重点不是“让 AI 更聪明”。它是在每个任务前放一张项目便签：哪些地方不要碰，完成后交什么证据。
规则写得越长，越容易变成没人维护的说明书。Cursor 也建议规则保持具体、可执行，并按需要拆开。项目已经有的 lint、测试和文档，不必复制到规则里，直接指向它们就够了。
让 Agent 先给计划，再动手
小改动可以直接编辑。只要任务跨多个文件、要查资料，或需要你确认方案，就先让 Agent 给计划。
Cursor 的 Plan Mode 会先找相关代码、整理实现步骤，并等待确认后再开始改。Agent 本身可以搜索代码、编辑文件和运行终端命令，所以“先计划”不是礼节，而是权限边界。Cursor Agent
可以用这段提示把范围锁住：
为这个任务写一个计划，不要修改文件。
计划要列出：目标、涉及文件、不会修改的边界、验证命令和回退方法。
如果信息不足，先提问题。
看到计划后，重点看两件事：它有没有碰到不该碰的目录；验证命令是不是项目真的在用。计划没有通过，就在这里改，不要等几十个文件被修改后再回头收拾。
改动完成后只看三样东西
Agent 说“完成”时，不要只看聊天里的总结。检查三个实物：diff、检查输出和最终页面或接口。
git diff --check
npm run lint
npm test
npm run build
这些命令只是常见例子。项目没有某个命令就不要硬跑，应该用仓库已有的 package.json、README 或 CI 配置里的检查。对后端服务，还要再请求受影响的接口；对数据库改动，要确认迁移和回退路径。
Cursor 的价值不在于替人签字。它把找文件、写初稿和跑命令接过去了，但 diff 仍需要人确认。把第一次任务控制在一处小改动里，你会很快知道自己的规则和检查是否够用。
下次想让 Cursor 处理大任务时，先写计划，再让它改；每个任务都留下可复现的验证结果。
官方资料
- Cursor Quickstart：从第一个小改动到 diff 和检查。
- Cursor Rules：项目规则的作用、格式和维护建议。
- Cursor Agent：Agent 可用的代码搜索、编辑和终端工具。
评论前必须登录！
立即登录 注册