企业官网建设流程全解析

如何写出符合规范的 Caveman 基准测试报告：fixture、计数器与负结果披露

【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman

如果你的任务是为 Caveman 的某个组件发布 token 压缩数字——eval 结果、browse 效率数据、harness 前缀测量或 wrap 对比——仓库里有明确规范：报告必须能回答“这个数怎么来的、失败在哪、结论边界是什么”。这篇文章按 docs/technical/testing-and-benchmarks.md 的 “Writing a benchmark report” 一节、docs/technical/accounting-and-evidence.md 的证据基础与发布清单，以及仓库中已发布的两份基准报告，给出从 fixture、计数器到报告成文再到披露的完整操作路径。

规范对一份报告的要求

docs/technical/testing-and-benchmarks.md 规定每个对外发布的结果都应包含以下 10 项：

1. 被测的问题；
2. fixture 名称、来源和哈希；
3. 代码版本与日期；
4. 相关的硬件或 provider/model；
5. 精确命令；
6. 计数基础（count basis）与价格来源；
7. 基线（baseline）与处理组（treatment）的定义；
8. recovery、parse 与质量检查；
9. 失败、排除项与负 delta；
10. 数据支持的窄结论。

三条硬性边界：fixture 级结果不等于生产验证；本地 token 估计不等于 provider 成本；成功检索不证明质量对等（recovery 检查建立的是源可用性，不是模型理解力）。

先定证据基础与计数器

docs/technical/accounting-and-evidence.md 的核心规则是：按数字的产生方式给它贴标签，不同证据基础不能共用一个标签，聚合时不能静默换基础。

计数器的选择决定基础标签。Engine 使用离线o200k_base计数（不可用时退回字符估算），这类计数对 provider 计费而言属于inferred——不同 provider 可能对同一段文本分词不同，并可能把 cache 或图片输入计入不同单位。provider 返回的 token 字段保留 provider 基础，字段缺失时不要用本地估算替换。

如果报告涉及成本，本地成本显示是：provider-reported 或显式选择的 token 单位 × 带日期的公开目录价格 = 列表价小计。文档明确这不是发票——协商条款、订阅、区域价格、批量费率、缓存规则、抵扣、税费都可能导致差异。未知价格记零并标unpriced：零防止虚构成本进入总和，unpriced防止零被误读为免费使用。

准备 fixture：名称、来源、哈希

docs/technical/accounting-and-evidence.md 要求“exact fixtures and their hashes or versions”（确切的 fixture 及其哈希或版本）。可操作的做法：

• fixture 用仓库内已提交的文件，直接链接路径。例如 browse 基准的语料库就是 browse/testdata/order_dashboard.html（200 行订单表）与 browse/testdata/agent_checkout.html。
• 为每个 fixture 记录哈希。git 提供现成工具：

git hash-object browse/testdata/order_dashboard.html

• 记录代码版本：git rev-parse HEAD得到 commit，并确认 worktree 是否干净（已发布的 docs/WRAP-BENCHMARK.md 同时记录了Harness Git commit与Dirty worktree at execution: false）。
• 如果测试框架自己产出来源记录，直接引用。subagent-tax 的每次运行都会写一个 repro pack，含report.json、原始捕获、日志、临时配置和manifest.sha256（见 packages/subagent-tax/METHOD.md）；docs/WRAP-BENCHMARK.md 则记录了 corpus、skill、harness 源码、二进制共 5 个 SHA-256 加生成时间戳2026-08-06T14:31:43Z。

docs/technical/testing-and-benchmarks.md 里按类别列出了仓库的基准入口：Engine fixtures（比较原始与压缩表示）、Browser fixtures、Cache corpus、Subagent tax（packages/subagent-tax，本地 fixture 无 provider 请求）、Wrap report。下节给出其中两条可直接跑的路径。

跑内置 harness：收集完整运行记录

可选路径 A：evals 离线快照（无 API key）

evals/README.md 的 eval harness 跑同一组 prompt 在三个臂下的真实 Claude Code 输出，比较输出 token 数：

文档强调：任何 skill 的诚实增量是<skill>vs__terse__——skill 本身在“要求简洁”之上增加了什么。与无 prompt 基线比较会把通用简洁指令的效果一并算给 skill，这是早期版本数字虚高的原因。

读取已提交快照不需要 LLM 和 API key，可在 CI 中运行：

uv run --with tiktoken python evals/measure.py

它读 evals/snapshots/results.json（已提交的 source of truth，含生成时间、Claude CLI 版本、模型、prompt 数等元数据），用 tiktokeno200k_base计数，输出 median/mean/min/max/stdev 表。注意两个文档明确给出的限制：

• o200k_base是 OpenAI 的 BPE，只是 Claude tokenizer 的近似——臂间比例有意义，绝对数字是“近似的输出长度降幅”，不是精确 Claude token；
• 每个 (prompt, arm) 只跑一次，min/max/stdev 让你判断数字是扎实还是噪声，但这不是统计显著性检验；
• 不衡量保真度、延迟或成本。

刷新快照需要已登录的claudeCLI，每个 prompt ×（N 个 skill + 2 个控制臂）调用一次 Claude，可用环境变量换小模型控制费用：

CAVEMAN_EVAL_MODEL=claude-haiku-4-5 uv run python evals/llm_run.py

新增 prompt（追加一行到 evals/prompts/en.txt）或新增 skill（放入skills/<name>/SKILL.md）后都要刷新快照。

可选路径 B：subagent-tax（harness 前缀测量，默认无 provider 调用）

subagent-tax 测量每次调用时 harness 重发的完整前缀（system prompt + 全部工具 schema）。它用一个本地 sink 模拟 provider 端点，每个已安装 harness 向 sink 发送一次真实请求。默认没有任何 provider API 调用。

副作用与前提（文档明确列出）：

• 默认node run.mjs会启动机器上已安装的 harness 并在捕获后终止其进程树；
• claude 行故意对你的真实配置运行（你的插件/MCP 就是被测的“税”），这会启动你的 MCP server、运行你的 hook，并在~/.claude/projects留下会话记录；
• --count-tokens是 opt-in 例外：把捕获的 body（你的真实 system prompt）发送到 Anthropic 的免费count_tokens端点，需要ANTHROPIC_API_KEY，没有 key 会警告并保持估算。

node run.mjs --harness claude,pi --repeat 3 --out ./subagent-tax-report

写报告时 packages/subagent-tax/METHOD.md 要求遵守的标签规则：

• 证据基础永远是inferred——前缀大小，不是账单、支出或节省；
• variant列说明每行测的是什么配置；不同 variant 的行是不同构造，直接比较比的是插件配置而不是 harness；
• token 列标est（字符数 ÷ 6.4，两位有效数字，校准带 ±8%，且校准来自 Anthropic tokenizer 后套用到所有协议）或exact（仅 Anthropic 协议行的count_tokens）；
• mcp列的-表示未知而不是零（只有 Claude Code 的 MCP 命名约定被确认）；
• --repeat N的 min–max 是单机 N 次运行的观测范围，文档明确它不是置信区间；
• repro pack 的 body 仍是 harness 真实 system prompt（本地路径、skill 列表、MCP 工具名），分享前必须审查。

报告成文：以已发布的两份报告为模板

browse/BENCHMARK.md 是一份要素齐全的报告：

• 开头声明测量日期（2026-08-10）、Chrome 版本（151.0.7922.108）、锁定的@playwright/test1.56.1、离线o200k_base计数器，并声明“每个数字都是单个快照的inferredtoken 计数，不是 provider 用量或账单”；
• 结果为五次独立 Chrome 运行的中位数加[min–max]范围；
• 语料库直接链接已提交 fixture，并注明规模（200 行操作表）；
• 复现命令给出精确写法：

CAVEMAN_BROWSE_CHROME="/path/to/Chrome" \ go test -tags=integration -run 'TestCDPQueryScales|TestCDPFullTokenEfficient' -count=5 -v ./browse

/path/to/Chrome需要替换为你本机的 Chrome 可执行路径。

• 结尾的 “Claim boundary” 一节声明结果只适用于该语料库与工具链，OOPIF、对话框、下载等延后处理。

docs/WRAP-BENCHMARK.md 展示了来源记录与发布门槛的完整写法：开头标注Claim basis: benchmark_counterfactual，并声明这是受控基准证据，不是生产流量、客户支出、provider 发票或 Cavemanverified_savings；“Reproduction availability” 一节直接说明本仓库只有发布报告与来源哈希、没有原始 harness 与运行产物，当前 checkout 无法独立复现，应把它当作 pinned report 而不是可复现的公开基准。发布门槛（来自同一文档）：至少 6 个案例且 3 次重复；每次运行都有 direct 与 Caveman 的精确质量检查；每运行一次 fixture 调用；同一 provider 用量来源；Caveman skill 处于激活状态；至少一次已验证的压缩；正的聚合降幅；95% 区间完全在零以上；负案例与 no-op 案例不得移除。

负结果披露

docs/technical/accounting-and-evidence.md 的 “Negative and failed results” 一节给出规则：

• 保留负 delta 和失败的变换，丢弃回归会使结果偏置；
• 被拒绝的优化仍可能产生 provider 用量，即使紧凑输出未被服务也要计入。

两份已发布报告都是执行示例（文档示例，供对照写法）：

• browse/BENCHMARK.md 的小表单场景里，Caveman 完整 agent 可见结果 157 token，比 Playwright 裸 ARIA 文本 67 token大 2.34 倍——文档明确写道“This small-page loss is important”，因为 recovery handle、精确计数器、honesty basis 与动作 UID 在页面本身很小时开销高于裸 ARIA 文本；
• docs/WRAP-BENCHMARK.md 中dashboard-html-alert案例为-9.9%：该案例没有压缩变换生效，但完整 Caveman skill 开销仍被计数，案例保留在聚合中；Headroom 臂的 3 个 YAML 运行未通过精确答案检查，“remain visible rather than counting toward savings at held quality”。

verified是保留词：只用于前提被强制约束、且记录指明方法的验证手段。公开本地运行时不能仅凭 Engine 估计、skill 输出、pixel 转换、TOON 输出、cache 计划或合并代码自行标记verified。证据不足时用inferred、observed、provider-reported或诚实的零。

发布前清单

docs/technical/accounting-and-evidence.md 的 “Publication checklist” 在发布任何数字前逐项核对：

1. 标注确切的证据基础；
2. 链接已提交的 fixture 或来源记录；
3. 披露计数器与价格日期；
4. 声明质量测试与失败数；
5. 区分列表价与发票；
6. 不跨模型、provider、任务或时间外推；
7. 支持缺失时发布零或unpriced。

最后，结论只写数据支持的窄结论：一个 fixture 的结果只支持该 fixture 与该方法；平均降幅不证明任务质量相等；docs/HONEST-NUMBERS.md（即 HONEST-NUMBERS.md）中列出的、当前仓库支持的公开声明清单，是写对外结论时的参照。

【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman