WorkBuddy 积分到底花在哪了？

WorkBuddy 积分到底花在哪了？我翻了本地数据库做了一次逐请求复盘

备选标题（二选一，都带关键词，过审更稳）

1. WorkBuddy 积分烧得太快？我从本地数据库做了逐请求复盘，找到 3 个"吃分大户"
2. WorkBuddy 使用心得：9 天 709 积分，我把它花在哪儿全查清楚了

建议标签：#WorkBuddy #AI Agent #效率工具 #踩坑记录 摘要：9 天用了 709 积分，我一度以为是模型太贵。翻了客户端本地数据库才知道：吃分的不是模型，是返工的轮次和 PPT 类重任务。附完整排查方法和 3 条实测有效的省分建议。

一、背景：我的工作场景

我日常要产出的是 PPT、质量问题汇报、安全履职报告、车间目视看板这类"重排版、重数据"的材料。

用上 WorkBuddy 之后，它确实接掉了不少活：把 Excel 里的不良率数据做成图表、把会议纪要整理成 PPT 大纲、把零散的检查记录汇总成台账。但用了不到一周，我就发现一件事——积分掉得比预想快得多。

有多快？我 10 月 4 日开始正式用，到 10 月 12 日，9 天累计消耗 709 积分、151 次请求，其中单日最高 253 分。按这个强度，免费的体验版 500 分/月连一周都撑不过。

于是我决定不猜了，直接把数据挖出来看。

二、踩坑一：找错数据源，白折腾半小时

我第一个想法是：客户端肯定有日志文件。

翻到 C:\Users\<用户名>\.workbuddy\，确实有一堆看着很像的东西：

• usage-log.json —— 名字简直写着"用量日志"四个字
• audit-log\2026-10-09.jsonl —— 按天切分，内容还挺大

结果打开一看：

usage-log.json 记录的是技能（Skill）和 MCP 的调用日期，比如"tencent-pptx 在 10-07、10-08 被使用过"，只有日期，没有任何消耗数值。

audit-log 是命令安全审计——记录的是"某条命令被沙箱允许/拒绝"，跟积分一毛钱关系没有。

结论：配置文件的名字会骗人，要看内容结构再判断。

三、踩坑二：真正的数据藏在 SQLite 里

继续往目录里翻，找到了 workbuddy.db——一个 SQLite 数据库。用工具打开，建表语句一看就明白了：

credit_json 长这样：

每个 key 是一次请求，value 是这次请求消耗的积分。 这才是我要的东西。

但新问题来了：它只存了会话级的汇总，看不出每次请求发生在哪一天，没法做"按天统计"。

四、踩坑三：PowerShell 拿不到输出，换 Bash

我想用 PowerShell 脚本直接算，结果遇到两个连环坑：

坑 A：工具的 stdout 不返回。 脚本 exit code 是 0，但什么都不打印，看起来像执行失败了，实际是输出没被捕获。

坑 B：安全策略拦截。 我想调用系统回收站接口，写法是 Add-Type -AssemblyName Microsoft.VisualBasic，直接被拦：

换成反射加载同样被拦，COM 组件（Shell.Application）也一样。

解决方式：统计类的活全部改走 Bash + Python，一次就通了，而且输出稳定。

五、解决方案：用 UUIDv7 解出请求时间

那个看着像乱码的 key，其实是带时间戳的 UUIDv7——前 12 个十六进制字符就是毫秒级 Unix 时间戳。

验证一下：某个会话的创建时间是 1791363641578（毫秒），而它的第一条请求 key 是 01a11597f10b...，把 01a11597f10b 按十六进制转成十进制，得到 1791363641611——误差 33 毫秒，完美对上。

于是用 Python 就能还原出每一次请求发生的具体时刻：

两个小提示：① 用 ?mode=ro 只读打开，避免和正在运行的客户端抢锁；② 有极少数老格式的 UUID（v4）不含时间戳，脚本里要单独兜底，否则统计会漏。

跑完之后，我的积分去向第一次清清楚楚。

六、真实结果：9 天 709 积分

顺着数据往下钻，三个结论浮出水面：

结论 1：吃分的是任务类型，不是模型档位。 我全程用的都是快速档模型（这本身是省分的选择），但单次成本差了 5 倍：

结论 2：跑得最贵的那一次，不是因为它复杂，是因为我在反复改。 单次消耗 Top1 是 45.19 积分——那是做述职报告 PPT 的第一轮。而同一个项目里，我把需求说清楚之后的几轮，单次都在 2～5 分。返工才是真正的烧分大户。

结论 3：多任务并行会叠加消耗。 10-09 那天 5 个会话同时跑，单日 253 分，占 9 天总量的 36%。多任务并行确实提效率，但积分是叠加扣的。

结论 4（意外的收获）：长会话的单价会涨。 数据库里 used/size 字段显示，我有几个会话的上下文已经用到 14 万 / 30 万 token。上下文越长，每次请求的单价越高——这是隐形成本。

七、三条实测有效的省分建议

① PPT、报告类任务，先要大纲再要成品。 别一上来就说"帮我做一份述职 PPT"。改成两步：

第一步："我要做一份生产部季度述职 PPT，面向公司管理层，包含安全/质量/交付三块，先给我一版大纲和每页要点。" 第二步（确认大纲后）："按这个大纲生成完整 PPT，套用我上传的模板。"

我实测，同样的产出，多花一轮确认、少花三四轮返工，总消耗能降一半以上。

② 长会话该断就断。 一个会话聊了十几轮、上下文堆到十几万 token 之后，新建会话重新开始，比在长上下文里继续追问更省。

③ 重任务错峰，别同时铺开。 如果当天不是交付节点，不要 5 个任务一起跑。并行的部分通常是"等 AI"的效率，但你付的是叠加的积分。

八、写在最后

这次折腾最大的收获不是省了多少积分，而是用数据替代了猜测。

一开始我以为是"模型太贵"，差点就为了降本去手动选便宜模型。结果数据告诉我：真正的问题是我的提问方式和任务组织方式——需求一次说不清、PPT 反复返工、长会话不清理。

顺手说一句，WorkBuddy 本地数据目录里其实还藏着不少可玩的东西（会话记录、变更历史、任务索引），README 和文档里不会写，但自己翻一翻挺有意思。如果你也在做类似的用量分析，欢迎交流。

最后提醒：本文的统计数据来自本机客户端，不含其他设备或云端消耗，仅作方法演示，具体数值每个人都不一样。