省积分 · 四个根治方法详解

成本 = 请求次数 × 当时上下文体积。历史只增不减、输出永久驻留、每轮全量重发 ——
四个方法分别打在这个链条的不同环节上。

先纠正一个口径：第 1 轮「只产生 27 万 token」吗？

实测同一个会话（443 次带 usage 的模型请求）：

27 万（269,522）= 第 1 轮结束时上下文的绝对体积。这是"水位"，只算一次。
1,090 万（10,906,992）= 第 1 轮实际计费的 input 合计。101 次请求，每次都把当时的全部历史重发一遍。
⇒ 两者差 40 倍。
而第 1 轮在全量 1.93 亿里只占 5.6% —— 它的问题不是"贵"，是把水位顶起来了。
真正最贵的是第 11、12 轮：22.0% + 18.4% = 40.4%。它们在 68 万的水位上，各跑了 66 / 55 次请求。

⇒ 「顶水位」（第 1 轮）和「在高水位上跑请求」（第 11/12 轮）是两件事，后者更贵。

方法 ①

批量活写脚本

打在：请求次数

干什么	同质的小改动（清注释、改文案、换版本号、批量改名）不逐处 Edit，写一个脚本一次做完。
触发条件	同一会话内对同一文件 ≥3 次编辑，或待办本身是"同类 × N 处"。
为什么根治	一次工具调用在历史里留两条记录（入参 + 结果），后续每一轮都要重发。把 N 次编辑压成 1 次 ⇒ 历史里的工具痕迹从 2N 条降到 2 条，且不再随轮数放大。
实测	出事那轮：101 次请求、142 次文件编辑、179 次命令，只为清 96 处同类注释。改成 1 个脚本 ⇒ 请求数可降到个位数级别。
现状	未实现 —— 属"操作纪律"，不是硬门禁。
代价	脚本要写对；一次动的地方变多 ⇒ 必须先 dry-run + 备份。写错的话影响面比逐处改大。
落地	写进根 `CODEBUDDY.md` 的操作纪律；钩子里对"同文件第 3 次编辑"给提示。

收益量级：单轮请求数 101 → 10 上下，该轮计费量随之腰斩再腰斩。

方法 ②

打在：每次请求的体积

干什么	硬门禁（`PreToolUse`）拦 6 类高置信度命令： `cat` 大文件（>200 KB）· `ls -R` · `find <根>` 无 `-maxdepth` · `journalctl` 无 `-n/--since` · `dmesg` 无 head · `Read` 超大文件（>400 KB）
放行什么	一切带管道的写法（`\| head` / `\| grep` / `\| wc -l`）——输出已被下游截断，不构成风险。
为什么根治	上下文体积只增不减。一条 2 MB 输出进去，就永久占 2 MB，再乘以后面每一次请求。 ⇒ 拦一条 = 省 `字符数 ÷ 2.11 × 剩余请求数` 的 token。
实测	回放 4,053 条真实命令：误拦率从 1.63% 收到 0.05%（2 条，且都是真阳性）。
现状	已上线 —— 配置已挂 `Bash\|Read`，完全重启后生效。
代价	低。带 `DSH_OUTPUT_GUARD_OFF=1` 应急开关；三档 soft / hard / off 可切。
落地	无需额外动作，重启即生效。

这是唯一在"灌进去之前"就把体积掐掉的手段，其余三个都是事后收敛。

方法 ③

打在：高水位段的请求次数

干什么	软告警（`UserPromptSubmit` 钩子）：读本会话 usage，当"当前体积"或"单轮工具调用次数"越线时，向下一轮注入一句话 ——「本轮已 66 次调用、水位 68 万，请收敛成一个脚本 / 一次批量操作」。
为什么根治	①② 降的是每次请求的体积，③ 降的是请求次数。成本 = 次数 × 体积，两个都要压。
实测	第 11 轮：66 次请求 × 64 万水位 = 4,247 万（占全量 22%）。同轮若收敛到 10 次请求，量级掉到 640 万左右 ⇒ 省下全量的约 19%。
现状	未接入 —— 钩子本体已存在，限流提示被取消，尚未接回。
代价	提示本身占约 50 token，可忽略；但它只是"劝"，AI 不理会就无效 ⇒ 软约束。
落地	把 `stop-dialog-guard.py` 的 `budget_note()` 重新接上（改一个 if 条件）。

它治的是"在水位已经很高时还猛跑请求"这个最贵的模式。

方法 ④

打在：让体积归零

干什么	一个需求一个会话。需求闭环就新建会话，不开"万能长会话"。
为什么根治	这是唯一能让上下文归零的手段。历史是 append-only，AI 无权删自己的历史 —— 所以在一个 59 万水位的会话里"少说两句"完全没用，体积不会降一分。
实测	目标会话末段水位 593,510。有几轮指令只有几个字（如"推送"），却仍要重发 49.8 万 token；那一轮 9 次请求合计 443 万 input，就为了推一次代码。
现状	纯纪律 —— 无工具强制；跨会话靠 `session-handoff/` 交接单。
代价	开会话要读交接单（几十 KB 一次），会话内上下文会丢 ⇒ 交接单必须写全。
落地	写进 `CODEBUDDY.md`：一个需求一个会话；闭环即新建。

前三个是"别让水位涨太快"，这一个才是"把水位倒掉"。

① 批量活写脚本少留痕迹 —— 从源头减少历史条目

② 拦大输出别灌垃圾 —— 挡住单条巨型输出

③ 命令限流高位少跑 —— 压住高水位段的请求数

④ 切会话及时倒水 —— 唯一能归零的动作

共同根因：历史只增不减，工具输出永久驻留，每轮全量重发。 ①②③ 在会话内减缓累积，④ 才是重置。会话内解决不了根因本身 —— 那要靠平台的压缩策略。

数据来源：目标会话转录逐条统计（443 次带 usage 的模型请求）｜折算比 2.11 字符/token