Cursor新手实战：六步工作流搞懂改动、回退与验收

为什么新手用 Cursor 总是"翻车"

很多零基础用户第一次接触 Cursor 时，最常见的困惑不是"AI 写不出代码"，而是"AI 写完了，但我看不懂它到底改了什么"。这条 B 站教程用一个具体项目——制作"流量标题体检台"网页小工具，把 Cursor 的开发流程拆解成一套可复用的六步工作流。

这个案例的巧妙之处在于，它同时解决了两个问题：一条是内容线（如何写出留得住人的标题），一条是工具线（如何用 Cursor 做工具时看得懂改动、管得住范围、验得了结果）。对新手来说，后者才是真正的核心技能。

作者明确了工具的边界：不采集数据、不联网、不登录，所有测试的标题都存在用户本地电脑上。这种"纯前端单页工具"的定位，恰好让整个开发流程变得可控、可验收，是新手练手的理想场景。所谓"纯前端单页工具"，是 Web 开发中最轻量的应用形态——它只依赖浏览器端的 HTML、CSS 和 JavaScript 三件套，不需要后端服务器、数据库或任何网络请求。所有逻辑在用户浏览器中本地执行，数据通过 localStorage 等浏览器原生 API 持久化存储。这种架构的部署成本为零——双击 HTML 文件即可运行，也不存在数据泄露风险。对 Cursor 新手来说，它消除了环境配置、依赖安装、接口调试等后端复杂度，让开发者可以专注于学习 AI 协作流程本身。

动手前先搞清楚：Cursor 的收费与模型怎么选

在正式开发前，教程先厘清了一个新手最容易踩坑的问题——收费和模型选择。

免费档与付费档的区别

Cursor 的免费档提供一定的 Agent 用量，也能使用自家的 Composer 模型，对于跟着做一个小工具来说是足够的。但免费档用量有限，如果想手动锁定某个具体的前沿模型，至少需要订阅。

这里需要理解 Cursor 的 Agent 模式与传统代码补全（如 GitHub Copilot 的 inline suggestion）的本质区别。传统补全是"光标在哪补哪"，一次只生成几行代码片段；而 Agent 模式是一个具备自主规划能力的智能体，它能理解整体需求后同时创建、编辑多个文件，甚至执行终端命令和安装依赖。Agent 会自主决定工作步骤：先读取现有代码理解上下文，再制定修改计划，最后跨文件执行变更。这种能力让零基础用户也能完成完整项目，但也意味着它的"自主行为"更多，用户需要更强的审查意识来确保 Agent 没有偏离需求。

个人订阅从每月 20 美元的 Pro 档起步。这里有个重要概念：订阅包含两个独立的用量池，可以理解成两个钱包——第一个钱包装自家模型的用量，额度充足，日常开发通常用不完；第二个钱包装第三方模型的用量，按美元计价，像 Claude Opus 这类高能力模型消耗很快。

这种双池设计反映了当前大模型行业的成本结构。不同模型的推理成本差异极大：以 Claude 系列为例，Sonnet 级别的模型每百万 token 输入成本约 3 美元，而 Opus 级别可达 15 美元以上，差距达 5 倍。Cursor 的自家模型经过针对编程场景的微调和量化压缩，推理成本远低于通用大模型，因此可以提供较充裕的免费额度。而 Claude Opus、GPT-4o 等前沿模型虽然在复杂推理和长上下文理解上更强，但 token 单价高昂。

省额度的实用技巧

教程给出了一个非常实用的建议：平时用 Auto 自动档，它会按任务自动选择合适的模型，优先消耗自家模型的额度；只有在某一步反复做不对时，再临时切到更强的模型，用完立刻切回来，不要一直锁定在高消耗模型上。Auto 模式的核心逻辑就是根据任务复杂度智能路由——简单的代码补全用轻量模型，复杂的架构设计才调用重量级模型，从而在能力和成本之间取得平衡。

有意思的是，国产模型如 GLM、Kimi 系列已在官方模型列表中，官方文档专门标注其"智能程度高、成本低"，对国内用户是实打实的利好。

六步工作流：从空文件夹到能验收的工具

整套流程围绕六个步骤展开，其中藏着 Cursor 三个特别实用的核心能力。

第一步：正确打开项目文件夹

通过"文件—打开文件夹"选中新建的项目目录，这一步定义了 Cursor 的工作空间。最常见的错误是打开了上一级目录（比如"文档"或"下载"），导致 Cursor 把项目文件建到大文件夹里，事后难以清理。判断是否正确的方法很简单：看左侧文件树最上面显示的工作区名称是否是你的项目名。

第二步：用 Cursor Rules 把规矩定在动手之前

这是第一个核心能力。很多人用 AI 编程最头疼的是每次都要重复交代边界——不要加登录、不要联网、只用纯 HTML 和 JavaScript。Cursor Rules 就是把这些要求写成规则存在项目里，之后每次对话自动加载。

Cursor Rules 本质上是一种"系统提示词工程化"的实践。在大模型应用中，系统提示词（System Prompt）决定了 AI 的行为边界和输出风格，但手动在每次对话中粘贴提示词既低效又容易遗漏。Cursor Rules 将这一过程自动化——规则以 .mdc 文件形式存储在项目的 .cursor/rules 目录下，支持 Markdown 语法和 glob 模式匹配（比如只对 .js 文件生效的规则）。这种机制借鉴了软件工程中 .editorconfig、.eslintrc 等项目级配置文件的思路：把团队约定固化为文件，而非口头传达。

官方文档有一条最佳实践：当你发现自己在对话里反复重复同一段要求时，就该把它写成规则了。规则分三类：User Rules（全局个人偏好）、Project Rules（仅当前项目生效）、以及从 Git 导入的团队共享规则。针对具体项目的规矩，应选择 Project Rules。写规则可以用自然语言，像平时说话一样描述项目要求、风格和禁忌即可。更进阶的用法包括为不同文件类型设置不同规则、通过 @ 符号引用其他规则文件实现模块化管理。

第三步：用 Plan 模式先出计划再动手

这是官方文档写明的 Agent 工作方式——先规划，再执行。在 Plan 模式下，Cursor 不直接写代码，而是先研究需求、列出完整实施计划：建哪些文件、每个文件干什么、分几步做。你审阅满意后点击执行，它才真正动手。

Plan 模式的设计哲学与大模型领域一个核心挑战直接相关——AI 幻觉（Hallucination）。当 AI 在没有充分理解需求的情况下直接生成代码时，它可能"自信地"编造不存在的 API、添加需求之外的功能、或用错误的逻辑实现正确的表述。Plan 模式通过引入"思考-确认-执行"的中间层来缓解这个问题：AI 先用自然语言输出它的理解和计划，人类在这个阶段审查其意图是否正确，然后才授权执行。这类似于软件工程中的"设计评审"环节——在概要设计阶段发现方向性错误的修正成本，远低于在代码实现阶段。OpenAI 和 Anthropic 的研究也表明，让模型先"思考再行动"（如 Chain-of-Thought）能显著降低错误率。

对于"流量标题体检台"，计划会明确列出创建三个文件：Index.html 管页面结构，App.js 管打分逻辑，Style.css 管样式。审阅计划时要核对四件事：五项打分规则在不在、建议词在不在、字数统计在不在、历史记录在不在，以及有没有多余的东西（登录、服务器、数据库）。方向错了改一段文字，总比写了一堆代码再推翻便宜得多。

用 Diff 验收代码：看清每一行改动

代码生成后如何验收？这就是第二个核心能力——Diff 加源代码管理。

Diff（差异比较）是版本控制系统的基石概念，最早可追溯到 1974 年 Unix 系统上的 diff 命令。它的核心算法是最长公共子序列（LCS），通过比较两个版本的文件内容，以最小编辑距离标记出新增、删除和修改的行。在 Cursor 中，Diff 视图不仅用于查看 Git 提交历史，更关键的是用于审查 AI 每一次代码生成的结果。这相当于把传统软件开发中的 Code Review（代码评审）流程下沉到了人机交互层面——AI 是"提交代码的开发者"，用户是"审查代码的 Reviewer"。即使看不懂每行代码的语法细节，通过 Diff 视图也能快速判断变更范围是否合理、有没有超出预期的"副作用"。

点开左侧源代码管理图标，可以看到这次创建了哪些文件、每个文件增删了多少行。点开 Diff 查看细节：绿色是新增代码，红色是删除代码，改了什么、改了多少一目了然。

验收时教程建议问自己三个问题：

• 新增的是不是我们要的功能？
• 有没有加我没要求的东西（分享按钮、埋点、外链请求）？
• 删除的有没有误伤已有功能？

这里有一条硬规则值得所有新手记住：Cursor 说"已完成"不代表真的做完了。点接受之前，Diff 必须过目。它生成的每段代码你未必逐行都懂，但它动了哪里、动了多少、有没有多余代码，必须清楚。不能它给什么你就收什么。

Checkpoint 回退：改坏了也不用慌

第三个核心能力是 Checkpoint 快照回退。教程特意演示了一次"故意翻车"：切回普通 Agent 模式，说一句宽泛的"把这个工具做强一点，适合做自媒体爆款"。结果 Cursor 自作主张加了分享按钮、多余页面和外链——这些都不是需求。

补救有两种办法：一是在 Diff 里逐条拒绝改动；二是用 Checkpoint 回退——在聊天窗口找到想退回的那条消息，鼠标移过去会出现回退箭头，点一下所有文件就退回到那条消息发送时的状态。

不过教程也强调了 Checkpoint 的局限：它是对话级别的回退，方便但不够可靠。真正可靠的版本管理是 Git。Checkpoint 和 Git 虽然都提供"回退"能力，但其机制和可靠性完全不同。Checkpoint 是 Cursor 内置的会话级快照，它记录的是"每次 AI 操作前后的文件状态"，生命周期绑定在当前编辑器会话中，关闭项目后可能丢失，也无法跨设备同步。Git 则是分布式版本控制系统，每次 commit 会生成一个基于 SHA-1 哈希的不可变快照，存储在 .git 目录中，支持分支、合并、远程推送等完整的版本管理能力。两者的关系类似于"撤销键"和"存档"的关系：Checkpoint 适合快速试错和即时回退，就像游戏中的快速存档；Git commit 则是正式的版本里程碑，适合标记"验收通过"的稳定状态。最佳实践是每完成一个功能模块并验收通过后，立即执行 git commit，将 Checkpoint 的临时保护升级为永久版本记录。

这次翻车给出的核心结论很清晰：翻车多半是边界没想到、需求没写清、流程没走对，而不是模型突然不行了。 退回后回到正确流程，切 Plan 模式把需求改窄，只优化输入框样式，其他功能一律不动，AI 就能精准执行。

最后一关：在浏览器里亲手验收

代码写得再好，跑不起来就不算完成。教程用浏览器逐项实测了工具的四项功能：

• 五项打分：贴入"我今天学了编程"得 1 分（缺受众、缺痛点、缺工具名、缺可见结果）；贴入优化后的标题得 5 分。
• 缺项建议词：缺什么给什么，还能一键加进标题作为参照。
• 字数统计：实时统计并提示是否在 20-30 字的最佳区间，避免被平台截断。
• 历史记录：测过的标题带分数保存在浏览器本地，刷新和关闭都不丢失。

"刷新和关闭都不丢失"这一特性，依赖的是浏览器原生的 Web Storage API 中的 localStorage。与 sessionStorage（页面关闭即清除）不同，localStorage 的数据没有过期时间，除非用户主动清除浏览器缓存。每个域名下的 localStorage 通常有 5-10MB 的存储上限，数据以键值对形式存储，值只能是字符串类型，因此复杂数据结构需要通过 JSON.stringify() 序列化后存入，读取时再用 JSON.parse() 反序列化。这种方案的优势是零配置、零成本、完全离线可用，非常适合小型工具类应用；但它的局限也很明显——数据仅存在于当前浏览器中，换设备或清缓存就会丢失，且不适合存储敏感信息。

四项全部验收通过，这一版才算真正完成。

总结：六个好习惯让 Cursor 开发从碰运气变成做工程

这套工作流的价值不在于做出了一个标题工具，而在于沉淀出六个可复用的开发习惯：

1. 先有项目文件夹，再提需求
2. 规矩（Cursor Rules）定在动手之前
3. 复杂任务先走 Plan 模式，审过再执行
4. Diff 逐条确认，先看改动再接受
5. Checkpoint 能回退，但可靠版本管理靠 Git
6. 浏览器亲自验收，跑得起来才算做完

正如教程所言，六步走下来，你不是在碰运气，而是在做工程。这也呼应了官方文档反复强调的思路：任务越重，越要在计划上花时间。对于想真正上手 AI 编程的新手，理解"看懂改动、管住范围、验证结果"这三件事，比追求写出多复杂的代码更重要。

核心要点