很多开发者接入聚合型 LLM API 后，会遇到一个很现实的问题：服务商只给账单接口，不提供 Web 管理后台。Token 消耗、扣费明细、成本趋势都藏在 JSON 里，看得见数据，却看不清变化。

按照上篇文章《氛围编程实战系列：先规划清楚学习路径》这个规划路径，我们今天就来用 AI 先开发一个 LLM 使用量监控功能。

01 | 先看清使用场景

这类场景可以叫“中转代理式裸 API 计费场景”。

开发者通过 LiteLLM 模型网关接入多家大模型厂商 API，服务商负责统一转发和统一计费，但没有配套 Web 可视化控制台。用户只能通过 curl 调用账单接口，拿到原始 JSON 文本。

问题也随之出现：数据是有的，但缺少折线图、饼图这类直观报表，模型费用占比、每日扣费变化都需要自己整理。

因为使用AI编程消耗的token量还是很多的，而笔者目前计划可用的配额又非常有限，所以能有一个可视化监控界面就非常必要，这样能更直观看到账户余额消耗情况，做到心中有数，从而更合理地安排本周的AI编程任务。

02 | 自建看板的基本思路

一个轻量方案是：定时拉取账单接口 JSON，清洗字段后入库，再用图表组件展示 Token 消耗和费用趋势。

把定期的数据先落到 CSV，使用 Oracle 外部表定义直接访问，再基于视图做报表或图表，让Vibe Coding直接基于这些数据，开发一个前端界面展示。

03 | 自建看板的具体实现

Oracle外部表需要创建一个directory，例如：/u01/media/xxxx，赋予该目录高权限，便于其他OS层面的普通开发用户可访问此目录。

同时数据库层面内部对具体开发用户赋予该目录读写权限，外部表的具体创建语句，直接让Codex调用Oracle的skill给出即可，这种底层数据相关的，建议还是要人工确认下是否符合自己的预期后再创建。

假设LLM提供商给的API查询余额方法usage.sh，这个脚本查询结果是一整串原始json信息。

我们可以这样把该json串信息加工，只取其中想关注的值，直接让Codex来做就OK，这里给出一个笔者实际使用的示例如下：

[alfred@xxxx-dev1 ~]$ cat /home/alfred/scripts/llm_usage.sh
#/bin/bash

  usage_json=$(/home/alfred/scripts/usage.sh)

  printf '"%s",%.6f,%.6f,%.6f,"%s","%s"\n' \
    "$(date '+%Y-%m-%d %H:%M:%S')" \
    "$(jq -r '.info.spend' <<< "$usage_json")" \
    "$(jq -r '.info.max_budget' <<< "$usage_json")" \
    "$(jq -r '.info.max_budget - .info.spend' <<< "$usage_json")" \
    "$(jq -r '.info.budget_duration' <<< "$usage_json")" \
    "$(jq -r '.info.budget_reset_at' <<< "$usage_json")" \
    >> /u01/media/xxxx/llm_usage_alfred.csv 

然后设置os定时调用该脚本，多长时间调用一次取决于你对观测颗粒度的需求，笔者这里设置每半小时追加写入csv文件：

*/30 * * * * /home/alfred/scripts/llm_usage.sh

Oracle数据库层面直接使用外部表加载这个csv文件。

然后Vibe Coding帮解决前端界面开发和展现工作，哪里不满意，直接对话给指令让它微调即可。

这样就自定义出一个LLM使用情况的监控界面，PC端效果如下：

同时，也可以使用手机移动端进行查询（支持 PWA），起初移动端显示有些bug，但没关系，直接告诉Codex，让它帮忙修改好就OK：

笔者注：PWA 的全称是 Progressive Web App，中文通常翻译为“渐进式 Web 应用”。

04 | 这套方案补齐了什么

它补齐的不是模型能力，而是用量可观测能力。

对个人开发者、小团队 AI 项目、初创 AI 产品来说，裸 JSON 账单很难长期人工阅读。把它变成私有化用量看板后，每日消耗、剩余额度、模型费用占比才更容易被持续跟踪。

这就是“自研 API 账单采集 + 可视化看板方案”的核心价值：在没有商用管理后台的情况下，用低成本方式把账单数据变成可理解、可追踪的成本信息。

关注我，和AI一起成长~