管理多张信用卡的人有个共同的痛点：银行App各自为政，没有一张图能告诉你这个月到底花了多少、花在哪了。一位开发者干脆自己动手，用谷歌刚发布的Gemma 4模型做了个本地优先的账单分析工具Swipey。

这位开发者自述持有四张信用卡，专门用来攒积分换机票。不同卡对应不同消费场景——一张吃饭、一张旅行、一张兜底日常开销。但超过三张卡后，跨行追踪消费结构变得异常困难。"这个月最大支出类别是什么？""跟上个月比怎么样？"这些基础问题反而最难回答。

打开网易新闻 查看精彩图片

Swipey的解决方案很直接：把Chase或Capital One的CSV交易记录拖进网页，选定月份，Gemma 4自动生成消费摘要。输出包含三项核心内容：当月消费亮点、支出模式识别、以及优化建议。系统还会自动将相似商户聚合成组，显示各类别总和，支持在线编辑调整。

这并非该开发者的第一次尝试。早期版本每月把原始交易数据完整发给Claude处理。新版Swipey迁移至Cloudflare Workers AI运行Gemma 4，核心差异在于数据不再外流——处理全程留在云端推理层，不经过第三方API。

技术选型上，开发者选中了Gemma 4的260亿参数MoE变体（@cf/google/gemma-4-26b-a4b-it）。这是Cloudflare截至2026年5月唯一托管的Gemma 4版本。他在文档中补充了选型逻辑：20亿和40亿参数版本适合内存受限的边缘或端侧场景，但对约100行交易记录的综合分析可能力有不逮；310亿参数稠密版质量最高，首token延迟也最长；260亿MoE版在延迟与质量间取得平衡，恰好匹配Swipey的需求。

项目采用Next.js 14构建前端，PostgreSQL存储数据，Tailwind CSS处理样式。功能层面支持拖拽上传CSV、多账户管理、导入前预览及重复交易检测。目前仅适配Chase和Capital One两种银行格式。

代码已开源，但开发者明确标注"仅供本地使用"。Docker Compose配置自带开发环境默认凭证，API路由无身份验证，直接暴露公网存在数据泄露风险。项目定位是个人工具而非成熟产品——解决的是开发者自己的痛点，开放给有相同需求的技术用户自行部署。

这个案例的有趣之处在于模型应用场景的选择。金融数据敏感性强，本地优先架构天然契合隐私诉求。Gemma 4的开源属性允许开发者完全掌控推理环境，相比闭源API少了一份数据被用于模型训练的担忧。同时，消费分析属于结构化数据总结任务，对模型创造力要求不高，更看重成本可控与响应速度——这正是中等规模MoE模型的舒适区。

从Claude到Gemma 4的迁移，本质上是一次"去中心化"实验：把原本依赖单一供应商的智能能力，分散到可自主部署的开源基础设施上。对于持有敏感个人数据的工具类应用，这种架构思路可能会越来越常见。