现在，越来越多开发者开始把 Claude Code 当成日常开发环境的一部分。
但同样是用 Claude Code，有人越用越顺：查代码、修 Bug、补测试、做重构、看 PR，一整套流程越来越丝滑。 也有人越用越乱：上下文越来越脏，改动越来越散，修了很多轮，最后还得自己回来兜底。
差别不只在模型能力，更在于你是不是把它当成了一个真正进入工程链路的工具。
很多人把 Claude Code 当成“会写代码的聊天框”，所以一上来就是想到哪儿问到哪儿。 更高效的方式，其实是把它放进一套完整的开发习惯里：会规划、会验证、会收口、会沉淀规则、会控制边界、会并行推进。
这篇文章直接把 Claude Code 最值得长期保留的 50 个日常技巧梳理出来。 让你看完之后，第二天真能拿去用。
目录
先把基础操作用顺 让 Claude 真正进入执行闭环 上下文管理，决定它能稳定发挥多久 把项目经验沉淀成长期规则 自动化、并行和协作能力，才是进阶分水岭
一、先把基础操作用顺
1. 给 Claude Code 配一个顺手的别名
每天频繁进入 Claude Code，会话入口越短越顺手，摩擦越小。
alias cc='claude --dangerously-skip-permissions'
source ~/.zshrc
之后直接输入 cc 就能启动。 但这个参数别乱开，前提是你已经很清楚当前仓库里哪些操作能放权，哪些不能。
2. 用 ! 直接执行命令，不要多绕一层
像 git status、npm test、pnpm lint 这种命令，能直接跑就直接跑。
!git status
!pnpm test
!pnpm lint
命令输出会直接进上下文，Claude 能基于真实结果继续往下做，比你手动描述快很多。
3. 学会用 Esc 及时止损
方向不对的时候，越早停越值钱。Esc 可以中断当前动作，不会丢上下文。
很多人不是被难题拖住，而是被错误方向拖住。
4. 用 Esc + Esc 或 /rewind 回到检查点
Claude Code 真正好用的地方，不只是能改，还在于你敢试。 试错不可怕，前提是你能快速回退。
如果某次尝试明显走偏，直接回到检查点，比继续补补丁更省时间。
5. 给常用语言装上 LSP 插件
如果你的项目有 TypeScript、Python、Go、Rust 这些语言，LSP 很值得装。
/plugin install typescript-lsp@claude-plugins-official
/plugin install pyright-lsp@claude-plugins-official
/plugin install gopls-lsp@claude-plugins-official
/plugin install rust-analyzer-lsp@claude-plugins-official
这样 Claude 改完文件后，很多类型错误、未使用导入、缺少返回类型之类的问题会更早暴露出来。
6. 把 gh CLI、jq、curl 这类工具也纳入日常武器库
很多场景根本不需要额外的 MCP。 像 gh CLI 处理 PR、issue、评论，就已经很够用了。
CLI 工具的一个优势是：轻、直、上下文占用少。
7. 复杂问题时，加上 ultrathink
不是每个任务都需要高强度思考。 但架构讨论、链路排查、复杂调试、多步骤推理，适合明确告诉它多想一层。
简单重命名不值得烧推理成本，复杂问题则恰恰相反。
8. 技能只在需要时加载，比把一堆说明塞进主上下文更干净
有些知识不是每次都会用到，比如部署约定、内部 API、特定编码模式。 这种内容更适合做成按需加载的技能，而不是每次会话都塞满。
主上下文越干净，Claude 越不容易被噪音带偏。
9. 手机远程接管，会让长任务更顺手
如果某个任务已经启动，你不一定非得守在电脑前。 远程查看进度、确认操作、接一句下一步，这种用法在长时间任务里非常舒服。
尤其是你已经把权限边界设好之后，移动端跟进会更自然。
10. 大上下文不是越大越好，要和任务匹配
上下文窗口更大，确实能装下更多内容。 但不是所有任务都需要一步拉满，能控制压缩阈值、知道什么时候该清理，才是真正会用。
二、让 Claude 真正进入执行闭环
11. 多文件修改、陌生模块、架构变更，先开计划模式
最怕的不是 Claude 慢，而是它用 20 分钟很自信地改错方向。 复杂任务先出计划，再进实现，通常更稳。
先让它说明会改哪些文件、为什么改、怎么验证，后面的偏差会少很多。
12. 不相关任务之间，先 /clear
一个干净会话，通常比一场混着三四个话题的长会话更值钱。
刚修完 CI，马上又聊新需求； 刚讨论完重构，又开始看另一个 Bug。 这种场景不清理，上下文只会越来越乱。
13. 不要解释错误，直接贴原始数据
报错、日志、CI 输出、PR 检查项，越原始越有用。
cat error.log | claude "解释这个错误并给出修复建议"
pnpm test 2>&1 | claude "修复这些失败的测试"
你先自己总结一遍，往往会丢掉真正能定位根因的细节。
14. 用 /btw 处理插问，别把主上下文越搅越乱
很多时候你只是临时想问一句：
为什么选这个方案？ 这个改法的代价是什么？ 有没有更轻的实现？
这种附带问题最好别直接塞进主流程里，避免干扰当前任务推进。
15. 给 Claude 明确的反馈循环
不要只说“帮我改一下”，要把验证动作一起写进去。
比如：
修复登录流程中的 session 失效问题。
改完后执行：
1. pnpm lint
2. pnpm test
3. 如果失败，继续修到通过
一旦形成“修改—验证—继续修”的闭环，结果会稳很多。
16. UI 改动最好接上真实验证
前端页面最怕“代码看着对，页面根本不对”。 如果是表单、弹窗、权限、跳转、列表刷新这类改动，尽量让它看到真实效果，而不是只看代码。
能跑到真实页面层面的验证，价值远高于口头确认。
17. 长命令放后台，不要堵住会话
构建、迁移、全量测试这类任务一旦跑起来，很容易把人也卡住。 这种时候让长任务自己跑，Claude 继续推进别的部分，会舒服很多。
18. 给终端加状态行，随时知道当前状态
当前目录、分支、上下文占用、任务状态，这些信息如果能一眼看到，决策会快很多。
状态清晰，本身就是效率的一部分。
19. 用 Ctrl+S 暂存长提示词草稿
你写到一半的大提示词，突然想先问个小问题。 这时候如果不能暂存，思路很容易断。
能保住草稿，就能减少很多来回重写。
20. 用语音输入补足上下文
口述往往比打字更容易把背景、限制、担心点一次说全。 尤其是需求描述、问题复盘、链路解释这种长信息，语音比短打字更自然。
三、上下文管理，决定它能稳定发挥多久
21. 上下文压缩时，明确告诉它保留什么
不要让 Claude 自己猜哪些内容最重要。 你可以直接指定：
当前任务目标 已改文件列表 当前测试状态 绝不能触碰的边界
这样压缩后不容易丢掉关键线索。
22. 用 /loop 做周期性检查
像部署状态、流水线结果、某个服务恢复没有，这类信息天然适合轮询。
/loop 5m 检查部署是否成功并汇报结果
你不用一直盯着，它会按节奏回来汇报。
23. 陷入反复修正时，重开比硬拖更高效
一个问题连续修两轮还在原地打转，通常不是因为差一点点，而是上下文已经被失败尝试污染了。
这时候最值钱的动作往往不是继续补，而是带着新认知重开一个干净会话。
24. 用 @文件路径 直接点名要看的文件
不要让它先在整个仓库里兜一大圈。
重点看：
@src/auth/middleware.ts
@src/api/session.ts
@src/pages/login.tsx
先分析调用关系，再给修改方案。
指明文件，本质上是在给它缩小问题空间。
25. 适当用模糊提示探索陌生代码
不是所有提示都必须写得特别死。 刚接触一个仓库时，像“你会怎么改这个文件”“这里最值得优化的地方是什么”这类开放问题，反而容易得到有启发的观察。
26. 计划不是只能看，还可以改
当 Claude 给出计划后，不一定要全盘接受。 删步骤、加约束、换顺序、改边界，很多时候比重写一遍提示更高效。
27. 会话命名和颜色区分，不是小题大做
你同时开两三个会话时，很容易输错终端。 一个是 auth 重构，一个是 PR 审查，一个是脚本迁移，不做标记，迟早会串。
28. --worktree 是控制并行污染最有效的办法之一
claude --worktree feature-auth
不同任务有独立目录、独立分支、独立文件状态，互不影响。 这比所有事情都堆在同一个工作区里稳得多。
29. 子 Agent 最适合拿来做“先研究，再汇报”
比如你想先搞清楚支付失败链路、某个模块的历史演进、某几个接口的调用关系。 这种研究型任务如果直接塞进主会话，很容易把主上下文撑脏。
子 Agent 的价值就是把“调查”与“实现”拆开。
30. 多 Agent 团队适合拆分研究、审查、重构，不适合抢同一文件
并行的前提是边界清楚。 如果几个人或几个 Agent 同时改同一组核心文件，覆盖和冲突只会越来越多。
四、把项目经验沉淀成长期规则
31. 先用 /init 生成一个 CLAUDE.md 骨架
CLAUDE.md 不是装饰文件，它是项目级长期指令入口。 先让工具帮你生成一版，再自己做减法，效率最高。
32. CLAUDE.md 不要写成百科全书
真正应该放进去的，是那些没有它，Claude 真可能做错的约束。
比如：
启动命令 测试命令 关键目录说明 不允许触碰的边界 团队必须遵守的编码约定
33. 每一条规则都问一句：没它会怎样？
如果没有这一条，Claude 大概率也会做对，那它可能就是冗余。 规则越多，真正重要的规则越容易被稀释。
人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇
34. Claude 犯过一次的错，最好沉淀成规则
比如：
改接口忘补测试 动了 migration 越过了权限边界 不该自动执行的命令直接跑了
这类问题不该只修这一次，而应该变成下一次不会再犯的规则。
35. 条件性规则放到 .claude/rules/
全局规则和局部规则不要混着写。 TypeScript 规范、Go 规范、数据库规范、某目录专属要求，都更适合拆到条件规则里。
36. 用 @imports 引用补充文档，不要把主文件撑爆
README、package.json、架构说明、内部操作文档，这些都可以作为补充上下文引用。 主文件只保留骨架，细节让 Claude 按需读取。
37. 输出风格也值得设定
解释详细一点，还是更偏行动型； 偏简洁，还是偏技术化。 输出风格统一之后，长时间协作的阅读成本会低很多。
38. 分清“建议”与“硬约束”
CLAUDE.md 更适合放建议与偏好。 而必须 100% 执行、不能漏的动作，应该交给 hooks 或自动化机制。
别把“最好这样做”和“必须这样做”混在一起。
39. PostToolUse hook 很适合做自动格式化
比如在 .claude/settings.json 里加：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npx prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
}
]
}
]
}
}
这样每次 Claude 改完文件后，就会自动执行格式化。
40. 需要的话，再顺手补一个 ESLint 自动修复
你也可以继续往后加：
{
"type": "command",
"command": "npx eslint --fix \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
}
机械动作尽量自动化，别让人每次手动提醒。
五、自动化、并行和协作能力，才是进阶分水岭
41. PreToolUse hook 用来拦危险命令，非常值
比如直接拦掉 rm -rf、drop table、truncate：
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "if echo \"$TOOL_INPUT\" | grep -qE 'rm -rf|drop table|truncate'; then echo 'BLOCKED: destructive command' >&2; exit 2; fi"
}
]
}
]
}
}
很多风险，不在于它会不会改错，而在于一旦执行错了，代价太大。
42. 长会话里，给压缩阶段补一个“记忆回填”钩子
会话拉得越长，越容易在压缩后丢任务主线。 这时候自动回填“当前任务、已改文件、禁止触碰区域”会很值钱。
43. 敏感变更一定要人工审查
认证、支付、数据迁移、删除性操作，这些地方不能只看“代码挺像那么回事”。
Claude 可以写代码，但责任最后还是在你手里。
44. 用 /branch 尝试不同方案，不必二选一
一个方案不确定时，不一定非要放弃原路线。 可以保留当前路径，再开一个分支去试激进改法。
这在重构、替代实现、性能优化时很好用。
45. 需求不清时，让 Claude 先反向访谈你
很多功能不是做不出来，而是一开始规格就没问清。 让 Claude 先问你边界条件、异常场景、权衡取舍，再产出 SPEC.md，比边做边猜要稳。
46. 双 Claude 协作，最适合“一个实现，一个审查”
让一个会话写，另一个会话只审。 评审视角越独立，越容易发现“实现者因为一路参与而忽视”的问题。
47. PR 审查不要只要一个结论，要把它聊透
一次性问“这个 PR 有没有问题”，很容易得到浅层结论。 更好的问法是：
风险最高的改动在哪？ 这段代码并发下会怎样？ 错误处理和项目其它地方一致吗？ 这次修改会不会留下后续维护坑？
48. 完成任务时加提示音，能明显减轻盯屏成本
长任务最浪费人的地方，是你总得时不时抬头看看它结束没有。 有提示音之后，你可以切出去干别的，等它叫你回来。
49. claude -p 适合做批量、低耦合的重复任务
比如批量迁移、批量替换导入、批量更新某类文件：
for file in $(cat files-to-migrate.txt); do
claude -p "把 $file 从旧写法迁移到新写法，并保持测试通过" \
--allowedTools "Edit,Bash" &
done
wait
前提是这些文件之间耦合不高。
50. 连加载动画都可以自定义，但重点不是好玩，是可持续使用
这类小定制表面看起来不重要，实际上很影响长期体验。 一个你愿意每天打开、愿意一直用下去的工具，往往不是靠一个大功能赢下来的，而是靠大量小细节慢慢积累出来的。
写在最后
很多人以为，Claude Code 拼到最后，比的是谁提示词更会写。
真正拉开差距的，往往不是这个。
而是你有没有把它放进一套稳定的工程习惯里：
复杂任务先计划 改完必须验证 上下文脏了就清 规则能沉淀就沉淀 机械动作尽量自动化 高风险操作一定设边界 能并行的任务就别全串行堆着做
同样都是 Claude Code， 有人用它偶尔“惊艳一下”， 有人已经把它变成了日常开发流的一部分。
差别，通常就藏在这 50 个细节里
