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

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

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

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

作者明确了工具的边界：不采集数据、不联网、不登录，所有测试的标题都存在用户本地电脑上。这种"纯前端单页工具"的定位，恰好让整个开发流程变得可控、可验收，是新手练手的理想场景。所谓"纯前端单页工具"，是 Web 开发中最轻量的应用形态——它只依赖浏览器端的 HTML、CSS 和 JavaScript 三件套，不需要后端服务器、数据库或任何网络请求。所有逻辑在用户浏览器中本地执行，数据通过 localStorage 等浏览器原生 API 持久化存储。这种架构的部署成本为零——双击 HTML 文件即可运行，也不存在数据泄露风险。对 Cursor 新手来说，它消除了环境配置、依赖安装、接口调试等后端复杂度，让开发者可以专注于学习 AI 协作流程本身。值得一提的是，这种架构在业界被称为"零依赖应用"（Zero-dependency App），它与当前主流的 React、Vue 等前端框架形成鲜明对比——后者虽然功能更强大，但需要 Node.js 环境、npm 包管理器和构建工具链的支持，光是初始化项目就可能让新手卡住半天。纯前端单页工具的哲学是"用最少的技术栈解决问题"，这恰好与 AI 辅助编程的学习目标一致：先跑通流程，再逐步增加复杂度。

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

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

免费档与付费档的区别

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

这里需要理解 Cursor 的 Agent 模式与传统代码补全（如 GitHub Copilot 的 inline suggestion）的本质区别。传统补全是"光标在哪补哪"，一次只生成几行代码片段，本质上是一个基于上下文的文本预测模型，它看到你正在写的函数签名，就预测接下来最可能出现的代码行。而 Agent 模式是一个具备自主规划能力的智能体（AI Agent），它能理解整体需求后同时创建、编辑多个文件，甚至执行终端命令和安装依赖。Agent 会自主决定工作步骤：先读取现有代码理解上下文，再制定修改计划，最后跨文件执行变更。从技术架构上看，Agent 模式背后是一个"感知—规划—执行—反馈"的循环系统：它先感知项目的文件结构和已有代码（通过读取文件树和代码内容），然后规划出一系列操作步骤，接着逐步执行（创建文件、写入代码、运行命令），最后根据执行结果（如终端报错信息）进行自我修正。这种能力让零基础用户也能完成完整项目，但也意味着它的"自主行为"更多，用户需要更强的审查意识来确保 Agent 没有偏离需求。

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

这种双池设计反映了当前大模型行业的成本结构。不同模型的推理成本差异极大：以 Claude 系列为例，Sonnet 级别的模型每百万 token 输入成本约 3 美元，而 Opus 级别可达 15 美元以上，差距达 5 倍。这里的"token"是大模型处理文本的基本单位，英文中大约每个单词对应 1-1.5 个 token，中文则每个汉字通常对应 1.5-2 个 token。一次完整的代码生成对话可能消耗数千到数万个 token，其中包含你发送的需求描述（输入 token）和 AI 返回的代码与解释（输出 token），而输出 token 的单价通常是输入的 3-5 倍。Cursor 的自家模型经过针对编程场景的微调（Fine-tuning）和量化压缩（Quantization），推理成本远低于通用大模型，因此可以提供较充裕的免费额度。所谓量化压缩，是将模型参数从 32 位浮点数降低到 8 位甚至 4 位整数，在轻微损失精度的前提下大幅减少计算量和显存占用，从而降低每次推理的成本。而 Claude Opus、GPT-4o 等前沿模型虽然在复杂推理和长上下文理解上更强，但 token 单价高昂。

省额度的实用技巧

教程给出了一个非常实用的建议：平时用 Auto 自动档，它会按任务自动选择合适的模型，优先消耗自家模型的额度；只有在某一步反复做不对时，再临时切到更强的模型，用完立刻切回来，不要一直锁定在高消耗模型上。Auto 模式的核心逻辑就是根据任务复杂度智能路由——简单的代码补全用轻量模型，复杂的架构设计才调用重量级模型，从而在能力和成本之间取得平衡。这种"模型路由"策略在业界被称为 MoE（Mixture of Experts）的应用层实践：不是所有任务都需要最强的模型，一个智能调度层根据任务特征将请求分发给最合适的模型，既节省成本又保证效果。

有意思的是，国产模型如 GLM、Kimi 系列已在官方模型列表中，官方文档专门标注其"智能程度高、成本低"，对国内用户是实打实的利好。这些国产模型在中文理解和生成方面往往具有天然优势，因为它们的训练数据中中文语料占比远高于 GPT 或 Claude 系列，对于处理中文注释、中文界面文案等场景尤为适用。

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

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

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

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

这一步看似简单，背后却涉及一个重要的技术概念——工作区作用域（Workspace Scope）。Cursor（基于 VS Code）的许多功能都以工作区为边界运行：文件搜索只搜索工作区内的文件，终端默认打开工作区根目录，而最关键的是，AI Agent 的上下文感知范围也被限定在工作区之内。如果你把"下载"文件夹作为工作区，Agent 可能会读取到无关文件并将其误认为项目的一部分，导致生成混乱的代码引用。正确设置工作区，本质上是在为 AI 划定"它能看到的世界"的边界。

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

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

Cursor Rules 本质上是一种"系统提示词工程化"的实践。在大模型应用中，系统提示词（System Prompt）决定了 AI 的行为边界和输出风格。系统提示词与用户提示词（User Prompt）的区别在于：系统提示词在整个对话过程中始终生效，充当 AI 的"人格设定"和"行为准则"，而用户提示词则是每轮对话的具体指令。手动在每次对话中粘贴提示词既低效又容易遗漏。Cursor Rules 将这一过程自动化——规则以 .mdc 文件形式存储在项目的 .cursor/rules 目录下，支持 Markdown 语法和 glob 模式匹配（比如只对 *.js 文件生效的规则，或只在处理 *.css 文件时激活的样式规范）。这种机制借鉴了软件工程中 .editorconfig、.eslintrc 等项目级配置文件的思路：把团队约定固化为文件，而非口头传达。

官方文档有一条最佳实践：当你发现自己在对话里反复重复同一段要求时，就该把它写成规则了。规则分三类：User Rules（全局个人偏好，比如"永远用中文回复""代码注释用中文"）、Project Rules（仅当前项目生效，比如"只用原生 JavaScript，不引入任何框架"）、以及从 Git 导入的团队共享规则（适用于多人协作场景）。针对具体项目的规矩，应选择 Project Rules。写规则可以用自然语言，像平时说话一样描述项目要求、风格和禁忌即可。更进阶的用法包括为不同文件类型设置不同规则、通过 @ 符号引用其他规则文件实现模块化管理。一个写得好的 Rules 文件，就像一份精炼的项目技术规范书，它让 AI 在每次对话开始时就已经"读过"了你的所有要求。

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

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

Plan 模式的设计哲学与大模型领域一个核心挑战直接相关——AI 幻觉（Hallucination）。所谓幻觉，是指大模型以高置信度输出事实上错误或不存在的内容，这在代码生成中表现为：编造不存在的 API 函数名（比如调用一个 JavaScript 中根本没有的 String.toTitleCase() 方法）、添加需求之外的功能、或用错误的逻辑实现看似正确的表述。幻觉产生的根本原因在于，大模型是概率性的文本生成系统，它预测的是"最可能出现的下一个 token"，而非"逻辑上正确的下一个 token"。Plan 模式通过引入"思考-确认-执行"的中间层来缓解这个问题：AI 先用自然语言输出它的理解和计划，人类在这个阶段审查其意图是否正确，然后才授权执行。这类似于软件工程中的"设计评审"（Design Review）环节——在概要设计阶段发现方向性错误的修正成本，远低于在代码实现阶段。OpenAI 和 Anthropic 的研究也表明，让模型先"思考再行动"（如 Chain-of-Thought 推理链技术）能显著降低错误率，因为模型在生成计划的过程中会自我校验逻辑一致性。

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

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

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

Diff（差异比较）是版本控制系统的基石概念，最早可追溯到 1974 年 Unix 系统上的 diff 命令，由 Douglas McIlroy 在贝尔实验室开发。它的核心算法是最长公共子序列（LCS，Longest Common Subsequence），通过比较两个版本的文件内容，以最小编辑距离标记出新增、删除和修改的行。这个算法的时间复杂度为 O(n×m)，其中 n 和 m 分别是两个文件的行数。现代编辑器中的 Diff 视图通常采用"并排对比"（side-by-side）或"行内对比"（inline）两种展示方式，并用颜色编码直观呈现差异。在 Cursor 中，Diff 视图不仅用于查看 Git 提交历史，更关键的是用于审查 AI 每一次代码生成的结果。这相当于把传统软件开发中的 Code Review（代码评审）流程下沉到了人机交互层面——AI 是"提交代码的开发者"，用户是"审查代码的 Reviewer"。即使看不懂每行代码的语法细节，通过 Diff 视图也能快速判断变更范围是否合理、有没有超出预期的"副作用"——比如你只让 AI 改按钮颜色，但 Diff 显示它还修改了数据处理逻辑，这就是一个明确的警告信号。

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

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

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

这里有一条硬规则值得所有新手记住：Cursor 说"已完成"不代表真的做完了。点接受之前，Diff 必须过目。它生成的每段代码你未必逐行都懂，但它动了哪里、动了多少、有没有多余代码，必须清楚。不能它给什么你就收什么。这一原则在软件安全领域有一个对应概念叫"最小权限原则"（Principle of Least Privilege）——AI 的每次代码变更都应该只包含完成当前任务所需的最小改动，任何超出范围的变更都应该被质疑和拒绝。

Checkpoint 回退：改坏了也不用慌

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

这次翻车揭示了 AI 编程中一个常见陷阱——需求模糊导致的功能膨胀（Feature Creep）。当你给 AI 一个宽泛的指令如"做强一点"时，模型会基于训练数据中的常见模式进行"合理推测"：自媒体工具通常有分享功能、用户系统、数据分析面板……于是它把这些都加上了。这不是 AI 的 bug，而是它在忠实地执行一个模糊指令的"最大化解释"。解决方案很明确：需求描述要具体、边界要清晰，比如"只修改输入框的圆角和阴影样式，其他文件不要动"。

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

不过教程也强调了 Checkpoint 的局限：它是对话级别的回退，方便但不够可靠。真正可靠的版本管理是 Git。Checkpoint 和 Git 虽然都提供"回退"能力，但其机制和可靠性完全不同。Checkpoint 是 Cursor 内置的会话级快照，它记录的是"每次 AI 操作前后的文件状态"，生命周期绑定在当前编辑器会话中，关闭项目后可能丢失，也无法跨设备同步。Git 则是由 Linus Torvalds 于 2005 年创建的分布式版本控制系统，每次 commit 会生成一个基于 SHA-1 哈希算法的不可变快照，存储在 .git 目录中，支持分支（branch）、合并（merge）、远程推送（push）等完整的版本管理能力。SHA-1 哈希确保了每个版本的唯一性和完整性——即使修改一个字符，commit 的哈希值也会完全不同，这意味着版本历史是防篡改的。两者的关系类似于"撤销键"和"存档"的关系：Checkpoint 适合快速试错和即时回退，就像游戏中的快速存档（Quick Save）；Git commit 则是正式的版本里程碑，适合标记"验收通过"的稳定状态，就像游戏中的手动存档（Manual Save）。最佳实践是每完成一个功能模块并验收通过后，立即执行 git commit，将 Checkpoint 的临时保护升级为永久版本记录。对于 Git 零基础的用户，Cursor 内置的源代码管理面板提供了图形化的 commit 和 push 操作，无需记忆命令行语法。

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

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

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

• 五项打分：贴入"我今天学了编程"得 1 分（缺受众、缺痛点、缺工具名、缺可见结果）；贴入优化后的标题得 5 分。
• 缺项建议词：缺什么给什么，还能一键加进标题作为参照。
• 字数统计：实时统计并提示是否在 20-30 字的最佳区间，避免被平台截断。这个 20-30 字的建议源于各大内容平台的标题显示规则：微信公众号标题上限 64 字但折叠后只显示约 30 字，抖音标题在信息流中通常只展示前 25-30 个字符，小红书标题上限 20 字。超出显示区间的部分会被截断为省略号，核心信息如果落在截断区域就等于白写。
• 历史记录：测过的标题带分数保存在浏览器本地，刷新和关闭都不丢失。

"刷新和关闭都不丢失"这一特性，依赖的是浏览器原生的 Web Storage API 中的 localStorage。与 sessionStorage（页面关闭即清除，适用于临时会话数据如表单填写进度）不同，localStorage 的数据没有过期时间，除非用户主动清除浏览器缓存或通过 JavaScript 调用 localStorage.removeItem() 显式删除。每个域名（origin）下的 localStorage 通常有 5-10MB 的存储上限（不同浏览器实现略有差异，Chrome 和 Firefox 默认为 5MB），数据以键值对（key-value）形式存储，值只能是字符串类型，因此复杂数据结构（如包含分数和时间戳的标题历史记录数组）需要通过 JSON.stringify() 序列化为 JSON 字符串后存入，读取时再用 JSON.parse() 反序列化还原为 JavaScript 对象。这种方案的优势是零配置、零成本、完全离线可用，非常适合小型工具类应用；但它的局限也很明显——数据仅存在于当前浏览器的当前配置文件（Profile）中，换设备、换浏览器或清缓存就会丢失，且不适合存储敏感信息（因为同源下的任何 JavaScript 代码都能读取 localStorage）。如果未来需要跨设备同步，则需要引入后端数据库，但这已经超出了"纯前端单页工具"的范畴。

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

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

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

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

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

这六个习惯背后，其实对应着软件工程中久经验证的三大实践：需求管理（步骤 1-2：明确边界和约束）、变更控制（步骤 3-5：计划审查、差异确认、版本回退）、质量验收（步骤 6：功能测试）。传统软件开发团队靠流程规范、代码评审制度和测试团队来保障这三点；而在 AI 辅助编程的新范式下，这些责任全部落在了使用者一个人肩上。掌握这六个习惯，本质上就是学会了如何做 AI 的"项目经理"——你不需要亲自写每行代码，但你需要确保方向正确、变更可控、结果可验。