Cursor联动Claude Code：小步开发与Git回退实战指南

把整个项目一股脑交给AI一次做完听起来很省事，可一旦改错了，往往说不清应该退回哪一步。这一讲换一种思路：让 Cursor 和 Claude Code 两个工具配合，为一张已经完成外观的页面补上一个小功能——「今日重点」的保存与刷新恢复。核心方法论只有九个字：看得见、管得住、退得回。

Cursor与Claude Code各司其职

这套工作流的关键在于让两个 AI 工具在同一条工作线上各做自己擅长的事，而不是让它们同时写代码抢活干。

• Cursor：擅长把页面截图和文件放在一起，帮我们把需求说清楚。Cursor 是一款基于 VS Code 深度改造的 AI 代码编辑器，其核心能力之一是多模态理解——它可以同时接收截图、文件内容和自然语言指令，利用视觉识别模型解析页面 UI 的当前状态，再结合代码上下文生成精准的需求描述。这种多模态理解依赖于视觉语言模型（Vision-Language Model, VLM）的底层支持，这类模型能同时处理图像像素信息和文本 token，将截图中的 UI 元素——按钮位置、文本内容、布局结构——映射到代码层面的 DOM 结构和 CSS 样式。这意味着当你拖入一张截图并 @ 引用代码文件时，Cursor 不只是在「看图说话」，而是在建立视觉表现与代码实现之间的双向映射关系，从而能精准判断「页面上看到的这个按钮对应代码里的哪个元素，它目前绑定了什么事件，还缺少什么逻辑」。它能读懂截图里的页面表现，结合 index.html 和 script.js 的现有结构，把模糊的需求转化成准确的文字任务。
• Claude Code：擅长进入项目目录读文件、提方案、改代码、跑检查。Claude Code 是 Anthropic 推出的命令行 AI 编码助手，它直接运行在终端中，可以读取整个项目目录、执行 shell 命令、编辑文件并运行测试，更接近一个具有自主操作能力的开发代理。它是真正的「执行者」。两者的设计哲学不同：Cursor 强调可视化交互与上下文融合，Claude Code 强调终端级别的执行力和项目级别的代码理解。
• Git：负责把每一个确认过的正确结果稳稳存下来。

主线非常明确：Cursor 帮我们把需求说清楚，Claude Code 帮我们把功能做出来，Git 帮我们把正确结果存下来。 而整个过程中「是否继续下一步」始终由人来决定。

第一步：确认目标与整理任务卡

动手之前，先在浏览器里确认这项功能确实尚未实现。输入一条「今日重点」，点击保存页面没有任何反应，刷新之后内容也没有恢复——由此确认保存与恢复功能确实缺失。目标确认得越清楚，验收时越有把握。

文中提到的「保存与刷新恢复」功能，在 Web 开发中通常通过浏览器提供的 localStorage API 实现。localStorage 是 HTML5 规范定义的客户端存储机制，它以键值对形式将数据持久化在用户浏览器中，容量通常为 5-10MB，数据不会随页面刷新或浏览器关闭而丢失（除非用户主动清除）。与之对应的还有 sessionStorage（会话级存储，关闭标签页即失效）和 Cookie（容量小、会随 HTTP 请求发送到服务器）。对于「今日重点」这类轻量级、纯前端的数据保存需求，localStorage 是最简单直接的选择，不需要后端服务器或数据库的支持。

不过，使用 localStorage 时也需要了解几个关键限制：它遵循同源策略（Same-Origin Policy），即同协议、同域名、同端口下的页面共享同一存储空间；它只能存储字符串类型，复杂数据需要通过 JSON.stringify 序列化后存入，读取时再用 JSON.parse 反序列化；它是同步阻塞 API，大量数据读写可能影响主线程性能。对于课程演示的「今日重点」这种少量文本保存场景，这些限制几乎不构成问题，但如果未来扩展到存储大量结构化数据，可能需要考虑 IndexedDB 等更强大的客户端数据库方案。

用Cursor生成清晰的任务卡

接下来进入第一段联动。注意，这一步 Cursor 不修改任何代码，只做一件事：把页面截图和相关文件整理成一张清楚的任务卡。

具体做法是把页面截图拖进 Cursor 对话框，再用 @ 引用 index.html 和 script.js。为什么两类信息要一起给？因为截图说明页面表现，文件说明现有结构，两者结合 Cursor 才能把需求转成准确的文字任务。

给 Cursor 的指令要求它只读检查、不修改文件，并整理出六项内容：

1. 现有页面已经具备什么
2. 可能直接相关的文件
3. 本轮需要实现什么
4. 允许修改的范围
5. 本轮不要修改的范围
6. 完成后的验收条件

这里有个实测细节值得注意：当前 Claude Code 使用的 GLM-4.5 系列模型不支持读取截图，所以图片不传给它，只把 Cursor 整理好的文字任务卡复制过去，由 Claude Code 在项目里独立核实。

第二步：Claude Code Plan Mode核实方案

任务卡就绪后，进入第二段联动。在项目根目录启动 Claude Code，并切换到 Plan Mode（计划模式）。Plan Mode 是 Claude Code 提供的一种安全工作模式：在该模式下，AI 可以完整读取项目文件、分析代码结构、提出实现方案，但所有文件写入操作都会被拦截，必须由用户显式确认后才能执行。这种设计源自一个重要的软件工程原则——方案审查与代码执行应该分离。在传统开发中，这对应于代码审查（Code Review）流程：先看方案是否合理，再决定是否合入。Plan Mode 将这个流程嵌入了人机协作的工作流中，避免 AI 在用户尚未理解方案全貌时就修改了代码。

从更广泛的角度看，Plan Mode 体现了「读写分离」的安全原则。在大型团队中，资深工程师审查方案（Architecture Review）和审查代码（Code Review）是两个独立环节——先确认方向正确，再确认实现正确。Plan Mode 将这个流程压缩到了人机对话中：AI 先展示它打算做什么（相当于提交 PR 的描述），人确认后才允许它真正动手（相当于批准合入）。这避免了一个常见陷阱：AI 在用户还没理解全貌时就已经改了十几个文件，等发现方向错误时已经难以回退。

把 Cursor 的任务卡原样粘贴过去，再补一条指令：先核实、不修改，必须亲自检查项目文件，不能跳过核实直接动手。方案提出后，人只需检查四件事：

• 它准备改哪个文件，是否在任务卡允许范围内？
• 要补的逻辑是否符合任务卡目标？
• 检查是否覆盖验收条件？
• 有没有把无关页面和依赖带进来？

关键：先建立Git基线再动手

方案看清楚之后，不要急着点「同意执行」。这里有一个极其重要的处理方式：先按 ESC 关闭卡片，因为动手前还有更重要的事——给项目存一个起点。

Git 是目前最主流的分布式版本控制系统，其核心概念是将项目在每个时间点的完整状态存储为一个「提交」（commit）。所谓「基线」（baseline），是指一个经过确认的、已知正确的项目状态快照。在 AI 辅助开发中，基线的意义被进一步放大：由于 AI 可能一次性修改多个文件、引入不可预期的变更，如果没有事先保存的基线，开发者就失去了「回到出发点」的能力。Git 的 diff 命令可以精确显示任意两个提交之间的差异，checkout 命令可以将单个文件恢复到指定提交的状态，这些都是实现「退得回」的基础操作。

此时页面仍是「保存功能尚未实现」的状态，正是保存基线的正确时机。切回菜单模式后，让 Claude Code 先查看当前改动、确认没有密钥个人配置或临时文件，再创建第一次 Git 提交，提交说明写「今日重点保存功能待实现」。

基线一定要在开发之前建立，不能等功能完成以后再补。起点没有了，后面的回退就无从谈起。

第三步：实现功能与人工验收

Git 基线保存后，才轮到 Claude Code 动手。指令要求它只实现本地保存、刷新恢复和页面更新，只改方案中确认的文件，不新增依赖，完成后运行约定的自动检查并停止。

执行过程中不需要逐行读代码，重点看三件事：是否只改了确认的文件、是否没有增加依赖、自动检查是否真正覆盖了「空白不能保存、保存后立即显示、刷新后仍能恢复」这几种情况。

这里要澄清一个易误解的点：自动检查是 Claude Code 按方案运行的一段可重复检查，不是它嘴上说「已经检查」就算数。如果它没实际运行，就要求它重新做，跑通了才算数。

复核Diff与浏览器验收

实现完成后还有最后一关。先回 Cursor 看 Diff——这是 Cursor 在这条工作线上的第二个作用：把 Claude Code 的改动可视化呈现，便于复核。

Diff（差异比对）是软件工程中最基础也最重要的代码审查工具之一。它逐行显示文件修改前后的差异：绿色标记新增行，红色标记删除行，便于审阅者快速定位变更范围。在 AI 辅助开发场景下，Diff 复核的重要性远超传统开发。原因在于：AI 生成的代码可能包含看起来合理但实际引入了副作用的改动，比如无意中修改了与当前任务无关的函数、改变了变量作用域、或引入了不必要的依赖。通过 Cursor 的可视化 Diff 界面，开发者可以在几秒内确认「AI 只改了它该改的地方」，这比阅读 AI 的自然语言总结要可靠得多。

看 Diff 时只关注：改动是否只在 script.js、按钮前后逻辑是否一致、有没有混入无关文件。

然后回到浏览器做人工验收：输入内容点保存立即出现、刷新后内容仍在、清空后点保存给出「不保存空白内容」的提示。到这里两段联动才算闭环。终端显示完成只代表这一轮操作结束，功能是否真的可用必须回到浏览器人工核验。

验收通过后，创建第二个 Git 提交，说明写「实现今日重点保存与刷新恢复」。至此仓库里有了两个清楚的版本。

两种回退方式：Checkpoint救急，Git管长期

有了两个版本，就可以演示两种「后悔药」的使用场景。

Claude Code检查点（Checkpoint）快速回退

Claude Code 每次提问前会自动拍一张快照。改错了，在空输入框连按两次 ESC 或输入 rewind，就能打开回退菜单，把代码恢复到修改之前。

Checkpoint 机制本质上是一种会话级别的文件快照系统。每当用户发起一次新的提问，Claude Code 会自动记录当前被它编辑工具管理的文件状态。这类似于文档编辑器中的「撤销历史」，但粒度是按对话轮次划分的。从计算机科学的角度看，Checkpoint 和 Git commit 虽然都是「快照」，但它们的实现层级和持久性完全不同。Git commit 基于内容寻址的有向无环图（DAG），每个提交通过 SHA-1 哈希唯一标识，存储在 .git 目录中，即使项目在不同机器间传输也能完整保留。而 Claude Code 的 Checkpoint 更接近于编辑器的 undo buffer——它是进程内存中的临时状态记录，依附于当前会话的生命周期。这就从根本上解释了为什么 Checkpoint「救得了急但管不了长期」：它的设计目的是降低单次对话中的试错成本，而不是替代版本控制系统。

需要特别注意的是 Checkpoint 的局限性：它只追踪 Claude Code 通过自身编辑工具（如 write_file、edit_file 等内置工具）修改过的文件，如果 AI 通过 shell 命令（如 sed、echo 重定向）修改了文件，或者触发了外部进程的副作用（如数据库写入、API 调用），这些变更都不在 Checkpoint 的管辖范围内。

它的优点是快，不需要记任何 Git 命令，眼前刚改错的东西马上能退回去。但它并非万能：只管当前对话里 AI 用编辑工具改过的文件，命令行改的、数据库、远程服务、网络请求都撤销不了；而且对话结束或过期后检查点就消失了。一句话——它救得了眼前的急，管不了长期的账。

Git版本回退：可靠的长期保障

长期可靠的回退靠 Git。让 Claude Code 先显示两条提交中 script.js 的差异，确认后再只把该文件恢复到指定提交，不动其他文件。回退后同样要回到浏览器验证效果是否真的消失或恢复。

这里有一条重要建议：初学阶段只做「把单个文件恢复到指定提交」这一种操作，删除提交、强制覆盖历史不要作为入门常规做法。这是因为 Git 的操作可以分为「安全操作」和「危险操作」两大类。安全操作如 git checkout <commit> -- <file> 只修改工作区内容，不改变任何提交历史，相当于从档案馆借出一份旧文件的复印件。危险操作如 git reset --hard 和 git push --force 会改写提交链，相当于撕掉档案馆里的原始记录。在多人协作中，历史重写可能导致其他人的本地仓库与远程仓库不一致，引发合并冲突甚至数据丢失。即使在个人项目中，初学者也容易因误操作 reset --hard 丢失未提交的工作。因此「只做单文件恢复」是一条非常务实的安全准则，风险可控，即使操作有误也可以再次恢复。

总结：小步开发的核心心法

回顾整条工作线：浏览器确认目标 → Cursor 整理任务卡 → Claude Code 核实并实现 → Cursor 看 Diff、浏览器验收 → 出错用检查点救急，验收通过用 Git 留下版本。

这套工作流本质上是将敏捷开发中「小步迭代、持续验证」的思想应用到了 AI 辅助编程场景。在传统敏捷开发中，团队通过短迭代周期（通常1-2周）、持续集成和自动化测试来降低风险。而在 AI 辅助开发中，由于 AI 的输出不可完全预测，迭代周期被压缩到了以「单个功能点」为单位——每实现一个小功能就验收一次、存档一次，确保每一步都站在稳固的基础上。

这里暗合了控制论中「反馈回路最小化」的原则：系统的可控性与反馈回路的长度成反比。在传统瀑布式开发中，反馈回路可能长达数月（需求→设计→开发→测试→交付），任何环节的偏差都会在后续环节被放大。敏捷开发将反馈回路缩短到 1-2 周的 Sprint。而 AI 辅助开发进一步将其压缩到「单功能点」级别——每一个功能的实现、验收、存档构成一个完整的微循环。这种极短的反馈回路使得错误被发现的速度远快于被放大的速度，这正是「管得住」的理论基础。

最后的建议非常实用：以后做任何小工具，都不要从「把整套系统做完」开始，先选一个可以复现、可以验收、可以回退的小功能，等这一小步真正做对了，再进入下一步。 这正是「看得见、管得住、退得回」九字心法的精髓所在。

核心要点

• Cursor 负责需求翻译，Claude Code 负责执行落地：两个 AI 工具各司其职，Cursor 通过多模态理解将截图和代码融合成清晰任务卡，Claude Code 在终端中读取项目、核实方案并实现功能，避免工具职责混乱。
• Plan Mode 实现「先审后做」：Claude Code 的计划模式将方案审查与代码执行分离，AI 必须先展示完整实现方案并经人确认，才能动手修改文件，对应传统开发中的 Code Review 流程。
• 基线必须在开发前建立：在 AI 动手修改任何代码之前，先用 Git 提交当前已知正确的项目状态作为基线，确保任何时候都有明确的回退起点。
• Checkpoint 救急，Git 管长期：Claude Code 的检查点机制适合会话内快速撤销，但仅限于 AI 编辑工具直接修改的文件且会话结束即失效；Git 提交是持久化的版本记录，支持跨时间、跨机器的精确回退。
• 人工验收不可省略：终端显示完成不等于功能可用，每轮实现后必须回到浏览器人工核验保存、刷新恢复、边界条件等验收项，Diff 复核确认 AI 只改了该改的文件。
• 小步迭代是核心策略：不要一次性交给 AI 做完整个系统，而是以单个可复现、可验收、可回退的功能点为单位，每完成一步就存档一步，将反馈回路压缩到最短。