Awesome AI Tokenomics：把 AI 的"电费单"摊开给你看

一、一个让你睡不着觉的账单

如果你最近用 Claude Code、Codex 或者 Cursor 干了一周的活，月底看到账单时大概率会有同样的反应："这点工作量，怎么花了这么多钱？"

2026 年 7 月，Quesma 团队（一家做高性能日志与遥测基础设施的公司）把这个问题摊开在桌面上。他们的观察很直接：围绕 AI token 成本的工具、论文、基准测试和工程实践，散落在整个互联网的各个角落，没有人把它们系统性地拼在一起。于是他们动手做了 awesome-ai-tokenomics——一个关于"AI token 经济学"的策展清单。

这个清单在创建后的三个月里涨到了 206 star、38 fork，成为该细分领域里最完整的中文可读（虽然作者写的是英文）资源导航之一。

二、这不是"又一个 awesome list"

市面上的 awesome list 大多是链接堆砌：给你 200 个仓库标题，不解释为什么。而这个项目走了完全相反的路子。

它的五个顶层分类不是按技术栈分的，而是按"你在账单上会做什么"分的：

• Monitor（监控）——你的钱现在花在哪？
• Optimize（优化）——怎么花得更省？
• Govern（治理）——怎么让团队不乱花？
• Understand（理解）——市场定价规律是什么？
• Measure（度量）——你测出来的数准不准？

更有意思的是它的 271 条结构化元数据（research/manifest.json），每一条都记录了 title、url、verified_on（验证日期）、stale_after（失效日期）、super_area（所属领域）、kind（类型）。这不是手写 README，而是有工程化的数据管道。

按类型分布：oss（开源工具）91 条、article（文章）48 条、company（商业公司）30 条、paper（论文）30 条、tool（工具）17 条、report（报告）13 条、benchmark（基准）13 条、model（模型）11 条。按领域分布：optimize 94 条、understand 70 条、measure 50 条、govern 29 条、monitor 28 条。

质量控制是这个项目最值钱的部分。 每个条目都带"最后提交时间"徽章，链接失效会被 CI 发现；scripts/check_staleness.py 会扫描 manifest，超过 186 天未验证报 WARN，超过 365 天或超过 stale_after 报 ERROR，并且用白名单机制把"已完成但不再活跃"的条目降级为警告而不是误杀。.github/workflows/ 下的 links.yml、lint.yml、staleness.yml 三条流水线持续跑这件事。

三、最有价值的那一页：claims.md

如果这个项目只留一个文件，应该是 claims.md。

它列出了 8 条**"工作性论断"**（working claims），每条都标注置信度（当前统一是 medium）、最强证据链接，并且明确写"当论断被强化或被推翻时，这一页会改，并且会说明改了什么"。

举几个例子：

"Harness 设计对 agentic 编码的成本影响 rivals 模型选择" —— 证据是 Terminal-Bench 上同一模型在不同 harness 下输入 token 差异达约 66 倍；Claw-SWE-Bench 显示仅靠适配器设计就能带来约 54 个百分点的成功率摆动；Codex issue #16812 中一个压缩阈值改动就让账单翻倍。

"跨厂商的 $/MTok 对比在没有 tokenizer 归一化前是无效的" —— 同内容 token 数差异超过 2.65 倍，最便宜的厂商会随内容类型翻转。

"可修复的 harness 浪费占真实总账单的约 11% 是一个站得住脚的下限" —— 团队自己插桩的会话数据给出 10.9%–13.1%，并诚实标注这是未公开的单机数据。

这种"敢标注自己数据是 unpublished、敢写 confidence=medium、敢列出反面证据"的做法，在 AI 领域的清单项目里非常罕见。它甚至专门写了一页 concepts/case-against-the-thesis.md 来论证"反对本项目核心论断"的情况。

四、实战派：copy-paste 配置

清单的另一面是可以直接抄的配置，都在 setups/ 目录：

• claude-code/CLAUDE.md-cost-template.md——把官方全部成本旋钮拼成一个可复制块，每个旋钮都溯源到厂商文档的实时抓取
• claude-code/settings-model-routing.md——用 settings.json 的模型上限 + 子 agent 的 model: 字段，编码一套"四级分级升级策略"（Brain / 默认 worker / 精度关键 / Micro），已在 Quesma 自家研究栈上从 2026-07-02 持续运行
• codex/config-cost.toml.md——Codex 侧的 reasoning effort、自动压缩上限、工具输出截断、审批策略、service tier
• gateway-patterns.md——专门做"消歧"：四样东西都被叫作"LiteLLM pattern"，这篇告诉你你要的到底是哪一种

作者也很有自知之明，明确标注两个 skill（cost-review.md、cache-hygiene-audit.md）"未端到端测试过"。

practices/ 目录里的 9 篇实践文档同样具体，比如"Prompt-cache hygiene"要求稳定前缀保持 append-only 且逐字节相同，否则缓存静默失效并按全价重新计费；"Context-compaction discipline"指出压缩本身是有成本的运算，还有"重读循环"失败模式，应该度量而不是信任。

五、局限性

诚实地说，几个问题值得注意：

1. 它是清单，不是工具。 仓库本身不能给你省钱，需要你按图索骥去装 ccusage、OpenLIT、Langfuse 等几十个独立工具。实际收益取决于执行力度。
2. 两条 skill 未经端到端验证，作者已标注，但使用者容易忽略。
3. 数据强依赖自研单机插桩，样本量有限，且 manifest.json 中的 verified_on 会被 staleness 检查强制更新，长周期准确性依赖 CI 持续可用。
4. 清单本身是英文的，虽然结构化程度高，但对企业中文团队的落地仍需二次翻译与内部消化。
5. 部分条目带商业属性（company 类 30 条，如 Comet Opik、Braintrust），作者自己在条目描述里标注了"Comet 声称节省 15%–30%，但没有公开方法论"——这种克制值得肯定，但读者仍需自行判断。

六、部署可行性

这本质上是一个文档 + 少量脚本的仓库，没有任何运行时服务：

维度	评估
Dockerfile / docker-compose	无
Web UI	无
Kubernetes 编排	无
实际运行依赖	仅 scripts/check_staleness.py（Python 3 标准库）与 scripts/lint_readme.sh（bash）
部署难度	极低——克隆即用，或直接当在线目录阅读
硬件需求	几乎为零，512MB 内存 / 100MB 磁盘足够

对团队而言，最实用的落地方式不是部署它，而是把 practices/ 的 9 篇规范和 setups/ 的 4 份配置纳入内部知识库，配合清单里推荐的 ccusage / OpenLIT / splitrail 等工具，形成"度量 → 归因 → 优化"的闭环。

七、行业意义

2026 年最明显的一个趋势是：AI 成本优化的重心正从"调模型参数"迁移到"调 prompt / context / harness"。这个项目用一个清晰的数据结构把这条趋势完整地记录了下来——optimize 分类下 94 条内容，比 monitor 的 28 条多出三倍多。

在一个所有人都在问"该用哪个模型"的时代，这份清单给出的答案是另一个问题："你的 harness 让这个模型浪费了多少？" 这个问题或许才是 2027 年 AI 工程真正的主战场。

---

项目地址：https://github.com/QuesmaOrg/awesome-ai-tokenomics （CC0-1.0 许可，代码部分 MIT）