跳到正文
Claude Code 15 个实用技巧:从够用到真正好用
0%
工具评测 · · 1,079 字 · 漫游君 · 进阶 · 🟡 中级 · Claude Code 实战 6/9 · ·

Claude Code 15 个实用技巧:从够用到真正好用

用了 Claude Code 大半年,踩了很多坑,也摸索出一套让它真正好用的方法。

整理了 15 条,全部来自实际使用,没有”多用多练”这种废话。


上下文管理

1. CLAUDE.md 是上下文的基础设施,不是笔记本

很多人把 CLAUDE.md 当记事本用,什么都往里塞。结果文件越来越长,反而稀释了重要信息。

正确用法:CLAUDE.md 只放约束和索引,不放内容。

# 项目约定
- 部署前必须 npm run build
- 不修改已发布文章的 slug

# 知识在哪里找
- 架构决策 → memory/knowledge/
- 上次进度 → memory/logs/最近日期_daily.md
- 部署流程 → memory/skills/deploy.md

控制在 50 行以内。细节放到 memory 层级,CLAUDE.md 只做指针。

2. 用 /clear 而不是新开窗口

上下文窗口满了,很多人的反应是关掉终端重开。正确做法是 /clear 清空对话历史,但保留 CLAUDE.md 加载的上下文。

重开窗口会重新读 CLAUDE.md,效果一样,但 /clear 更快。

3. 用 # 引用文件,而不是”你去看 xxx 文件”

❌ "你去看 src/components/SearchDialog.tsx"
✅ "修改 #src/components/SearchDialog.tsx 的搜索结果布局"

# 前缀让 Claude 立刻读取文件,而不是等到它自己决定要不要读。在上下文有限时,这个区别很重要。

4. 长任务开始前先写 Plan

对于超过 3 步的任务,先让 Claude 写一个执行计划,确认后再开始执行:

先给我写一个实现计划,不要开始写代码。
计划确认后我会说"开始执行"。

这避免了 Claude 理解偏差导致的大段无效代码。


工作流加速

5. /loop 让重复任务自动化

Claude Code 支持循环执行:

/loop 30m "检查 tasks.yaml 待办,处理一条 in_progress 需求"

适合:定时同步、心跳检查、内容批量处理。不适合:需要实时判断的复杂任务。

6. 用任务文件替代长对话

超过 10 轮的对话,信息密度下降,Claude 容易”忘事”。更好的方式:

把任务写成 markdown 文件,每次执行时读文件:

读取 tasks/current-sprint.md,按优先级处理第一条未完成任务。
完成后在文件里标记状态,再告诉我结果。

任务状态在文件里持久化,不依赖对话历史。

7. 用 --dangerously-skip-permissions 解放生产力(谨慎使用)

在已建立信任的项目里,每次工具调用都要确认会极大拖慢速度。

在受控环境(已配置 Hooks 的项目)里可以跳过权限确认:

claude --dangerously-skip-permissions

前提:必须先配置好 Hooks 做安全兜底,不然等于裸奔。

8. Git worktree 做实验性修改

不确定 Claude 的改动是否正确时,用 git worktree 隔离:

git worktree add ../experiment-branch -b experiment
cd ../experiment-branch
# 让 Claude 在这里做修改
# 满意了再 merge,不满意直接删

Claude Code 对 worktree 的支持很好,能正确识别当前工作目录。


提示词技巧

9. 给 Claude 角色,而不是只给任务

❌ "重构这个函数"
✅ "你是一个 Python 性能工程师,重构这个函数,重点关注减少不必要的内存分配"

角色定义给 Claude 一个判断框架,输出质量会明显提升。

10. 用”不要做什么”约束输出范围

Claude 倾向于”帮忙做更多”,但有时候你只想要最小改动:

只修改 getUser 函数的错误处理逻辑。
不要重构其他函数,不要添加类型注解,不要修改函数签名。

明确说”不要做什么”,比说”只做这一件事”更有效。

11. 要求 Claude 先解释再修改

对于重要文件,先让 Claude 解释当前代码的逻辑,再提修改:

先解释 auth.py 里 verify_token 函数的工作原理,
特别是 token 过期的处理逻辑。
理解后我再告诉你要改什么。

这一步能暴露 Claude 是否真正理解了代码,避免盲目修改。


防坑实践

12. 每次重要操作后立刻 git commit

不要攒着一起提交。Claude 做了 5 件事,你只想撤销第 3 件——很麻烦。

养成习惯:Claude 完成一个独立功能 → 立刻 commit → 继续下一个。

完成了,帮我写一个 git commit message,然后我来 commit。

13. 让 Claude 写测试,而不是”帮我验证”

❌ "你觉得这段代码对吗?"
✅ "为这个函数写 3 个边界用例的单元测试,包括空输入和超大输入"

Claude 自己评估自己写的代码,容易产生确认偏差。测试用例是更客观的验证方式。

14. 用 /cost 追踪费用,避免账单冲击

长会话的 token 消耗会超出预期。定期查看:

/cost

如果发现费用飙升,通常是某个任务在循环消耗上下文。找到后 /clear 重置。

15. 保存有效的提示词到 CLAUDE.md

当你发现某个提示词特别有效,不要让它消失在对话历史里:

# 有效提示词模板

## 代码审查
"以安全工程师视角审查这段代码,重点找 injection 漏洞和权限边界问题"

## 重构
"最小化改动重构,保持函数签名不变,只改内部实现"

## 调试
"不要立刻给解决方案。先列出 3 个最可能的原因,我来确认方向"

好的提示词是可复用资产,对待它就像对待代码一样。


一个元技巧

所有这些技巧背后有一个共同逻辑:把你的隐性知识显性化,放进 Claude 能读到的地方

你知道的约束、你踩过的坑、你喜欢的代码风格——这些都应该在某个文件里,而不是在你的脑子里靠每次对话重新传递。

这是 Claude Code 和普通 AI 对话框最大的区别:它可以积累上下文,前提是你愿意建设这个上下文。


系列文章:Claude Code 实战 · 相关:记忆架构 · Hooks 实战 · MCP 实战

这篇文章对你有帮助吗?

分享这篇文章

X / Twitter

感谢阅读这篇文章

约花了 11 分钟。如果对你有帮助,欢迎订阅 RSS 或收藏待读。

讨论

这篇文章让你感觉

评分

喜欢这篇文章?

订阅 RSS,第一时间收到新文章推送

订阅 RSS

私人笔记

仅保存在本地浏览器

讨论

评论加载中...