# 我用 WorkBuddy 做了一次 API 账单审计：7 天 16,007 次请求，发现单次成本差 9.6 倍

> 行业与岗位：通用办公 · 成本分析（个人/团队 AI 费用管理）
> 使用产品：WorkBuddy（自建 Skill ×2 + 定时任务 ×1）
> 数据窗口：2026-09-09 ~ 2026-09-15

---

## 一、起因：一次"积分不够用"的追问

我每天的活儿是长时间和 AI 一起做的——读材料、整理文档、跑批处理、写报告。用了一个多月，积分开始不够用了。

最初我的判断很朴素：**是不是我话说得太啰嗦**？于是我开始压缩提问、删减上下文、尽量一句话把需求说完。折腾了一阵，积分没怎么降。

这时候我意识到一个问题：**我根本不知道我的积分花在哪了。**

WorkBuddy 只给一个总数。哪个任务贵、哪个档位贵、钱是花在输入还是输出上——全都没有。想省钱，得先有一本账。所以我决定：**别猜了，把账查出来。**

这就成了一个小型的成本分析任务。下面是完整过程。

## 二、输入材料

| 材料 | 位置 | 拿到了什么 |
|---|---|---|
| 逐请求日志 | 本机 `projects/**/*.jsonl` | 每一条请求的输入/缓存命中/输出 token，以及**实扣积分** |
| 会话汇总表 | 本机 `workbuddy.db` | 会话级的积分与模型归属 |
| 档位与倍率配置 | 本机 `cache/acc-product-config-v3*.json` | 各档位的倍率与时段规则 |

这些文件都在本机，不需要任何外部工具就能读。`jsonl` 里每行是一条完整请求记录，关键字段是 `providerData.rawUsage`，里面就有我要的全部数字。

## 三、WorkBuddy 配置

这一节是我觉得这次任务里最值得说的部分——**我没有每次重新问一遍，而是把它固化成了两个 Skill。**

| 配置项 | 名称 | 作用 |
|---|---|---|
| **自建 Skill ①** | `workbuddy-cost-audit` | 成本审计与比价：取本机真实 token 结构，逐模型实测"积分/百万输入 token"，而不是拿挂牌价估算 |
| **自建 Skill ②** | `wb-usage-daily` | 用量日报：按日聚合请求与积分，出逐日明细 + 分时段统计 + 会话级下钻 |
| **脚本** | `usage_probe.py` / `fit_weights.py` / `wb_usage_daily.py` | 分别负责探量、拟合单价、生成报告 |
| **定时任务** | WorkBuddy 每日积分管家 | 每天 13:00 自动跑日报，产出落 `reports/wb-usage-<日期>.md` |
| **回归套件** | `wb_verify.py` | 48 项断言自测，改动脚本后必跑，保证口径不被改坏 |

两个 Skill 都是 `agent_created` 的自建技能，覆盖了我日常 90% 的用法。**建 Skill 这个动作本身，是整个任务里回报最高的一步**——它把我"每次都要重新解释一遍"的成本，变成了一次性投入。

## 四、操作步骤

### 第 1 步 · 先定位数据，不急着算

我没有一上来就写公式。第一步是**确认账本长什么样**：读一条原始记录，看 `rawUsage` 里到底有什么字段。

这一步的收获是发现了一个关键事实：`credit`（实扣积分）是**直接存在于日志里的**。这意味着我不需要用"单价 × token 数"去估算——**账本是实扣值，可以逐条核对**。这一点决定了后面所有结论的可信度。

### 第 2 步 · 踩到第一个坑：同一行被写了两次

第一次汇总跑出来，积分明显偏高。查了一圈才发现：**同一行记录可能被快照重放重复写入**。

修正方式是按 `(sessionId, id)` 组合去重。去重前后差了 1～12 条记录——**不去重，账就是虚高的**。

顺带还踩到一个：`timestamp` 字段是**毫秒**，按日聚合必须先除以 1000，否则所有日期都会跑到 1970 年去。这个错很隐蔽——**报表能正常生成，只是全空**。

> 配图 4（三个踩坑点与修正：去重缺失 / 毫秒时间戳 / 高 R² 掩盖荒谬结论）在此处插入。文件名：`fig4_踩坑与修正.html`

### 第 3 步 · 拆成本结构：钱到底花在哪个环节

做完了才敢算。第一版想要的是"输入多少钱、输出多少钱"。我用了最小二乘拟合，结果**拟合出了负系数**。

原因是：**缓存命中的 token 和未命中的 token 在会话级是强共线的**——缓存多了，未命中自然就少，两个变量在数学上分不开。三元回归在这种情况下必然失真。

改法是两步走：**先剔除缓存命中项，只用（未命中, 输出）做二元拟合**，再用残差把缓存命中单价反推出来。这才拿到了能站住的结构（分 / 百万 tokens）：

| 成分 | 单价 | 对积分的贡献 |
|---|---|---|
| 未命中输入 | **47.83** | **≈ 67.5%** |
| 输出 | **23.02**（≈ 未命中的 0.5 倍） | **≈ 32.5%** |
| **缓存命中输入** | **≈ 0.00** | **≈ 0%** |

**这一张表直接推翻了我原来的假设。** 缓存命中占了 96.8% 的 token，却几乎不产生积分——所以我一开始"压缩上下文、精简提问"的做法，动的是最便宜的那部分，**难怪折腾半天没效果**。

另一个反直觉的点：**输出单价只有未命中输入的一半**，不是更贵。所以"让模型少说话"能省的钱，比我原先估的还少。

> 配图 1（成本结构：未命中 47.83 / 输出 23.02 / 缓存命中 ≈0，单位分每百万 tokens）
![Snipaste_2026-10-03_21-16-32.png](https://developer.qcloudimg.com/http-save/yehe-12753971/065be300e96f032c6e44c1ed684e599d.png)
真正的结论是：**成本 ≈ 请求数 × 每轮新增的内容**。省钱的着力点根本不在"怎么问"，而在"用哪个档位"和"要几轮"。

### 第 4 步 · 又踩一坑：R² 高达 0.94，结论却是错的

接着我想让报告更"聪明"一点——按模型分别拟合各自的单价，看看哪个贵。

结果 `glm-5.3-flash` 拟合出了**"输出单价 = 未命中输入单价的 17.5 倍"**。这个数字荒谬到一眼就知道不对——输出比输入贵 17 倍，不合常理。

但真正让我警觉的是：**这个结果的 R² 高达 0.94。**

也就是说，如果我只盯着拟合优度看，我会把一个完全错误的结论写进报告，而且它看起来"拟合得很好"。混档窗口下的样本让拟合失去了意义。

**改法**：不再信任回归系数。主表改成**实测直算**——`积分 ÷（未命中输入 + 输出）`，这个口径不受共线性影响，任何窗口都成立。同时给回归加了一道合理性闸门：输出/未命中比值超过 5 倍就直接判为不可信，**宁可不报，也不报一个看起来漂亮的错数**。

最终各档位的实测刻度（分 / 百万 tokens）：

| 档位 | 实测刻度 | 相对主力档 |
|---|---|---|
| 主力档 `deepseek-v4.1-flash` | **39.50** | 基准 |
| 备选档 `glm-5.3-flash` | **53.42** | 1.35 倍 |
| 旗舰档 `deepseek-v4-pro` | **281.50** | **7.1 倍** |

> 这一列是**档位贵不贵的直接刻度**，比比值更抗噪声——因为它不受"缓存命中率高低"的干扰。同样是 100 万 token，付在旗舰档上是 281.5 分，付在主力档上是 39.5 分。

### 第 5 步 · 算出真正的结论

账清楚了，缺口一下就找到了。七日实测（16,007 次请求 / 3,128 积分）：

| 模型 | 请求数 | 请求占比 | 积分 | 占积分 | 分/请求 |
|---|---|---|---|---|---|
| `deepseek-v4.1-flash`（主力） | 13,133 | 82.1% | 2,063 | 65.9% | 0.157 |
| `glm-5.3-flash`（备选） | 1,722 | 10.8% | 839 | 26.8% | 0.487 |
| **`deepseek-v4-pro`（旗舰）** | **130** | **0.8%** | **196** | **6.3%** | **1.507** |
| `hy4-preview` / `hy3`（免费档） | 1,004 | 6.3% | **0** | 0% | 0 |

**关键不在"谁占的积分多"，而在"请求占比和积分占比的错位倍数"**：

- 主力档 82.1% 请求 → 65.9% 积分，**基本合理**；
- 备选档 10.8% 请求 → 26.8% 积分，**放大 2.5 倍**；
- 旗舰档 0.8% 请求 → 6.3% 积分，**放大 7.9 倍**，单请求成本是主力档的 **9.6 倍**。

旗舰档那一栏最容易被看漏——**130 次请求，占比不到 1%**，扫一眼表格只会觉得"没什么影响"。但它单请求成本是主力档的 9.6 倍，属于**典型的"用得少、但每一下都贵"**。这正是只看总量排名会漏掉的成本。

> 配图 2（三档位请求占比 vs 积分占比错位）与配图 3（各档位实测刻度）![Snipaste_2026-10-03_21-16-46.png](https://developer.qcloudimg.com/http-save/yehe-12753971/ca71f6cb0f31673fcf86b08c2875f171.png)![Snipaste_2026-10-03_21-16-59.png](https://developer.qcloudimg.com/http-save/yehe-12753971/5fd11d424eeee6a9c9edbc7cc0b8dffc.png)

再往下挖一层，我找到了根因——**WorkBuddy 没有"全局默认模型"**。模型是**逐会话手动选**的，不管的话会落在最贵的档位上。而我当时大多数会话，是没管的。

这个结论在日报里得到了独立印证：档位告警显示 **09-07 高倍率档位占 100%、09-08 占 99%**——这两天我几乎全程挂在旗舰档上，而那两天我自己完全没察觉。

顺带做成了一件顺手的事：日报加了**档位告警**——某日高倍率档位积分占比超过 30% 就报警。这把"忘记换档"从事后察觉变成了当日发现。

### 第 6 步 · 改流程，加回归自测

最后一件事是**防止自己把口径改坏**。这种数据脚本改一次就可能悄悄错一次，于是补了一套 `wb_verify.py` 回归套件，从 32 项扩到 **48 项断言**，覆盖去重、时间戳、环比语义、分时段合计一致性等。

当前基线：`PASS 48 ｜ FAIL 0 ｜ SKIP 0`。**每次改脚本必跑**——这是这套东西能持续用的前提。

## 五、产出物

| 产出 | 形态 | 说明 |
|---|---|---|
| **用量日报** | `reports/wb-usage-<日期>.md` | 逐日明细 + 分时段统计 + 会话级下钻，每天 13:00 自动生成 |
| **成本结构结论** | 上文的单价表 | 未命中 47.83 / 输出 23.02 / 缓存命中 ≈0（分每百万 tokens），可复算 |
| **档位告警** | 日报内置 | 高倍率档位占比 >30% 自动报警 |
| **回归套件** | `wb_verify.py` | 48 项断言，保障口径不漂 |
| **两个 Skill** | `workbuddy-cost-audit` / `wb-usage-daily` | 可复用，不必重新解释 |

日报里最终跑出来的关键数（2026-09-09 ~ 09-15 这七天）：

- 请求 **16,007** 次，积分 **3,128**
- 输入 **1930.09M** tokens，**缓存命中率 96.8%**
- 输出 **14.56M** tokens
- 会话 **246** 个，平均 **0.195 分/请求**
- 夜间窗口（23:00–08:00）占 **24.7%** 请求、**27.5%** 积分

## 六、这件事最值得说的三点

**第一，别在"怎么问"上抠，要在"用哪个档位"上抠。**
我一开始花了最多力气在提问技巧上，而数据显示那块几乎不产生成本——缓存命中占了 96.8% 的 token 却近乎免费。真正的大头是档位：同样 100 万 token，旗舰档 281.5 分、主力档 39.5 分，**差 7.1 倍**；落到单请求上差 **9.6 倍**。而且在 WorkBuddy 里，这个动作只需要在开新会话前点一下。

**第二，账本要能自证。**
这次最有价值的两个发现，都来自"数字对不上"：一次是重复写入导致积分虚高，一次是 R²=0.94 却拟合出荒谬系数。**如果我只信一个好看的总数或一个好看的 R²，这两个错都会留到最后。** 现在的做法是：表格里显示的数必须能被人按着复算出来——宁可损失小数精度，也要让读者能自己验一遍。

**第三，把结论固化成 Skill，而不是留在对话里。**
我最初的用法是每次问一遍。现在是两个 Skill + 一个定时任务，每天自动出报告。**能自动跑的账，才是真账。**
![Snipaste_2026-10-03_21-17-20.png](https://developer.qcloudimg.com/http-save/yehe-12753971/3b1f08a50de07d0e043ff7a35bb8623d.png)![Snipaste_2026-10-03_20-44-17.png](https://developer.qcloudimg.com/http-save/yehe-12753971/65da552d18b5b5bbbe6438a6769a57c8.png)
---

*文中所有数值来自本机日志的实扣值与直算口径，未做估算。档位名称与倍率请以你自己客户端的实际配置为准。*


行业与岗位：通用办公 · 成本分析（个人/团队 AI 费用管理） 使用产品：WorkBuddy（自建 Skill ×2 + 定时任务 ×1） 数据窗口：2026-09-09 ~ 2026-09-15

我用 WorkBuddy 做了一次 API 账单审计：7 天 16,007 次请求，发现单次成本差 9.6 倍

七天 16,007 次请求、3,128 积分，账面看不出钱花在哪。我用两个自建 Skill 把逐请求日志拉成成本结构：缓存命中占 96.8% 的 token 却近乎免费，各档位单位成本差 7.1 倍，旗舰档单请求成本是主力档 9.6 倍——用得少却每下都贵。本文完整记录输入材料、配置、六步排查与产出，含三个真实踩坑：去重缺失、毫秒时间戳、以及 R²=0.94 掩盖了荒谬结论。

后端

开发工具

职业发展

WorkBuddy API成本审计：7天16007次请求，单次成本差9.6倍。旗舰档占积分6.3%却仅0.8%请求，缓存命中占96.8%token近乎免费。真正成本驱动是模型档位而非提问方式。通过自建Skill和定时任务实现自动化成本追踪，附48项回归测试保障数据准确。

WorkBuddy 

2026上云采购 | AI焕新·智启新局

workbuddy

tione

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我用 WorkBuddy 做了一次 API 账单审计：7 天 16,007 次请求，发现单次成本差 9.6 倍-腾讯云开发者社区-腾讯云

我用 WorkBuddy 做了一次 API 账单审计：7 天 16,007 次请求，发现单次成本差 9.6 倍

我用 WorkBuddy 做了一次 API 账单审计：7 天 16,007 次请求，发现单次成本差 9.6 倍

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐