Claude Code高效使用的30个设置与工作流

0xwhrrari 发布于 2026-06-28 阅读 23

本文详细介绍了高效使用Claude Code的30个技巧,强调将其从“自动补全”升级为“编程系统”。

图像

大多数人使用 Claude Code 就像使用一个花哨的自动补全工具。

他们要求写代码。
他们等待。
他们接受第一个输出。

然后他们手动修复所有问题。

这是错误的使用方式。

当你不再把它当作一个提示框,而是开始把它当作一个编码系统时,Claude Code 才会变得强大。

区别并非一个神奇的提示词。
区别在于 设置

上下文。
记忆。
权限。
Hook。
子代理。
快捷键。
可复用的工作流。

大多数用户从未触及这些。

这就是为什么他们从一个本可以做更多事的工具那里得到的只是平庸的输出。

Claude Code 不仅仅是“终端里的 ChatGPT”。

它可以读取你的仓库,记住项目规则,运行命令,使用工具,创建可复用工作流,并且检查自己的工作成果。

但前提是你正确设置了它。

多数用户跳过的基石

1. CLAUDE.md

这是我会在任何重要仓库中首先创建的文件。

Claude Code 会将其作为项目上下文读取。

用它来定义:

  • 技术栈
  • 命令
  • 架构
  • 代码风格
  • 测试规则
  • Claude 不应触碰的文件
  • 已做出的决策

示例:

## 项目规则

技术栈: Next.js, TypeScript, Postgres
测试: 运行 npm test 后再给出最终答案
风格: 生产代码中无 any,无 console.log
API 路由位于 src/api
未经请示绝不要编辑迁移文件

没有这个文件,每次会话都是冷启动。

有了它,Claude 启动时就已经加载了你的项目规则。

2. CLAUDE.md 导入

不要把所有的东西都放进一个巨大的记忆文件里。
使用导入。

示例:

@docs/architecture.md
@docs/testing.md
@docs/deployment.md
@docs/style-guide.md

这样你就可以按用途分割上下文。

一个文件用于架构。
一个文件用于测试。
一个文件用于部署。
一个文件用于风格规则。

更清晰的上下文意味着更好的输出。

3. /init 工作流

大多数人打开 Claude Code 后立即要求它开始构建。

顺序错了。

首先,初始化项目上下文。

使用 /init 让 Claude 检查仓库并创建一个初始记忆文件。

然后自己编辑那个文件。

不要盲目相信自动生成的上下文。

把它当作初稿。

工作流:

/init
↓
审查生成的 CLAUDE.md
↓
删除通用部分
↓
添加真实项目规则
↓
提交该文件

这使 Claude 从“猜测助手”变为“项目感知助手”。

4. 项目记忆

Claude Code 可以使用跨会话保留的记忆文件。

这一点很重要,因为大多数 bug 不是一次提示就能解决的。

使用记忆来存储:

  • 架构决策
  • 已知问题
  • 重复命令
  • 项目约定
  • 过去的调试经验
  • Claude 不应再次争论的事项

示例:

### 已知问题

Redis 有时在预发布环境会失败。
重启 worker 可以临时修复。
在未先检查 worker 日志前不要更改队列配置。

记忆可以避免你每天早晨都解释同样的事情。

5. settings.json

Claude Code 有设置。

大多数用户从未触碰过。

这是个错误。

你的设置定义了 Claude 在工具、权限、Hook 和项目规则方面的行为。

使用设置让 Claude 更安全、更可预测。

目标不是给它无限的自由。

目标是移除无聊的审批,同时将危险操作限制起来。

6. 权限规则

权限是你如何让 Claude 保持有用,同时又不让它破坏你的仓库。

良好的权限规则允许常规工作,阻止危险工作。

允许:

  • 读取文件
  • 运行测试
  • 运行 linter
  • 编辑安全项目文件

需要批准:

  • 删除文件
  • 更改环境文件
  • 编辑迁移文件
  • 推送到远程
  • 运行破坏性命令

当护栏清晰时,Claude Code 表现更好。

上下文控制

7. 文件引用

如果 Claude 能读取真实文件,就不要把随机代码粘贴到提示中。

直接指向文件。

示例:

读取 @src/api/auth.ts 并解释为什么登录失败。

这给 Claude 提供了真实的上下文,而不是部分片段。

部分片段产生部分答案。

8. 文件夹引用

对于更大的任务,指向一个文件夹。

示例:

检查 @src/components 并找出重复的 UI 模式。

这比问一个模糊的问题要好,比如:

“你能改进我的前端吗?”

具体的上下文产生具体的输出。

9. 编辑前先询问

Claude Code 不仅仅是用来写代码的。

它也擅长理解代码。

在进行大的更改之前,先问:

先读取相关文件。
解释这个功能目前是如何工作的。
然后提出一个计划。
暂时不要编辑任何内容。

这一个习惯可以防止许多糟糕的编辑。

先理解。
后编辑。

10. /compact

长会话会变得混乱。

上下文填满了。

旧细节变得不太有用。

模型开始携带太多噪音。

当会话有有用的进展但对话历史太多时,使用 /compact。

思路:

保留重要状态。
去除对话垃圾。
从更干净的上下文继续。

这是恢复长会话最简单的方法之一。

11. /clear

有时 compact 不够。

如果会话混乱了,重置它。

在以下情况使用 /clear:

  • Claude 卡住了
  • 任务改变了
  • 上下文被污染了
  • 你之前给出了错误指令
  • 对话不再有用

重新开始往往比拖着糟糕的上下文前进更快。

模式与快捷键

12. Shift + Tab

这个快捷键循环切换 Claude Code 的权限模式。

大多数人从未学习过它。

这是个问题,因为模式改变了会话的摩擦程度。

使用它可以在以下模式之间切换:

  • 默认模式
  • 接受编辑模式
  • 计划模式

具体可用的模式取决于你的设置,但思路很简单:

控制 Claude 在询问前能做多少事。

13. 计划模式

计划模式用于在构建之前思考。

在以下情况之前使用:

  • 重构
  • 架构变更
  • 数据库变更
  • 多文件编辑
  • 新功能

提示:

进入计划模式。
读取相关文件。
给我计划。
在我批准之前不要编辑任何内容。

这使 Claude 从一个随机代码生成器变为一个协作者。

14. 接受编辑模式

接受编辑模式对常规更改很有用。

用于:

  • 重命名变量
  • 更新文案
  • 格式化文件
  • 小重构
  • 添加显而易见的测试

不要用于有风险的工作。

关键在于有边界的速度。

15. Esc

Esc 中断 Claude 的响应。

在以下情况使用:

  • 它误解了任务
  • 它开始编辑错误的东西
  • 它正走向错误的方向
  • 你忘记添加上下文

及早停止比之后清理糟糕的工作更省时间。

16. Esc Esc

Esc Esc 是人们发现得太晚的一个功能。

它允许你将会话回退到更早的时间点。

当会话走向了糟糕的方向时使用。

示例:

Claude 制定了一个糟糕的计划。
你让它编辑了太多东西。
上下文变得混乱。
回退到错误之前。
从干净的点重新开始。

这比手动撤销所有操作要好得多。

17. Ctrl + R

Ctrl + R 搜索命令历史。

当你重复使用提示、shell 命令或工作流时很有用。

不必再次输入同样的内容,搜索即可。

小快捷键。
如果你经常在终端工作,能省很多时间。

18. ! Bash 模式

当你想要运行一个 shell 命令并将结果带入上下文时,使用 !

示例:

!npm test

现在 Claude 可以看到输出。

这就是以下两者的区别:

“我的测试失败了,现在怎么办?”

和:

“这是确切的测试失败信息,修复它。”

真实的输出胜过记忆中的描述。

可复用工作流

19. 自定义斜杠命令

如果你输入同一个提示超过两次,就把它变成一个命令。

自定义斜杠命令是可复用工作流。

例子:

  • /review-pr
  • /write-tests
  • /explain-module
  • /prepare-release
  • /debug-failing-test

一个好的斜杠命令包含:

  • 目标
  • 步骤
  • 输出格式
  • 质量标准
  • Claude 应避免什么

停止重复编写提示。
保存工作流。

20. Skills(技能)

Skills(技能)是可复用的能力。

当任务需要不止一个提示时使用它们。

好的技能包括:

  • 指令
  • 示例
  • 模板
  • 脚本
  • 参考文件

用于以下工作流:

  • 前端审查
  • API 文档
  • 测试生成
  • 发布说明
  • 安全审查
  • 设计系统清理

斜杠命令触发任务。
Skills 教会 Claude 如何完成一类工作。

21. 子代理(Subagents)

子代理(Subagents)是你如何阻止一个对话做所有事情的方法。

用于隔离的任务:

  • 研究
  • 代码审查
  • 测试编写
  • 安全检查
  • 文档编写
  • Bug 调查

示例工作流:

主 Claude 会话拥有目标
↓
研究子代理扫描仓库
↓
测试子代理编写测试
↓
审查者子代理检查有风险的变更
↓
主会话总结最终决定

子代理保持主要上下文更干净。

它们也让 Claude 感觉更像一个小团队而不是一个助手。

22. MCP 服务器

MCP 是 Claude Code 连接外部工具的方式。

没有 MCP,Claude 主要使用本地文件和命令。

有了 MCP,它可以连接到:

  • GitHub
  • Linear
  • Jira
  • 数据库
  • 文档
  • 浏览器工具
  • 内部 API
  • 搜索工具

这时 Claude 不再猜测,而是开始检查真实系统。

不要安装随机的 MCP 服务器。

安装与你的实际工作流匹配的 2-3 个。

23. Hooks(Hook)

Hooks(Hook)是在 Claude Code 生命周期的特定点自动运行的操作。

这是最被低估的功能之一。

用于:

  • 运行格式化工具
  • 运行测试
  • 阻止危险命令
  • 记录工具使用
  • 验证文件更改
  • 强制执行项目规则

Hooks 很有用,因为它们不依赖于 Claude 的记忆。

它们之所以运行,是因为系统规定它们运行。

安全与质量门控

24. 预工具Hook(Pre-Tool Hooks)

预工具Hook在 Claude 采取行动之抢跑。

用于阻止危险行为。

示例:

阻止 rm -rf
阻止编辑 .env
阻止直接推送到 main
阻止未经批准的迁移编辑
阻止触碰生产环境的命令

这就是你让 Claude 快速行动而不给它上膛武器的办法。

25. 后工具Hook(Post-Tool Hooks)

后工具Hook在 Claude 采取行动之后运行。

用于检查发生了什么变化。

示例:

编辑 TypeScript 文件后 → 运行类型检查
编辑前端文件后 → 运行 lint
编辑测试后 → 运行测试命令
编辑文档后 → 检查格式

这创建了一个反馈循环。

Claude 编辑。
Hook 检查。
Claude 看到结果。
工作质量提升。

26. 停止Hook(Stop Hooks)

停止Hook在 Claude 认为自己完成时运行。

这是你捕获敷衍结尾的地方。

使用停止Hook要求:

  • 测试通过
  • Lint 通过
  • 包含摘要
  • 列出更改的文件
  • 提及已知风险
  • 解释下一步

最终回答不应该是:

“完成了。”

而应该是:

“这是更改的内容,这是通过的部分,这是仍需要注意的地方。”

27. 使用 Worktrees 进行并行 Claude 会话

高级用户不会只运行一个 Claude 会话。

他们会运行多个。

但如果多个代理触碰同一个仓库,你需要隔离。

使用 git worktrees。

示例:

会话 1: 修复认证 bug
会话 2: 编写测试
会话 3: 更新文档
会话 4: 审查实现

每个会话都有自己的分支和工作空间。

无文件冲突。
无混乱覆盖。

这就是 Claude Code 开始感觉像一个团队而不是一个助手的方式。

28. 迭代任务

最好的 Claude Code 工作流不是一次性的提示。

而是迭代任务。

示例:

定义目标
↓
阅读上下文
↓
计划工作
↓
做出更改
↓
运行检查
↓
修复失败
↓
重复直到完成

用于:

  • 修复失败的测试
  • 清理一个模块
  • 重构一个功能
  • 审查安全问题
  • 在代码更改后更新文档

要点很简单。

不要要求 Claude “试一次”。

要求它持续执行直到满足成功条件。

29. 成功条件

大多数人给 Claude 的任务没有终点线。

这会产生模糊的输出。

给它一个停止条件。

示例:

当所有认证测试通过时停止。

当 TypeScript 零错误时停止。

当 README 包含设置、环境变量、命令和部署说明时停止。

当 PR 摘要包含更改的文件、已运行的测试和剩余风险时停止。

当“完成”被定义时,Claude Code 表现更好。

没有成功条件意味着模型决定什么是足够好。

这通常不是你想要的。

30. 最终验证

在 Claude 说它完成之前,让它验证工作。

使用这样的最终验证:

最终回答之前:
1. 列出每个更改的文件
2. 解释为什么需要每个更改
3. 运行相关检查
4. 报告通过的内容
5. 报告未测试的内容
6. 提及任何剩余风险

这可以防止敷衍的结尾。

你不想要:

“完成了。”

你想要:

“这是更改的内容,这是通过的部分,这是仍需要注意的地方。”

我的默认 Claude Code 设置

如果今天我要设置一个严肃的仓库,我会从这些开始:

  • CLAUDE.md 用于始终开启的项目上下文
  • 导入的文档用于架构、测试和部署
  • 针对危险操作的严格权限规则
  • 用于重复工作流的自定义斜杠命令
  • 用于研究、测试和审查的子代理
  • 仅用于我实际使用的工具的 MCP
  • 用于测试、lint 和安全检查的 Hook
  • 用于并行会话的 Worktrees

这对大多数人来说足够了。

你不需要 50 个插件。

你需要 5-8 个每天实际运行的系统。

如何在接下来的一周开始

不要试图一下子设置全部 30 项。
按照以下步骤做。

第 1 天
创建 CLAUDE.md。
添加你的技术栈、命令、规则和禁止操作。

第 2 天
为架构、测试和部署文档添加导入。

第 3 天
创建 3 个斜杠命令:

  • /review
  • /test
  • /debug

第 4 天
添加一个在代码更改后运行测试的 Hook。

第 5 天
创建一个用于代码审查的子代理。

周末
尝试一个使用 worktrees 的并行工作流。
一个会话构建。
一个会话测试。
一个会话审查。

那时 Claude Code 开始感觉不同。

真正的区别

在这套设置之前:

  • 你提示。
  • Claude 编辑。
  • 你手动检查所有内容。
  • 你明天又要解释同样的上下文。

在这套设置之后:

  • Claude 从项目上下文开始。
  • 它使用保存的工作流。
  • 它遵循权限规则。
  • 它自我检查工作。
  • 它委派狭窄的任务。
  • 它记住重要的内容。

同样的工具。
不同的操作系统围绕它。

大多数人将继续把 Claude Code 用作自动补全。

那些设置好上下文、记忆、Hook、命令和子代理的人,将把它当作一个真正的工程系统来使用。

这就是差距。

  • 原文链接: x.com/0xwhrrari/status/2...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论