本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
众所周知（并不），我是有个小工作室的，为了强迫员工跟上Vibe Coding的节奏自建了公司自用的中转站。出于对人性的不信任，这么贵的订阅总不能让员工用来养虾或者酒馆。所以趁着周末时间搞了这个Token审计的小项目，当然也就是Github没有 
，不然我还是很自信能拿个1k 的。 
总得来说分了两步实现，首先是改造New-API，加了三个小hook，改动很小，方便我跟着上游更新。然后是加了一个独立的审计小项目，着实不大，全程都是codex开发，我只提供思路。所以如果是想开发同类的小玩意，其实把README扔给AI大概率就能搞定。
后台
企业微信日报
项目一：New-Api简单改造
这个仓库是基于 QuantumNous/new-api 的审计专用 fork。
它不是一个重新实现的网关，也不改变 New-API 的核心业务逻辑。这个 fork 只增加一组很小的审计采集 hook，用来把 New-API 中已经解析到的请求信息和结算后的 token 用量，异步上报给独立的 token-audit 审计服务。
目标是支持企业内部的 Token 审计需求：
- 按时间范围统计每个用户、每个 token 的 token 消耗。
- 识别请求类型，例如编码实现、调试修复、架构设计、配置运维、文档编写、代码审查、数据分析、疑似非工作、其他。
- 对疑似非工作或不确定请求，能够追溯到具体用户、token、模型、时间、token 用量和 prompt 预览。
- 保持 New-API 升级成本尽可能低，把分类、报表、复核、企业微信推送等逻辑放在独立审计服务中。
项目二：审计面板和通知
token-audit 是一个独立运行的审计服务，用来接收 Bigduang/new-api-audit 上报的请求事件和用量事件，按 request_id 合并 prompt、用户、token、模型、tokens、quota 等信息，保存到本地 SQLite，并在每天用量稳定后生成审计日报。
它解决的不是实时限流，而是事后可追溯：
- 统计一段时间内每个用户、每个 token 的请求数、Prompt Tokens、Completion Tokens、总 Tokens 和 quota。
- 判断请求是否用于工作，尤其是开发、调试、架构、部署、文档、代码审查、数据分析等场景。
- 对疑似非工作或无法判断的请求保留用户、token、模型、tokens、分类原因和 prompt 预览，方便复核。
- 提供轻量管理端，用来启用/停用审计用户、维护日报显示名、查看请求历史和完整 Prompt。
- 生成移动端友好的 HTML 日报，并通过企业微信 textcard 推送摘要和详情链接。
- 使用 SQLite 和 30 天保留策略，适合 VPS 上的小型公司内部中转站。
总结
我试过了，这个B项目在Github上并不容易被搜出来，所以只要牛马们不作死，老板自己是不会发现的！
和new-api-tools一个方向？
它是只读newapi的数据库
ARM 3
知道了，不能用老板自己搭的中转站。
ck_235 (Vvvvv) 4
并不是，new-api的日志实际上不太够用的，所以第一个项目fork了一下，往里边加了转发接口
大家以后用老板的tokens要小心了 可能被监控了
ck_235 (Vvvvv) 6
是的，实际上我在公开公司自用中转站的时候就提醒了大家会有Token审计的，而且这个日报是公司内部群发的，不仅限于我自己，目的在于提醒，而且目前为止即便有非工作内容，我也没有跟任何人讨论过，毕竟有些跟不上的还处在惊讶阶段，不知道应该怎么用。
但是吧，保不齐有那种有怪癖的老板喜欢看点这种日志的