这篇不是“功能说明书”，而是“今天就能照做”的上手实战。
你会在 30 分钟内完成一个真实任务：
- 在现有 Nuxt/Vue 项目里，新增“空状态组件 + 接入页面 + 手动验收”
- 全程分别用到
Cmd+L（查路）、Cmd+K（小步改）、Cmd+I（跨文件落地） - 每一步都有“可复制提示词 + 通过标准 + 失败处理”
如果你已经会基础操作，想看进阶控制与多文件策略：
先准备：开始前 4 条规则
- 不用空项目练手：直接在真实代码库里做一个小需求。
- 每轮只改一个目标：先定位，再修改，再验证。
- 先要计划再要代码：尤其是
Cmd+I。 - 永远保留回滚路径：改动大时先在分支或暂存下操作。
30 分钟实战任务（跟着做）
任务定义
在已有页面里，当列表为空时展示空状态模块：
- 新增组件：
EmptyState - 页面接入：列表为空时显示组件
- 验收：空数据时显示，非空时隐藏，样式不破版
完成标准（DoD）
- 至少 1 个组件文件 + 1 个页面文件发生改动
- 页面可正常渲染，无明显控制台报错
- 改动范围可解释（为什么改这些文件）
- 提供手动验证步骤（路径 + 操作 + 预期）
第 1 步：Cmd+L 先查路，不急着写代码
目标
搞清楚三件事：
- 空列表逻辑现在在哪个文件
- 项目里有没有现成空状态组件可复用
- 页面当前数据来源和判断条件是什么
可复制提示词
请基于当前仓库帮我定位“列表为空时显示占位内容”的实现位置：
1) 列出最可能相关的 3-5 个文件；
2) 每个文件说明为什么相关；
3) 给我最小改动方案（优先复用现有组件）。
先不要生成代码。
这一步常见错误
- 直接问“帮我做一个空状态组件” → 容易跳过现有实现，造成重复建设。
- 不要求“先列文件” → 后续改动不可控。
第 2 步：Cmd+K 做最小改动（先局部）
目标
先改页面中的条件渲染分支，不急着抽象。
可复制提示词（选中页面相关代码后）
仅修改当前选中代码：
1) 当列表为空时渲染 EmptyState；
2) 不改变现有数据获取逻辑；
3) 不修改其他文件；
4) 保持现有命名风格和缩进。
请先展示修改计划，再给最终代码。
通过标准
- 改动只在当前文件
- 不引入新依赖
- 逻辑分支可读（空/非空清晰）
第 3 步：Cmd+I 做跨文件落地（再扩展）
目标
补齐组件文件，并统一文案/样式，完成“可交付”状态。
可复制提示词
需求：新增 EmptyState 组件并接入当前页面。
约束：
- 先输出将修改的文件清单与每个文件改动点；
- 不新增依赖；
- 不做跨目录重构；
- 保持现有 UI 风格。
我确认后再生成补丁。
这一步的关键
- 如果文件清单超出你的预期，立即收窄：
只允许修改 A/B 两个文件，其他文件不要动。
第 4 步：验收与回滚（避免“看起来能跑”）
手动验收清单
- 空数据：是否展示空状态文案与按钮
- 非空数据：空状态是否消失
- 边界：加载中/接口异常时是否冲突
- 视觉：移动端是否挤压或换行异常
回滚策略
- 单文件改坏：只回退该文件
- 多文件改坏：回退到上一轮“可运行状态”
- 不确定是否改对：保留当前分支，另起小分支重做
高质量提示词 = 目标 + 范围 + 约束 + 验证
你可以把这 4 个字段当固定模板：
目标：我要实现什么
范围：只改哪些文件，不改哪些
约束：风格/API/依赖/性能边界
验证：如何确认改动正确
反例 vs 正例
反例（跑偏高发）
帮我优化这个页面
正例（可执行）
目标：给列表页增加空状态展示。
范围：仅修改 pages/xxx.vue 与 components/EmptyState.vue。
约束：不新增依赖，不改变现有 API，不改路由结构。
验证：给出 3 条手动验证步骤与预期结果。
新手最常见的 6 个坑（实用排查）
1）改动范围失控
处理：下一轮强制 先输出文件清单，未经确认不生成代码。
2）回答像教程，不像项目代码
处理：加上 仅基于当前仓库已有模式，不要引入新框架/新目录。
3）生成代码能跑但风格不一致
处理：在提示词里指定 遵循当前文件风格，不新增命名体系。
4）索引慢，@codebase 不稳定
处理：先精简索引范围；规则模板见：
5）一个需求改太久
处理：强制拆成三轮：定位 → 核心逻辑 → 收尾（类型/边界/文档）。
6）不知道何时该停
处理：提前写 DoD（完成标准），满足即停，不做“顺手优化”。
常见问题（FAQ）
Cursor 和 VS Code + 插件，差别到底在哪？
核心不是“能不能补全”，而是能否把“查路→改动→验证”做成闭环。Cursor 在这条链路上更顺滑，但是否高效取决于你能否控制范围。
我应该先学哪个快捷键？
先 Cmd+K，因为它最适合小步迭代。能稳定完成 10 次小改动后，再把 Cmd+I 用于跨文件任务。
怎么判断我是在“用 AI 提效”，而不是“被 AI 带着跑”？
看两个指标：
- 每次改动是否能解释“为什么改这几个文件”
- 回滚成本是否低（出错时能快速回到可运行状态）
下一步建议
- 想要更深入控制多文件改动： Cursor 进阶指南（2026）
- 想把输出稳定在团队规范内： Cursor Rules 实战
- 想对比 Copilot 的协作策略： GitHub Copilot 高效使用技巧
- 安装 Cursor，并完成登录
- 打开你的一个真实项目（别用空项目练手）
- 先把语言/输出习惯固定（中文/英文、注释风格）
- 检查隐私与索引（尤其是公司代码和敏感目录）
- 记住三件套：
Cmd+K/Cmd+L/Cmd+I
如果你只想先体验“能带来明显提升”的能力，建议从 Cmd+K 开始：选中一段代码 → 让它做一个很小、很明确的改动 → 你审查并应用。
Cursor 是什么？和 VS Code + AI 插件有什么区别
一句话：Cursor 是一款 AI 原生 IDE（基于 VS Code 的体验，但围绕 AI 工作流做了更深的整合）。
你会在三个方面明显感受到区别：
- 上下文更“项目化”：它更倾向于理解仓库结构，而不是只围绕当前文件
- 多文件改动更顺手：对话驱动的修改更容易跨文件落地
- 闭环更完整：从提需求、生成、应用改动到复盘，路径更短
但它也带来两个需要你管理的变量：
- 项目索引是否可用、是否准确
- 你的指令是否把“范围 / 输出 / 约束”说清楚
安装与登录：账号、订阅、团队（只讲你会遇到的点）
1）安装
- 去官网下载并安装
- 首次启动时把主题/字体/快捷键先设置成你习惯的（这会直接影响你后续使用频率）
2）登录与订阅
- 登录后通常才能使用完整 AI 能力
- 团队/公司环境优先确认是否有组织订阅、网络代理、使用策略限制
3）一个重要认知：AI 能力 ≠ 永远联网可用
- 模型调用依赖网络与服务状态
- 在企业环境可能还有代理/访问策略
如果你遇到“AI 按钮灰色/不可用”，先从网络、登录状态、订阅状态排查。
基础设置：模型、语言、隐私/索引（新手最该先配的三项）
1）选择模型：优先“稳定 + 适合你任务”的
一般来说：
- 写代码/改 bug：优先更擅长代码理解与修改的模型
- 写文档/总结：选择更擅长语言表达的模型
不要一开始就纠结“哪个最强”，先保证：稳定、可复现、能持续产出。
2）语言与输出习惯
- 你希望它输出中文还是英文？
- 代码注释风格？
- 是否需要“先给方案再改代码”？
把这些写成固定指令（更进一步可以写进规则文件）。
3）隐私与索引：决定“它能理解多少”和“会不会泄露”
你需要明确两件事：
- Cursor 是否会把你的代码用于索引/上下文
- 哪些文件不应该被纳入（例如
.env、私钥、商业敏感目录）
最佳实践：
- 用忽略规则排除敏感目录（例如
.env、证书、密钥、构建产物、依赖目录） - 索引不是越大越好：越大越慢、越容易误判；只索引你需要的
想把“隐私/目录边界/输出格式”一次性写清楚，可以看这篇（含可复制模板）：
必学快捷键：Cmd+K / Cmd+L / Cmd+I（记住这三个入口就够了）
不同版本的命名可能有差异，你可以把它们理解成三种场景：
| 入口 | 你什么时候用它 | 你应该怎么提问 |
|---|---|---|
Cmd+K（内联编辑） | 只改一小段、想要“就地改” | 明确约束：行为不变/不改 API/只改这一段 |
Cmd+L（Chat） | 解释/排查/给路径 | 先让它给排查顺序，再让它动手 |
Cmd+I（Composer） | 多文件改动、需要先出计划 | 先要文件清单与改动点，确认后再生成 |
1）Cmd+K：在当前代码附近“就地改”
适合：
- 选中一段代码，让它重构/改写/补类型
- 让它生成一个函数/组件
提示词模板：
- “把这段改成更可读的写法，不改行为”
- “给这个函数补齐边界处理，并保留现有 API”
2）Cmd+L：对话式解决问题（理解/方案/排查）
适合：
- 问“为什么报错”
- 让它解释代码结构
- 让它给你一个可执行的排查清单
提示词模板：
- “先列出可能原因（按概率排序），再给我最短排查路径”
3）Cmd+I：把“需求”变成“修改计划”，再应用改动
适合：
- 多文件改动
- 需要生成补丁/提交一组修改
提示词模板：
- “请先列出将修改的文件清单与改动点，确认后再生成补丁”
新手工作流：写需求 → 先要计划 → 小步应用 → 验证（最稳的一套）
Cursor 用得稳的人，通常不是“会写提示词”，而是有固定流程。
第 1 步：把需求写成约束清单
至少写清：
- 目标：要实现什么
- 范围：改哪些文件/模块，不改哪些
- 约束：代码风格、兼容性、性能、不能破坏 API
- 验证：怎么验证（命令/页面/用例）
第 2 步：让 AI 先给“改动计划”，不要直接出大段代码
这样可以避免跑偏和过度改动，也更容易 code review。
第 3 步：小步提交
一次只做一个小目标：
- 先让它把 bug 定位清楚
- 再改最小的代码
- 再跑一遍验证
第 4 步：复盘并固化成项目规则
你发现 AI 总犯同一类错（比如乱改目录/输出太长/风格不一致），就把规则写进规则文件，让它下次别再犯。
常见问题与排查：索引慢、回答跑偏、上下文不足
1）索引很慢/一直在索引
可能原因：
- 项目太大（尤其 monorepo）
- 纳入了不必要的目录（
node_modules、构建产物）
排查与优化：
- 限制索引范围，只索引需要的目录
- 忽略构建产物与依赖目录
2）回答跑偏：它写了“看起来对但不符合你的项目”
典型原因：
- 你没有说明“基于当前仓库”
- 它在用通用模板回答
解决方法：
- 明确范围：
仅基于当前项目代码做修改，不要引入新框架 - 明确输出：
先给改动计划，再给补丁
3）上下文不足：它不知道你在说哪个文件/哪个函数
解决方法：
- 选中关键代码再提问
- 让它“列出它需要哪些信息”，你再提供
8 个常用提示词（直接复制）
- “先帮我定位问题：列 5 个可能原因，按概率排序，再给最短排查路径。”
- “只改最小范围，保持现有 API，不要做跨目录重构。”
- “把这段重构成可读性更强的版本，行为不变。”
- “补齐边界条件与错误处理，并解释为什么这样做。”
- “给我一个最小可复现示例（MRE）来验证这个 bug。”
- “请先给改动计划（文件列表 + 修改点），确认后再输出补丁。”
- “输出一个 checklist，方便我逐条验证。”
- “如果信息不足，请直接问我缺什么，不要猜。”
常见问题（FAQ）
Cursor 和 VS Code 有什么区别？
Cursor 更偏“AI 原生工作流”，对话、就地修改与多文件变更更顺滑；VS Code + 插件更自由，但需要自己拼装工作流。
Cursor 需要联网吗？会上传代码吗？
通常需要联网调用模型。代码是否会被用于上下文/索引，取决于你的设置与使用方式。团队/公司场景建议先明确策略，并用忽略规则排除敏感目录。
为什么 Cursor 生成的代码不对？
多数是范围不清或上下文不足。先让它给“改动计划”，再小步应用，并把常见约束写进项目规则。
怎么让 Cursor 理解整个项目？
需要项目索引与正确的引用范围；但不要把不必要目录纳入索引，否则会变慢且更容易跑偏。
Cursor 如何管理上下文？
优先用“选中代码 + 提问”，并明确你希望它参考哪些文件/模块。必要时把需求拆成小任务。
Cursor 如何配置快捷键？
在设置里搜索快捷键映射，把 Cmd+K/Cmd+L/Cmd+I 固化成自己的习惯即可。
Cursor 免费吗？
通常有免费额度或试用，但更完整能力需要订阅。以官方定价为准。
Cursor 适合什么人？
最适合：需要频繁写代码、改代码、读代码，并希望把“需求→实现→验证”流程变快的开发者与技术团队。
下一步：把 AI IDE 的产出落到“可发布的网页”
如果你的目标不仅是写代码，而是把网页做出来并上线，可以继续看：
- 进阶： Cursor 编辑器深度玩法：AI 原生 IDE 的进阶使用指南
- 进阶： Cursor 编辑器深度玩法：AI 原生 IDE 的正确打开方式
- 规则与隐私： Cursor Rules 实战：.cursorrules 与 .cursorignore 怎么写（含模板）
- Copilot 对比与技巧： GitHub Copilot 高效使用技巧：从入门到精通的实战指南
- 直接开始制作与发布： 在线网页制作与发布
