企业官网建设流程全解析

上个月排查一起线上接口超时，我顺手看了一眼 Claude Code 的 token 统计，整个人都不好了。一个我认为只花了两小时的修复，实际消耗的输入 token 接近 8000 万，折算下来比其他同类工具贵了好几倍。查来查去，问题不在我的代码，而在 Claude Code 的默认行为：上下文要一直攒到大约 96 万 token 才触发压缩。这个设计对长任务很友好，但对钱包很不友好。

后来我参考一个社区里流传的算账方法，把每周额度和压缩阈值调到了 40 万 token，跑了两个星期，同样类型的活，账单降了接近三成。这篇文章就把这笔账掰开揉碎讲清楚：96 万是怎么来的、40 万改的是什么、怎么改、以及哪些场景千万别无脑抄。

1. 为什么默认能“聊到 96 万 token 才压缩”：先搞懂上下文是怎么长大的

1.1 上下文不是流水账，而是每次请求的“参演名单”

很多刚开始用 Claude Code 的人会有一个误解：上下文是“记忆”，像人脑一样，记住最近聊了什么就行。实际上不是这样。Claude Code 的上下文是每次请求都要带上台的全部材料，相当于每次开会都要把历史纪要、全部附件、上一轮的笔记重新读一遍。

举个例子。你让它改第 10 个文件，它处理这个文件时，输入里除了你刚说的“把超时时间改成 3 秒”，还包括前 9 个文件里的代码、前面所有工具执行结果、报错信息，甚至包括你最早说的“这个项目是处理订单状态的”。它不会像人一样凭印象干活，而是每次调用模型都要把整段历史原样送进去。

这也解释了为什么 token 会涨得这么快。你以为自己在对话，实际上每次请求都在“重放”整个会话。越到后面，单次请求的输入 token 越大，费用也越高。很多人看账单只看到“调用次数”，却忽略了每次调用背后的上下文体积。

1.2 96 万这个数字是哪来的：百万级窗口与安全余量

Claude 家族的大模型目前支持百万级的上下文窗口，Claude Code 默认就会尽量用满这个窗口，直到接近上限才做压缩。大约 96 万 token 触发压缩，不是随便拍出来的数字，而是给窗口留出了“安全余量”。

你想想看，如果上下文真的到了 100 万再压缩，那模型输出的时候窗口已经满了，回复都可能写不下。所以它会在 96 万左右就动手，预留约 4% 的空间给新输出。从机制上讲，这个设计特别合理：尽可能保留原始信息，让模型在长任务里有完整的上下文，减少“失忆”带来的返工。

问题在于，这个设计没有考虑成本曲线。上下文从 1 万涨到 96 万的过程里，每一次请求的输入都在变大，费用也在加速上涨。到 90 万 token 时，一次请求的输入成本已经是 10 万 token 时的 9 倍。默认策略保证了任务质量和完整度，但它是以“尽量不压缩”为优先级的，对成本几乎不敏感。

2. 这笔账到底怎么算：从 96 万压到 40 万，为什么会省近三成

2.1 先搭一个算账模型

要搞清楚 40 万阈值为什么省钱，我们得先搭一个简化的计算模型。模型不需要精确，只需要能量级正确，能说明趋势。

我拿一个典型的跨 20 个文件重构任务来举例。假设整次任务一共发生 800 次请求，每次请求会产生大约 2000 token 的新增内容，其中用户输入约 500 token，模型输出和工具返回约 1500 token。这个数字在实际开发中会波动，但量级是合理的。

价格方面，我按输入每百万 token 3 美元、输出每百万 token 15 美元的量级来估。不同渠道价格有差异，但比例关系是一致的，不影响后面的结论。

2.2 默认策略下的 token 消耗

默认策略下，上下文从 0 开始增长，到 96 万触发压缩。800 次请求里，前 480 次左右把上下文从 0 推到了 96 万，每次请求的平均上下文约 48 万，输入 token 消耗 480 × 48 万 = 2.304 亿。

触发压缩后，模型会把之前的对话内容提炼成一份摘要，假设这份摘要加上系统提示和工具定义总共约 5 万 token。接下来剩下 320 次请求，上下文从 5 万继续增长，到 69 万左右，平均约 37 万，输入消耗约 1.184 亿。

两次加起来，输入 token 约 3.488 亿。输出方面，800 次请求的正常输出约 120 万 token，压缩摘要输出约 5 万 token，总共约 125 万。按前面的单价估算，总费用在 1200 美元上下。

这里最扎眼的是：3.488 亿输入 token 里，绝大部分是历史的反复重放，而不是真正的新信息。

2.3 40 万阈值下的 token 消耗

把压缩阈值改成 40 万之后，情况完全不同。同样 800 次请求，上下文每攒到 40 万就压一次，压缩后从 10 万左右重新开始增长。

我重新算了四次分段：第一次从 0 到 40 万，平均 20 万，200 次请求，输入约 4000 万；压缩后从 10 万再涨到 40 万，平均 25 万，大约 150 次，输入约 3750 万；第三次、第四次同样如此。最后还剩余约 150 次请求，平均输入约 25 万，输入约 3750 万。

总输入约为 4000 + 3750 × 3 + 3750 = 1.9 亿 token。压缩摘要触发了 5 次，输出约 25 万 token，正常输出还是 120 万。总费用算下来约 650 到 700 美元，和默认策略的 1200 美元相比，理想节省大约 45%。

2.4 理想节省 45%，实测为什么只有“近三成”

如果只看上面的模型，你会觉得应该接近省一半，但实际能省到 30% 就已经不错了。问题出在“压缩有代价”这件事上。

每次压缩都是一次信息有损操作。模型把 40 万 token 的详细历史压成几千字摘要，很多细节必然丢失。压缩之后，你经常需要重新补充上下文，比如告诉它某个文件里的接口定义是什么，或者提醒它之前定下的命名规范。这些额外的补充输入，都是默认策略下不需要花的。

更麻烦的是，压缩后模型偶尔会“假装记得”。有一次它压缩后忘了之前改过的函数签名，还继续按旧签名写代码，等测试报错才发现，来回折腾了三轮。这种重试成本很难量化，但在长任务里非常常见。

所以我把理想模型和实际情况的差距拆成三块：一是压缩摘要本身的输出成本被低估了，摘要不是免费的；二是压缩后用户要补充说明，额外输入约增加 10% 到 15%；三是压缩导致的返工和重试，让请求数增加了 20% 左右。三块加在一起，理想节省 45% 就被稀释到 30% 上下，和标题里说的“近三成”基本吻合。

3. 实际操作：把阈值和额度改到 40 万的几种做法

3.1 改配置的通用路径

先说最重要的一句话：不同版本、不同平台的 Claude Code 配置项名称不完全一样，我下面给的是通用思路，具体字段以你本地的提示为准。

我用的是用户目录下的配置文件，里面能看到 context 和 budget 两个区块。context 区域里有一个和“压缩阈值”相关的字段，我把它从默认值改成了 400000，单位是 token。budget 区域里有一个“每周额度”之类的字段，我也改成对应的 400000，避免单周超额。

如果你找不到这两个字段，可以在 Claude Code 的交互界面里输入 /config，大部分版本会把上下文管理选项做成可视化菜单，里面有 Context Management 或类似名称的一栏。选中后直接把阈值改成 400000 就行。

注意：改配置之前最好备份原文件，改动后也先跑一个小任务验证，不要直接拿正在进行的重构任务做测试。压缩阈值改坏了最坏的结果是上下文频繁被压，任务逻辑全乱，到时候连排查都无从下手。

3.2 环境变量方案：适合脚本化和多机器管理

如果你习惯把 Claude Code 接入自动化脚本，或者在多台机器上同步配置，环境变量方案会更顺手。在启动 Claude Code 之前，把与上下文限制、预算限制相关的参数通过环境变量传进去。

具体可以用这个命令检查当前已经生效的变量：

env | grep -i claude

你会看到一堆 CLAUDE 开头的变量。找到上下文管理相关的那几个，在 shell 配置文件或启动脚本里添一行，把它设成 400000。建议你在 .bashrc 或 .zshrc 里一次性写死，这样每次打开终端都自动生效。

我自己的习惯是在项目根目录放一个.env文件，启动脚本里用set -a加载，这样每个项目可以有不同的压缩阈值策略。比如一个小工具项目我用 30 万，一个大型重构项目我用 60 万，比全局统一配置灵活得多。

3.3 验证阈值是否生效

改完配置别急着干活，先确认阈值真的变成了 40 万。我建议做一个最短验证流程：起一个新会话，随便让它写一段 300 行的代码，然后查看当前的上下文大小。

Claude Code 里可以用 /context 或类似命令查看当前会话 token 数，具体命令不同版本有差异。确认它显示的上下文总量和剩余空间和改之前不一样，说明配置已经生效。更直接的办法是故意快速积累大量上下文，触发一次压缩，看压缩发生时上下文是否在 40 万附近。

刚开始我犯过一个错：只改了每周额度，以为压缩阈值也会跟着变。结果账单降得不明显，一查才发现压缩阈值还是默认的 96 万，额度只是做了硬性限制，任务做到 40 万直接被拦停，反而更痛苦。这两个配置要拆开理解：额度是“刹车”，阈值是“早转快转”，省钱主要靠阈值提前。

4. 阈值调低不等于白捡钱：压缩的代价和适配场景

4.1 便宜但有代价：一个真实的翻车案例

阈值调低确实便宜，但它不是免费的。有一次我接了一个本地项目，需要跨 12 个模块改公共状态管理逻辑。这个任务特别依赖全局记忆：前面改过哪个模块、新架构里状态树长什么样、哪些旧接口被废弃，每一步都建立在上一步的基础上。

我当时为了省钱，把阈值调到了 25 万。结果第一个模块还没改完，上下文就触发了压缩。摘要里把架构调整方向写清楚了，但丢了具体几个文件里旧的调用链。后续模型开始一本正经地写不存在的接口，编译立刻报错。我花了大半天排查，反复补上下文，最后不仅没省到钱，还比默认策略多花了 20% 的 token。

这个案例给我一个很深的教训：上下文是任务的“工作记忆”，压缩就是让你失忆。失忆后你可以靠外部笔记补，但补记忆的过程也有成本。对于强依赖长期记忆的任务，阈值不是越低越好，而是要找到一个平衡点。

4.2 适合调低阈值的任务画像

经过两个星期的实测，我总结出三类特别适合低阈值的任务。

第一类是相互独立的批量小任务。比如批量修正代码格式、给多个函数补注释、把一堆 JSON 换成 YAML。这类任务本身不依赖前面改过的内容，压缩后丢一点历史也没关系，反正下一步是独立文件。

第二类是单文件深度修改。只改一个文件时，上下文里最有价值的就是这个文件本身，而它会被反复读取和重写，压缩阈值低一点影响不大。我经常把这种任务的阈值压到 20 万到 30 万，实测很稳。

第三类是代码解释、文档生成、知识问答这类“读多写少”的场景。任务目标是理解代码生成文档，不需要跨文件的长期一致性，压缩丢一些细节反而更容易提炼重点。

4.3 不适合的任务画像：这些场景请把阈值调高

和上面相反，有四类任务我建议保留较高阈值，别盲目抄 40 万。

跨文件大规模重构是最典型的一种。多个文件互相依赖，模型必须同时记得 A 文件的导出、B 文件的引用、C 文件的旧逻辑，任何一环断裂都可能让整个重构变成灾难。

长链路调试也是高危场景。从现象反推到根因往往要跨越十几次工具调用，每次调用结果都是推理链条的一部分。压缩会把中间结果浓缩掉，等于把侦探故事的最后三页撕了。

还有涉及架构决策的任务，比如设计新模块、规划数据模型、评估技术方案。这类任务的信息密度高，且决策往往分布在上百次请求里，前后呼应的细节非常多。压缩后哪怕丢一个“当时为什么选 A 不选 B”的原因，都可能让方案跑偏。

最后是长时间会话配合外部记忆物质导入。如果你已经往上下文里塞了大量参考资料，压缩会把这部分资料当成普通文本摘要掉。参考资料的价值恰恰在原文细节，摘要一出来，参考价值就没了。

4.4 已踩坑的人怎么办：手动压缩 + 外部记忆组合拳

如果你已经在低阈值下踩了坑，别急着把阈值改回去，可以先试着用手动压缩和工作区笔记来弥补。

Claude Code 支持手动压缩命令，我平时会在任务阶段告一段落时主动执行一次，而不是等阈值自动触发。手动压缩的好处是你可以选时机：两个模块之间、逻辑相对完整的节点。这时候压缩产生的摘要质量高，信息丢失少。

我还会在项目根目录放一个progress-notes.md，把架构决策、已改文件清单、剩余任务、已知坑位都记进去。每次压缩后，我会让 Claude Code 先读这个笔记，再继续干活。这等于在外部建了一个“备份记忆”，压缩把内部工作记忆清掉后，外部记忆还在。

实际操作下来，这个组合比单纯调高阈值还省钱。因为它减少的是“上下文里塞太多重复内容”的问题，而不是靠降低压缩频率来硬扛。

5. 实测两周的数据、感受和值得抄的作业

5.1 两周前后的账单对比

我用两周时间做了对比实验。第一周保持默认 96 万压缩策略，第二周把阈值和额度都改成 40 万，任务类型基本一致，都是日常的代码编写、Bug 修复和小型功能开发。

结果如下：第一周总输入 token 约 2.1 亿，输出约 900 万，压缩触发 1 次，总费用约 750 美元。第二周总输入 token 约 1.4 亿，输出约 1100 万，压缩触发 4 次，总费用约 540 美元。节省幅度约 28%。

注意输出 token 反而增加了，原因就是压缩更频繁，每次压缩都要先生成一段摘要。但输入 token 从 2.1 亿降到 1.4 亿，这个量级的降幅远超摘要花掉的成本，所以整体还是省了。

5.2 心得一：按任务类型分批跑，别让一个会话背负所有上下文

改完阈值后我发现一个更重要的问题：上下文里塞了太多不需要的东西。有时候一个会话从早上写到晚上，前面解决的是 A 模块，后面切换到 B 模块，中间还顺手查了两个报错。结果整个上下文 70% 的内容和当前任务无关。

压缩阈值调得再低，也只是在“已经攒了很多垃圾”的前提下做减负。真正的省钱方法是按任务类型分批跑：一个会话只做一件事，做完立刻新开一个会话。新会话的上下文干净，一上来就是 0，根本不需要压缩。

我自己现在的习惯是：每个独立功能开一个会话，中间切换任务就用/clear或类似命令清理上下文，把重要的结论写进 progress-notes.md，下个会话直接读笔记。这比调阈值更有效，两个方法叠加之后，第二周的输入 token 其实已经低到接近理论下界。

5.3 心得二：压缩后花 30 秒做一次“状态核对”

刚开始调低阈值时，我经常一看到“上下文已压缩”的提示就继续往下走，结果经常发现它把关键文件内容搞丢了。后来我养成了一个习惯：每次压缩后，先让它用三句话总结当前状态，包括任务目标、已完成部分、下一步计划。

如果它把某件事说错了，我立刻纠正，花 30 秒补全。这个核对动作的成本很低，但能省掉后面几小时的返工。你可以在压缩后直接问：“基于当前上下文，你认为我们接下来要做什么？有没有已知的约束条件？” 看它回复和你记忆中的差异即可。

这个做法本质上是在确认压缩摘要的质量。摘要质量高，后面的任务就顺；摘要质量差，你必须尽早干预，而不是等问题在代码里暴露后再回头查。

5.4 心得三：阈值不是越低越好，40 万只是我的平衡点

最后说说 40 万这个数字。它不是金科玉律，只是我试出来的平衡点。我把阈值从 96 万降到 80 万、60 万、40 万、25 万、15 万分别跑过几天，结果挺有意思。

15 万到 20 万区间，压缩次数太频繁，经常一个文件还没改完就压一次，摘要输出成本开始反超省下的输入成本，总费用反而上升。25 万到 40 万之间，费用下降最明显，而且任务质量没有明显下降。50 万到 80 万区间，费用比 40 万高一些，但长任务的成功率高不少，适合复杂重构。

如果你日常任务比较重，我建议从 60 万起步，观察一周费用和返工频率，再慢慢压到 40 万或更低。如果你只是写写小脚本、改改配置文件，25 万也能跑得很舒服。关键是记录你自己的数据，不要直接抄我的结论。

根据我个人的实际体验，压缩阈值这件事最值得做的不是马上改成 40 万，而是先搞清楚现在的上下文到底是从哪里涨上去的。下次你扫一眼账单时，如果发现输入 token 高得离谱，九成是历史重放的成本，而不是模型真的写了复杂代码。这时候再动手把阈值压低，顺便把无关上下文清掉，你会回来感谢那笔账。