避坑与省钱：上下文管理与常见问题

Claude Code 用一阵之后，会遇到两类让人头疼的问题：一类是"怎么账单突然涨了这么多"，另一类是"怎么它又把我没让它动的地方改了"或者"怎么它搞到一半完全跑偏了"。这两类问题其实有一个共同根源——上下文管理。理解清楚上下文怎么累积、怎么消耗、怎么污染，就既能省钱也能绕开大多数坑。

账单是怎么涨起来的

按量付费时的价位大致是这样：Haiku 输入约 $0.8/M、输出约 $4/M；Sonnet 是 $3 和 $15；Opus 是 $15 和 $75。一个认真干活的长会话，从几美金到几十美金都正常，这不是 bug 是正常范围。订阅（Pro / Max）按额度计费不会超支但会被限速，对 90% 的日常使用订阅都更划算——除非你的用量真的很大或者接了 CI 之类的自动化。

真正容易让账单失控的不是模型单价，而是一个常被忽视的事实：长会话每次对话都要重发完整历史给模型。一个累积了 100k token 的会话，你发一句"改个错字"，实际计费的输入不是 10 token 而是 100k+。所以贵的不是单次请求，而是你没意识到它每次都在重新"读"你过去所有说过的话。

理解了这一点，省钱的第一招就不言自明——任务切换立即 /clear。这是所有省钱动作里最便宜、收益最高的一条。对话还想接着但已经很长，用 /compact 让 Claude 自己先做摘要替换长历史，次优但也很有效。第二招是利用 Prompt Caching：稳定的 CLAUDE.md 和会话开头如果不变，输入部分会按 10% 计费，所以 CLAUDE.md 写好后少动，固定指令放前面、变化放后面。第三招是让它一次把相关动作做完而不是来回几轮——"读 src/auth.ts，分析现有逻辑，然后按下面要求改造"比分成三条指令便宜一倍以上，因为文件只读一次。

模型选型也很关键。大多数日常任务用 Sonnet 就够，简单的 rename 和改错字用 Haiku，Opus 留给真的需要深度推理的架构设计和复杂重构。会话内可以用 /model sonnet、/model opus、/model haiku 来回切，不必所有任务一律 Opus——那是账单最快的涨法。

养成每次会话结束敲一下 /cost 和 /status 的习惯，几天你就能摸清自己的消费模式在哪一档。

跑着跑着偏了，怎么拉回来

Claude Code 对每次文件修改都有记录，/rewind 能回到之前任意一步；加上你始终在 git 里工作的前提，最坏也能 git checkout . 全局还原。所以"永远在 git 里工作"是第一条硬规则——没有版本控制地让 Agent 改代码，等于开车不系安全带。

更常见的场景是它开始反复改同一个地方、越改越错。这一般不是它变笨了，而是上下文污染——前面几轮积累的错误假设被持续带入，每一步都在错误的地基上加砖。这种情况没有什么"再耐心一点它就好了"的说法，直接 /clear 重开，然后用更精准的描述重新提问：

（新会话）
src/cart.ts 第 45 行的这段代码有 bug：[粘贴代码]
期望行为：[描述]
实际行为：[描述]
根因可能在 xxx 附近，从这里查起

这种重启比"继续尝试"快十倍，前提是你要识别出"它已经卡在污染的上下文里了"这个信号——如果连续两三轮都没实质进展、每次修改都像在打补丁打补丁，就是该 /clear 的时刻。

另一类常见坑是它"声称改完了但实际没改"或者"改完了但没验证"。解法很直接：在 Prompt 里写"做完后跑 pnpm build 和 pnpm test，把结果贴给我，失败就修到通过"；并且养成收尾时 git diff 自己看一眼的习惯——别听它的口头报告。

权限与安全的硬底线

Agent 能运行命令是它的超能力，也是最容易出事故的地方。社区里真的发生过这种事：有人开着 --dangerously-skip-permissions，Claude 在某一轮里执行了 rm -rf 类操作。这种事故很罕见，但一次就够受的。底线有三条：永远别在没有 git 的目录里工作、非必要不开 skip-permissions、把高危命令写进 deny 列表。

推荐的最小安全配置放在项目根目录 .claude/settings.json 并提交到 git，让团队共享：

{
  "permissions": {
    "allow": [
      "Bash(pnpm install)",
      "Bash(pnpm test:*)",
      "Bash(pnpm lint:*)",
      "Bash(pnpm build)",
      "Bash(pnpm dev)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(gh pr:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/**)"
    ]
  }
}

这份配置里有两点值得单独说。一是把 .env 系列文件放进 Read deny——默认情况下 Claude Code 不会主动读 .env，但如果你习惯用 @.env 引用某个变量就会把整份密钥泄进上下文，deny 规则相当于自动防手滑。二是 pnpm install 虽然在 allow 里，但要警惕 npm 生态的 postinstall 脚本风险：Agent 批准你装某个包，那个包的 postinstall 就能执行任意代码。日常写 Prompt 时明确"只装这几个包，不允许装别的"比事后查要保险得多。

另外把 .claude/settings.local.json、.claude/logs/、CLAUDE.local.md 这几项追加到 .gitignore——个人化的配置和日志不要跟进版本库。

一些小问题的小答案

长会话越跑越慢不是错觉，100k+ token 的上下文对任何模型都是负担，加上每次要重发整段历史。处理方式和省钱是同一招：/compact 或 /clear，合理分段，一个任务一个会话。

在 Windows 原生终端用 Claude Code 常踩奇怪问题（路径、权限、子进程），前面装环境那篇里已经讲过——用 WSL，别跟自己过不去。

一个规则反复口头强调三遍它还犯，说明你不该继续口头强调。直接"把这条规则加进 CLAUDE.md"——它会自己改，从此每次会话自动带上，比每次开头提醒更省心也更可靠。

一份用下来的心法

到这里这个手册就完整了。从在 Windows 上装 WSL、装 Claude Code、登录配置，到理解上下文 / 权限 / 计划模式的底层，再到怎么把需求说清楚、怎么把日常 bug 修复重构写测试四件事套进稳定的工作流，再到 Slash Commands / Hooks / Subagents / MCP 这些能把常用动作固化下来的进阶武器，最后落在账单和安全这些用久了必然遇到的现实问题上。这条路线走下来，Copilot 时代的"一行一行让它补全"应当已经被"一个任务完整交给它"取代了。

剩下的就是用。给自己订一个小目标——比如这周所有 bug 都让 Claude Code 先尝试一次、所有 PR 都让它先过一遍——两三周之后你会摸清它的脾气：什么任务它擅长、什么任务它会翻车、该给多大自由度、什么时候该踩一脚刹车。这些感觉不是读出来的，是用出来的。

读到这里还有几个值得顺手做的动作：每个月回看一次 /cost 累计，借机清理一下 .claude/commands/ 下那些已经不太用的快捷命令、调整 CLAUDE.md；在 GitHub 搜 filename:CLAUDE.md 看看顶级开源项目是怎么写规则的，借鉴过来；把自己常用的 Prompt 沉淀进 .claude/commands/，省得每次手敲。

参考资料

• Claude Code 官方文档 — 持续更新
• Claude Code Release Notes
• Anthropic 官方博客
• awesome-claude-code
• r/ClaudeAI — 踩坑现场