第22期 | Cursor深度使用从入门到高效 今天你将学会理解 Cursor 的核心架构Composer、Tab 补全、Chat 三大模式配置 .cursorrules 让 AI 理解你的项目约定掌握多文件编辑、上下文引用、指令链等高阶技巧建立一套属于你的 Cursor 高效工作流 核心知识Cursor 是什么为什么它不只是「又一个编辑器」你可能用过 Copilot——它像一个坐在旁边的朋友偶尔递给你一行代码。Cursor 不一样——它像一个真正理解你项目上下文的搭档能同时编辑多个文件、遵循你的项目规范、甚至帮你规划整个功能。Cursor 的三层能力模型层级能力对应功能何时用L1 逐行补全补全当前行/块Tab 补全写常规代码时L2 单文件编辑在当前文件内修改CmdK (Inline Edit)改某个函数/组件L3 多文件编排跨文件规划编辑Composer (CmdI)开新功能/重构很多人只用 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 模式多文件编辑的真正力量ComposerCmdI 或 CtrlI是 Cursor 最强的功能。它不只是帮你写代码而是帮你规划然后执行。一个完整的使用场景给博客系统加「标签过滤」功能打开 Composer输入给博客列表页添加标签过滤功能 - 在 BlogList 组件上方添加 TagFilter 组件 - TagFilter 展示所有标签点击可过滤 - 支持「全部」和「多标签组合」过滤 - 在 Zustand store 中添加 filterByTags 方法 - URL 同步/blog?tagsreact,typescriptCursor 会分析现有代码结构列出需要改动的文件清单逐个文件修改保持一致性你审查每个文件的改动逐个 Accept 或 Reject。关键你不需要一次性描述所有细节。先给大方向审查输出后再追加细节修改。这就是「迭代式 AI 协作」——不是一次生成完美代码而是多轮对齐。上下文引用让 AI 看到正确的信息Cursor 有三种方式给 AI 提供上下文引用方式语法何时用文件src/components/BlogList.tsx让 AI 看某个文件文件夹src/features/blog/让 AI 看整个功能模块WebWeb https://react.dev/reference/react/useEffect让 AI 查阅官方文档CodebaseCodebase让 AI 搜索整个项目DefinitionsDefinitions引用类型定义最佳实践改一个组件时用文件引用它和相关文件开新功能时用文件夹引用所在模块 Codebase搜索类似实现用不确定的 API 时Web查官方文档比让 AI 瞎猜靠谱得多Tab 补全 vs Inline Edit vs Composer什么时候用哪个很多人犯的错误是用 Composer 做所有事。其实三个模式各有最佳场景场景1写一个简单的 Button 组件 → 用 Tab 补全边写边补自然流畅 场景2给现有组件加一个 prop → 用 Inline Edit (CmdK)选中组件声明 → 输入加一个 variant prop 支持 primary/secondary/danger 场景3给整个博客系统加评论功能 → 用 Composer (CmdI)因为它涉及多个文件CommentForm、CommentList、store、路由决策规则改动 ≤ 1 个文件、≤ 5 行 → Tab / Inline Edit改动 ≥ 2 个文件 → Composer需要规划思考 → Composer常见误区误区1给 AI 一个大 prompt 就不管了最大的错误是写一长段描述然后直接 Accept All。正确的做法是先给方向性描述审查第一轮输出针对不满意的部分追加指令逐个 Accept误区2不用 .cursorrules没有 rulesCursor 不知道你的项目用 Zustand 还是 Redux、用 Tailwind 还是 CSS Modules。它每次都得猜——猜错的概率很高。误区3过度依赖 Composer简单改动用 Inline Edit 更快。Composer 的优势在于跨文件不是在于单个文件内修改。 AI协作实战实战场景配置你的 Cursor 工作流我给 AI 的 promptCodebase 分析我的项目结构和技术栈选择 然后帮我生成一份 .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 的 promptsrc/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/Composerprompt 的结构模板审查流程Accept/Retry/Reject 的决策标准遇到 AI 输出错误时的修正策略 本期要点Cursor 的三层能力Tab 补全逐行→ Inline Edit单文件→ Composer多文件编排越复杂的功能用越高的层级.cursorrules 是刚需没有它AI 每次都在猜你的规范有了它输出质量从「大概能用」跳到「符合标准」上下文引用是效率杠杆文件CodebaseWeb让 AI 看到正确信息而不是靠记忆猜测迭代式协作 一次性交付先给方向 → 审查 → 微调比写一个超长 prompt 期望完美输出更靠谱审查是你的责任AI 生成代码后逐个 Accept/Reject不是 Accept All 就完事 下期预告下一期我们进入 Prompt Engineering——不是泛泛的「写好 prompt」而是专门为前端开发场景设计的结构化 prompt 方法论、上下文管理技巧和迭代优化流程。你将建立自己的「前端 prompt 模板库」。如果你没有苹果电脑需要上传ios到APPStore可以访问以下网站iPA上传工具 - IPA解析与AppStore提交