我用氛围编程做了一款适合自己的记账应用
从银行卡通知、账单截图 OCR，到现金支出和预算比较，记录我用对话式 AI 逐步完成个人 Android 记账应用的过程。
我用氛围编程做了一款适合自己的记账应用
市面上有很多成熟的记账应用，但很难找到完全符合我习惯的产品。不同银行卡有不同的消费统计周期，我还希望把卡片消费、现金支出和固定费用放在同一个地方查看。对于过去的记录，我想从账单截图导入，同时不希望金融信息被发送到外部服务器。
于是我把需求告诉对话式 AI，把生成的应用安装到真实手机上，再把发现的问题继续反馈给它。这属于常说的氛围编程，但并不是输入一次提示就得到完整应用。真实过程是拆分需求、运行程序、比较总额、寻找差异原因并补充测试。
本文截图中的个人信息和真实金额已经全部删除，可能通过柱状高度推测金额的图表区域也已遮盖。
从“希望一眼看清”开始
最初的目标很简单：在首页直接看到月度预算、当前卡片统计周期的消费、当月现金支出以及整体消费状态。底部导航分为概览、卡片、现金、预算和导入。
第一版只是一个小型 MVP，通过 Android 通知访问服务读取指定银行卡的新支付通知。银行登录、账户访问、短信与联系人读取、广告 SDK 和服务器上传都被主动排除。通知原文和整理后的记录只保存在设备中。记账应用包含敏感的生活模式，因此隐私边界必须先于便利功能确定。
卡片统计周期是第一个难题
简单统计每月一号到月底，并不符合真实账单。每张卡都有自己的周期，因此我加入了按卡计算的统计区间，以及前后周期切换。
同一笔交易如果同时来自通知和截图，只能计算一次；但同一家商户、相同金额的两次真实购买又不能被误删。最终规则会同时考虑数据来源、发卡方、统计周期、时间和金额。概览页与详细页也改为共享同一套计算逻辑。
用设备端 OCR 补充过去记录
通知访问只能获取安装应用之后的新通知。为了补充过去的记录，我加入了卡片账单和消费明细截图导入。用户先选择发卡方，韩文 OCR 随后在设备内运行。确认之前不会保存结果，切换发卡方时也会清除之前的候选数据，避免内容混在一起。
不同银行卡应用的布局和用词都不同，因此需要反复改进：按照画面位置匹配日期与金额、处理展开菜单遮挡交易行的情况，以及区分取消和正常消费。
加入预算表和现金支出
只有银行卡消费无法反映完整生活支出。应用可以读取已有的 Google Sheets 预算表，不仅保留大类总额，也保留每一行的详细项目。现金支出分为固定和一次性两类：固定费用延续到下个月，一次性费用只留在发生月份。新增、编辑或删除后，概览和月度图表会立即更新。
之后又加入了多月卡片与现金对比，并用文字说明当前支出低于还是超过预算。
验证比提示词更重要
AI 加快了开发速度，但金融数字是否可靠，仍需要清楚的定义和人工验证。自动测试覆盖了卡片周期边界、通知解析、OCR 日期与金额匹配、跨来源去重、保留正常重复购买、固定现金费用延续、各页面总额一致，以及预算明细之和与总额一致。
重要修改前我会备份源代码，修改后再执行单元测试和 APK 真机安装检查。一个数字在某个页面看起来正确，并不代表其他页面使用了相同规则，因此必须同时检查可见结果和内部计算逻辑。
一款在使用中持续进化的应用
氛围编程最大的价值不只是速度，而是能把日常需求立刻变成可验证的原型。不过，AI 生成的第一版绝不能直接相信。隐私范围、总额定义、去重规则和既有功能回归都需要反复检查。
真正有用的产品来自小需求、真实数据中发现的错误、备份、测试和再次验证的循环，而不是一条神奇提示词。它不是面向所有人的通用金融产品，却已经成为符合我真实使用方式的个人工具。氛围编程并不是替代开发，而是在用户能清楚描述问题并验证结果时更强大的制作方式。