Claude Code 使用技巧：从入门到高效

Claude Code 是 Anthropic 官方的命令行 AI 编程助手。和 Cursor、Cline 等 IDE 集成式工具不同，它更像一个”长在终端里的资深结对程序员”——你打开一个项目目录，它就能读代码、跑命令、改文件、提 PR。本文整理我在日常使用中沉淀下来的一些实用技巧，覆盖 Plan 模式、Skills、Subagents、Hooks、MCP、Memory、状态栏、Workflow 等高阶能力。

目录

• 目录
• 整体能力地图
• 一、上手就该养成的 5 个习惯
• 二、Plan 模式：让 AI 先想清楚再动手
• 三、Skills：把重复套路封装成”一句话指令”
• 四、Subagents：让多个 Claude 并行干活
• 五、Hooks：在工具调用前后插入自动化
• 六、MCP：把外部世界接进来
• 七、Memory：跨会话记住你和项目
• 八、状态栏与权限：少打断你的小细节
• 九、Workflow 编排：当任务超过单个上下文
• 十、调试与排错
• 总结

整体能力地图

先用一张图把 Claude Code 的核心组件和它们的协作关系串起来：

记住一个原则：主循环只做一件事——决定下一步调用什么工具。所有”玩花样”的能力，本质都是给主循环增加可调用的工具或注入更好的上下文。

一、上手就该养成的 5 个习惯

1. 用 ! 前缀直接发命令 在输入框里以 ! 开头，会把命令交给 shell 执行并把结果直接进上下文。比如：

!git log --oneline -20

比让 Claude 自己 git log 再读再总结快得多，特别是查状态、看日志、试试某条命令是否生效这种场景。

2. 让它先 /init 摸清项目 新仓库第一次进入时跑 /init，Claude 会扫描代码生成 CLAUDE.md——这是它和你之间关于”这个项目长什么样”的契约。后续会话每次启动都会读这个文件，省去你反复解释架构。

3. 把”具体目标 + 限制条件”一次写清 不要 “帮我优化代码”。要 “把 _javascript/utils/ 下的 IIFE 改成 ES module 写法，不要动 rollup 配置，保持现有公开 API 不变“。 约束越具体，跑偏的可能越小，也越容易在事后用 git diff 验收。

4. 大改之前要 EnterPlanMode 后面会专门讲。一句话：让它先写计划再写代码，能省掉 70% 的返工。

5. 用 /clear 而不是新开会话 当上下文塞满了你不再需要的内容（比如刚解决完一个 bug，要切到另一个任务），用 /clear 清掉历史但保留 CLAUDE.md 和 Memory，比关掉重开成本低得多。

二、Plan 模式：让 AI 先想清楚再动手

Plan 模式是 Claude Code 区别于其它 CLI 助手最有价值的一项设计。

触发方式：

> 给这个 chirpy 主题加一个"阅读时长"功能
> /plan

或者在它准备动手前直接说 “进入 plan 模式”。进入后它只读不写，只能编辑那一份 plan.md，并按四步走：

怎么用得好：

• 写需求时点名”先 Plan 再做”：复杂改动养成习惯。
• 让它分析多个方案：Plan 模式下你可以让它列 2-3 种方案对比，再选一种。
• 拒绝不合意的计划：直接评论”重写第 3 步，理由是 ……”，它会改。绝对不要让一个你心里都不踏实的计划进入实现阶段——后面修代码比改计划贵 10 倍。

三、Skills：把重复套路封装成”一句话指令”

Skills 是带说明书的可执行指令，用斜杠触发。系统自带几个常用的：

Skill	用途
/init	首次扫描项目生成 CLAUDE.md
/review	审 PR
/code-review	审当前 diff，可加 --fix 自动改
/security-review	安全审计
/simplify	让代码更简洁
/loop 5m /xxx	每 5 分钟跑一次某个命令（监 CI、轮询状态）
/verify	跑代码并观察行为，验证改动是否真的工作
/run	启动项目跑起来看效果

自定义 Skill 的能力极强。在 ~/.claude/skills/ 下建个目录，写个 SKILL.md，描述触发场景和做法即可。比如我自己写了一个 /post：

---
name: post
description: 在当前 jekyll 项目下创建一篇技术博客文章
---

接收主题后：
1. 在 `_posts/technology/` 下创建文件，命名格式 `YYYY-MM-DD-<slug>.md`
2. 顶部写 front matter（layout/post, date, categories）
3. 至少包含：目录、整体架构图（plantuml）、分点详述、总结
4. 引用同目录下的同类文章，确保风格一致

之后 /post claude code 使用技巧 直接出稿。重复 3 次以上的提示词，就该考虑封成 Skill。

四、Subagents：让多个 Claude 并行干活

主代理一个上下文有限（约 200K token），但你可以通过 Agent 工具派子代理——它们有独立上下文，做完只把结论返回给主代理。

三个最常用的内置子代理类型：

• Explore：只读搜索 agent，扫一大批文件后返回结论。读源码、找接口、定位 bug 时首选——它会读片段而不是整文件，不撑爆上下文。
• Plan：架构师 agent，专门设计实现方案。Plan 模式 Phase 2 默认调用它。
• general-purpose：复杂任务通用兜底。

并行用法：把没有依赖的子任务放在同一条消息的多个 tool 调用里发出去，会真正并发执行。比如：

启动 3 个 Explore：
- agent A：找出所有 plantuml 配置相关代码
- agent B：找 _config.yml 中所有插件的引用
- agent C：调研 _data/locales 的本地化机制

隔离 worktree：当多个子代理需要并行修改文件时，给每个 agent 加 isolation: "worktree"，会自动各自起一个 git worktree，互不打架，结束后能合并。

五、Hooks：在工具调用前后插入自动化

Hooks 是 ~/.claude/settings.json 里挂钩工具调用生命周期的钩子。最常见的几个用法：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "echo \"$CLAUDE_TOOL_INPUT\" >> ~/.claude/bash-audit.log"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "cd \"$CLAUDE_PROJECT_DIR\" && npx prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null"
        }]
      }
    ]
  }
}

典型用途：

• 审计：把每次 Bash 调用记日志；
• 格式化：每次保存自动跑 prettier / eslint –fix；
• 拦截：返回 exit code 2 拒绝某些命令（比如禁止 rm -rf）；
• 通知：跑完 PR 时自动发个钉钉机器人。

注意 hook 是 harness 在 Claude 之外执行的——它的输出会作为”用户反馈”回传给 Claude，所以是真正可强制的约束，比写在 prompt 里有效得多。

六、MCP：把外部世界接进来

MCP（Model Context Protocol）已在另一篇文章《MCP 完整开发指南》里详述过。这里只讲 Claude Code 里使用它的核心心法：

别一次接 50 个 MCP。Claude 启动时要把所有 MCP 工具的 schema 拉进上下文，接得太多会炸。建议：

• 常用的留全局：GitHub、文件系统、数据库；
• 项目相关的放项目级 .mcp.json：只在该仓库会话里激活；
• Workflow 内才用的：用 ToolSearch 模式按需加载。

/mcp 命令可以看当前激活的 server 和它们暴露的工具数量。

七、Memory：跨会话记住你和项目

Memory 解决一个真实痛点：每次会话都从零开始，重复解释相同的事情。

它是怎么工作的：

• 文件路径：<project>/.claude/projects/<encoded-path>/memory/*.md
• 每条记忆是一个独立 md 文件 + 顶部 front matter（type: user / feedback / project / reference）
• MEMORY.md 是索引，每行一条指向具体记忆文件
• 每次会话启动自动注入 MEMORY.md 索引；命中关键字时按需读对应记忆

什么该写进去：

• ✅ 用户偏好（”我喜欢中文回复”、”代码风格用 4 空格”）
• ✅ 反馈与教训（”上次用 sudo 在 Netlify 失败了，要用 root 用户”）
• ✅ 项目特殊约束（”这个项目部署到 GitHub Pages，不能用未发布的 plugin”）
• ❌ 代码本身的事实（git history 已经记录了）
• ❌ 一次性的对话内容

怎么写进去：直接说 “记住一下：……”，Claude 会按规范写入对应文件并更新 MEMORY.md。

八、状态栏与权限：少打断你的小细节

自定义状态栏 —— ~/.claude/settings.json：

{
  "statusLine": {
    "type": "command",
    "command": "bash ~/.claude/statusline.sh"
  }
}

statusline.sh 会从 stdin 读到一段 JSON（包含 model、cwd、上下文使用率等），输出一行字符串显示在底部。常见展示：模型 ｜ git 分支 ｜ 路径 ｜ 上下文占比。

⚠️ 注意：Windows Git Bash 默认不带 jq，统计字段建议用纯 bash + grep/sed 解析，避免 statusline 直接 exit 1 导致整行不显示。

权限白名单 —— 反复被问”是否允许执行 npm install”很烦：

{
  "permissions": {
    "allow": [
      "Bash(npm install:*)",
      "Bash(npm run *)",
      "Bash(git status:*)",
      "Bash(git diff:*)"
    ]
  }
}

或者直接跑 /fewer-permission-prompts，它会扫描你最近的会话，自动建议加哪些到白名单。

九、Workflow 编排：当任务超过单个上下文

当任务规模大到一个 agent 装不下（审 200 个文件、跨 10 个目录迁移、生成多视角报告），用 Workflow 工具——它是用 JavaScript 写的编排脚本，可以：

• fan-out：parallel(items.map(...)) 一次起一堆 agent
• pipeline：每个 item 经过 stage1 → stage2 → stage3，stage 之间不阻塞，最快的项可以已经在 stage3 时最慢的还在 stage1
• 结构化输出：给 agent 加 schema，强制它返回 JSON 而不是自然语言
• token 预算：用户说 “+500k tokens” 时，脚本可以读 budget.remaining() 决定循环多少轮

例子（伪代码）——对当前 diff 做多维度审查 + 对抗验证：

const dimensions = ['正确性', '性能', '安全', '可读性'];
const results = await pipeline(
  dimensions,
  // stage 1: 每个维度独立审一遍
  d => agent(`从 ${d} 维度审查当前 diff`, { schema: FINDINGS }),
  // stage 2: 每个发现都派 3 个独立 agent 反驳
  review => parallel(review.findings.map(f => () =>
    agent(`尝试反驳：${f.title}`, { schema: VERDICT })
  ))
);

关键节制：Workflow 一次能起几十个 agent，token 消耗指数增长。只在用户明确说”用 workflow / 并行”时才用，平时单 agent 就够。

十、调试与排错

Claude 给的代码不对怎么办？

1. 不要直接说”错了” ——告诉它怎么错的：报错信息、复现步骤、期望结果。这是它最常缺的输入。
2. 让它先复现：/run 或 /verify 让它真的跑一下，看它是不是真的能在你的环境里复现。
3. 看 plan 历史：如果是个走过 plan 模式的任务，回去看那份 plan，往往是当时计划就不对。

长会话变迟钝？ 看状态栏的”context % used”，超过 70% 时考虑：

• /clear 清空但保留记忆；
• 把当前进展写进 CLAUDE.md 或 memory，再开新会话续；
• 把没做完的拆成 Tasks（TaskCreate），新会话直接 TaskList 接着干。

Hooks 不生效？ 检查三个地方：① settings.json JSON 是否合法；② matcher 是否覆盖到目标工具名；③ hook 命令本身在你 shell 里能跑通（Windows 上注意路径分隔符）。

总结

Claude Code 真正强的不是它能写多牛的代码，而是整个 harness 给你提供的可组合能力：

• Plan 模式让它先想再做；
• Skills 把重复指令固化；
• Subagents 拓展上下文边界；
• Hooks 在外部强制规则；
• MCP 接通外部世界；
• Memory 把会话经验沉淀；
• Workflow 把工作流自动化。

把这些看作”积木”，根据任务复杂度搭不同的塔——简单的 commit 信息让它直接写就行；改一个跨模块的功能就该走 Plan；做一次大型代码审查就该上 Workflow。工具之上是判断力——而判断力，正是这套工具想为你节省下来的东西。