核心心智模型：上下文、权限与计划模式

从 Copilot 切到 Claude Code 之后，大多数人最初的一段时间都在"凭感觉用"——遇到问题就问、让它改就改、账单变贵也只能归因于"这工具就是贵"。但真正用熟的人会告诉你：决定用得好不好的，其实只有三个概念——上下文窗口、权限系统、计划模式。理解了这三样，后面所有操作技巧都是在它们之上的微调。

上下文窗口：token 是会累加的

Claude Opus 和 Sonnet 现在的上下文窗口是 200K token，换算大概 50 万中文字。看起来多到用不完，但实际使用里它比你想象的容易见底。

问题出在长会话的累加效应。第一轮任务读 3 个文件加生成代码，可能 5K token；第二轮再读 2 个文件再改，累计到 12K；第三轮跑测试失败读日志再改，涨到 25K；一路下来到第二十轮就是 60K 到 80K。超过 160K 左右 Claude Code 会自动压缩，但压缩是有代价的——它会摘要保留关键点，但细节会丢，你之前说过的约束、它之前看过的某段代码、某个决定背后的原因，都可能在压缩中被稀释。你会感觉它"忽然忘了之前说过不要动 config"，其实是细节没了。

这就是为什么"一个任务一个会话"是最值钱的习惯。三个管理工具日常都用得上：/clear 是核武器——切换到不相关的新任务立刻清干净，避免旧任务的残留污染新任务的思路；/compact 次优，让模型自己先摘要替换长历史，适合"同一件事还想接着干但已经太长"的场景；/cost 随时能看当前会话的 token 和费用，用几天就对自己的消费模式有感了。

主动管上下文的收益是三重的：输入 token 是主要费用所以直接省钱；上下文越短模型响应越快；上下文越干净模型越不容易混淆和遗忘。所以"多开会话、勤 /clear"看似麻烦，实际是同时省了钱、时间和错误。

权限系统：给 Agent 戴合适松紧的项圈

Claude Code 能执行 shell 命令、改写文件、调网络，这些都是它比纯聊天模型强大的地方，同时也是需要管理的风险面。权限系统的设计思路就是给不同类型的操作配不同的松紧度。

四类操作的默认行为大致是：读类（Read、Grep、Glob）无需确认，编辑类（Edit、Write）每次要确认，执行命令（Bash）每次要确认，网络请求每次要确认。这套默认值在新项目里最稳，但每条命令都要批一次很快就烦得受不了，于是 Claude Code 提供了两层方式让你放松或收紧这个默认。

启动时的权限模式是全局开关：claude 是默认模式；claude --permission-mode plan 是纯只读，什么都不让做只出计划；claude --permission-mode acceptEdits 自动允许文件编辑，适合你已经把任务讲得很清楚愿意让它跑；claude --dangerously-skip-permissions 是全自动，顾名思义——只在沙箱或一次性 VM 里用，日常开发机不建议。

更精细的控制在 .claude/settings.json 里按操作配置。提交进 git 的项目级配置大致是这样：

{
  "permissions": {
    "allow": [
      "Bash(pnpm install)",
      "Bash(pnpm test:*)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "ask": ["Bash(git push:*)"],
    "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)"]
  }
}

配套一份 .claude/settings.local.json 写个人偏好（不进 git）：

{
  "permissions": {
    "allow": ["Bash(docker:*)", "Read(~/notes/**)"]
  }
}

原则可以记三条：只读命令（ls、cat、git status、pnpm test 这些）尽量放行，每次弹窗只是在训练你按回车；破坏性命令（rm、git push --force、drop table）永远要确认，哪怕烦；团队项目把 allow 和 deny 写清楚到 settings.json 里，让每个加入的人都共享同一套边界。

Plan Mode：从 Copilot 过来最该学的一招

这是 Copilot 用户进入 Claude Code 最容易忽视、也是收益最大的一个功能。启动时加 --permission-mode plan 或会话里按 Shift+Tab 切过去都行，界面右下角会显示 Plan Mode。进入之后 Claude 只读代码不改不跑，它给你的产出是一份完整计划——做什么、改哪些文件、为什么这么做。你审核、批准、退出 Plan Mode 再开干。

为什么这事关键？想象一下"把登录改成 OAuth"这样一条指令。不用 Plan Mode，它可能啪啪改八个文件，你一看方向不对，得撤销加手动清理，一片狼藉。用 Plan Mode，同样这条指令得到的是：

计划：

1. 在 auth/providers/ 加 google.ts
2. 修改 auth.config.ts 注册新 provider
3. 环境变量加 GOOGLE_CLIENT_ID 和 GOOGLE_CLIENT_SECRET
4. 登录页 UI 加"用 Google 登录"按钮
5. 迁移现有用户表：users 加 provider 字段，默认 "credentials"

你看到第 5 步是数据库迁移，风险太大，要求改方案——它调整，你再批准，执行。30 秒的审核省掉了 30 分钟的回滚。

Plan Mode 不是所有任务都要用。跨文件改动、不熟悉的代码库、重构、技术栈升级、迁移、数据库 schema 改动这些适合先规划；改个拼写、加一行日志、调一个颜色，没必要进。判断标准其实就一句话：如果它做错了，你是一眼能 revert 还是得花十分钟清理？如果是后者，进 Plan Mode。

组合起来的老手工作流

这三个概念连起来就是一个稳定节奏：开个会话，任务复杂就 Shift+Tab 进 Plan Mode，描述目标看计划反馈调整，计划 OK 退出 Plan Mode 开始执行，危险命令弹窗时手动批，任务完成 /clear，下一个任务重新开始。CLAUDE.md 在最外层作为长期说明书，Plan Mode 在任务开头做护栏，权限系统在执行过程中做兜底，/clear 在任务之间做隔离。四层叠起来，Agent 既有足够自由度干活，又不会真的把事情搞砸。

下一篇讲怎么跟它说话——Prompt 技巧，和 Copilot 思维差异最大的一章。

参考资料

• Claude Code 设置文档 — 权限配置详解
• Plan Mode
• Cost Management