想长期稳定用 Claude Code，前提还是账号、订阅和网络环境要稳。可以先看我这篇：2026 最新 Claude 订阅防封全攻略：小白也能搞定的低成本防封实操。
从去年开始用 Claude Code 之后，我基本就离不开它了。日常写代码、改项目、查问题、发版前自查，很多事都会交给它跑一遍。用得多了之后，我最大的感受是：它不能只当成一个“更会写代码的聊天框”。
Claude Code 真正强的地方，是它能读仓库、改文件、跑命令、调工具，还能按你的项目规则持续干活。但问题也在这里：能力越多，越容易乱。上下文给多了会乱，工具开多了会乱，规则写太长也会乱。最后就会变成：它看起来一直在忙，但结果不一定靠谱。
所以我现在更愿意把 Claude Code 当成一个小型工程系统来用，而不是只靠一句“帮我优化一下”去赌运气。
1. 先把 Claude Code 拆成六块来看
刚开始用的时候，很容易把规则、工具、自动化、子代理、测试这些东西混在一起。拆开之后就清楚多了。
| 这块是什么 | 主要靠什么 | 它解决什么 | 最容易踩的坑 |
|---|---|---|---|
| 项目上下文 | CLAUDE.md / rules / memory | 告诉 Claude：这个项目有什么规矩 | 写成大百科，真正重要的规则反而被淹没 |
| 动作能力 | Tools / MCP | 让 Claude 能访问 GitHub、数据库、浏览器、日志系统 | 工具太多、名字太泛，它会选错 |
| 做事流程 | Skills | 给 Claude 一套“这类事该怎么做”的步骤 | 一个 Skill 什么都想管，最后触发不稳定 |
| 硬性约束 | Hooks / permissions / sandbox | 不靠 Claude 自觉，直接自动检查或阻断 | 用 Hook 做复杂判断，输出又长又吵 |
| 隔离执行 | Subagents / worktrees | 把搜索、审查、长日志分析丢到单独上下文里 | 权限给太大，隔离就没意义 |
| 结果验证 | tests / lint / screenshots / logs | 证明它真的做对了 | 只听它说“完成了”，自己不验 |
这六块里，哪一块过度了都会出问题。CLAUDE.md 写太长，上下文会脏；MCP 接太多，工具定义会吃掉很多 token；Subagent 没边界，最后不知道谁改了什么；验证不做，Claude 说完成了你也没法判断。
2. 上下文别塞太满
很多时候 Claude Code 跑偏，不是它不聪明，而是你给它的信息太杂。
上下文窗口不是无限的。系统提示、工具定义、MCP schema、CLAUDE.md、历史对话、文件内容、命令输出，全都在抢同一块空间。尤其是 MCP 和命令输出，很容易不知不觉把上下文塞满。
我现在一般这么分：
| 这类信息 | 放哪里 | 什么时候加载 | 怎么判断该不该放 |
|---|---|---|---|
| 每次都必须遵守的项目规矩 | CLAUDE.md | 常驻 | 少了它，Claude 会反复犯同一个错 |
| 某个目录或语言特有的规矩 | .claude/rules/ | 按路径加载 | 只对一部分代码成立 |
| 偶尔才用、但步骤固定的流程 | Skills | 用到再加载 | 需要方法，不需要天天占上下文 |
| 大范围搜索、长日志、并行审查 | Subagents | 单独隔离 | 会产生很多中间输出 |
| 格式化、轻量检查、阻断危险操作 | Hooks | 不进主对话 | 不需要推理，只需要执行 |
CLAUDE.md 最别写成团队知识库。项目背景、完整 API 文档、长篇架构介绍、口号式原则，都不适合放进去。Claude 自己读仓库就能看懂的东西，也别重复写。
真正值得写的是这些：
- 怎么安装、怎么启动、怎么测试。
- 哪些目录负责什么。
- 哪些文件不能随便碰。
- 提交前必须跑什么。
- 上下文被压缩时，哪些信息必须保留。
我会在 CLAUDE.md 里专门写一段压缩规则。比如保留架构决策、改了哪些文件、验证状态、还有没处理完的风险。长会话压缩后，最怕丢的不是命令输出，而是“当时为什么这么决定”。
3. CLAUDE.md 要像合作约定，不要像说明书
一个能用的 CLAUDE.md，其实不用很长。差不多这样就够了：
# Project Contract
## Build And Test
- Install: `npm install`
- Dev: `npm run dev`
- Test: `npm test`
- Build: `npm run build`
## Architecture Boundaries
- Content posts live in `src/content/posts/`
- Site identity lives in `src/site.config.ts`
- Do not put article-specific promotion links in global navigation
## Safety Rails
## NEVER
- Do not rewrite unrelated dirty files
- Do not deploy production without explicit approval
- Do not claim success without running verification
## ALWAYS
- Inspect `git status` before committing
- Keep article frontmatter valid
- Run `npm test` and `npm run build` before publishing
## Compact Instructions
Preserve:
1. User-approved scope and wording
2. Modified files and why they changed
3. Verification commands and pass/fail status
4. Remaining risks or rollback notes这类东西越具体越好。“写高质量代码”基本没用；“改 API 时要同步更新 contract test”才有用。
还有个小技巧：每次 Claude 犯了那种以后还可能再犯的错，就让它自己把规则补进 CLAUDE.md。比如它忘了跑测试，你就直接说：“把这条写进 CLAUDE.md，以后提交前必须先跑测试。”
但规则也别一直加。用一段时间要清理一下，不然半年后又会变成新的噪声。
4. Skills 不是模板库，是做事流程
Skill 的价值是“用到再加载”。它不是拿来堆资料的，也不是脚本文件夹。它更像一张小纸条，告诉 Claude：遇到这类事，先做什么，再做什么，最后怎么交付。
坏描述大概是这样：
description: help with backend这太泛了，什么后端任务都可能触发。
好一点的描述是：
description: Use when reviewing API changes for compatibility, tests, and rollback risk.一个好 Skill 至少要讲清楚四件事：
- 什么时候必须用它。
- 要先看哪些文件、拿哪些证据。
- 每一步怎么做。
- 碰到什么情况必须停下来问人。
别把一个 Skill 写成大杂烩。review、debug、deploy、incident、docs 全塞进去，Claude 会很难判断到底该怎么用。一个 Skill 就解决一类问题，反而稳定。
如果这个 Skill 会产生副作用，比如迁移配置、发布版本、清理数据，那就更要谨慎。最好要求显式触发，并且写清楚 dry-run、备份和回滚。
5. 工具要让 Claude 少猜
给人用的 API，和给 Agent 用的工具，不是一回事。
人会读文档，会问上下文，会凭经验猜。Agent 更依赖工具名、参数名和返回格式。名字写得含糊，它就真的会用错。
我比较喜欢这样的工具：
- 名字直接，比如
github_pr_get、sentry_errors_search，不要叫query、fetch、do_action。 - 参数也直接，比如
issue_key、project_id、response_format，别只给一个id。 - 默认返回精简内容，需要时再用
detailed。 - 报错时告诉它下一步怎么修，不要只甩一个错误码。
- 能封成高层动作就封起来，别让它自己拼一堆底层小工具。
还有一点：不是所有事都值得做成 MCP 工具。本地 shell 能稳定完成的，就用 shell。只是静态知识的，就放文档或 Skill。工具适合的是那种“要和外部系统交互，并且结果会影响下一步判断”的事。
6. Hooks 适合管硬规则
Hooks 最适合处理那些“必须执行，而且不需要 Claude 思考”的事。
比如：
- 改完某类文件自动格式化。
- 改关键文件前先提醒或阻断。
- 任务结束后发通知。
- 会话开始时告诉它当前分支、环境、运行目录。
- 把测试输出截短，别让几千行日志塞进上下文。
不适合放到 Hooks 里的，是复杂业务判断、长时间流程、多步权衡、需要读很多上下文的审查。这些更适合 Skill 或 Subagent。
Hooks 有一个细节很重要：输出要短。测试失败时，Claude 需要知道“哪里挂了、下一步看什么”，不是完整日志。
7. Subagents 最大的价值是隔离
很多人一提 Subagent，就想到并行。但我觉得它更重要的价值是隔离。
有些任务会产生很多噪声，比如全仓库搜索、长日志分析、方案对比、审查一组文件。如果都塞在主对话里，主线很快就脏了。交给 Subagent 做，主对话只拿结论，会干净很多。
适合派出去的任务：
- 全仓库找某个行为的调用链。
- 只读审查一组文件。
- 分析一大段日志。
- 比较两个实现方案。
- 跑一组不会改状态的验证。
不适合派出去的任务：
- 子任务之间强依赖，需要来回共享中间状态。
- 权限边界说不清。
- 输出格式不固定，主对话拿回来没法用。
- 没有 worktree 隔离，却让多个 agent 同时改同一块代码。
给 Subagent 的指令要具体：能用哪些工具，不能用哪些工具，最多跑几轮，最后按什么格式汇报。需要动文件时，最好配合 git worktree。
8. 复杂任务先计划，再动手
复杂任务别一上来就让 Claude 写代码。先让它读一圈，弄清楚目标、边界、影响范围和验证方式，再开始改。
这些场景尤其适合先规划：
- 跨模块重构。
- 数据迁移。
- 发布流程调整。
- 涉及生产环境的任务。
- 需求本身还不够清楚的功能。
规划不是为了走流程，而是为了少走弯路。一个错误假设如果在读代码阶段发现，只浪费几分钟；如果写完、测完、发完才发现，那就麻烦多了。
我自己有时会让一个 agent 写计划，再让另一个 agent 用 reviewer 的角度挑毛病。AI 审 AI 当然不是万能，但查范围遗漏、验证缺口、危险默认值，确实挺好用。
9. 没有验证，就别说做完了
Claude 说“我完成了”，这句话本身没什么工程意义。真正有意义的是：它跑了什么验证，结果是什么。
验证可以分三层：
| 这一层 | 常见做法 | 能证明什么 | 还不够证明什么 |
|---|---|---|---|
| 基础验证 | 命令退出码、lint、typecheck、unit test | 代码能编译，核心逻辑没破 | 真实链路一定可用 |
| 集成验证 | 集成测试、contract test、截图、浏览器 smoke test | 页面、接口、跨模块行为大体符合预期 | 线上环境一定没问题 |
| 线上验证 | 生产日志、监控指标、真实页面、人工 review 清单 | 发布后真实路径可用 | 还需要持续观察 |
写 prompt 或 Skill 时，最好提前写清楚什么叫完成：
## Definition of Done
- `npm test` passes
- `npm run build` passes
- Changed article appears in generated blog route
- No unrelated dirty files are staged
- Deployment only happens after explicit approval不要把“看起来可以”当成完成。前端页面就看截图；接口就跑 contract test；生产发布就看线上页面、健康检查和日志。
10. 这些命令我用得比较多
下面这些命令，用久了会很顺手：
/context：看看上下文被谁吃掉了，尤其是 MCP、文件内容和命令输出。
/clear：重开当前任务。Claude 被你纠偏两次还跑偏，通常不如清掉重新说。
/compact：阶段切换时压缩上下文。最好配合 CLAUDE.md 里的压缩规则。
/memory：看看哪些记忆和项目规则真的被加载了。
/mcp：检查 MCP server。闲置的就关掉，不要让工具定义一直占上下文。
/permissions 和 /sandbox：收权限边界。自动化越强，权限越要管住。
claude --continue：接着当前目录最近一次会话继续。
claude --resume：从历史会话里挑一个继续。
claude --worktree：给需要隔离文件系统的任务开 worktree。
claude -p --output-format json：把 Claude 接到脚本或 CI 里。
还有一个习惯我很推荐：长任务结束后，让 Claude 写一份 handoff。里面写清楚现在做到哪、试过什么、哪些路走不通、下一步该干什么。下一个新会话直接读这个，比赌自动压缩摘要靠谱。
11. 常见坑
把 CLAUDE.md 写成 wiki。 每次加载一堆背景，真正重要的规则反而不显眼。解决办法：只留项目契约，资料放到 docs、rules 或 Skills。
Skill 写成大杂烩。 什么都管，最后什么都管不好。解决办法：一个 Skill 只管一种任务。
工具太多，名字还很模糊。 Claude 选错工具，或者工具定义把上下文挤满。解决办法：合并重复工具，名字和返回格式都写清楚。
没有验证。 Claude 觉得自己完成了，但你不知道能不能发。解决办法：每类任务都配明确的 verifier。
过度自治。 多个 agent 同时跑，权限全开，出了问题不知道是谁干的。解决办法：最小权限、worktree 隔离、固定输出格式、限制轮数。
批准过的命令长期不清理。 settings.json 里残留危险命令，某天被自动执行。解决办法：定期看 allowed tools 和 permissions。
12. 新手别一下子配太满
如果你刚开始认真用 Claude Code，不用一口气把 Skills、Hooks、Subagents、MCP 全配满。先做一个最小版本：
- 写一个短的
CLAUDE.md，只放构建、测试、边界和禁止项。 - 固定提交前要跑的验证命令。
- MCP 只接最常用的，别全开。
- 给高风险流程写一个 Skill，比如发布、迁移、线上排障。
- 给容易忘的检查加 Hook，比如格式化或轻量 lint。
- 大范围搜索和审查，再交给 Subagent。
用一段时间后，你会发现自己总在重复提醒 Claude 同几件事。那些才值得沉淀到项目规则里。偶尔才用一次的知识，不要让它常驻上下文。
13. 最后说一句
Claude Code 的上限，不只看模型本身，也看你给它搭了一套什么样的协作方式。
你只把任务扔进去等结果，它就像一个很聪明但容易跑偏的同事；你给它清楚的上下文、能用的工具、必要的硬约束、隔离的执行环境和明确的验证方式，它就会稳定很多。
一句话：别只问“Claude Code 会不会写代码”，要问“它怎么知道该写什么、不能碰什么、写完怎么证明是对的”。
14. 最重要的前提
上面这些方法都有一个前提：你得能稳定使用 Claude Code。
如果账号经常异常、订阅不稳定、网络环境一天一个样，那 CLAUDE.md、Skills、Hooks、Subagents 配得再好，也会被最基础的可用性问题打断。
如果你还卡在 Claude 账号注册、订阅支付、代理环境、风控这些问题上，可以先看这篇，把基础环境跑稳：
2026 最新 Claude 订阅防封全攻略：小白也能搞定的低成本防封实操
如果账号和订阅已经搞定，只是在找适合 Claude Code、ChatGPT、Codex 的稳定网络环境，可以看这篇：
2026年7月 稳定优质的 VPN 机场推荐：6 家适合 Claude、ChatGPT 的稳定代理平台
先解决“能稳定订阅和使用 Claude Code”，再谈怎么把它用得更顺。这个顺序别反过来。