Cursor顶级用户转向Claude Code 2.0的真实体验

你收藏了 6～7 篇关于 Claude Code 的文章。你已经看到了这股浪潮，也想成为其中的一员。这里有一份全面的指南，作者从 2021 年起就开始使用 AI 编程，并且已经替你读完了所有那些 Claude Code 指南。

这份指南结合了：

我使用 AI 编程 5 年的经验

我使用 Claude Code 的经验

我整理的 10 多篇文章和无数篇关于 Claude Code 的 X 帖子（参考资料见文末）

读完这篇文章后，唯一能限制你的，就只剩下你自己的想法了。

时间来到 2023 年 3 月。Github Copilot 代表着当时 AI 编程的最前沿。

ChatGPT 仍然是个新鲜事物。人们并不认为模型能力会理所当然地持续提升。

但我们立刻意识到，这将带来范式转变。

我们可以创建一个让 AI 循环思考的系统，再为它配备一些工具，让它替我们搜索网页、编写代码。空气中弥漫着 AGI 的气息！

我们决定把这些循环称为“智能体”。我很幸运地参与构建了最早的 AI 智能体 AutoGPT。它一经发布便迅速爆火，直到今天仍然是最快达到 10 万 star 的代码仓库。

但它其实并不好用。如果足够幸运，偶尔可以让它做出一个勉强能运行的井字棋游戏。

至于更复杂的东西？想都别想。

Cursor 在 2023 年带着满满的承诺登场。我在 2023 年 10 月试用后弃用了它，2024 年 5 月又试了一次，还是弃用了。老老实实从 ChatGPT 复制粘贴，依然更好用。

随后，Cursor Composer 于 2024 年 9 月发布。

从那一刻起，我 90% 的代码都由 AI 生成。

我几乎住在这个编辑器里。我不断挑战它的极限，写了一份从未发布过的内部最佳实践指南，并摸清了所有技巧：精准放置光标、管理上下文窗口、编写 Cursor 规则，以及模型能力那些尖锐而棘手的边界。

我以为自己找到了解决所有问题的答案。Cursor 团队甚至给我发过一封邮件，告诉我属于排名前 0.01% 的 Cursor 用户。

今年早些时候，我试用了 Claude Code。然后弃用了。

与我在 Cursor 中搭建出的工作流相比，它的工作方式感觉像是倒退了一步。模型能力还差一点火候，多数时候我仍然需要了解代码中究竟发生了什么。

我为什么要使用一个能力勉强相当、用户体验却差了 10 倍的工具？

然后 Claude Code 2.0 出现了。

它的用户体验已经进化。整个运行框架更加灵活、稳健，Bug 也得到了修复。但这些都只是次要因素。

事实是，无论 Anthropic 对 Opus 4.5 做了怎样的 RLHF，都彻底改变了局面。我们现在已经进化到了下一个抽象层级。

你不再需要审查代码，也不再需要在文件或函数层面指导模型。你可以转而测试行为。

我只用了一天时间，就构建了一个遗传算法模拟器。它带有交互式可视化功能，能够实时展示进化过程，其中包括复杂的适应度函数、选择压力、突变率等内容。我一行代码都没有写。

下面是人们正在使用 Claude Code 构建的一些东西：

一个可以将 Claude Code 智能体在办公室中的工作过程可视化的插件：子智能体会被雇用、习得技能，并提交完成的工作。

一个 Theo Jansen Strandbeest 模拟器：用于机器人可视化的复杂连杆系统。

一个进化模拟器：在假期的零碎空闲时间里随手做出来的。

一个售价 30 美元、带有运动检测和鸟类分类功能的喂鸟器摄像头：包括 ESP32 固件以及在 Fly 上的部署。

下面是我最近使用 Claude 构建的其他项目：

莱特兄弟飞行模拟器

像本文这样的交互式文章（仍在开发中）

私人研究和学习项目

现在每个人手里都有一根魔法棒。你只需要弄清楚该如何使用它。

Twitter 上的一位怀疑者问道：

“谁能向我解释一下，为什么人们使用 Claude Code 而不是 Cursor？”

直到一个月前，我也持有同样的看法。下面是我的回答：

异步优先的思维方式：待在 IDE 里，很容易让人本能地审查代码、追求完美。但我们已经上升到了下一个抽象层级，而终端原生的工作流会迫使你迈出这一步。

针对自身脚手架进行过 RLHF：Claude 模型（尤其是 Opus 4.5 及以上版本）在 Claude Code 中的表现明显更好。文件搜索、工具使用，一切都针对这个界面进行了调优。

成本效率：与 Cursor 套餐相比，Claude Code 似乎能让每个 token 发挥更大的价值。

可定制性：DIY 是原生能力，并且内置了可组合性。

像素级完美的前端：为了获得像素级完美的 UI，我经常发现自己仍然需要参与迭代循环。

学习：当你为了学习而迭代某些内容时，反馈循环会快得多。

防止上下文污染：如果只是一个与任何 Claude Code 终端都无关的小改动，直接在 Cursor 中完成最方便。

建议：如果你属于以下情况，请将 Cursor 作为默认工具：

a）你是一名喜欢自然编写代码的程序员，觉得把所有代码都抽象成行为很可怕；或者 b）你想学习如何编程。

如果你属于以下情况，请使用 Claude Code：

a）你完全不打算学习，只关心输出；或者 b）你是抽象最大化主义者。

Claude Code 有一个 VSCode 扩展，可以帮助你更轻松地完成过渡。但它的用户体验仍然远不及 Cursor，而且这也违背了使用 Claude Code 的初衷。

你应该把抽象程度拉到最大。

大多数任务使用搭配 Opus 4.5 的 Claude Code。包括规划、代码生成、复杂重构和架构决策。

当我需要紧密的反馈循环时，使用搭配 GPT 5.2 / Sonnet 4.5 的 Cursor。包括学习、打磨 UI，以及进行小改动。

ChatGPT 用于处理少数几类事情：（a）不需要项目上下文的编程相关问题（例如在 Azure 中配置一台 A100 VM）；（b）对方案征求第二意见；以及（c）当我不理解某个输出，或者需要 Claude 对它所说的内容作进一步解释时。

使用 Ghostty 作为终端。它由 HashiCorp 的联合创始人开发。速度快、不会闪烁、原生支持终端分屏，文本编辑体验更好，并且原生支持图片。

使用 Wispr 将语音转换为文字。如果你居家办公或者拥有独立办公室，不必一直打字会很有价值。腕管综合征，退散吧。不过我得处于某种特定状态时才会使用它。

AI 智能体编程的五大支柱

Download these commands to ~/.claude/commands/:

1. /setup-claude-code (run once per machine - installs all other commands):
https://gist.github.com/SilenNaihin/3f6b6ccdc1f24911cfdec78dbc334547

2. /setup-repo (run once per project):
https://gist.github.com/SilenNaihin/e402188c89aab94de61df3da1c10d6ca

Fetch each gist and save as [command-name].md in ~/.claude/commands/

Then run /setup-claude-code to install everything else.

Download these commands to ~/.claude/commands/:

1. /setup-claude-code (run once per machine - installs all other commands):
https://gist.github.com/SilenNaihin/3f6b6ccdc1f24911cfdec78dbc334547

2. /setup-repo (run once per project):
https://gist.github.com/SilenNaihin/e402188c89aab94de61df3da1c10d6ca

Fetch each gist and save as [command-name].md in ~/.claude/commands/

Then run /setup-claude-code to install everything else.

这一切早已写在经文之中。系好安全带。

下面是我在长期实践中总结出的一些上下文管理技巧：

“spawn a subagent to do deep research on this topic”：生成子智能体来并行工作。它们不会污染主智能体的上下文。每个子智能体都可以独立工作，并且只将工作中有价值的上下文添加到主智能体的上下文中。

/compact：其他人对压缩上下文有所顾虑，但为了留在同一个对话中继续工作，接受压缩所带来的取舍通常是值得的。Claude 的压缩系统很智能。

/transfer-context：话虽如此，在压缩足够多次之后，或者执行了任何不直接相关的任务之后，输出质量都会下降。不要害怕创建新对话。如果需要转移上下文，只需让模型生成一段提示词，供你放入另一个模型中，其中包含该任务所需的相关上下文和文件（对于任何高级任务，可以创建 md 文件，不过我觉得管理这些 md 文件很麻烦）。这里有一个我的 /transfer-context 命令的 gist。

/context：显示你还剩多少上下文。你会看到一份类似这样的报告：当上下文即将耗尽时，Claude 也会提醒你。此时你需要决定是压缩上下文，还是切换到新对话。不要等到它降至 0%，因为这会降低输出质量；如果它在任务进行到一半时压缩上下文，就可能忘记你提供过的相关信息，甚至包括你在上一次对话中刚刚给出的内容。

保持专注：一个对话大致对应一个任务。如果一个对话专注于单一任务，它就会包含更多相关上下文。如今，“任务”的定义已经比过去宽泛得多。测试它的极限，看看什么方式最适合你。

在已经拥有上下文的对话中生成内容，效果永远是最好的，无论生成的是文档、测试，还是相关代码。有时对于一次性改动（例如修复 Bug），我会直接在当前对话上下文中完成，提交更改，然后回退对话以节省上下文。

使用 /resume 从之前的对话继续。

关于上下文限制的说明：Claude Code 的上下文上限是 20 万。与 Codex（40 万）或 Gemini（100 万）等替代方案相比，你会更快撞上这堵墙。

你投入规划的时间，与智能体的输出质量成正比。

经验法则：你每花 1 分钟规划，一个好的提示词就能为你节省 3 分钟用于后续提示和调试的时间。

按两次 Shift+Tab：进入计划模式。我会使用它，但只用于较大的任务，或者我还不清楚自己究竟想要什么样的结果时。注意：计划模式会将内容保存为全局 ~/.claude 文件夹中的 .md 文件，而在你的仓库中无法访问它。退出计划模式后，我会让 Claude 在仓库里创建一个 plan.md；或者完全跳过计划模式，直接在聊天中进行规划。

计划模式对话：发起对话、提出问题、让它探索代码，然后共同制定计划。当你满意后，就说：“write plan to docs/*.md and start coding.”；如果正处于计划模式，则说：“yes, and bypass permissions.”

冲刺式待办事项列表：对于较大的项目，建立一个 progress.txt 和结构化任务列表（prd.json）。高级部分会进一步介绍。

生成回退计划：运行你的提示词，看看它生成了什么，然后回退，并继续规划最终方案。

创建计划后，使用我们的 /interview-me-planmd 命令。它会在开始构建前，围绕你的计划对你进行深入访谈。（参见这篇 X 帖子，我自己也试过，发现它确实有效。）

Opus 4.5 非常擅长解释问题，还能制作出色的 ASCII 图。我的探索过程包括提出大量问题、澄清需求，以及理解应该在哪里、如何以及为什么进行修改。

向后兼容性：目前的模型已经被 RLHF 调教得矫枉过正，以至于你必须明确要求它不要保持向后兼容性。

警惕过度工程化：Claude 模型非常喜欢做得太多——创建额外文件、加入你没有要求的灵活性，以及不必要的抽象。尽可能明确地说明不要做什么。Pete 总结得很好：“我们想要尽可能简单的改动。我们不关心迁移。代码可读性最重要，为了实现这一点，我们乐意进行更大规模的修改。”

请记住：编码智能体更擅长创建新文件，而不是编辑现有文件。调整初始提示词，然后将所有代码从头重置，往往很有价值。

有一则经典的 XKCD 漫画，讲的是程序员花一周时间，将一项只需 5 分钟的任务自动化。

有了智能体编程，这个等式已经反转。现在，闭合反馈循环几乎总是值得的。自动化的成本已经大幅下降。过去需要一周完成的事情，现在只需要一场对话。

如果你发现自己做某件事超过一次，就闭合反馈循环。如果你花了大量时间做某件事，也闭合反馈循环。

为重复使用的提示词创建命令

为重复性工作创建智能体

更新你的 claude.md

把提示词写进 .md 文件（就像 Cursor rules！）

修改 tsconfig 和其他配置文件

你或模型知道自己是否正确的唯一方式，就是能够验证输出。

以前，你必须深入代码。后来使用 Cursor 时，你必须批准每一次编辑。现在，只需通过接口测试来检验行为。

接口测试让你能够知道哪里出了问题，并对问题作出解释。

对于 UI，这意味着亲眼查看；对于 UX，这意味着实际点击操作；对于 API，这意味着发出请求，并检查响应。

理解闭合反馈循环的一个好方法是：让智能体更容易验证，也就是让你自己更容易验证。

对于大型重构：事先让 Claude 构建全面的接口测试。这可以确保重构结果正确。这些测试会成为你的验证层。

编写测试：最好的测试，是在与被测代码相同的上下文中编写的。

让耶稣来掌舵。对于生产应用，在 PR 对应的 staging 或 dev 环境中进行测试。集成测试是你的安全网。如果它们通过了，就发布。

AI 编写代码很快，但调试 AI 代码需要不同于调试自己代码的技能。代码不是你写的，所以你没有相应的心智模型。

当某些东西失败时，使用系统化的调试方法。我有一个 /debug 命令，用于触发彻底调查：

为可能的问题原因建立假设

阅读所有相关代码（慢慢来）

添加有针对性的日志来验证假设

在新的聊天中换一种方式处理

尝试不同的模型

最坏的情况：亲自深入代码

三次法则：如果你已经把同一件事解释了三遍，而 Claude 还是没有理解，那么继续解释也不会有帮助。改变某个条件。

展示，而不是描述：如果 Claude 一直误解你的意思，就给它看一个你期望输出样式的最小示例。Claude 很擅长遵循示例。

重新开始：如果你正在对计划进行大量修改，就启动一个新会话。让智能体总结当前情况、已经尝试过的方法以及得到的经验。将总结复制粘贴到新的 Claude 会话中。

不同模型有不同的盲区。遇到阻碍时，获取新的视角：

/ensemble-opinion：获取多个模型对问题的看法。并行运行 Claude、Gemini 和 Codex，然后综合它们的回答。灵感来自这里。

/codex-delegate：将任务委派给 OpenAI Codex 自主执行。

你可以自动审查自己的 PR 和提交。在人工审查开始之前，Claude 就可以发现问题、提出改进建议，并提供能够感知上下文的反馈。

你可以通过 Stop hook（稍后会详细介绍）实现这一点：以无头模式（-p）运行 Claude Code，并在每次提交时触发；也可以通过 PR 实现。我使用自动审查时，始终是在 PR 层面进行的。

如果你有权限，请使用 Codex 审查 PR。你不会希望由拥有相同归纳偏差的模型来审查它自己编写的代码。Codex 能发现 Claude 遗漏的问题，反之亦然。

jscpd：检测重复代码

knip：移除死代码

code-simplifier 插件：在会话结束时简化复杂代码。Claude Code 的创始人推荐使用。

运行 /refactor，使用这些工具进行一次专门的代码清理会话。

当 Claude 不断犯错、让我感到痛苦时，或者在代码库中加入大量新内容之后，我会进行重构。认为持续进行重构会扼杀开发势头的人不只我一个。应当把它视为一个独立阶段。

Claude 不会自动理解你对代码整洁度的偏好。随着时间推移，将能够体现你个人偏好的上下文添加到 Claude.md 中，从而减少重构时间。

Claude Coder 高效使用技巧

始终倾向于使用能力最强的模型。使用 /model 切换到 Opus 4.5。与质量差异相比，成本差异微不足道。

在提示词中使用 @ 直接提及文件。有时你需要输入 @/，才能让完整的文件列表显示出来。

我最常用的键盘快捷键

按两次 Shift+Tab：计划模式。

Ctrl+R：搜索提示词历史记录（类似于终端中的反向搜索）。

Esc+Esc：访问 /rewind 检查点功能。当 Claude 把某些东西搞砸时，可以回退到之前的检查点。代码和对话都可以回退。

!：在聊天中为消息添加 ! 前缀，即可输入任意 bash 命令。

实用的 Mac 快捷键：

Shift+Enter：添加换行而不发送消息。

Cmd+Option+C（Raycast）：访问完整的剪贴板历史记录。复制多个内容时必不可少。

Option+方向键：按单词跳转。Cmd+方向键：跳转到行首或行尾。

“直接问 Claude”心态

很多你以为必须手动完成的事情，其实通常都可以让 Claude 来做。比如更改默认权限、修改配置，以及任何与文件相关的操作。

培养这种心态：直接问 Claude。它知道如何完成创建自定义命令之类的事情（如果不知道，它会搜索网络并找出方法）。

同时使用 12 个并行终端

现在，我经常甚至不会为仓库打开 IDE。我会同时打开 12 个终端，并在任意时刻积极使用其中的 1～8 个。通常每个项目使用两个终端：一个用于上下文管理或 Ralph，另一个用于主动多线程工作。

想同时在 4 个项目中取得实质性进展，这些项目就必须更偏向执行，而不是思考。而且我必须喝下一罐 Celsius，再来一盒 Zyn，才能完全进入状态（这是比喻，我两样都不碰。我只碰生活这种烈性毒品）。

人的自然直觉是使用 git worktree 隔离并行工作。

但在运行多个实例时，让它们共同猛改同一个分支才是最佳方案，因为这样速度最快，也最简单。实践中，如果方法得当，你几乎不需要使用 worktree。Armin 也同意，Pete 也是。

用某个终端实例的“爆炸半径”来思考问题。在发送提示词之前，评估改动的作用范围。如果它与另一个实例的工作重叠，你就应该让 Claude 在那个实例中完成这项工作。你会发现，这种思路真正不适用的情况极其少见。

最坏的情况下，如果出现错误或你计算失误，始终可以回退或修复。与这种情况偶尔发生所付出的成本相比，这种做法带来的收益是值得的。

我们的 /commit-smart 命令有助于创建符合上下文的提交。它只会提交当前 Claude Code 实例修改过的文件，因此我可以回退某一项特定改动，而不会丢失无关工作。

对于个人项目，我会直接推送到 main。与其他人协作时：

如果只有一个人，我会创建一个名为 silen 的分支，定期为它创建 PR 并合并；或者

如果有多位协作者，我会创建多个分支，让各个 Claude 实例签出对应分支，并且

如果是一个更成熟的代码仓库，我会创建第二个 worktree，并让两个终端分别关联两个不同的分支。

另一个技巧是：当一个会话正在执行重构之类的任务，而你已经在第二个实例中输入好了下一个新增功能的提示词时，可以先在第二个实例中执行 !sleep 600，然后再发送提示词。

默认的 /init 命令会分析你的项目并生成一份初始配置。我们的 /setup-repo 命令则更进一步，会从一开始就帮你配置好代码仓库。它包含适用于智能体式代码仓库的最佳实践（也会参考 /init 命令），并通过提问了解你的具体需求。

通常来说，你应该根据实际遇到的痛点决定要加入哪些内容。除了 /setup-repo 提供的基础模板之外，还可以包含：

项目摘要和目录结构：让 Claude 能够立即了解项目概况。

主要依赖和设计模式：如果你使用领域驱动设计、微服务或特定框架，请把它们记录下来。

非标准的组织方式：记录任何可能让代码库的新成员（或 Claude）感到困惑的内容。

工具链和代码仓库布局信息：尽量减少 AI 智能体需要自行搜索的信息量。

仅在必要时添加注释（尽量减少“切斯特顿栅栏”式错误）：对于会在其他地方被引用，或缺少上下文便难以理解的代码，应添加注释。你不需要让所有地方都具备人类可读的文档，因为有需要时可以稍后再生成。

Monorepo 需要额外指导：Claude 不太擅长处理 Monorepo。请明确指出你正在处理哪个 package，使用从代码仓库根目录开始的完整路径，并记录各个 package 专用的脚本。

当你在同一个对话中发现注意事项、添加新的模式或更改项目结构时，请使用 /update-claudemd。它会尽量保守地更新，只保留真正有价值的信息。

优秀的提示词和指导原则最有帮助。UI 很难描述，也很难验证。

我发现，让它通过截图查看 UI 的方式既缓慢又不够完美，不过一个月后情况也可能不再如此。

我网站上图书和播客版块的交互花了很长时间才完成。这个过程需要人类判断、截图、解释，以及自然地手写代码。

让叶子组件保持展示性：业务逻辑应放在父组件中。关注点分离可以方便你审查 props 并发现异常，也有助于 AI 智能体找到可供遵循的模式。

在最后一公里阶段，回到你的 IDE：AI 很难完成像素级精准的工作。你很可能仍需要自然地手写一些代码，才能达到完美效果。

响应式设计很容易被遗忘：模型不善于始终记住响应式设计的重要性。从一开始就提醒它注意这一点，同时做好自然地手写一些代码来完善结果的准备。

frontend-design 插件：可以在 Claude Code 插件商店中找到。它有助于进行设计决策和规划组件结构。直接让 Claude 安装即可。

把截图拖进对话中。

Pete 提到，他至少 50% 的提示词都包含截图。我只偶尔使用截图。截图对修复 UI 问题可能很有帮助，但对于需要反复迭代的前端工作来说，速度较慢且效果并不完美。

我喜欢先在 Nano Banana Pro 中生成 UI 或视觉组件，然后粘贴截图，让 Claude 根据截图生成实现。

让 linter 闭嘴：有时 AI 智能体会倾向于使用 eslint-disable 消除 linter 报错，而不是解决实际问题。如果你发现这种情况，可以使用 eslint-comments/no-restricted-disable。

制作样式参考文档：创建样式组件和组件参考 Markdown 文件，并始终引用它们。在 tailwind.config 中配置主色、间距 token 等内容。

安装 Vercel 的 React 最佳实践 skill：Vercel 发布了一个封装 React 模式和约定的 skill。任何 React/Next.js 项目都值得安装。

在这方面，可验证性相对容易实现。以下是一些建议：

使用 ORM 将 schema 作为上下文：把整个数据库 schema 放在一个 AI 能够理解的文件中。虽然还有其他实现方式，但我非常喜欢将 Prisma 与编程 AI 智能体搭配使用。

真实的种子数据：投入精力完善工具链，让本地数据库始终包含贴近真实情况的数据。这样，AI 智能体就能在更真实的环境中自行验证结果。

生成 API 文档和 Postman 工作区：处理 API 时，让 Claude 生成文档和 Postman collection，以便你自己轻松测试各个端点。

我才刚开始尝试这种方式。我让 Claude 可以访问一台配备 A100 的虚拟机，想看看它会进行哪些实验。

Karpathy 分享了他的体验：

从早上开始，Claude 就一直在运行我的 nanochat 实验。它会编写实现、用玩具示例调试、编写测试并让测试先失败再通过、启动训练任务、通过持续查看日志和从 wandb 拉取统计信息来照看任务、持续维护一个记录重点内容的 Markdown 文件、持续记录迄今为止的运行情况和结果，并用美观的表格展示结果。我们刚刚完成了一些性能分析，发现了优化器中的低效之处，解决了这些问题，并测量了改进效果。

它并不完美，但我过去习惯手动完成所有这些事情。因此，仅仅是看到它在一旁持续处理范围更大的问题，并以相对连贯的方式协调所有这些流程，就绝对是一种全新的体验，也彻底改变了工作流。

到目前为止，在我看来，模型几乎能够理解任何东西，也是一起思考问题的优秀伙伴。把一份关于你假设的文档粘贴进去，它们就能帮助你付诸实践。

玩得开心。但请记住，非同寻常的主张需要非同寻常的证据。不要因为一次生成的结果就坠入精神错乱的深渊。

Claude Code 很适合生成 IPYNB 文件，也适合通过较长的提示词学习概念。但当你坐在那里努力理解某些内容，并且希望自己始终参与其中时，Cursor 的 Cmd+K 和聊天功能是最佳选择（ChatGPT 也一样）。

质疑你的假设：让它挑战你的理解。

填空式代码：不要让它生成所有内容，而是让它创建留有空白的脚手架，再由你来补全。

Claude Code 高级用法

在 Mac 上运行 caffeinate -dimsu，防止 Claude 工作时笔记本进入睡眠状态。启动一个任务，合上笔记本，然后出门去做其他事情。

当你粘贴较长的内容时，Claude 会在终端中将其简化显示为 [Pasted text #x +x lines]。十次中有九次，我都喜欢这种处理方式。

这