# 【AI 工作流手记 #1】积分到底被谁烧了：给 AI 助手用量做消费归因，附"该订阅还是买加量包"的临界点算法

## 起因：差点砍错人

某天打开 AI 助手客户端，发现额度掉得比预期快。第一反应很自然：**那些每天定时跑的自动化太费了，砍掉几条。** 毕竟它们天天在跑，看着就像"固定开销"。

动手之前我想先算一笔账。结果这一算，方向直接反过来了——**自动化根本不是那个烧钱的人**。

这件事和我以前做投放时遇到的情况一模一样：拿到一张只有总额的账单，任何"降本"动作都是猜。要先有**结构**，才谈得上优化。

采集本身（只读本地用量库、快照差分）之前已经写过，本文只讲两件新事：**消费归因**和**充值决策**。

## 关键发现

### 发现 1：消耗结构是 2 : 98

把最近一天的用量按"任务类型"拆开，同一台机器上：

| 来源 | 采样消耗 | 占比 | 单次成本量级 |
|---|---|---|---|
| 自动化任务（后台定时跑） | 二十几分 | **2%** | 1~6 分 |
| 人机交互（我自己在聊） | 一千一百多分 | **98%** | 最高七百多分 |

三条每天执行的自动化任务加起来，一天**只花十来分**。而我在同一天里的两次重会话，就吃掉了一千分出头。

结论：**砍自动化省不出钱，它反而是最便宜的产能。** 真正的钱花在"我自己开的长会话"上。

### 发现 2：单次成本 ≈ 上下文规模，不是"问了多少次"

这是整个问题的机理，也是反直觉的地方：

- 普通小请求：个位数积分；
- 一个上下文涨到 **15 万 token** 的长会话：单次请求 **300~760 分**。

一次这样的重请求，**约等于一百次自动化**。

为什么会这样？因为按上下文计费的模型里，**每一轮请求都要把整个上下文重新送进去**。上下文只增不减，于是"聊得越久，每一轮越贵"——成本是随上下文长度近似线性上涨的，跟"你一共问了几个问题"关系不大。

所以省钱的方向不是"少用"，而是**别让上下文无限长**：一个任务告一段落就归档、另起新任务，比省着不敢用有效得多。

### 发现 3：本地库里的数字只是"下限"

本机用量库里，每个任务只保留**最后一次请求**的用量，不是历史累计。所以本地能算出来的是**下限值**。

想拿到真实量级，得做一次校准：把本地统计和官方用量管理页的明细对一次，算出「真实消耗 ÷ 同期本地统计 = 校准倍数」。倍数一出来，以后日常只看本地日报就够了，不用天天开后台翻明细。

## 实现

### 第一段：消费归因（把消耗拆成两类）

```python
import sqlite3, json, collections, datetime

DB = "/path/to/usage.db"     # 客户端的本地用量库（只读打开）

def credit_of(raw):
    """credit_json 容错解析：可能为 NULL、非法 JSON，值里也可能混着字符串"""
    try:
        d = json.loads(raw or "{}")
    except (TypeError, ValueError):
        return 0.0
    if not isinstance(d, dict):
        return 0.0
    return sum(float(v) for v in d.values() if isinstance(v, (int, float)))

# mode=ro：物理只读连接，不可能写坏别人的库
con = sqlite3.connect("file:%s?mode=ro" % DB, uri=True)

SQL = """
SELECT s.is_background_automation AS is_auto,
       u.used        AS ctx_tokens,
       u.credit_json AS raw,
       u.updated_at  AS ts
FROM session_usage u
JOIN sessions s ON s.id = u.session_id
"""

agg = collections.defaultdict(lambda: collections.defaultdict(float))
for is_auto, ctx, raw, ts in con.execute(SQL):
    # 时间戳可能是秒、也可能是毫秒；库里的时间没有时区，统一按 +8 小时归日
    sec = ts / 1000.0 if ts > 1e11 else float(ts)
    day = (datetime.datetime.fromtimestamp(sec, datetime.timezone.utc)
           + datetime.timedelta(hours=8)).strftime("%Y-%m-%d")
    agg[day]["自动化" if is_auto else "人机交互"] += credit_of(raw)

day = max(agg)                                  # 最近有数据的一天
auto, inter = agg[day]["自动化"], agg[day]["人机交互"]
total = (auto + inter) or 1.0
print("%s  自动化 %.1f 分 (%.0f%%)  |  人机交互 %.1f 分 (%.0f%%)"
      % (day, auto, auto * 100 / total, inter, inter * 100 / total))
```

跑出来就是那句「2% : 98%」。归因做完，优化方向就不用猜了。

### 第二段：让"当日增量"在一天内重复运行也不会算小

这是我实际踩到的坑。原来的做法是每次运行都把"当前各任务上下文"写回快照，于是**同一个自然日里跑第二次，增量窗口就只剩几小时**。

实测：晚上 21:00 定时任务跑出当日新增 **519 千 token**；23:00 我手动重跑验证，同一天的数字掉成 **0.8**——因为第二次只统计了 2 小时的窗口。这种"跑得越勤数字越小"的指标，是没法用来做决策的。

修法两条：**同一个日冻结基线**、**写汇总时当日取最大值**。

```python
import json, os

def load_baseline(snap_path, today, current_used):
    """返回 (基线, 要写回磁盘的快照)。
    规则：同一个"日"内重复运行 → 沿用文件里已有的基线，绝不用当前状态覆盖它；
         跨天 → 才用当前状态建立新基线。新任务首次纳入时增量记 0。
    """
    snap = {"baseline_date": today, "sessions": {}}
    if os.path.exists(snap_path):
        with open(snap_path, encoding="utf-8") as f:
            old = json.load(f)
        if old.get("baseline_date") == today:
            snap = old                              # 今天已经跑过：基线不许动
    base = snap.setdefault("sessions", {})
    for sid, used in current_used.items():
        base.setdefault(sid, used)                  # 只补新任务，不覆盖已有基线
    return base, snap


def day_delta(base, current_used):
    """当日新增 token：负值归零（应对上下文被压缩的情况）"""
    return sum(max(0, used - base.get(sid, used))
               for sid, used in current_used.items())


# 写日报/台账时，对当日各列取最大值——保证一天内重跑永不把数字改小
def keep_max(old_value, new_value):
    return max(float(old_value or 0), float(new_value or 0))
```

改完之后，同一天跑几次，当日增量都会**收敛到同一个真实值**（529 千 token），环比也从假的 -99% 回到真实的增长。

### 第三段：该订阅还是买加量包？把它变成一道算术题

额度要用完了，摆在面前通常是三条路：买加量包、升级套餐、忍着不用。其实这三条路可以量化——**先算"每分成本"，再算"缺口阈值"**。

```python
def unit_cost(fee, credits):
    """每分成本（元/分）：fee 是月费，credits 是月额度"""
    return fee / credits if credits else float("inf")


def break_even_gap(low, high, topup):
    """月缺口超过多少分时，升级比"原档 + 买加量包"更划算。
    low/high = (月费, 月额度)；topup = (加量包价格, 加量包额度)
    """
    slope = unit_cost(*topup)              # 加量包每分成本
    return (high[0] - low[0]) / slope      # 临界缺口（分）
```

下面这组数字是**演示用的假设值**，只用来讲算法，不代表任何厂商的真实价目（实际请以官方页面为准）：

| 档位 | 月费（假设） | 月额度（假设） | 每分成本 |
|---|---|---|---|
| 低档 | 100 | 5,000 | 0.0200 |
| 高档 | 600 | 40,000 | 0.0150 |
| 加量包 | 40 | 1,000 | **0.0400** |

代入 `break_even_gap(low=(100, 5000), high=(600, 40000), topup=(40, 1000))`，临界缺口 = (600 − 100) ÷ 0.04 = **12,500 分**。于是决策规则就三条：

1. **月缺口 < 12,500 分** → 买加量包，别升档（升档付的是"包月"的钱，你只用一部分）；
2. **月缺口 > 12,500 分** → 升档更省，且缺口越大越省；
3. **加量包永远是单价最高的补充方式**——它只适合"偶尔超一点"，不适合当主力。

两条推论也值得记住：**不要为了"怕不够"直接上最高档**（额度按月发、到期不结转，提前付的都是沉没成本）；**缺口要用连续两周的真实用量估算**，别用单日峰值——单日的波动可以有几倍。

## 踩坑清单

| 坑 | 现象 | 原因 | 解法 |
|---|---|---|---|
| 只看总量、不看结构 | 想砍自动化，砍了没效果 | 自动化只占 2%，砍它省不出钱 | 先归因，再优化 |
| 把采样值当真实消耗 | 日报一千多分，实际更多 | 库里只存每个任务最后一次请求 | 只当"下限"用，和官方明细对一次算校准倍数 |
| 同日重复运行把增量算小 | 21:00 是 519 千 token，23:00 重跑掉成 0.8 | 快照被当前状态覆盖，统计窗口只剩 2 小时 | 同日冻结基线 + 当日各列取最大值 |
| 直接 `sum(json.loads(...))` | 报错或静默漏算 | 字段可能为 NULL、非法 JSON，值里混着字符串 | 容错解析，只累加数值型 |
| 时间戳单位/时区搞错 | 昨天的量算进今天 | 秒与毫秒混用、本地时区差 8 小时 | 判单位（`ts > 1e11` 当毫秒）+ 统一偏移 |
| 读别人的库还给了写权限 | 担心污染数据 | 普通 `connect` 默认可读写 | `file:...?mode=ro` + `uri=True` |

## 效果

- **推翻了一个错误决定**：原本准备砍掉每天跑的自动化，归因后发现它们一天只花十来分，砍了等于白砍；
- **找到了真正的成本源**：上下文很长的会话。改法是"任务告一段落就归档 + 新建任务"，靠的是纪律，不是省钱不敢用；
- **充值从"凭感觉"变成"算出来"**：把月缺口代进临界点公式，该买加量包还是该升档，一行代码给答案；
- 顺手修掉一个真 bug——当天重复运行会把当日增量算小，这种指标用了比不用更危险。

## 你可以怎么用

1. **这套方法不绑定具体工具**。任何按用量计费的 AI 客户端都适用：本地有用量库就直接读，没有就每天抄一次余额进 CSV，"日消耗曲线 + 缺口估算"照样做得出来。
2. **顺序不能反**：先归因（看清结构）→ 再定阈值（决定要不要补）→ 最后才谈"省"。跳过归因的任何降本动作，大概率砍在没肉的地方。
3. **单次成本跟着上下文走**。把"别让上下文无限长"当成使用习惯：长任务分段、阶段结束就归档，比任何精打细算都有效。
4. **指标要能重复跑**。任何"跑得越勤数字越小"的统计口径都是坏口径；加一句"取最大值"、加一个"当日冻结基线"，成本极低，可信度天差地别。
5. **只读是底线**。分析别人的生产库时一律 `mode=ro`，这不是礼貌，是工程纪律。

---

> **关于作者**：10 年跨境电商老兵，拥抱 AI 时代。这里记录我踩过的坑和跑通的方法。

---

某天打开 AI 助手客户端，发现额度掉得比预期快。第一反应很自然：那些每天定时跑的自动化太费了，砍掉几条。 毕竟它们天天在跑，看着就像"固定开销"。

【AI 工作流手记 #1】积分到底被谁烧了：给 AI 助手用量做消费归因，附"该订阅还是买加量包"的临界点算法

只读本地用量库，把积分消耗拆成"自动化 vs 人机交互"。实测自动化只占 2%，98% 花在上下文很长的会话上；再用每分成本算出"该订阅还是买加量包"的临界点。

人工智能

算法

开发工具

AI助手用量分析显示：消耗结构呈2:98分布，自动化任务仅占2%成本，人机交互长会话才是主要支出。单次成本取决于上下文规模而非提问次数，15万token会话单次消耗达300-760分。建议通过任务归档控制上下文长度，并使用临界点算法决策订阅方案。本地用量数据仅为下限，需校准对比官方数据。

人机交互

代码解释

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

【AI 工作流手记 #1】积分到底被谁烧了：给 AI 助手用量做消费归因，附"该订阅还是买加量包"的临界点算法-腾讯云开发者社区-腾讯云

【AI 工作流手记 #1】积分到底被谁烧了：给 AI 助手用量做消费归因，附"该订阅还是买加量包"的临界点算法

【AI 工作流手记 #1】积分到底被谁烧了：给 AI 助手用量做消费归因，附"该订阅还是买加量包"的临界点算法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐