Claude Code CLI 高效使用：7个技巧与自动化实战

引言

凌晨三点，终端窗口的光刺得眼睛发酸。我盯着屏幕上第18次失败的测试跑过，脑子里只有一个念头：如果早点知道 /clear 这个命令，今晚就不用熬到这时候了。

说实话，这事儿让我挺懊恼的。

官方数据显示，Claude Code 在 SWE-bench 测试里能自主搞定 80.9% 的代码问题。挺厉害的数字，但问题是——你真的在用它最核心的能力吗？我观察了一圈身边的朋友，发现一个有意思的现象：大多数人启动了 Claude Code，然后就用 claude 这个命令，聊几句，改改代码，就完事了。

50多个命令里，只用了3到5个。浪费了90%的效率潜力。

这篇文章分享7个我亲测有效的CLI技巧，外加3个自动化实战案例。不是那种看完就忘的技巧列表，而是按场景分类的系统性方法——从基础命令到上下文管理，再到Hooks配置、CI/CD集成。看完之后，你大概能从”会用”升级到”真的高效用”。

---

第一章：CLI基础三剑客 — 启动、模式、命令

先把基础打牢，后面高级技巧才有意义。

1.1 三种启动方式，各有用途

claude              # 当前目录启动交互界面
claude -c           # 继续最近一次会话
claude --print "检查这个函数的类型定义"  # 单次查询后退出

很多人只知道第一种。其实第二种 -c 特别实用——当你刚关掉一个会话，发现还有个问题没解决，直接 claude -c 就能接上刚才的上下文，不用从头解释项目背景。

第三种 --print 我用来做快速查询。比如想确认一个类型定义对不对，一个命令搞定，不用进入完整交互模式。省时间。

1.2 三种工作模式，按场景切换

这个是官方文档里的核心概念，阿里云那篇深度文章也专门讲过：

模式	安全性	适用场景
Default（默认）	高	探索新项目、不确定的操作
Auto-Accept	中	熟悉的代码库、批量修改
Plan	最高	分析问题、制定方案

Default模式下，每次修改文件、执行命令都要手动确认。麻烦，但安全。适合你在陌生项目里摸底的时候。

Auto-Accept模式——文件修改自动执行，shell命令还是需要确认。当你在自己的项目里做批量重构，这个模式能让Claude一口气改完，你最后统一检查就行。效率翻倍。

Plan模式我喜欢用来分析复杂问题。让Claude先读完整个项目，然后输出一个详细的执行计划。这时候不做任何修改，只是规划。看完计划觉得靠谱，再切换到Auto-Accept模式执行。

1.3 三条斜杠命令，必须记住

官方50多个命令，大多数人只用了不到10%。这三条我用得最多：

/init     # 扫描项目生成CLAUDE.md配置文件
/clear    # 清空会话历史
/compact  # 压缩上下文节省token

/init 第一次在新项目里启动时用。Claude会扫描整个代码库，生成一个配置文件，告诉它项目的结构、依赖、约定。后面所有操作都会参考这个配置。

/clear 我后面会专门讲——这是我发现的最大效率提升点。

/compact 当上下文堆了太多对话历史时用。Claude会保留关键信息，把冗余的删掉，节省token消耗。适合你在同一个会话里做了很多轮修改的情况。

---

第二章：上下文管理艺术 — 清空、压缩、并行

这部分是 Builder.io 那篇实战文章给我的启发——他们说 /clear 是”最大的生产力提升点”。我试了一周，发现确实如此。

2.1 /clear 的正确用法

什么时候清空会话？

任务切换时。

比如你刚在修一个bug，和Claude聊了二十轮，把问题定位到了。这时候老板突然让你去处理另一个紧急issue。很多人的做法是：继续在同一个会话里切换话题。

错了。

这时候应该先 /clear，把刚才的对话历史全部清掉。为什么？因为那些历史对话在占用token，而且和新的任务完全无关。Claude会被旧上下文”污染”，新问题的理解质量下降。

我的习惯：从一个任务切换到另一个，先 /clear，然后简单说明新任务背景。效果比直接在老会话里继续聊好太多。

2.2 /compact 何时用

当你在同一个任务里做了很多轮修改——改了十几个文件，聊了三十多条消息——这时候上下文已经很长了。

/compact 会压缩这些历史，保留关键信息（修改过的文件、关键的决策），删掉冗余对话。

什么时候触发？我给自己定了个粗略的规则：对话超过30条就 compact 一次。不用太精确，大概感觉”有点长了”就压一下。

2.3 并行会话策略

这个技巧来自 Claude 官方的 Help Center：同时运行 3-5 个会话，每个在不同的 git worktree 里处理代码库的不同部分。

什么是 git worktree？简单说，就是同一个仓库创建多个工作目录，每个目录可以切换不同的分支。

# 创建worktree
git worktree add ../feature-A feature-branch-A
git worktree add ../feature-B feature-branch-B

# 在不同worktree里启动Claude
cd ../feature-A && claude
cd ../feature-B && claude

这样你可以在两个终端窗口里同时干活：一个让Claude写feature-A的代码，另一个让它处理feature-B。两个会话互不干扰，上下文各自独立。

还有一个实用的终端技巧：按 Ctrl+B 可以把长时间运行的bash命令移到后台。适合Claude在执行一些耗时操作（比如npm install、测试跑半天）的时候，你的会话界面不会被阻塞。

---

第三章：自动化三大件 — Hooks、Routines、CI/CD

前面讲的技巧，都是手动的。这部分开始上自动化——让Claude在你干活的时候，顺便帮你把重复劳动做了。

3.1 Hooks机制：任务触发器

Hooks是Claude Code的自动化核心。有三种主要类型：

Hook类型	触发时机	典型用途
PreToolUse	执行工具前	权限检查、参数预处理
PostToolUse	执行工具后	自动运行测试、格式化代码
Notification	通知事件	发送Slack消息、记录日志

最实用的是 PostToolUse。配置一个hook，每次Claude修改完代码，自动跑一遍测试。

// settings.json 里的配置示例
{
  "hooks": {
    "PostToolUse": [{
      "command": "npm test",
      "timeout": 60000
    }]
  }
}

这个配置的效果：每次Claude用Write工具修改文件后，自动执行 npm test。如果测试失败，Claude会看到输出，然后自己修复问题。

3.2 Routines：定义重复流程

Routines适合定义那些重复出现的任务流程。

官方文档给的例子：当Claude检测到某个条件（比如某个文件存在），就自动执行一系列预设的命令。

具体配置有点复杂，我暂时还没在生产环境大规模用。但这个方向很值得探索——把”每次都要做的检查”固化下来，不用每次手动提醒Claude。

3.3 CI/CD集成：GitHub Actions实战

这个是官方提供的headless模式：claude -p。

在GitHub Actions里用，可以让Claude自动处理PR review、issue实现、安全审计。

# .github/workflows/claude-review.yml
name: Claude Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Review
        run: claude -p "Review this PR and suggest improvements"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

GitLab那篇官方博客讲了三个工作流：

1. 从issue创建MR
2. 分析性能回归
3. 直接实现功能并让CI验证

这个方向我还在研究，但已经能看到潜力——把Claude Code嵌入到整个开发流程里，让它成为你CI/CD管道的一部分。

---

第四章：实战案例 — 从配置到自动化

讲了原理，现在看实际怎么用。

案例1：一句话搞定git commit

这个是我最常用的场景。

传统做法：git add、git status、写commit message、git commit。一套下来，几分钟。

用Claude Code：

claude
> commit these changes

一句话。Claude会自动读取你当前的修改，生成一个合适的commit message，然后提交。它会分析修改内容，理解这次改动的核心意图，写出一个有意义的message。

我实测下来，生成的message质量比我自己写的还好——因为它真的读了diff内容，而不是随便写。

案例2：PostToolUse Hook自动跑测试

回到刚才那个hook配置。我把完整版本写出来：

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "npm run test:related",
        "timeout": 30000
      }
    ]
  }
}

matcher: "Write" 表示只监控Write工具（修改文件）。npm run test:related 是我自己定义的命令，只跑和修改文件相关的测试——不是全量测试，速度快很多。

效果：每次Claude改完代码，30秒内就能看到测试结果。如果失败，Claude会收到输出，然后自动修复。

我踩过一个坑：一开始配的全量测试 npm test，跑太慢了，经常超时。改成只测相关文件，问题解决。

案例3：GitHub Actions自动PR Review

这个配置来自官方文档：

# .github/workflows/claude-pr-review.yml
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Claude Review
        uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review this PR for:
            - Code quality issues
            - Potential bugs
            - Security vulnerabilities
            - Performance concerns
          api_key: ${{ secrets.ANTHROPIC_API_KEY }}

这个workflow会在PR创建或更新时触发，让Claude自动review代码，然后在PR下面评论。它能检查代码质量、潜在bug、安全漏洞、性能问题。

我用了一个月，发现它抓到的bug比我手动review还多——因为它不会偷懒，每个文件都认真看。

---

第五章：生产力倍增技巧 — 配置简化与工具链集成

最后几个技巧，是我在 Marmelab 和 Builder.io 的文章里学到的——关于如何让整个工作流更顺畅。

5.1 CLAUDE.md 简短哲学

很多人写CLAUDE.md配置文件，写得特别详细——项目背景、技术栈约定、代码风格、禁止事项……洋洋洒洒几千字。

Marmelab的建议反过来了：保持CLAUDE.md尽可能短。

为什么？因为配置越长，Claude越容易”过度遵循”——每次操作都去翻配置，反而限制了灵活性。而且长配置本身也消耗token。

他们推荐的写法：只写最核心的3-5条约定，把配置当成一个”简化代码库的强制函数”。比如：

# CLAUDE.md
- TypeScript严格模式，所有变量都要有类型
- 组件文件放在 src/components/
- 测试文件和源文件放在同一目录
- 不要用var，只用const和let

就这么几句。够了。

5.2 Bash Wrapper策略

Builder.io 那篇文章有个观点让我印象深刻：不要写长文档说明，写bash wrapper脚本。

比如你想让团队成员快速启动项目，与其写一个复杂的README告诉他们”先npm install、再配置环境变量、再启动dev server”，不如直接写一个脚本：

#!/bin/bash
# dev.sh - 快速启动开发环境

npm install
source .env.local
npm run dev

然后Claude Code里只需要说”run dev.sh”。简单，不费脑子。

这个思路也可以用在Claude本身：把常用的命令组合封装成alias或script。省得每次都要打一长串。

5.3 MCP Server集成：安全检查和输出过滤

最后是 MCP（Model Context Protocol）相关的工具集成。

两个实用的例子：

Snyk MCP Server：让Claude在写代码的时候自动检查安全漏洞和依赖问题。不用你手动提醒，它会在每次引入新依赖时自己跑一遍安全扫描。

rtk工具：过滤和压缩命令输出。GitHub上有专门的技巧提到这个——很多CLI命令的输出特别长（比如npm install的日志），会占用大量token。rtk可以把这些输出压缩，只保留关键信息。

这两个工具我还没完全集成好，但方向很清晰：让Claude Code不只是写代码，而是接入整个安全检查、依赖管理的工具链。

---

总结

说了这么多，核心就几件事：

基础命令要扎实——三种启动方式、三种工作模式，按场景切换。不要只用最简单的那一种。

上下文管理别偷懒——任务切换时 /clear，对话太长时 /compact。这两个习惯能帮你省掉大量token浪费。

自动化值得投入——Hooks配置、GitHub Actions集成，前期花点时间学习，后面省下的时间会成倍回报。

配置保持简洁——CLAUDE.md写短点，复杂流程用脚本封装。不是文档越长越好。

我的建议：

1. 今天立刻试试：在当前会话里输入 /clear，感受一下清空后的清爽感
2. 本周任务：配置一个 PostToolUse hook，让Claude每次改完代码自动跑测试
3. 长期目标：把Claude Code嵌入你的CI/CD流程，让它成为团队的标准工具

如果你想深入了解Claude Code的配置优化，可以看我们系列的第一篇《别再让Claude乱写代码了！一个配置文件让AI准确率提升10%》（讲CLAUDE.md怎么写）。想了解Subagent机制，看第二篇《Claude回复太啰嗦？用Subagent打造你的专属AI团队》。本文是系列第七篇，专注CLI命令行的技巧。

这些技巧我都是踩坑之后才学会的。希望你看完能少踩几个坑，早点把效率拉起来。