企业官网建设流程全解析

文件名：tokens 消耗 20260927.md
版本：v6（2026-09-27）· 定稿
性质：原始会话 transcript 的解释层，第一人称自述
来源：02_领域/编程/Harness/tokens 消耗 20260927.md（117,410 B / 1505 行，原文一字未动）
版本演进：v1（685 行）→ v2（799 行）→ v3 → v4（710 行·完整版）→ v5（621 行）→ v6（本次修订）
凭证存档：_ai_drafts/tokens 消耗 20260927（自述版·完整版 v4）.md，保存源码片段、完整哈希表和全部原始细节
本文件大小/哈希：在交付汇报中给出；文件不能包含自身最终哈希值
核验数据：见附录 D，本版全部指标重新核验，不直接继承旧版本结论

〇、写在前面：为什么叫「实践」，而不是「失误」
这篇文档，我把原来标记成「失误」的三章，全部重命名为「实践」。

这不只是换个词玩文字游戏，评判标准本身变了。

以前我理解的失误：一件事本来可以一次做对，但我没做到。潜台词是存在唯一标准答案，我没能拿到，相当于做错了、有亏欠。

现在想法不一样了。探索实验本身，就会试错。出错不可耻，定位问题、动手修复才是核心。反复试跑，才能分清哪些路径可行、哪些走不通。我不想只看别人的 PPT、视频，纸上谈兵，必须亲自跑一遍。实践是检验真理的唯一标准。

落到这次 token 消耗排查上，最核心的因果：

纸面推演只能得到「看起来合理」的猜想；动手跑起来，才能拿到真实反馈。

文中所有硬数字——57.1M、0.57%、176.8 倍、WinError 5、!!js 标签、pruner 的剪枝-重测-摘要三段逻辑，没有一个是靠脑补算出来的，全是踩坑踩出来的真实结果。

事实不变，只是换一套理解这件事的框架：错是客观发生的事实，实践是我们看待这件事的框架。

〇.1 两条基本判据
判据一：修订解释文本时，只调整措辞，不改动实测数字和底层机制描述。任何机制说明，都要能追溯到源码行号或者会话日志。

判据二：表格里每一个数字，都要标注「实测」或者「预估」；不带标签，一律视作估算值。

〇.2 错误点统计
版本 漂移处数 问题落点
v2 12 处 机制描述 10 处 + 口径/算术混淆 1 处（132.3 和 176.8 混为一谈）+ 标签错误 1 处（写「占比（估）」）
v3 4 处 机制描述 2 处 + 凭证引用 1 处 + 标注错误 1 处（把预估 −76% 写成实测）
v4 精简稿 7 处 可核验信息被删掉 3 处（哈希值、四态归档链、正误对照）；内容被替换 3 处；文件名引号书写错误 1 处
v5→v6 5 处 表头颠倒 1 处；自引用哈希 1 处；锚点标签 2 处；错误继承旧核验结果 1 处
结论：没有一处错误出在原始数字本身。

→ 数字比文字描述、机制解释更稳定。所有关于机制的表述，都必须能回查到源码或者原始日志。

一、结论先行
项目 数值 标记 来源
会话到 185 步时，单次会话输入总量 57.1M token 实测 会话日志
有效信息占比 0.57% 实测 322,952 ÷ 57,105,160
占比的倒数 176.8 倍 实测 57,105,160 ÷ 322,952
131 步时点，单步平均倍数 132.3 倍 实测 261,005 ÷ 1,972
根因 五套上下文治理机制全部没有挂载 — 源码 + 日志
预估可削减规模 从 33.3M 降到约 8M，减少约 76% 预估（双重外推，没有实跑） 未实测
下一步处置第 0 步 新开会话，先启用 custom-ctx — 见第八节
状态 方案已经定好，还没实际跑起来 — —
注意：这两个倍数不能混为一谈。132.3 倍是「单步平均」口径；176.8 倍，是按有效占比算出来的口径。

−76% 只是预估，从来没有实测验证。提到 57.1M，必须带上步数说明：见附录 A，185 步。

标签这一列，只用来标记数字，不写多余描述。

二、统计口径说明
输入总量 = 每一次请求里 prompt 的累加。

这是无状态 API 天生的特点：每发一次请求，都要把完整上下文一并提交，不是系统自动做了什么额外操作。

账单 vs 上下文窗口：99.2% 的 token 消耗属于缓存读（cacheRead），缓存把实际账单压得很低；真正的硬约束，是 1M 的上下文窗口。

不要简单说成「99% 都浪费了」，容易造成误解：被占用的是窗口容量，不是计费 token。

三、钱（token）都花在哪了
来源 实测值 占比 分母 标记
第 1 步基础 prompt（初始底板，含系统提示、工具 schema） 10,210 tok 4% 总输入量 33.3M 实测
持续累积、反复重发的上下文 — 96% 总输入量 实测
├ 助手历史回复正文 395,333 字符 — — 实测
├ 工具返回结果 329,914 字符 — — 实测
│ └ 其中 read 读取结果占工具返回的 71% — 71% 工具返回总字符 实测
├ 工具调用参数 177,263 字符 — — 实测
└ 思维链内容（不计入模型输出） 78,550 tok — — 实测
用户发出消息 21,094 字符 2% 上下文总字符 实测
⚠️ 71% 和 96% 不能直接对比，二者分母不一样：前者分母是工具返回内容，后者分母是全部输入 token。

最大的优化杠杆在 read 调用，它占全部工具返回结果的 71%。

四、根本原因：治理机制全都没挂上
问题不是 custom-ctx 反复全量重注入——本次会话根本就没启用它。custom-ctx 是解决办法，不是病根。

也不是 pruner 和摘要共用阈值，互相干扰：源码里根本没有这个逻辑。

真正根源：五套上下文治理机制全部未挂载。

机制 状态 造成的后果
会话压缩 未挂载 上下文无限累加，从 1 万涨到 39 万，没有自动回落
工具结果剪枝 未挂载 read 读到的内容全部留在上下文里，23.3 万字符永久驻留
子代理委派 未挂载 所有工作都堆在主上下文；4 轮探测、26 次读取、99 次修改，全部在主会话里跑
/compact 手动压缩命令 未挂载 无法手动触发压缩
大输出落盘机制 未挂载 长结果不落地，直接留在上下文
默认阈值 0.8，对应 1M 窗口就是 80 万 token。本次峰值才 39 万，就算开启默认配置，也永远不会触发压缩。

→ 问题不只是「没挂载机制」；这套默认参数本身，并不适合 1M 窗口。

五、成本真相
桶内 token 分类：

uncachedInputTokens：269,318，全价计费 token

cacheReadTokens：32,984,192，缓存读取，占 99.2%

cacheWriteTokens：0

模型输出补全：183,995

口径一（有效信息占比）：0.57% 的倒数 = 176.8 倍（实测），用来衡量新增有效信息的稀释程度。

口径二（单步均值）：131 步时，261,005 ÷ 1,972 = 132.3 倍（实测），衡量每一步的信息效率。

预估优化幅度：33.3M → 约 8M，减少约 76%（预估）。

不是减少 99%。无状态 API 必须重复带上下文，这个开销没法彻底消除。不能夸口说，这里有 131.3 倍的节省空间——这属于过度承诺。

六、实践一：三处配置全错，是追问核对才发现的
背景：拿到一份现成配置，准备直接照搬修改。核对的时候多追问了一句，对照官方预置模板校验，查出 4 处错误。

我原先写的（错误） 官方标准写法（正确） 问题说明
name: ‘@deepseek-ai/dsh-compaction’ name: cordis:group ＋ group: true 包名搞错，这只是一个库，不是可以直接挂载的插件行
config: {compaction: true, …} isolate: {compaction: true, …} 键名放错层级
把子配置写在顶层 compaction 放在 config 嵌套内 层级错误，group 分组语义失效
pruner 使用 thresholdRatio thresholdChars: 8192 / headChars: 4096 / tailChars: 1024 参数名混淆，thresholdRatio 属于 compaction-basic 组件
注意：前面提到的「默认参数不合适」不属于这四项，是第四节单独发现的另一个独立问题。

官方文件路径（凭证层也留存）：~/.dsh/profiles/node_modules/@deepseek-ai/dsh/config/agent-presets/standard/agent.cordis.yml

本次产出：

拿到权威结构，后面就以此作为 custom-ctx 的基础骨架。

发现一条失效的备份路径：custom-minimal 注释里引用 standard_agent.cordis.yml，完全匹配不到内容。如果没核对，后续会出现「备份成功」的假象，骗过所有人。

直接复制粘贴配置的坑：看起来配置写完了，但所有功能静默失效，一点报错都没有。

教训（已经登记到 ai_memory.md §6 第 6 条）：写入外部配置文件前，必须读取权威源文件核对。

七、实践二：提前推翻准备写进交接单的假阴性测试
不是跑一遍就能发现问题，是读源码（dsh-compaction-basic/lib/index.js L867–887）才看懂。

这也是这件事最有价值的地方：上下文总量低于 30 万的时候，怎么跑都看不出异常；要搞清楚它什么时候触发、谁来读取这个参数，只能读源码。

调参优先动 retainRatio 的底层理由：

参数 控制事项 说明
thresholdRatio 两件事 控制剪枝触发条件，同时控制摘要触发时机，两个行为共用这一个参数
retainRatio 一件事 只控制摘要保留多少内容
剪枝本身，不改参数也能运行。改动 thresholdRatio，会一次性修改两套逻辑。

→ 优先调只负责一件事的 retainRatio。

retainRatio 的语义：

两个比例的分母，都是窗口上限（1M），不是当前上下文长度。触发后会丢弃：300,000 − 80,000 = 22 万 token。

retainRatio 和 retainTokens 互斥。retainTokens 是固定绝对数量，不受窗口大小影响，预测性更强。

硬性约束：retainTokens < thresholdTokens。

这次的收获：在方案落地前，拦下一个假阴性问题。不然接手的人，会以为这套逻辑验证通过，等到真实故障发生，白白浪费好几天排查时间。

教训（登记原文，ai_memory.md §6 第 10 条）：参数文档写的含义，不等于运行时真实行为。

八、处置方案
步骤 动作 理由
0 新开会话，先启用 custom-ctx 不打开它，后面调的预设参数都不会生效
1 retainRatio：从 0.08 调到 0.15~0.20 分母是窗口上限，每次最多丢弃 22 万 token
2 thresholdRatio 暂时不动，保持 0.3 它同时控制剪枝、摘要两件事；一次只改一个变量
校准顺序：

启用 custom-ctx → 只修改 retainRatio → 双通道冒烟测试（§14.1）→ 对照五行判读表（§14.3）确认 → 确认没问题之后，再考虑调整 thresholdRatio。

⚠️ 两张表格不要弄混：五行判读表，用来验证压缩功能有没有正常跑；四指标表（§14.2），用来检查我们自己的操作习惯。

备选方案，预测性更强：如果不想比例跟着窗口大小浮动，可以直接设置固定值 retainTokens: 150000。

九、分段实测：8 个观测数值
锚点：就是写这份规范文档的那次 write 操作；同一会话切成前后两段，不靠猜步数定位。

指标 规范前（166 步） 规范后（19 步） 变化 标记
uncached（全新信息，全价计费） 1,856 780 −58% 实测
工具返回结果 393,565 16,846 −96% 实测
read 调用次数 32 2 −94% 实测
单步平均 prompt 大小 289,595 475,384 +64% 实测
prompt 峰值 457,528 492,595 +8% 实测
9.1 背后的数学逻辑
uncached（新增全价 token）总和：322,952
全部输入 token 总和：57,105,160
uncached 占总输入：0.57%

规范能优化的对象，只占全部输入的 0.57%。就算做到新增信息为 0，总 token 消耗也只能下降 0.57%。

所以，优化后看不到巨大降幅，不是操作不到位，而是底层原理限制。这套操作只能止血，没法一次性大幅削减总量。 真正大幅度降量靠 compaction 压缩，但本次会话里压缩没有挂载。

步数增加，边际成本越来越高是必然：跑到 145 步，总量 38.8M；后面新增的 40 步，每一步边际 token 约 458K，是会话平均值 309K 的 1.5 倍。

⚠️ −76% 是预估数值，不是本表里面的实测结果。

十、实践三：归档晚于改动，靠哈希补全证据链
两件事分开看：

WinError 5：创建 custom-ctx 的时候，系统 ACL 沙箱拒绝写入。按流程重试，提升权限即可成功，属于正常操作，不算故障。

归档备份：限制来自 vault_fp.py，工具不支持同一天多次备份。我不拿这个当借口，备份顺序是我自己安排的。

操作过程：

text
预期 sha256：2b2b5353c421c48fce98aab4ff1f562a8aa79216d29025342606d331e3af884f
重建文件 sha256：2b2b5353c421c48fce98aab4ff1f562a8aa79216d29025342606d331e3af884f
→ 哈希匹配，校验通过 ✓
中间状态可以凭哈希完整恢复。

教训：所谓「备份先行」，不只是执行备份这个动作，备份必须放在修改操作之前。

十一、归档链与凭证
ai_memory.md 四态归档链（实践三的物证；指纹校验 origin == backup == 文件原文）

状态 文件大小 sha256 说明
v1 18,106 B / 221 行 518991f0… §5.4 第 12 条修改前
v2 21,229 B / 241 行 a20b48b9… §6 第 6 条修改前
中间态 24,068 B / 251 行 2b2b5353… 没有正式归档，但可以按哈希重建
v3 26,854 B / 265 行 8edca0ea… 最终版本
交付文档凭证清单：

文档名 大小行数 sha256
_ai_drafts/_tools/ 上下文减量操作规范.md 177 行 / 10,796 B（增补 §2.0 后；原版 163 行 / 8,848 B） 4652bfeaf9d7cea6（原版 d796365f09baf252）
_ai_drafts/ 上下文减量操作规范_备份_20260927.md 163 行 / 8,848 B d796365f09baf252
_ai_drafts/ai_memory.md 29,687 B / 281 行（同日增补 §6 第 11 条；原版 26,854 B / 265 行） 2855233e64730025（原版 8edca0eafad88ce1）
_ai_drafts/tokens 消耗 20260927（自述版）_v5_备份_20260927.md 621 行 / 34,697 B（v5 旧稿） 551f86e0e924ecf9
_ai_drafts/ 交接单_四公子第二段_20260927.md 15,601 B / 232 行 b13fc6bc687ed14c
预设配置 4 个文件（明细放在凭证层）

文件 大小行数 sha256
custom-ctx/agent.cordis.yml 9,527 B / 195 行 6c770e99f59796b7
custom-ctx/preset.yml 317 B 13d32910282f9e0b
custom-minimal/agent.cordis.yml（无改动） 2,053 B 79362ecb22a19e77
custom-minimal/preset.yml（无改动） 204 B 9cb0d9467ab1e2bd
三条不变事实，可复核：

落盘文件，可以从备份原文逐字对齐开头 = True

custom-minimal 两个哈希 79362ecb… / 9cb0d946… 保持不变，回退路径完好 ✓

custom-ctx 顶层生效共 7 条；delegation 不在启用列表 ✓

本文件自身大小、哈希不在本表记录：文件不能包含自己最终哈希，这两项放在交付汇报里。

如果缺少这些物证，整篇文档就只是「我个人的描述」，违背第〇节的原则。

十二、实践四：升级解释框架时，事实描述最容易漂移
实测数字保留了：57.1M、0.57%、132.3 倍。

但是，造成现象的根因，很容易被替换成「看起来说得通，但不是真相」的解释。

v2 版本就犯过这个错：把根因说成 custom-ctx 全量重注入（不存在），还有「两个阈值互相干扰」（刚好说反）。

漂移有三种形态，这次全部遇到了：

形态 表现 本次例子
替换 底层机制被换成看似合理的错误说法 v2 写错的两个根因
剪除 删掉可以核验的证据，比直接写错更隐蔽 v4 精简稿删掉哈希、对照校验表
颠倒 表头和内容写反，读起来完全是另一个意思 v6 草稿里的正误对照表
这就是〇.1 判据的来由：修订解释文本，只能调整句式，不能改动数字、不能篡改机制。表格内所有数字，都标注「实测」或者「预估」。

和第十三节第 8 条对应：我提出的参数，也只是假设。同理，我写的机制解释，也都必须能回源核验。

十三、定律表（7 条已验证 + 1 条待检验假设）
编号 定律 核验方式 标记
1 开销大头是上下文反复重发，不是初始系统提示词的大小 实测：初始底板只占 4%，重复上下文占 96% 实测
2 输入总量 ≈ 上下文长度 × 请求步数；prompt 持续变长时，总输入接近步数的平方级增长 实测：后期边际消耗 458K / 步，是会话均值 309K 的 1.5 倍 实测
3 配置写在文档/注释里 ≠ 运行时真的生效。报告、注释、备份路径，都不算权威来源 三处静默失效，一条路径完全匹配失败；本文稿本身三次描述漂移 实测（最强证据）
4 操作纪律只能止血，没法一次性大幅削减总 token 实测：read/write 优化能做到 −58%/−96%，但这部分只占全部输入的 0.57% 实测
5 参数文档写的含义 ≠ 运行时真实行为。找不到调用入口，就不要设计测试 源码 L867–887 实测
6 备份必须放在修改之前。一旦顺序颠倒，只能靠历史记录反向重建 实践三，哈希重建验证 实测
7 无状态 API 必然重复提交上下文；重复提交这个基础开销无法消除 API 本身特性 实测
8 ⏳ 待检验假设：thresholdRatio: 0.3 / retainRatio: 0.08 这套参数，是否合适 新开会话跑一遍校准 假设
第 8 条的意义，就是留到下一次会话实测。

按本文标准：没有实测验证的推论，和网上 PPT 上随便给的数字，属于同一可信度等级。

补充：「假阴性测试比真故障更危险」属于心得，不算定律，实践二就是用来验证第 5 条定律。

十四、验收标准
14.1 双通道冒烟测试
(a) /compact 命令是否可用：由 compaction 组的 command-compact 组件提供

(b) 读取 custom-ctx 生效清单：顶层共 7 条，delegation 不在启用列表

如果两者结果冲突，以 (b) 为准。 (a) 会因为前端不展示命令，出现假阴性。

14.2 四指标表（用来评估我们自己的操作纪律）
指标 本次实测值 健康阈值 超标含义
read 占工具返回结果比例 71% <40% 反复整段重读文档
write 参数占工具参数比例 高 <30% 频繁用 write 做大面积修改
单步平均 prompt 254K <150K 上下文过长，该压缩或者新开会话
重发 ÷ 新增 token 132× <50× 步数太多，上下文已经失控
随时可用的单步判断规则：

如果某一步，新增 uncached 输入 < 3000 token，但整体 prompt > 200,000 token → 这一步几乎没有新增工作，绝大部分开销都在重复发送历史内容。这时应该合并步骤，或者执行压缩，不要继续往下跑。

14.3 五行判读表（验证 compaction 压缩是否生效）
序号 现象 判断
1 峰值超过 40 万才回落 thresholdRatio 设置偏大
2 反复触达上限，但不会掉到 8 万 属于「只剪枝、不生成摘要」阶段，正常，不要改参数
3 曾经下探到约 8 万 剪完仍然超阈值，进入摘要阶段
4 下限稳定低于 5 万 retainRatio 太小 → 优先上调到 0.15~0.20
5 数值单调上涨，永远不回落 compaction 完全没挂载，回到 14.1 做冒烟检查
补充说明：

① 反复触顶、回落，但下限远高于 8 万：说明剪枝单独承担减压。这是成本最低、最健康的状态，不会额外调用 LLM 做摘要。不要因为没掉到 8 万，误以为压缩没起作用。

② 剪枝先执行。看到单步 prompt 下降，有可能只是剪枝生效，不一定触发了摘要，别误判。

十五、实践观：五句话，每一句都对应本次实证
表述 本次实证 证据强度
实验本身就是探索 统计口径从渲染函数读出；压缩分两阶段，文档没有写，靠读源码拼凑出来 强
出错不可耻，解决问题才是重点 4 条配置全部写错 → 对照官方模板修复；假阴性风险，读源码提前拦下；归档顺序出错，靠哈希重建证据 强
持续试错，才能知道方案行不行 一次只改动一个变量；第七节源码推导理由；四指标、五行判读表 强
不想只听别人结论，要自己动手验证 别人给的配置有三处错误；就连我上一轮写的报告，也不视作权威来源；本文自己的描述，三次出现漂移 极强
实践是检验真理的唯一标准 所有数字带来源、标记实测/预估；没跑过的估算，明确标注预估、假设 强
15.1 这个标准，同样约束我自己
thresholdRatio: 0.3，目前和别人 PPT 上的数字一样，只是假设。

只有跑完实测，它才能变成经过检验的结论。

两处自我约束点：① 参数假设（§十三第 8 条）；② 机制文字描述（§十二）。

如果「实践是唯一标准」，只用来挑别人的错，不拿来审查自己，那就变成另一种形式的主观独断。

15.2 ⚠️ 本次最重要的洞见（已经写入规范）
pruner 的工作逻辑：当总 token 超过阈值，超过 8192 字符的工具返回结果，会被截断为头部 4096 字符 + 截断标记 + 尾部 1024 字符（总长度约 5160 字符）。

一旦 custom-ctx 启用，一次性读取长文档的时候，文档中段会被悄悄截掉。

→ read 读取不再只是省 token，更重要的是防止模型基于残缺文档做出错误判断。

→ 操作硬性要求：读长文档，必须分段读取（offset/limit）。

✅ 这条已经补进《上下文减量操作规范》§2.0，第 0 条，最高优先级，正确性要求。

15.3 待完善事项
在《DSH"纪律极简模式"完整实现报告.md》增加反向引用：27.2M / 57.1M，就是这个设计决策带来的实测代价。

把整套流程：度量 → 归因 → 定位根因 → 制定处置方案 → 验收核验，加上「实测/预估分级标记」，抽象成一套可复用方法论。

写一页简短 TL;DR 摘要，放到 03_资源 目录方便引用。

清理原始 transcript 里引号混用问题（需要先备份，并且遵守 §6 红线）。

⚠️ 文件名这个地方，连续 4 次写错，用了直双引号（v3、v4、v5 粘贴稿、v6 草稿）。规范写法是弯引号。凡是引用这个文件名，直接从目录复制，不要手动打字。

十六、留给下一个会话的一句话
新开会话，第 0 步：先启用 custom-ctx。它的启动清单在会话初始化的时候读取；当前已经跑起来的会话，修改不会生效。

然后按第八节的校准顺序：只调 retainRatio（0.08 → 0.15~0.20）→ 双通道冒烟测试 → 对照五行判读表确认 → 确认没问题，再考虑 thresholdRatio。

thresholdRatio: 0.3，现在还不是定论，只是我推导出来的假设。

跑一遍。跑完，它才算得到验证。

附录 A：五个观测时点总表
时点 步数 输入总量 有效占比 来源 引用强制要求
A 115 27.2M — footer 快照 引用必须带上「115 步」
B 131 33.3M — 会话日志重算 引用必须带上「131 步」
C 145 38.8M — footer 快照 引用必须带上「145 步」
D 183 56.1M — footer 快照 引用必须带上「183 步」
E 185 57.1M（57,105,160） 0.57% 会话日志终态 引用必须带上「185 步」
引用规则：引用这几组数字，必须附带对应步数，不带步数，视为无效引用。

⚠️ B 是日志重新计算；其余是 footer 快照。两套数据源不要混在一起计算。不是数据矛盾，是五个独立观测点。

核心比率汇总（实测）：见 §一、§五、§九。

初始底板 10,210；会话平均步长 308,676；uncached 1,972 → 780；单步重发 261,005；132.3 倍、176.8 倍；底板占比 4%；0.57%；缓存 99.2%；思维链 78,550 tok。

附录 B：复现方法，踩过的五个坑
全部是实际踩坑总结，不是文档查到的内容：

序号 坑 解决办法
1 会话日志是 zstd 多帧追加压缩，一次性解压只能读到 172 字节 使用流式解压，不能一次性调用 decompress()
2 agent.cordis.yml 文件包含 !!js 标签，裸 pyyaml 直接报文件损坏 注册 js 自定义构造器，再解析 yaml
3 PowerShell 默认 GBK 编码读取 UTF-8 文本，出现乱码 Python 打开文件，强制指定 encoding=‘utf-8’
4 写入 ~/.dsh 被 ACL 沙箱拦截，WinError 5 不算权限故障；按流程重试，按需提权即可
5 事件结构不统一，user message 的 data 字段直接是 content，不是嵌套 message 对象 解析前，先探测事件结构
数据源：~/.dsh/sessions/…/session.jsonl.zstd（本次日志 6.4MB，共 6416 条事件）

配套脚本放在 _ai_drafts/_tools/：

probe_session_log.py：探查结构 + 流式解压

analyze_session_tokens.py：token 归因统计

compare_segments.py：分段对比

collect_handover_credentials.py / check_handover.py：凭证收集、哈希核验

附录 C：证据层，可以直接 grep 检索的字符串
源码行号：

证据描述 出处
剪枝-重测-摘要三段逻辑，pruner 触发点 dsh-compaction-basic/lib/index.js L867–887
footer 渲染函数，K/M 单位换算 dsh-client-ui-conversation/lib/client.js（大约 2755 行）
compaction-basic 默认常量 0.8 / 0.16 同上源码包常量
原始 transcript 可检索关键词串：

关键字 对应内容
10,210 第一步 prompt 底板，占总量 4%
395,333 助手回复累计字符
329,914 工具返回累计字符
232,632 read 读取累计字符（占工具返回 71%）
177,263 工具调用参数累计字符
261,005 131 步，单步平均重发上下文
1,972 / 780 规范前后，单步 uncached
322,952 全部 uncached 新增 token 总量
57,105,160 总输入 token，和上面相除得到 0.57%
command-compact 双通道 (a) 对应的命令组件
thresholdChars pruner 参数 8192/4096/1024
WinError 5 ACL 沙箱报错
pruneSession pruner 触发入口，假阴性来源
2b2b5353 中间态重建校验哈希
⚠️ 这些字符串必须在原文 grep 命中。如果检索不到，这套证据链就失效了。

三条不变量、凭证清单，见 §十一。

附录 D：引号与格式核验
口径定义：正文 = §〇～十六 + 附录 A–C；全文 = 正文加上附录 D、E。两者差值就是本附录自身的自引用。正文改动，附录 D 必须重新跑核验。

待核验项目 全文 正文
一级弯引号「」配对数量 62 / 62 ✔ 51 / 51 ✔
弯引号（只用于文件名） 2 1
直双引号（只允许在代码块内） 0 ✔ 0 ✔
标签计数：实测／预估／假设 40／11／7 37／9／5
文中「失误」出现次数（只用于引用旧框架） 7 5
读数说明：

两处弯引号，是引用 DSH"纪律极简模式"完整实现报告.md（§15.3 和本段），不属于正文一级引用。

全文没有独立直双引号，全部在代码块内（本次代码块无直双引号，为 0）。

行数、字节数、sha256 不在本表记录。文件不能包含自身哈希，这几项放到交付汇报。

附录 E：《上下文减量操作规范》摘要
规范正式条目：第 0 条 + 四条硬纪律。

§2.0 第 0 条（最高优先级，正确性强制要求）

读取长文档，必须分段读取（offset/limit）；禁止一次性读取完整文档。

要点 内容
底层机理 custom-ctx 生效之后，如果工具返回超过 8192 字符，会截断成 head 4096 + 标记 + tail 1024（约 5160 字符），文档中间内容直接丢失
触发条件 pruneSession() 只在 compactIfNeeded() 内部调用；上下文总 token 小于 30 万，直接 return，不执行剪枝
⚠️ 风险 不是永远截断。低于 30 万不剪，高于 30 万才截断。能不能读到全文，取决于当前上下文大小。这种「有时完整有时残缺」是最危险的
和第 1 条的关系 第 1 条是成本管控；第 0 条是正确性红线。第 0 条是必须遵守，第 1 条是建议遵守
优先级理由 四条纪律只是省钱；第 0 条防止模型基于残缺文本推理，一旦出错，错误会持续传导下去
四条硬纪律：

序号 纪律 本次实测反面案例
1 read 定向检索：先用 grep 定位，再 offset/limit 分段读，禁止整份重读 read 占全部工具返回 71%
2 修改文件优先用 edit；新建或者改动超过 50%，才用 write write 单次参数 23,476 字符
3 脚本只输出聚合统计结果，原始日志落盘保存 6.4MB 日志被反复读回 3 次
4 长交付结果落地写文件，只粘贴关键片段，附带文件路径 助手正文累计 395,333 字符
自检判断标准：四指标表 + 单步判据（§14.2），不是五行判读表。

注：「一次只改一个变量」属于规范 §5.4 会话卫生，不属于这四条硬纪律。

规范版本变更记录：163 行 / 8,848 B / d796365f09baf252 → 177 行 / 10,796 B / 4652bfeaf9d7cea6，同日增补第 0 条。

附：2026-09-27，已决事项清单
序号 事项 结果
1 自述版文件落位 执行方案 (b)：Move-Item，移动至 02_领域/编程/Harness/tokens 消耗 20260927（自述版）.md；原始基础文件一字未动
2 规范文档增加第 0 条 已经写入 §2.0 + §3.1 细则，反面清单、页脚同步更新；原文件备份：_ai_drafts/ 上下文减量操作规范_备份_20260927.md（8,848 B）
3 凭证同步更新 自述版 §十一、附录 E、本表同步哈希与状态；完整版 v4 文档 §十一、§16.2 同步哈希和状态
4 ai_memory.md §6 新增第 11 条 新增 §6 读取时（正确性要求）小节，增加第 11 条「读长文档必须分段读」。本次顺序为先修改，再备份；修改前版本由 ai_memory_备份_20260927_v3.md 覆盖，origin 和 backup 哈希完全匹配。没有额外新建第三份同日备份。版本变迁：26,854 B / 265 行 / 8edca0eafad88ce1 → 29,687 B / 281 行 / 2855233e64730025
原文未改动证明（哈希、大小、mtime 三重凭证）：

text
BEFORE 117,410 B mtime 2026-09-27 10:03:51 sha256 941b47878de6689e
AFTER 117,410 B mtime 2026-09-27 10:03:51 sha256 941b47878de6689e
→ 源文件没有改动 ✔
操作顺序：所有编辑都放在 _ai_drafts 临时目录，改完再移动文件。全程没有直接修改 02_领域 目录里任何已有文件，遵守 §6 红线。