Day 013 · Claude Pro Plan 使用心得：如何更省 Token

先说明一下：严格来说，Claude Pro 订阅里更准确的说法是 usage / 使用额度，不是 API 那种精确 token 计费。

但日常使用里，说“省 Token”比较好理解，所以这里先沿用这个说法。

计算方式

- Claude / Claude Code / Claude Cowork 基本共享 Pro Plan 的使用额度，主要受 5h rolling limit + weekly limit 的影响

- Claude API 单独按 token / usage 计费，不包含在 Pro 订阅里

- Claude Design 有独立于普通 Claude / Claude Code 的 usage tracking 和 weekly limit，具体以界面显示为准

- 选择合适的模型，更经济地分配使用额度

- Opus 更适合需要深度 / 广度推理、没有标准答案的发散问题

- Sonnet 可以胜任比较明确的执行层任务

- 例如：产品前期定位 / 脑爆可以用 Opus；写 prompts / 整理 checklist / 验收阶段可以尽量用 Sonnet

- 跟 ChatGPT 的使用方式不同，Claude 的使用消耗会受当前对话长度影响，所以长 chat、大图片、大附件、代码文件都要谨慎使用

- Claude 里的每个 chat 最好只服务一个明确阶段

- 关闭 chat 时，可以按需产出 handover context prompt，方便下一阶段新开 chat 继续

- Claude Code 有 session 内的 context 压缩机制，同一个任务可以持续推进；但跨大任务时最好重开 session，避免上下文太脏

- Claude Design 我会按“一个 project = 一份产出”来管理；一个 project 里可以有多个 chat，但不建议把太多不同方向混在一起，容易让 context 和审美方向变脏

- 因为使用消耗和上下文长度有关，所以复杂任务不一定是 prompt 越短越省

- 结构化、有 context 的 prompts 反而更合适，可以减少反复解释和返工

- 我常用的结构是：Role / Goal / Task / Constraints / Context

- 也就是尽量一次说清楚：你是谁、我要什么、背景是什么、限制是什么、输出要求是什么

- 通用文件可以放在 project files 里，避免每次重复上传 / 重复解释

- 我自己的使用场景是：每个正在开发的产品有独立 project，里面会有一个 project context.md

- 常见链路是：Claude 里整理背景和 prompts → Claude Code 执行 → 再回到 Claude 做 review / critique

- Adaptive thinking 不用太焦虑，复杂问题可以开；简单执行类任务没必要执着

- Agent / Connectors 不用因为害怕消耗就全部关掉，但也不建议为了“看起来强大”全连上

- 真正读取、调用、执行时，才会明显增加消耗和噪音

- 原则还是：用得上再开，有真实任务再连

每周“福利”

- 如果 weekly limit 重置前刚好还有剩余，可以把 Cowork 用在本来就需要做的 housekeeping

- 例如：本地文件整理、文档归档、下载文件夹清理、批量重命名等

- 但前提是：它本来就是需要做的事，不是为了用完额度硬找任务

- Cowork 做复杂多步任务会比普通 chat 更消耗 usage，所以不适合拿来做简单问答

我的核心使用原则：

Opus 留给判断和复杂推理

Sonnet 负责明确执行

Project 放稳定背景

Agent / Cowork 留给真正适合多步骤执行的任务