第22期 | Cursor深度使用：从入门到高效
🎯 今天你将学会
- 理解 Cursor 的核心架构：Composer、Tab 补全、Chat 三大模式
- 配置 .cursorrules 让 AI 理解你的项目约定
- 掌握多文件编辑、上下文引用、指令链等高阶技巧
- 建立一套属于你的 Cursor 高效工作流
📖 核心知识
Cursor 是什么？为什么它不只是「又一个编辑器」
你可能用过 Copilot——它像一个坐在旁边的朋友，偶尔递给你一行代码。Cursor 不一样——它像一个真正理解你项目上下文的搭档，能同时编辑多个文件、遵循你的项目规范、甚至帮你规划整个功能。
Cursor 的三层能力模型：
| 层级 | 能力 | 对应功能 | 何时用 |
|---|---|---|---|
| L1 逐行补全 | 补全当前行/块 | Tab 补全 | 写常规代码时 |
| L2 单文件编辑 | 在当前文件内修改 | Cmd+K (Inline Edit) | 改某个函数/组件 |
| L3 多文件编排 | 跨文件规划+编辑 | Composer (Cmd+I) | 开新功能/重构 |
很多人只用 L1 和 L2，那 Cursor 就只是「更好的 Copilot」。真正的效率飞跃在 L3。
.cursorrules：你的项目宪法
.cursorrules是放在项目根目录的文件，告诉 Cursor 你的项目规范。这不是可选的——它是你从「AI 随意输出」到「AI 按你的规矩输出」的关键一步。
# .cursorrules 示例 ## 项目信息 - 技术栈：React 18 + TypeScript + Zustand + Vite - CSS方案：Tailwind CSS - 包管理：pnpm ## 代码规范 - 组件用函数式组件 + Hooks - 文件命名：PascalCase（组件）、camelCase（工具函数） - 状态管理优先用 Zustand，避免 Context - 不要用 class 组件 - 不要用 useEffect 做初始化之外的逻辑 ## 目录结构 - src/components/ — 通用组件 - src/features/ — 按功能分组（每个 feature 含 components/hooks/store） - src/lib/ — 工具函数和第三方封装 ## 测试要求 - 每个新组件必须含 .test.tsx - 用 Vitest + React Testing Library - 测试行为，不测实现 ## AI协作规则 - 先解释方案，再写代码 - 修改已有文件时，只改动需要改的部分，不要重写整个文件 - 如果不确定，问我而不是猜测为什么 .cursorrules 很重要？没有它，Cursor 每次都得从零理解你的项目风格。有了它，AI 的输出从「大概能用」变成「符合你的标准」。这就像给新入职的同事一份 Coding Style Guide——他第一天的代码就跟团队风格一致。
Composer 模式：多文件编辑的真正力量
Composer（Cmd+I 或 Ctrl+I）是 Cursor 最强的功能。它不只是帮你写代码，而是帮你规划然后执行。
一个完整的使用场景：给博客系统加「标签过滤」功能
- 打开 Composer，输入：
给博客列表页添加标签过滤功能： - 在 BlogList 组件上方添加 TagFilter 组件 - TagFilter 展示所有标签，点击可过滤 - 支持「全部」和「多标签组合」过滤 - 在 Zustand store 中添加 filterByTags 方法 - URL 同步：/blog?tags=react,typescriptCursor 会：
- 分析现有代码结构
- 列出需要改动的文件清单
- 逐个文件修改，保持一致性
你审查每个文件的改动，逐个 Accept 或 Reject。
关键：你不需要一次性描述所有细节。先给大方向，审查输出后再追加细节修改。这就是「迭代式 AI 协作」——不是一次生成完美代码，而是多轮对齐。
上下文引用：让 AI 看到正确的信息
Cursor 有三种方式给 AI 提供上下文：
| 引用方式 | 语法 | 何时用 |
|---|---|---|
| @文件 | @src/components/BlogList.tsx | 让 AI 看某个文件 |
| @文件夹 | @src/features/blog/ | 让 AI 看整个功能模块 |
| @Web | @Web https://react.dev/reference/react/useEffect | 让 AI 查阅官方文档 |
| @Codebase | @Codebase | 让 AI 搜索整个项目 |
| @Definitions | @Definitions | 引用类型定义 |
最佳实践：
- 改一个组件时，用
@文件引用它和相关文件 - 开新功能时，用
@文件夹引用所在模块 +@Codebase搜索类似实现 - 用不确定的 API 时，
@Web查官方文档比让 AI 瞎猜靠谱得多
Tab 补全 vs Inline Edit vs Composer：什么时候用哪个
很多人犯的错误是用 Composer 做所有事。其实三个模式各有最佳场景：
场景1：写一个简单的 Button 组件 → 用 Tab 补全，边写边补，自然流畅 场景2：给现有组件加一个 prop → 用 Inline Edit (Cmd+K)，选中组件声明 → 输入"加一个 variant prop 支持 primary/secondary/danger" 场景3：给整个博客系统加评论功能 → 用 Composer (Cmd+I)，因为它涉及多个文件（CommentForm、CommentList、store、路由）决策规则：
- 改动 ≤ 1 个文件、≤ 5 行 → Tab / Inline Edit
- 改动 ≥ 2 个文件 → Composer
- 需要规划思考 → Composer
常见误区
误区1：给 AI 一个大 prompt 就不管了
最大的错误是写一长段描述然后直接 Accept All。正确的做法是：
- 先给方向性描述
- 审查第一轮输出
- 针对不满意的部分追加指令
- 逐个 Accept
误区2：不用 .cursorrules
没有 rules，Cursor 不知道你的项目用 Zustand 还是 Redux、用 Tailwind 还是 CSS Modules。它每次都得猜——猜错的概率很高。
误区3：过度依赖 Composer
简单改动用 Inline Edit 更快。Composer 的优势在于跨文件，不是在于单个文件内修改。
🤖 AI协作实战
实战场景：配置你的 Cursor 工作流
我给 AI 的 prompt：
@Codebase 分析我的项目结构和技术栈选择， 然后帮我生成一份 .cursorrules 文件， 包含：项目信息、代码规范、目录结构约定、测试要求、AI协作规则AI 的输出（摘要）：
# .cursorrules ## 项目信息 - 技术栈：React 18 + TypeScript + Zustand + Vite + Tailwind CSS - 包管理：pnpm - 测试：Vitest + RTL ## 代码规范 - 函数式组件 + Hooks - 文件命名 PascalCase(组件)/camelCase(工具) - 状态管理用 Zustand - 禁止 class 组件和 useEffect 做非初始化逻辑 ...我如何审查和修改：
- ✅ 技术栈描述准确——AI 从 package.json 和 tsconfig 正确推断
- ❌ 「禁止 useEffect 做非初始化逻辑」太绝对了——数据同步场景还是需要 useEffect，改成「避免在 useEffect 中做复杂业务逻辑，优先用事件驱动」
- ❌ 缺少「每个 feature 目录必须含 index.ts 导出」这条——手动加上
- ✅ AI 协作规则合理——保留
学到了什么：AI 生成的 .cursorrules 是一个很好的起点，但你需要根据实际项目经验微调。特别是「禁止」类规则——太绝对的话反而会限制 AI 的合理输出。
实战场景：用 Composer 开发「暗黑模式切换」功能
我给 AI 的 prompt：
@src/features/theme/ @src/App.tsx 给项目添加暗黑模式切换功能： 1. 在 theme feature 下创建 useTheme hook（用 localStorage 持久化 + 系统 preference 检测） 2. 修改 App.tsx 的根元素，根据 theme 状态添加 dark class 3. 创建 ThemeToggle 组件（一个简洁的太阳/月亮图标切换按钮） 4. 确保切换时所有 Tailwind dark: 变体生效 按 .cursorrules 规范来AI 的执行过程：
- 先列出需要改动的文件：
useTheme.ts（新建）、ThemeToggle.tsx（新建）、App.tsx（修改） - 逐个生成代码，每个文件都能单独 Accept/Reject
- 代码风格遵循 .cursorrules 中的规范
我如何审查和修改：
- ✅ useTheme hook 实现完整——包含 localStorage、系统 preference、切换函数
- ❌ ThemeToggle 用了 emoji 而不是图标库——追加指令「用 Lucide React 的 Sun/Moon 图标替代 emoji」
- ✅ App.tsx 修改最小化——只加了 className 和 ThemeToggle 组件引用
- ❌ 没处理 SSR 兼容——追加「加一个 useEffect 做 hydration 安全的初始化」
最终效果：三轮交互，从大方向 → 审查 → 微调，暗黑模式功能完整可用。
💻 动手练习
练习1（简单）：创建你的 .cursorrules
在你当前的项目根目录创建.cursorrules文件，包含：
- 项目技术栈信息
- 至少3条代码规范
- AI 协作规则（至少2条）
练习2（中等）：用 Composer 开发一个小功能
选择你项目中的一个小功能（比如：添加一个「分享到 Twitter」按钮），用 Composer 模式完成：
- 先写方向性 prompt
- 审查第一轮输出
- 至少追加一次修改指令
- 记录你的 prompt 和最终代码
练习3（挑战）：建立 Cursor 工作流 SOP
写一份你个人的 Cursor 使用 SOP（标准操作流程），包含：
- 什么场景用什么模式（Tab/Inline/Composer）
- prompt 的结构模板
- 审查流程（Accept/Retry/Reject 的决策标准）
- 遇到 AI 输出错误时的修正策略
📌 本期要点
- Cursor 的三层能力：Tab 补全（逐行）→ Inline Edit（单文件）→ Composer（多文件编排），越复杂的功能用越高的层级
- .cursorrules 是刚需：没有它，AI 每次都在猜你的规范；有了它，输出质量从「大概能用」跳到「符合标准」
- 上下文引用是效率杠杆：
@文件@Codebase@Web让 AI 看到正确信息，而不是靠记忆猜测 - 迭代式协作 > 一次性交付：先给方向 → 审查 → 微调，比写一个超长 prompt 期望完美输出更靠谱
- 审查是你的责任：AI 生成代码后逐个 Accept/Reject，不是 Accept All 就完事
🔗 下期预告
下一期我们进入 Prompt Engineering——不是泛泛的「写好 prompt」，而是专门为前端开发场景设计的结构化 prompt 方法论、上下文管理技巧和迭代优化流程。你将建立自己的「前端 prompt 模板库」。
如果你没有苹果电脑，需要上传ios到APPStore可以访问以下网站
iPA上传工具 - IPA解析与AppStore提交
