第一个项目
第一次用 Cursor 做项目，最容易犯的错误就是一上来直接丢一个很大的需求，期待它自己把整套功能都做完。偶尔可能会成功，但更常见的结果是：它改了很多地方，看起来很忙，最后你还得花更多时间收拾。
所以第一个项目最好故意选小一点。目标不是炫技，而是先熟悉 Cursor 的工作节奏：什么时候让它补全，什么时候让它局部改，什么时候让它帮你补测试。
我会很建议把第一次体验理解成“建立预期管理”，而不是“验证它是不是魔法”。只要第一步预期对了，后面通常会越用越顺；如果第一步就期待它独立做完整功能，失望会来得很快。
1. 打开项目
你可以使用现有项目，或者克隆官方示例项目：
git clone git@github.com:voxelize/voxelize.git && \
cd voxelize && \
cursor .
也可以在 Cursor 里直接打开本地目录：
- macOS：
Cmd + O - Windows/Linux：
Ctrl + O - 命令行：
cursor <path-to-project>
2. 先用 Tab 感受它的节奏
Tab 会在你输入时自动给出补全建议，按下 Tab 即可接收。它能补全多行代码块，还会在需要时跨文件跳转到下一处建议。
尝试在任意文件中输入：
function calculate
看到建议后按 Tab 接受，Cursor 会补全函数参数和函数体。
这里最值得观察的，不是它补得快不快，而是它是不是顺着你当前代码的语境在补。如果你只是打一半名字，它有时会猜得很泛；如果你给出更明确的函数名、注释或参数方向，补全会稳定很多。
换句话说，第一个项目里你真正练的，其实是“怎么给出让它容易接住的起手式”。
3. 再用 Inline Edit 做一次局部改动
选中刚才生成的函数，使用 Inline Edit 让 Cursor 直接改写：
- 选中函数
- 按
Cmd + K/Ctrl + K - 输入：
make this function calculate fibonacci numbers - 按
Return/Enter应用修改
Cursor 会自动添加需要的实现细节（如注释或必要的导入）。
这一步很像你在真实开发里最常做的事：不是从零新建一个世界，而是对现有逻辑做一次定点修改。对很多人来说，Inline Edit 反而是最先带来“这个工具真能省时间”感觉的地方。
而且它的好处是边界很清楚。你让它改这里，它通常就改这里，不像一上来就用 Composer 那样可能牵出更多文件。
4. 让 Agent 补测试，而不是直接补功能
打开 Chat 或 Composer，让 Agent 帮你补齐测试：
Add tests for this function and run them.
你可以让 Agent 先写测试，再运行测试，最后让它实现通过测试的代码。
我很建议把“补测试”作为第一个完整闭环来体验，而不是直接做复杂功能。因为这里最容易看出 Cursor 的真实能力边界：
- 它能不能读懂当前代码
- 它能不能补出像样的测试
- 它能不能根据失败结果继续修
一旦这条链路你觉得顺了，后面再把它放进真实项目会更稳。
我会特别建议观察一点：它写测试时到底是在“顺着你的代码理解去补”，还是在“为了凑一个能跑的测试自己脑补逻辑”。这两者差别很大。
5. 第一个项目最值得练的不是“生成”，而是“收口”
很多新手会把注意力都放在“它生成了多少”，但第一个项目里更值得练的是：
- 怎么给出更明确的指令
- 怎么判断结果能不能直接用
- 怎么限制它的改动范围
- 怎么把修改收束在一个小闭环里
这几个能力其实比“会不会用快捷键”更重要。因为真正到工作里，你最缺的通常不是生成速度，而是控制成本。
Cursor 用得好的开发者，往往不是提示词写得最花的人，而是最知道哪里该让 AI 接手、哪里该自己马上收回来的人。
6. 一个更像真实工作的练习顺序
如果你准备真的拿 Cursor 上手，我会推荐这个顺序：
- 选一个很小的函数或组件
- 用 Tab 先补一个雏形
- 用 Inline Edit 改一次明确需求
- 用 Chat 或 Composer 让它补测试
- 自己再检查命名、边界和可读性
这个顺序能让你比较完整地感受到 Cursor 的三个核心入口是怎么互相接力的。
下一步
- Tab 智能补全 - 深入了解 Tab 机制
- AI Chat 对话 - 学习对话式开发
- Composer 多文件编辑 - 处理跨文件需求
如果你做完这一页的练习，下一步最值得看的通常是 Tab 和 Composer。前者决定你平时写代码时愿不愿意一直开着 Cursor，后者决定它能不能真正帮你做跨文件任务。
