声明（Statement）
根据我们基于使用量计费（Usage-Based）的 Enterprise 企业许可证，所有 Claude 会话均按 API 标准费率按 Token 计费。用户应将每个会话限定在单一任务范围内、保持提示缓存（Prompt Cache）处于有效状态，并根据任务选择合适的模型。
适用范围（Scope of Applicability）
适用于：
- 企业许可证下的所有交互式 Claude 使用场景
- Claude Chat（claude.ai）
- Cowork
- Claude Code 会话
不适用于：
- 通过 Claude API 进行程序化调用的生产系统（需考虑批处理、请求路由、单次调用缓存控制等独立设计问题）
- 执行本规范的工具或自动化机制本身（由配套的《强制执行措施（Enforced Measures）》文档覆盖）
背景说明（Rationale）
在我们采用的按使用量计费的 Enterprise 许可下，每个 Token 均按照标准 API 价格收费，不存在免费额度。因此，任何会话类型中的低效使用都会直接体现在账单上。
不同会话类型的 Token 消耗差异非常显著：
- 一个 Cowork 任务可能远超普通聊天会话的消耗。
- 一个 Claude Code 调试会话可能使用远多于普通 Chat 的 Token。
成本的主要来源是上下文重新处理（Context Re-processing）：
Claude 每收到一条新消息，都会重新读取整个会话历史。
因此：
- 会话越长，每条消息成本越高；
- 消息越多，总成本增长越快。
Prompt Cache 可以将重复读取成本降低至正常输入成本的大约 10%。
但缓存会在 1 小时无活动后失效。
一旦失效，下一条消息将：
- 重新处理全部历史上下文
- 按完整费率重新计费
本规范聚焦于用户能够控制的三个关键成本杠杆：
快速参考：常见场景
| 我想要... | 推荐做法 | Token 影响 |
|---|---|---|
| 降低整体成本 | 每个任务新会话 + Sonnet + 低 Effort | ⬇️ 最高 |
| 继续之前的工作 | 使用 /fork 继承缓存 |
⬇️ 中等 |
| 发现问题后纠正 | 使用 /rewind 回退 |
⬇️ 低 |
| 修复重大错误 | 使用 /clear + 新会话 |
⬆️ 可能增加 |
| 使用高端功能 | 仅在必要时用 Opus | ⬆️ 显著 |
1. 模型选择（Model Choice）
成本对比：
- Sonnet 的单 Token 成本约为 Opus 的 40%
- Sonnet 的单 Token 成本约为 Fable 的 20%
实际差异：
- Sonnet 比 Opus 便宜约 2.5 倍
- Sonnet 比 Fable 便宜约 5 倍
2. 上下文大小（Context Size）
在一个持续一整天的会话中：
即使只是提出一个单行问题，也需要为全天的上下文历史付费。
而在一个新会话中提出相同问题：
几乎不会产生额外成本。
3. 缓存生命周期（Cache Lifetime）
如果后续问题在几分钟内发送：
会话只需按约 10% 的输入费率重新读取缓存。
如果中断超过一小时：
整个上下文需要按全额费率重新处理。
应该这样做（Do This）
本章列出 Token 优化的最佳实践，按会话类型和通用场景组织。
所有会话类型（Chat、Cowork、Claude Code）
✅ 每个主题或任务开启新的会话
问题：旧上下文会增加后续每条消息的成本。
做法：开始新任务时，创建新的 Session 或 Conversation，而不是继续沿用旧会话。
成本差异：
- 长会话中的一个新问题 → 为整个历史重新付费
- 新会话中的同一个问题 → 几乎无额外成本
✅ 在会话开始时有意识地选择模型与思考强度
默认模型：Sonnet
Opus 仅在以下场景使用：
- 架构设计
- 复杂调试
- 多步推理
原因：单 Token 成本更高，相同工作负载下消耗强度更高
按任务类型选择 Effort：
| 任务类型 | 推荐设置 | 命令 |
|---|---|---|
| 模板代码、批量重命名、配置修改 | Low/Medium | /effort low 或 /effort medium |
| 系统设计、深度问题分析、疑难调试 | High | /effort high |
注意：Thinking Tokens 按输出 Token 计费，而输出 Token 是价格最高的一类 Token。
✅ 从长会话切换到新任务时编写交接摘要（Handoff Brief）
记录内容：
- 目标（Goal）：本任务的核心目标
- 已做决策（Decisions）：重要的技术选择
- 文件路径（File Paths）：关键文件位置
- 待解决问题（Open Questions）：未完成的项
好处：新会话仅需几百 Token 即可启动，无需重新发送完整上下文历史。
✅ 编写完整、批量化的提示词
成本对比：
| 方式 | Token 消耗 | 说明 |
|---|---|---|
| 多个相关问题放在同一消息 | 最低 | 仅需一次上下文处理 |
| 多个问题分开发送 | 高 | 每条消息都重新处理上下文，成本累积 |
发送前检查清单：
- ✅ 问题描述是否清晰完整？
- ✅ 是否提供了所需的背景信息？
- ✅ Claude 是否必须先反问才能完成？
- ❌ 如果答案是”会”，则需进一步完善提示词
✅ 在提示中加入验证标准
包含的内容：
- 测试用例
- 目标输出
- UI 参考图
- 预期行为
好处：
- Claude 可以自我校验结果
- 避免多轮纠错
- 减少额外 Token 消耗
例如：
期望输出格式：
- 每行一个结果
- JSON 嵌套不超过 3 层
- 包含错误处理
💡 在高强度使用时关注使用指标
在 Claude Code 中运行：
/usage
可以查看：
- 最近使用量
- 单项高消耗行为
- 优化建议
关键提示：
- 高 Cache Read 不代表浪费（只按约 10% 输入成本计费）
- 真正需要关注的是：持续出现高 Cache Write
常见 Cache Write 高的原因：
- 频繁切换模型
- 频繁更改 Effort
- MCP Server 波动
- 工具权限被中途拒绝
原则：不要只看 Token 数量，要结合成本权重分析。
💡 每月执行一次 Insights 分析
在 Claude Code 中运行：
/insights
用于发现：
- 请求理解错误
- 重复返工循环
- 使用摩擦点
与每周执行的 /usage 检查互为补充。
Claude Code 使用规范
✅ 保持 CLAUDE.md 简短
目标：不超过 200 行
为什么：CLAUDE.md 会被载入到：
- 每个主会话
- 每个子 Agent
大型文档会放大成本。
建议：迁移这些内容至 Skills（按需加载）
- 部署步骤
- 数据迁移流程
- Code Review 清单
结果：CLAUDE.md 保持精简，Skills 按调用时加载。
✅ 将大量输出任务交给子 Agent
适用场景：
- 日志分析
- 测试执行
- 大规模代码搜索
做法：主会话只保留摘要结果。
推荐配置：
model: haiku
或
model: sonnet
✅ 使用 Hooks 过滤噪声
示例：
构建输出（未过滤）：
10000 行日志
过滤后：
5 个失败项
结果：Claude 只需处理关键内容，节省大量 Token。
✅ 对复杂任务使用 Plan Mode
流程：
1. 启用 Plan Mode 先确认方案
2. 再开始编码
如果发现方向错误：
1. 立即按 Esc 退出 Plan Mode
2. 运行 /rewind 回退更改
原因：返工是最昂贵的 Token 浪费。在编码前验证方向可以避免大量返工。
✅ 大范围 AI Review 放到 CI 中执行
成本对比：
| 执行位置 | 成本 | 说明 |
|---|---|---|
| CI 中执行 Review | 单次付费 | 集中优化、每个 PR 只付费一次 |
本地执行（如 /core-reviewing） |
重复付费 | 每次本地运行都需付费 |
建议：
- 大范围审查 → 放到 CI 中自动执行
- 本地只做快速预检查
✅ 并行 Claude Session 使用独立 Worktree 或分支
推荐：使用 git worktree 或独立分支
优点：
- 避免工作区冲突
- 保持缓存和上下文独立
- 每个 Session 有独立的缓存生命周期
💡 在任务间隙使用 /compact
命令：
/compact
最佳时机：任务结束后的自然停顿点
为什么有效：
- 热缓存状态下成本极低
- 自动触发的 Compact：成本更高、丢失更多细节
结果：主动压缩比被动压缩效率高得多。
💡 当需要继承上下文时优先使用 Fork
命令：
/fork
Fork 的优势：
- 继承父会话历史
- 继承缓存
- 首次请求成本较低
对比 Subagent：
- Subagent 从冷启动开始
- 需要重新构建上下文
- 成本更高
适用场景：需要沿用已有上下文时，优先用 Fork。
Chat 与 Cowork 使用规范
✅ 经常使用的文档放入 Project
不要做：反复粘贴同样的文档
为什么：粘贴的内容会在每轮对话中被重新计费
应该做：将文档放入 Project
优势：
- 文档被索引
- Claude 仅提取相关内容
- 大幅减少进入上下文的 Token 数量
✅ 让 Claude 搜索历史聊天记录
用法：
“我们之前讨论过 X 什么内容？”
效果：Claude 从历史会话中检索相关片段，无需你重新解释背景
注意 - Enterprise 方案限制：
- ❌ Cowork 不支持记忆（Memory）
- ❌ Cowork 不支持文档化的聊天搜索能力
不要这样做（Don't Do This）
本章列出常见的 Token 浪费模式和成本陷阱。避免这些做法可以显著降低账单。
❌ 不要让一个会话贯穿一整天的多个无关主题
问题：每条消息都会为累计历史重新付费
具体影响：全天会话末尾的一句简单提问可能需要承担整天上下文的成本
成本对比：
- 8 小时对话后的一个新问题 → 重新处理 8 小时历史
- 新会话中的同一个问题 → 无历史负担
❌ 不要开启超出自己可管理数量的并行会话
问题：每个会话都有自己的缓存
缓存失效后：
- 需要全量重读历史
- 按完整写入成本计费
结果：大量闲置会话 = 频繁支付”冷启动”成本
建议：并行会话 = 你能主动维护的数量。
❌ 不要默认使用最大模型
大型模型的代价：
- 单 Token 更贵
- 消耗强度更高
- 普通任务得不到成比例的质量提升
建议：先用 Sonnet（经济），只在需要时升级到 Opus（高能耗）。
❌ 不要在任务中途切换模型、Effort 或 Fast Mode
关键概念：这些参数属于缓存键（Cache Key）的一部分
任何变更都会导致：
- 下一条消息按全价重新读取整个上下文
- 缓存完全失效
成本对比：
- 中途不切换 → Cache Hit，成本约 10% 输入费率
- 切换参数 → Cache Miss，成本 100% 输入费率
❌ 不要为简单任务启动 Subagent
Subagent 的代价：
- 重载 CLAUDE.md
- 加载自身系统提示词
- 重新读取文件
- 无法复用主会话缓存
成本数据：大量使用 Subagent 的工作流成本可达单线程会话的 4-7 倍
何时使用 Subagent：
- ✅ 输出量很大（需要独立处理）
- ✅ 并行工作（多个 Agent 同时运行）
- ❌ 简单一次性任务（用当前 Session）
❌ 不要粘贴原始日志、大文件或整个目录内容
为什么有害：
- 这些内容会永久进入上下文
- 后续所有消息都会重新计费
- 污染 Token 预算
事实：日志经过过滤后通常可缩减 80%-99%，而结果质量几乎不变
做法：
1. 先过滤（grep、jq 等）
2. 只粘贴错误相关部分
3. 后续引用即可
❌ 不要与模型反复争论
原则：修正两次仍失败，立即停止纠错。
做法：
/clear
然后重新梳理和重写提示词。
原因：
- 每轮纠错都会继续为污染上下文付费
- 长时间失败会话的浪费往往超过模型选择错误的损失
- 冷启动新会话 + 清晰提示词 < 多轮纠错
❌ 不要在 Claude 正在读写文件时手动编辑这些文件
产生的问题：
- Claude 依据旧版本工作
- 必须重新读取文件
- 需要额外轮次解决冲突
最终结果：
- 增加成本（多轮重新处理）
- 可能产生混合版本结果
- 时间浪费
建议：等 Claude 完成 → 确认结果 → 再手动编辑（如需要）
决策参考
模型与 Effort 如何选择？
| 场景 | 推荐 |
|---|---|
| 日常编码 | Sonnet + 默认 Effort |
| 重命名、模板代码、配置修改 | Sonnet + Low/Medium |
| 架构设计、复杂调试 | Opus High 或 Fable Low/Medium |
原则：在会话开始时确定，不要中途切换。
Delegate、Fork 还是新会话？
| 场景 | 推荐 | 说明 |
|---|---|---|
| 输出量大，仅需摘要 | Subagent（Haiku/Sonnet） | 减少主会话 Token 消耗 |
| 需要继承会话历史 | Fork | 复用缓存，成本低 |
| 新任务无需历史 | Handoff Brief + 新 Session | 新会话更清爽 |
| 一次性命令或小修改 | 当前 Session | 无需额外启动 |
上下文过大或会话出错怎么办？
| 场景 | 推荐 | 成本影响 |
|---|---|---|
| 错误方向但前面状态正确 | /rewind |
低 - 回退最近步骤 |
| 任务继续但历史仍有价值 | /compact |
低 - 压缩历史 |
| 任务完成或两次修正失败 | /clear |
低 - 清空开始新任务 |
影响与实施
| 维度 | 说明 |
|---|---|
| 成本 | 本规范有助于降低企业许可证下的实际使用费用（预计可降低 20-50%） |
| 培训 | 在员工入职培训阶段普及一次成本机制即可，无需反复培训 |
| 工具化 | 可通过 CI、仓库模板、托管设置等自动化措施进行落实 |
| 运营影响 | 通过人均成本监控发现需要提醒的团队，不影响生产运营 |
| 工作限制 | 无 - 不限制功能使用，只优化成本效率 |
总结
- 本规范属于指导性建议（Advisory），而非强制性限制
- 重点关注三个成本杠杆：模型选择、上下文大小、缓存生命周期
- 每项建议都有明确的成本—收益权衡
- 鼓励团队根据实际情况灵活应用