Claude Code 实战：八条心得经验

NikoAI编程
0 阅读9分钟

用Claude Code 写代码这段时间，从一开始的新鲜感到现在变成日常开发标配，中间踩了不少坑，也摸索出一些用法。这篇文章把这段时间积累的经验做一个整理，内容偏实操，适合已经在用或者准备用 Claude Code 的开发者。

一、一些额外设置

Claude Code 默认的输入体验有个小问题：在终端里输入多行内容时，直接按回车就会发送消息。如果你的 prompt 比较长，需要分段组织，可以用反斜杠 \ 加回车来换行：

这是第一行 \
这是第二行 \
这是第三行

不过每次都要打 \ 还是有些麻烦。Claude Code 支持切换输入模式，通过 /config 选择 editingMode 设置为vim：适合习惯 Vim 键位的用户，支持 Vim 的模式切换和编辑操作

也可以直接修改配置文件 ~/.claude/settings.json：

{
  "preferences": {
    "editingMode": "vim"
  }
}

选哪个看个人习惯，设置好之后多行输入会顺畅很多。更多可以参考前面的博文：Claude Code 上手指南：从 CLI 操作到个性化配置，一文搞定

二、不要担心 YOLO 模式

YOLO 模式的正式名称是 bypassPermissions，通过启动参数进入：

claude --dangerously-skip-permissions

看到 dangerously 这个词容易让人紧张，但实际使用下来，它没有想象中那么危险。这个模式做的事情是跳过执行过程中的权限确认弹窗，让 Claude Code 可以不间断地完成任务，不会每执行一步就停下来等你点确认。

几个事实可以缓解顾虑：

  • 即使在 YOLO 模式下，对 .git、.claude、.vscode 等目录的写入仍然会弹出确认提示，不会被跳过
  • 只要你的项目在 Git 管理下，随时可以用 git diff 检查改动，用 git checkout . 或 git reset --hard 回退
  • 执行过程中按 ESC 随时可以打断

建议设一个命令别名，省得每次打那么长的参数：

alias cc='claude --dangerously-skip-permissions'

以后在终端里直接输入 cc 就能进入 YOLO 模式。如果你用 Git 管理项目（应该是的），YOLO 模式的风险是可控的。

三、不着急写代码，先检查实现方案

用 AI 编程，最耗时间的环节往往不是写代码本身，而是实现方向跑偏之后的反复调整。Claude 有时会理解偏你的意图，直接开始改代码，改完发现不对再回退，几轮下来消耗的上下文和时间都很可观。

更稳妥的做法是在实际修改代码前，先通过 Plan 模式完成需求沟通和方案确认。Plan 模式在某些场景下会自动触发，但你也可以手动切换。两种方式：

  1. 按 Shift+Tab 切换到 Plan 模式（再按一次切回 Act 模式）
  2. 在 prompt 中直接说明意图，比如"先分析一下实现方案，不要修改代码"

Plan 模式下 Claude 会阅读相关代码、分析可行方案，但不会执行任何文件修改。你可以在这个阶段补充约束条件、调整方向，确认后再让它动手。

这个习惯能省掉大量"改了又撤"的成本。

四、AI 看不到的相当于不存在

这一点在实际项目中特别容易踩坑。Claude Code 的工作方式是基于它能读到的文件来理解项目，如果某些设计和约定没有体现在它能触及的代码里，那对它来说就不存在。

举个实际遇到的例子：项目里前后端接口参数统一使用下划线命名风格（user_name 而不是 userName），这个转换通过 Spring 的参数序列化配置实现。Claude Code 在初始化时如果没有扫到这段配置，定义新接口时就会按照默认的驼峰风格来写，导致参数不一致。

类似的情况还有：自定义的切面处理（AOP）、公共基类中的通用逻辑、Maven/Gradle 引入的公共依赖包里的工具类。这些东西 Claude 不会主动去翻 jar 包来了解。

解决办法是把这些隐性约定写到 Rules 里。在项目根目录下的 .claude/ 目录中创建规则文件：

.claude/
  rules/
    api-convention.md
    common-utils.md

比如 api-convention.md 的内容可以是：

## 接口参数命名

所有 REST API 的请求和响应参数使用 snake_case 风格。
项目已通过 Spring ObjectMapper 配置了自动转换，
Java 代码中字段使用 camelCase，JSON 序列化时自动转为 snake_case。
定义新接口时不需要手动处理转换。

对于公共依赖包中的工具类，也在 Rules 里说明用法和引用方式。这些规则会在 Claude Code 初始化时自动加载，相当于给它补上了"看不到的知识"。

五、关注上下文

上下文窗口是 Claude Code 的稀缺资源。窗口用满之后，Claude 的推理和代码质量都会下降。

一个简单的检查方法：在你的项目目录下启动 Claude Code，输入一句 hi，看看初始状态下上下文占了多少。如果一启动就占了很大比例，说明有不必要的内容被自动加载了。

检查初始化加载内容的方法：

  1. 查看 CLAUDE.md 文件的长度，内容是否过多。官方建议控制在 150 条指令以内
  2. 检查 .claude/rules/ 目录下的规则文件，是否有大段不必要的内容
  3. 对于大文件或者不常用的参考资料，不要放在初始化加载的文件里，改为在 CLAUDE.md 中注明文件路径，让 Claude 需要时再动态读取

另外，设置状态栏可以实时看到上下文占用情况。可以参考前面的博文：Claude Code 上手指南：从 CLI 操作到个性化配置，一文搞定 进行配置，这样终端底部会一直显示当前的上下文使用百分比。

上下文管理的策略：0-50% 正常工作；50-70% 开始留意，考虑清理冗余对话；70-90% 执行 /compact 压缩上下文；超过 90% 必须 /clear 重置，否则输出质量会明显下降。

一个有用的习惯是：不要让一个长会话成为你工作进度的唯一记录。频繁提交代码，把阶段性成果写到文件里，把每个会话当作随时可以丢弃的。

六、善用打断

Claude Code 执行过程中，如果你发现方向不对或者有需要补充的信息，按 ESC 可以立即打断当前操作。

打断之后 Claude 会停在当前位置，你可以补充说明或者调整指令，它会基于你的新输入继续工作。

连按两次 ESC 会回退到上一轮对话状态，相当于撤销了上一次交互。这在 Claude 理解错误的时候特别有用，不用手动去清理它已经做的改动。

什么时候该打断？Claude 开始修改你没提到的文件，或者生成的代码方向和预期不一致，又或者你想起有个前置条件忘了说。这些情况都应该立刻 ESC，不要等它跑完再纠正，越早打断浪费的上下文越少。

七、通过 Hooks 强制执行或者阻止

前面提到可以在 CLAUDE.md 和 Rules 里写规则，但这些规则是"建议性"的。Claude 大多数时候会遵守，但不保证每次都执行，特别是上下文比较拥挤的时候。

Hooks 不同，它是 Claude Code 处理流程中的强制扩展点，在特定事件触发时执行你定义的脚本，结果直接影响 Claude 的行为。

几个典型用途：

每次 Claude 修改文件后自动运行格式化工具，也可以用来阻止 Claude 修改某些文件。比如不允许修改数据库迁移文件：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "echo \"$CLAUDE_FILE_PATH\" | grep -q 'db/migrations' && echo 'BLOCK: 不允许修改已有的数据库迁移文件' && exit 1 || exit 0"
      }
    ]
  }
}

PreToolUse 在 Claude 执行操作前触发，脚本返回非 0 状态码时操作会被阻止。PostToolUse 在操作完成后触发，适合做格式化、检查等后处理。

Hooks 和 Rules 的区别可以这样理解：Rules 是告诉 Claude "你应该怎么做"，Hooks 是"不管你怎么想，这一步必须这样"。

八、善于总结

这是我认为最有价值的一条经验。

总结有两层含义。第一层是开发者自己总结使用中的经验教训，调整和 Claude 的协作方式。第二层更重要：让 Claude Code 自己积累经验，不要重复犯同样的错误。

具体做法：

积累到 CLAUDE.md。 项目根目录的 CLAUDE.md 是 Claude Code 每次启动都会读取的文件。把项目中反复出现的约定、踩过的坑、明确的技术选型写进去。比如：

## 数据库

- ORM 使用 MyBatis-Plus，不要使用原生 MyBatis XML
- 分页查询统一使用 PageHelper
- 表名前缀 t_，不要在实体类的 @TableName 中遗漏

## 已知问题

- Redis 序列化使用 Jackson，存取对象时注意类型信息保留

积累成自定义命令。 如果某类操作你经常让 Claude 做，而且步骤比较固定，可以写成自定义斜杠命令。放在 .claude/commands/ 目录下，以 .md 文件的形式定义。比如创建 .claude/commands/new-api.md：

创建一个新的 REST API 接口，包含以下步骤：
1. 在 controller 层创建接口方法
2. 在 service 层创建对应方法
3. 创建必要的 DTO 类
4. 遵循项目已有的命名和分层规范

以后输入 /new-api 就能触发这套流程。自定义命令和 Skill 不同，Skill 是 Claude Code 内置的能力扩展机制，而自定义命令是你自己定义的 prompt 模板，更灵活也更贴合项目需要。

积累成 Rule。 把具体领域的规范写到 .claude/rules/ 下的独立文件里，保持 CLAUDE.md 精简，同时让 Claude 在需要时能读到详细规则。

这个过程是一个持续改进的循环：使用中发现问题 -> 总结成规则或命令 -> Claude 在后续工作中表现更好 -> 继续发现和总结。随着经验的积累，Claude Code 会越来越了解你的项目和你的习惯，从一个"什么都要教"的新手变成懂你心的开发搭档。

这次就到这里。Claude Code 在快速迭代中不断进化，半年前的用法放到今天可能已经有更好的方案。保持尝试，保持总结，工具会越用越顺手。

扫码_搜索联合传播样式-白色版.png

avatar
文章
阅读
粉丝