几周前，我从 Cursor 的智能体转向了 Claude Code，而且不准备再回去了。这篇文章介绍我的实际使用方式和最实用的技巧。

作者：Steve Sewell
发布于：2025-07-11
更新于：2026-03-25
原文：https://www.builder.io/blog/claude-code

我是如何使用 Claude Code 的（以及我最实用的技巧）

我做了一年多的 Cursor 重度用户。我写过一篇 Cursor 使用技巧指南，每周都有数千名开发者参考。我深入研究过 Cursor 的每一项高级功能，以及智能体模式的各种最佳实践。

现在，我却为了 Claude Code 把它们全都放下了。

过去几周，我一直完全使用 Claude Code，不再使用 Cursor 的智能体。老实说，我已经回不去了。

下面就是我使用 Claude Code 的方式，以及我总结出的实用技巧。

如果你刚接触 Claude Code，建议先阅读 Claude Code 是什么，了解整体概念后再继续本文。

使用 VS Code 扩展

首先，安装 Claude Code 扩展。它支持 VS Code 和 Cursor，可能也支持 Windsurf。不要期待什么惊艳功能——它基本只是一个启动器。但它让打开 Claude Code 变得极其简单；只要各实例处理的是代码库的不同部分，你还可以在 IDE 的不同面板中并行运行多个实例。

我仍然会用 Cursor 快速完成 Command+K 补全和 Tab 补全。不过，Cursor 的智能体侧边栏？只有 Claude 服务不可用时我才会碰它。

真正有意思的是，我的工作流已经悄然改变。以前，我写代码时会把 Claude 放在一个小小的侧边栏里；现在，我默认先从 Claude 开始，只有审查修改时才去看代码。它已经从辅助界面变成了我的主要工作界面。

终端界面其实很好用

是的，我起初也很怀疑：用终端界面进行对话式代码编辑？听起来像是在倒退。但 Anthropic 把它做得相当不错。

你可以轻松地用 @ 引用文件，使用很实用的斜杠命令，还能精确选择要加入哪些上下文。我大部分时间使用 Opus；除非它偶尔状态不佳，我才切换到 Sonnet。多数人直接使用默认设置就好——系统会先使用 Opus，在用量达到 50% 后切换到 Sonnet，以提高成本效率。

一个实用建议：经常使用 /clear。每开始一项新工作，就清空一次对话。没必要让全部历史记录持续消耗 Token，更没必要让 Claude 为总结旧对话而运行上下文压缩。清空，然后继续工作。

按上方向键可以浏览以前的对话，甚至包括上一次会话的内容。需要引用昨天的信息时很方便。

权限系统会把你逼疯

Claude Code 最令人烦恼的一点，就是几乎做什么都要询问权限。你输入提示词，看它开始工作，然后去查看 Slack；五分钟后回来，却发现它一直停在那里问：“我可以编辑这个文件吗？”

当然可以编辑文件，这不就是使用它的目的吗？

运行基础命令也是一样。“可以运行 lint 吗？”可以！天哪，当然可以。

不过，有一个解决办法。每次打开 Claude Code 后，我都会按 Command+C，然后运行 claude --dangerously-skip-permissions。它没有名字听起来那么危险，可以把它理解成 Cursor 以前的 yolo 模式。理论上，一个失控的智能体会不会执行破坏性命令？当然可能。但我连续用了几个星期，有没有真的遇到过？一次也没有。

是否接受这种风险由你决定，反正我晚上睡得很安稳。

GitHub 集成确实很实用

比较酷的斜杠命令之一是 /install-github-app。运行之后，Claude 会自动审查你的 PR。

这项功能确实很有价值，因为 AI 工具用得越多，PR 数量通常也会越多。而且坦率地说，Claude 经常能找出人类漏掉的缺陷。人类喜欢纠结变量名，Claude 却能发现真正的逻辑错误和安全问题。

关键是要自定义审查提示词。默认配置过于啰嗦，几乎每个细节都要评论。Claude 会添加一个 claude-code-review.yml 文件，里面已经包含提示词。下面是我替换后的版本：

# claude-code-review.yml
direct_prompt: |
  请审查这个 Pull Request，寻找缺陷和安全问题。只报告实际发现的缺陷与潜在漏洞，回答务必简洁。

我们最初使用这项工具时，最大的问题就是它太啰嗦。它会评论各种细枝末节，为每个 PR 写出一整篇文章。我们真正关心的是缺陷和潜在漏洞，所以就明确告诉它只关注这些问题，而且要简洁。

它还能完成其他一些很酷的工作，例如读取 GitHub Pull Request 中的评论并逐项处理，或者直接审查某个 Pull Request。

需要提前了解的操作习惯

由于它采用终端界面，有些行为并不直观：

  • 默认情况下，按 Shift+Enter 不能换行。直接让 Claude 通过 /terminal-setup 配置终端，它会帮你解决。
  • 像在 Cursor 或 VS Code 中一样直接拖入文件，通常只会在新标签页中打开。拖动时按住 Shift，才能在 Claude 中正确引用文件。
  • 无法通过 Command+V 粘贴剪贴板图片，要改用 Control+V。我花了很久才弄明白。
  • 停止 Claude 不是按 Control+C，因为那会直接退出。按 Escape 才能真正停止当前操作。
  • 跳转到以前的消息：连续按两次 Escape，会显示所有历史消息，供你选择跳转。

如果你喜欢，Claude Code 还提供 Vim 模式。反正我不用。

Claude Code 更擅长处理大型代码库

这才是真正拉开差距的地方：Builder 有一个 18,000 行的 React 组件。（别在评论里批评我的代码组织，我知道。）除了 Claude Code，从来没有哪个 AI 智能体成功修改过这个文件。

使用 Cursor 时，我仍会遇到不少小问题。它很难正确应用补丁，经常不得不重写整个文件，在修改超大文件时尤其吃力。

这不只是文件大小的问题，Claude Code 处理复杂任务同样出色。我发现它几乎不会卡住，甚至想不起自己是否真的遇到过。用 Cursor 时，我总觉得需要盯着它；一旦它卡住，我就只能停止任务，然后意识到这件事可能不适合交给它。

Claude 也特别擅长浏览大型代码库、搜索模式，以及理解不同代码区域、组件和共享状态之间的关系。说实话，效果好得有些不可思议。

视频来源：YouTube

从经济角度也很合理

想想看：Cursor 开发的是一个支持多种模型的通用智能体。为此，他们需要维持一整个团队，还训练了自己的模型；在向 Anthropic 支付底层模型费用之后，公司本身也必须盈利。

Anthropic 明显拥有最强的编程模型，也最了解如何让 Claude Code 发挥这些模型的能力。当 Claude Code 遇到瓶颈时，他们可以直接改进模型。

示意图

他们知道模型如何工作、如何训练，也知道怎样深入利用模型，并且会持续训练模型，使它更适合 Claude Code 的实际需求。

这也意味着 Anthropic 可以用尽可能低的价格为你提供尽可能高的价值，因为你只需要向他们这一方付费。

他们可以在 Opus 等模型的使用额度上保持竞争力，不必面对 Cursor 那种还要额外留出利润空间的情况。

示意图

这就像直接从生产商手里购买，而不是经过经销商，效果当然更好。

价格很合理

我订阅的是每月 100 美元的 Max 套餐。如果你觉得一个全天候工作的、聪明得惊人的程序员不值每月 100 美元，不妨看看自己一个小时的工作怎么收费。无论在世界哪个地方，人类工程师的时薪都比这个数字高出几个数量级。

任何管理者认真算一遍账，都会发现它非常划算，即使选择最高的价格档位也是如此。

消息排队功能非常顺手

有一项功能我已经离不开了：消息排队。你可以连续输入多条提示词，Claude 会智能地依次处理。

以前，我会打开记事本，把接下来想做的提示词先写好。看到当前任务完成后，再粘贴下一条并按回车。我使用 Cursor 时就是这样做的，体验很烦人，因为我通常会继续一天中的其他事情——回复 Slack、处理邮件或者做别的工作——回来后才发现智能体不知道已经闲置了多久。

现在，我只需把所有内容排进队列：“再加一些注释”“另外还要……”“还有……也一起做”。Claude 很清楚这些任务应该在什么时候真正执行。如果它需要你的反馈，就不会自动运行后面的排队消息；完成当前工作后，则会在合适的时机开始处理下一条。整个系统相当聪明。

你可以排入很多任务，然后继续做自己的事；很多时候回来就会发现，它已经用合理而聪明的方式完成了大量工作。不过，还是要时不时看一眼，因为它可能需要你提供信息。

自定义能力相当深入

Claude Code 支持自定义 Hooks、斜杠命令和项目专属配置。更酷的是，你可以让 Claude 替你创建这些东西。

我曾让 Claude 添加几项默认 Hook、命令和设置。它检查项目后创建了一份很容易修改的配置文件，其中有几个值得注意的部分。

它添加了一个 CLAUDE.md 文件，用来提供项目概况和 Claude 应该掌握的关键命令。这样它就不必每次都重新扫描代码库，查找“项目有没有构建命令或 lint 命令”，而是始终提前知道这些信息。

它还添加了一些 Hook，用来决定在接受修改前后应该运行什么代码。例如，修改前可以对特定文件执行 Prettier；修改后可以针对该文件运行类型检查，确保只接受正确的文件。

你可以在项目目录的 .claude/settings.json 中配置自己的 Hook，例如：

{
  "hooks": [
    {
      "matcher": "Edit|Write",
      "hooks": [
        {
          "type": "command",
          "command": "prettier --write \"$CLAUDE_FILE_PATHS\""
        }
      ]
    },
    {
      "matcher": "Edit",
      "hooks": [
        {
          "type": "command",
          "command": "if [[ \"$CLAUDE_FILE_PATHS\" =~ \\.(ts|tsx)$ ]]; then npx tsc --noEmit --skipLibCheck \"$CLAUDE_FILE_PATHS\" || echo '⚠️ TypeScript errors detected - please review'; fi"
        }
      ]
    }
  ]
}

Claude Code Hooks 是在 Claude Code 生命周期的不同节点执行的 Shell 命令，例如 PreToolUse（工具执行前）、PostToolUse（工具完成后）、Notification（Claude 发送通知时）和 Stop（Claude 完成回答时）。

Hook 会通过标准输入接收包含会话信息的 JSON 数据，并能借助退出码或 JSON 输出控制执行流程。

例如，你可以创建 Hook，在文件修改后自动格式化代码，在允许编辑前验证输入，或者发送自定义通知。matcher 字段既支持精确字符串（如 "Edit"），也支持正则表达式模式（如 "Edit|Write" 或 "Notebook.*"），用来指定哪些工具会触发 Hook。

你还可以在 Claude Code 中使用交互式 /hooks 命令，通过菜单界面配置 Hook；这通常比直接编辑 JSON 更简单。

创建自定义斜杠命令

添加自定义斜杠命令也很容易。只需创建 .claude/commands 文件夹，再以命令名称新建一个 .md 文件。文件内容直接用自然语言编写，并通过 $ARGUMENTS 字符串把参数插入提示词。

例如，如果我想创建一个用于生成测试的命令，可以新建 .claude/commands/test.md：

# .claude/hooks/test.md
请为以下对象创建完整的测试：$ARGUMENTS

测试要求：
- 使用 Jest 和 React Testing Library
- 把测试放在 __tests__ 目录中
- 模拟 Firebase/Firestore 依赖
- 测试所有主要功能
- 包含边界情况和错误场景
- 测试 MobX 可观察状态的变化
- 验证计算值能够正确更新
- 测试用户交互
- 确保在 afterEach 中正确清理
- 尽可能提高代码覆盖率

之后，执行 /test MyButton 就会得到预期结果。甚至还可以使用子文件夹：例如 /builder/plugin 会匹配 builder 文件夹中的 plugin.md。我们就是这样非常轻松地创建新的 Builder 插件。

记忆系统

还有一项很实用的功能：通过 # 符号快速添加记忆。例如输入“以后新功能一律使用 MUI 组件”，Claude 会自动把它保存到最合适的文件中。

CLAUDE.md 可以按层级组织：既可以在项目根目录放一份，也可以在嵌套目录中继续放置。Claude 会读取所有相关文件，并在需要时优先采用位置最具体、目录层级最深的规则。

你还可以把偏好保存到全局用户记忆，让它适用于所有项目；或者保存到只与你有关、会被 Git 忽略的本地项目记忆。把信息添加到其中任何一类文件，Claude 都会替你写入。

它与 Codex 相比如何

Claude Code 的功能确实比 OpenAI Codex 更多，不过两者的智能体能力相当接近。Codex 有一项明显优势，让它也成了我的日常工具。想深入了解，可以阅读我对 Claude Code 与 Codex 的完整比较。

当你需要普通图形界面时

终端界面并不适合所有场景。有时候，你只是想像普通人一样点击并选中文字。

这正是我们的 Builder.io 扩展派上用场的地方。你可以从 IDE 中启动一个可视化界面，底层工作方式与 Claude Code 完全相同。我们尽可能精确地对它进行了逆向实现。你会得到普通的聊天界面和实时预览，甚至可以切换到类似 Figma 的设计模式，直接进行可视化编辑。

整个团队都可以使用它——设计师、产品经理或其他任何人。他们无需理解终端界面，就能创建原型、整理 UI 并提交 PR。

Builder 内部已经采用这种方式，让工程师专注于高难度的工程工作，其他团队则负责 UI 细节和像素级实现。

之后，工程团队需要继续修改 PR 时，只要提及 @builderio-bot，Claude 就会自动处理反馈，并推送相应的修改提交。