企业官网建设流程全解析

1. 从 400 到 80：账单砍掉八成到底砍在了哪里

先把结论摆在前面：一个月从 400 块压到 80 块，靠的不是换更便宜的模型这么简单，而是把"无脑全量喂上下文"这件事彻底改掉了。我刚开始用 Claude Code 的时候，习惯性地把它当成一个"高级补全工具"，每次对话都让它读整个项目、读整个文件、读一堆无关的依赖，结果就是 token 消耗像开了水龙头。第一个月账单出来 400 块，我盯着那个数字愣了半天——这还只是个人开发者的用量。

后来我花了一个周末做复盘，把每一笔消耗拆开看，发现问题集中在三个地方：上下文冗余、模型选型一刀切、重复读取同一批文件。这三件事单独看都不起眼，叠在一起就是账单爆炸的元凶。调整之后第二个月直接掉到 80 块左右，功能体验几乎没有下降，甚至因为上下文更干净，回答质量还更稳了。

这篇文章适合两类人看：一类是刚上手 Claude Code、还没摸清 token 消耗规律的开发者；另一类是已经用了一段时间、账单开始肉疼但不知道从哪下手的人。我会把每一个优化动作背后的原理、具体怎么配、实测效果都讲清楚，你照着抄作业就行。核心关键词就几个：Claude Code、API 账单、CLAUDE.md、Opus、Sonnet，这几个词贯穿全文，理解了它们之间的关系，省钱这件事就成功了一半。

需要说明的是，下面所有数字都是我自己的实测区间，不同项目规模、不同使用频率会有差异，但优化方向和比例是可以参考的。另外，本文讨论的是正常开发场景下的 API 调用成本优化，不涉及任何特殊网络手段，纯粹是使用习惯和配置层面的调整。

2. 先搞懂 Claude Code 的 token 到底烧在哪

2.1 一次对话背后其实发生了好几次 API 调用

很多人以为"我问一句、它答一句"就是一次 API 调用，其实远不止。Claude Code 在响应你的请求之前，会做一系列准备工作：读取当前工作目录结构、加载 CLAUDE.md 配置文件、检索相关文件内容、判断是否需要调用工具（比如执行终端命令、读写文件）。这些动作每一步都可能触发独立的 API 请求，而每一次请求都要把上下文重新发一遍。

这就是为什么你感觉"我只问了一个小问题"，但账单上却多了一大截。举个直观的例子：假设你的项目有 200 个文件，Claude Code 在理解你的意图时扫描了目录结构，又读取了其中 15 个相关文件，每个文件平均 300 行。光是这些文件内容，按每行约 10 个 token 估算，就是 15 × 300 × 10 = 45000 个 token 的输入。如果这轮对话来回三轮，输入 token 就要乘以三。

提示：token 消耗的大头永远是输入，不是输出。很多人优化时盯着"让它少说点"，其实方向反了，真正该控制的是"让它少读点"。

2.2 输入 token 和输出 token 的价格差了好几倍

以主流的模型定价结构来看，输出 token 的单价通常是输入 token 的 3 到 5 倍。这意味着什么呢？意味着如果你把上下文控制好，输入从 45000 降到 15000，省下来的钱远比"让它回答简短一点"要多得多。而且输入 token 是每一轮都要重新计费的，对话轮次越多，冗余上下文的代价就被放大得越厉害。

我做过一个粗略的对比测试：同一个重构任务，在"全量上下文"模式下消耗了约 12 万输入 token，在"精准上下文"模式下只用了约 3.5 万输入 token，输出 token 两者差不多。按当时的单价折算，单次任务成本差了将近 3 倍。这就是为什么我说，省钱的核心战场在输入端。

2.3 Opus 和 Sonnet 的定位差异决定了你不能一刀切

Opus 是能力最强的档位，适合处理复杂推理、架构设计、疑难 bug 定位这类"想不清楚就做不对"的任务。Sonnet 则是性价比档位，处理日常的代码补全、格式调整、简单重构、写测试用例绰绰有余。我第一个月的错误就是所有任务都用 Opus，包括"帮我把这个变量名改一下"这种 Sonnet 闭着眼睛都能干的事。

这里有个反直觉的点：不是所有复杂任务都必须用 Opus。很多看起来复杂的任务，拆解之后每一步其实都不难，用 Sonnet 分步做，总成本可能比 Opus 一次性做完还低，而且中间过程你还能干预纠偏。我现在的策略是默认 Sonnet，遇到它连续两次答偏或者明显理解不了的问题，再手动切 Opus。这个切换动作看起来麻烦，但一个月下来省的钱非常可观。

3. CLAUDE.md 写得好，等于给账单装了个阀门

3.1 CLAUDE.md 不是项目说明书，是给模型的"工作守则"

很多人把 CLAUDE.md 当成 README 的复制粘贴，写一堆项目背景、技术栈介绍。这其实浪费了它的核心价值。CLAUDE.md 的真正作用是约束模型的行为边界，告诉它"在这个项目里，你应该怎么干活、不要碰什么、优先看哪里"。写得好，模型就不会到处乱翻文件；写得差，它每次都要重新摸索，token 就哗哗地流。

我的 CLAUDE.md 里有一条很关键的规则：明确列出"核心目录"和"忽略目录"。比如src/core/是核心逻辑，node_modules/、dist/、coverage/一律不要读。就这一条，让模型每次扫描的文件数量直接砍掉一大半。因为默认情况下，它可能会去翻构建产物或者依赖包，那些内容又长又没用，纯属烧钱。

3.2 用"任务路由"规则减少无效探索

我在 CLAUDE.md 里加了一段任务路由说明，大意是：改 UI 相关的问题，优先看src/components/；改接口逻辑，优先看src/api/；改数据模型，优先看src/models/。这样模型拿到任务后，能快速定位到相关目录，而不是把整个项目从头到尾捋一遍。

这个思路的本质是把人的领域知识提前注入给模型。你比模型更清楚代码的组织结构，把这个信息写进 CLAUDE.md，它就不用靠"猜"和"试"来定位了。实测下来，同样的任务，加了路由规则之后，模型读取的文件数量平均减少了 40% 左右，对应的输入 token 也差不多降了这么多。

3.3 把常用命令和约定固化下来，避免反复解释

还有一个容易被忽略的点：每次对话你都要重复告诉它"我们用 pnpm 不用 npm""测试用 vitest 不用 jest""提交信息用中文"这类约定。这些重复的说明本身就是 token 消耗。把它们全部写进 CLAUDE.md，模型每次启动就自动加载，你就不用再啰嗦了。

我整理了一份自己的 CLAUDE.md 模板结构，大致是这样的：

# 项目工作守则 ## 核心目录 - src/core/ 核心业务逻辑，优先阅读 - src/api/ 接口层 - src/components/ UI 组件 ## 忽略目录 - node_modules/ dist/ coverage/ .next/ - 任何 lock 文件不要读取 ## 任务路由 - UI 问题 -> src/components/ - 接口问题 -> src/api/ - 数据问题 -> src/models/ ## 技术约定 - 包管理器：pnpm - 测试框架：vitest - 代码风格：见 .eslintrc - 提交信息：中文 ## 行为约束 - 修改文件前先说明改动范围 - 不要主动重构未提及的代码 - 单次读取文件不超过 5 个

最后那条"单次读取文件不超过 5 个"是我自己加的硬约束，效果出奇地好。它逼着模型先思考"我到底需要哪几个文件"，而不是一股脑全读进来。

4. 上下文管理：省钱的主战场在"少读"而不是"少说"

4.1 主动清理对话历史，别让上下文无限膨胀

Claude Code 的对话是有记忆的，你前面聊过的内容会一直带着。这在连续处理同一个任务时是好事，但如果你已经切换到新任务了，旧上下文就是纯粹的负担。我的习惯是：一个任务结束就开新对话，不要在一个会话里从早聊到晚。

有人会担心"开新对话它就不记得项目了"。不会的，因为 CLAUDE.md 会自动加载，项目的基本约定还在。真正需要延续的只是当前任务的细节，而任务都结束了，那些细节也没必要留着。我算过一笔账：一个持续 20 轮的会话，如果中间切换了 3 个不相关的任务，光是旧任务的上下文残留，就可能多消耗 30% 以上的 token。

4.2 用精准的文件引用代替"读整个目录"

当你需要模型看某个文件时，直接给出文件路径，而不是说"看看 src 目录下的代码"。前者它只读一个文件，后者它可能把整个目录都扫一遍。这个差别在小项目里不明显，在几百个文件的项目里就是天壤之别。

我现在的习惯是，提问时尽量带上具体路径，比如"帮我优化src/api/user.ts里的fetchUserProfile函数"，而不是"帮我优化用户相关的接口"。前者模型目标明确，读取范围可控；后者它得先自己找"用户相关"是哪些文件，这个寻找过程就是消耗。

4.3 长文件先摘要再处理，别整篇塞进去

有些文件就是很长，比如一个 2000 行的工具库。这种情况下，直接让模型读全文非常浪费。我的做法是先用 Sonnet 让它生成一个结构摘要，然后基于摘要讨论要改哪部分，最后只把需要改的那一段拿出来精读。这样把一个 2000 行的文件拆成"摘要 + 局部"，token 消耗能降到原来的三分之一甚至更低。

这个思路可以类比成查字典：你不会为了查一个词把整本字典背下来，而是先看目录、再翻到具体那一页。模型处理长文件也应该这样，先看结构、再定位细节。

注意：摘要这一步本身也要花 token，所以只对确实很长、且需要反复引用的文件做。短文件直接读反而更划算。

4.4 善用"只读必要行"的技巧

Claude Code 支持读取文件的指定行范围。当你明确知道问题出在某个函数的某几行时，直接指定行号范围，比读整个文件省得多。比如"看utils.ts的第 120 到 180 行"，而不是"看utils.ts"。这个技巧在处理大型配置文件、日志文件时特别有用。

我处理一个 3000 行的配置文件时，就是先让它看前 50 行了解结构，然后直接跳到出问题的那一段。整个过程读取的行数不到 200 行，如果整篇读，就是 15 倍的差距。

5. 模型选型策略：什么活派给 Sonnet，什么活留给 Opus

5.1 一张表说清楚任务和模型的匹配关系

我把日常任务做了个分类，对应到模型选择上，实测下来这套匹配基本不会出错：

这张表的核心逻辑是：能用规则解决的事不给 Sonnet 之外的模型，需要判断和推理的事才上 Opus。我第一個月所有任务都走 Opus，相当于用高射炮打蚊子，钱就是这么没的。

5.2 分步拆解：把 Opus 的活拆成 Sonnet 能干的活

有些任务看起来必须 Opus，但拆开之后每一步 Sonnet 都能胜任。比如"重构这个模块"，直接丢给 Opus 它要一次性想清楚所有依赖关系，消耗巨大。但如果拆成"先分析依赖关系（Sonnet）→ 再设计新结构（Opus，只处理设计这一小步）→ 再逐步实施（Sonnet）"，总成本反而更低。

因为 Opus 只在"设计"这一步出场，输入上下文可以控制得很小，输出也就是一个设计方案。而实施阶段虽然步骤多，但每步都简单，Sonnet 完全够用。我做过对比，同样一个中等规模的重构，全 Opus 方案花了约 8 万 token 的 Opus 用量，拆解方案只花了约 1.5 万 token 的 Opus 用量加 4 万 token 的 Sonnet 用量，折算下来便宜了一半多。

5.3 遇到 Sonnet 答不好，先别急着切 Opus

Sonnet 偶尔会答偏，这时候很多人的第一反应是"切 Opus"。但更省钱的做法是：先看看是不是你的提问方式有问题。Sonnet 对模糊指令的容忍度比 Opus 低，你把问题描述得更具体、把相关代码贴得更精准，它往往就能答对了。切 Opus 是最后手段，不是第一反应。

我的经验是，Sonnet 连续两次答偏，才考虑切 Opus。而且切换时，把前面 Sonnet 的尝试结果作为背景告诉 Opus，让它"在已有基础上修正"，比让它从零开始更省。因为从零开始意味着它要重新理解一遍问题，又是一笔输入开销。

6. 那些让我多花冤枉钱的操作习惯

6.1 让模型"先看看整个项目"是最贵的坏习惯

新手最容易犯的错，就是上来就说"你先看看我的项目结构"。这一句话可能触发几十次文件读取，token 瞬间飙升。正确的做法是：你自己先想清楚要它看什么，直接给路径。项目结构这种事，你自己心里有数就行，不需要让模型也从头摸一遍。

我第一个月就干过这事，一个下午让模型"熟悉项目"就烧掉了差不多 50 块钱。后来想想，那 50 块钱买到的信息，我自己花十分钟就能整理出来写进 CLAUDE.md，而且写进去之后还能反复用。

6.2 反复粘贴同一段代码

有些人习惯把代码复制粘贴到对话里，而不是让模型去读文件。如果这段代码要反复用到，粘贴一次就是一次输入消耗，粘贴十次就是十次。而如果它在文件里，模型读一次之后，后续对话可以引用，不用重复读。

当然，如果只是临时贴一小段，粘贴反而比让模型读整个文件省。关键看这段代码是不是"反复出现"。反复出现的，放进文件让模型读；一次性的，直接粘贴。

6.3 在错误的时机开新对话

开新对话的时机也有讲究。任务切换时该开新对话，但同一个任务的连续追问不该开。有些人一遇到模型答得不好就开新对话重来，结果每次都要重新加载上下文，反而更贵。正确做法是：同一个任务内，用追问的方式引导模型修正；只有任务彻底变了，才开新对话。

6.4 忽略缓存机制的存在

Claude 的 API 有 prompt caching 机制，对于重复出现的上下文（比如 CLAUDE.md、固定的系统提示），缓存命中后的计费会便宜很多。这意味着保持 CLAUDE.md 稳定本身就能省钱。如果你频繁改动 CLAUDE.md，缓存就失效了，每次都要按全价计费。

所以我的建议是：CLAUDE.md 的内容尽量稳定，把不常变的部分（技术约定、目录结构）和常变的部分（当前任务备注）分开。常变的部分不要写进 CLAUDE.md，放在对话里说就行。

7. 我的完整配置和一个月实测数据

7.1 最终落地的配置清单

经过一个月的调整，我现在的配置大致是这样的：

• 默认模型：Sonnet，覆盖 80% 的日常任务
• Opus 触发条件：复杂 bug 定位、架构设计、Sonnet 连续两次答偏
• CLAUDE.md：包含核心目录、忽略目录、任务路由、技术约定、行为约束五部分，保持稳定
• 对话管理：一个任务一个会话，任务结束立即开新会话
• 文件读取：优先指定路径和行范围，长文件先摘要
• 上下文清理：切换任务时主动清理，不依赖自动记忆

7.2 一个月前后的账单对比

从数据能看出来，省钱的贡献几乎全部来自输入端和模型选型，输出端没什么变化。这也印证了前面的判断：控制输入才是省钱的核心。

7.3 几个容易被忽略的细节

第一个细节是时段的利用。如果你的任务不紧急，可以安排在非高峰时段处理，部分平台在低峰期有更优惠的计费。这个不是所有平台都有，但值得留意。

第二个细节是批量处理。如果你有一批类似的小任务（比如给十个文件加注释），不要一个一个来，而是合并成一次请求，让模型批量处理。这样上下文只加载一次，比十次单独请求省得多。

第三个细节是定期复盘账单。我现在的习惯是每周看一眼用量明细，看看哪类任务消耗最多，有没有异常。有一次我发现某个任务消耗特别高，一查是模型误读了一个巨大的日志文件，及时调整了忽略规则。

8. 关于省钱这件事，我踩过的几个认知误区

8.1 "用便宜模型就是省钱"是错的

省钱不等于用最便宜的模型。如果一个任务 Sonnet 做三次都做不对，最后还得 Opus 来收场，那前面三次 Sonnet 的钱就白花了，总成本反而更高。正确的思路是用"刚好够用"的模型，而不是"最便宜"的模型。判断标准很简单：这个任务 Sonnet 一次能做对的概率有多高？高就用 Sonnet，低就直接上 Opus。

8.2 "上下文给得越多，回答越准"也是错的

很多人觉得给模型的信息越多，它理解得越全面，回答越好。实际上，无关信息会稀释关键信息，反而让模型抓不住重点。我实测过，把无关文件去掉之后，模型定位问题的准确率反而提升了。这就像你跟人解释一件事，说一堆背景反而让人抓不住重点，直接说核心问题对方秒懂。

8.3 "省钱会牺牲体验"这个前提本身就不成立

我一开始也担心，控制上下文、切换模型会不会让体验变差。实测一个月下来，体验不但没变差，反而更好了。因为上下文干净了，模型不容易被干扰；任务拆解了，每一步都可控；模型选对了，回答质量更稳定。省钱和好用在这件事上并不矛盾，矛盾的是"懒"和"省"——懒得整理上下文、懒得切换模型，才是账单高的真正原因。

8.4 别把 CLAUDE.md 当成一次性工作

CLAUDE.md 是需要持续迭代的。每次你发现模型在某个地方反复出错，或者反复问你要同样的信息，就应该把对应的规则补进 CLAUDE.md。我现在的 CLAUDE.md 已经迭代了十几版，每一条规则背后都是一次真实的踩坑。它越完善，你后续的每一次对话就越省。

9. 写在最后的一点个人体会

这套方法我用了两个月，账单稳定在 80 块上下，偶尔任务多的时候到 100 出头，但再也没回到过 400。更重要的是，我养成了"先想清楚再问"的习惯，这个习惯本身对写代码也有帮助——很多问题在整理上下文的过程中就自己想明白了。

如果你现在账单还高，别急着换工具或者找什么"省钱秘籍"，先把 CLAUDE.md 写好，把模型选型策略定下来，把对话管理习惯改掉。这三件事做到位，账单自然就下来了。至于具体能省多少，取决于你的项目规模和使用频率，但方向是确定的：省钱的本质是减少无效信息，而不是降低工作质量。

最后分享一个小技巧：我会在 CLAUDE.md 里放一行"当前项目阶段"的备注，比如"正在做用户模块重构"，这样模型每次启动就知道当前重点，不用我反复解释。这个备注我会定期更新，但更新频率很低，基本不影响缓存。这个习惯帮我省下了不少重复解释的口舌，也省下了对应的 token。