早上好，我是まさきん。
之前介绍过一个把AI和freee结合起来，每天早上回顾家庭收支的机制。这次是它的夜间版本。要写的是，当天用掉的银行卡消费，在睡前由AI自动检查的机制。
如果说早上的回顾是「从昨天的趋势里发现1个点」，那么夜间的机制性质稍有不同，是为了在当天之内就捞出「今天有没有需要确认一下的支出」。这次连判定规则的公式、执行时的细节控制都会一起介绍。
起因是「金额越大的支出反而越容易被搁置」
日常的零碎支出，会自然而然地被家计簿App记录下来。但单笔金额较大的支出不一样，往往是想着「以后再说」，结果就忘了。
所以我做了一个专门捞出金额较大支出的机制，让它能在当天之内就被察觉到。这个机制不是由人手动启动，而是作为一个在固定时刻自动执行的「定时任务」在运行。
正因为是自动执行，才要注意这些
既然是在固定时刻自动运行，就没办法当场找人确认。所以我事先定下了以下几条运行原则。
- 就算中途某个环节获取失败，也不在那里停下，继续处理剩下的部分
- 无法判断的情况，不勉强深入，直接跳过并只留下日志
- 外部API获取失败的当天，放弃常规汇总，改用简化版的回顾方式兜底
自动执行的任务，设计上优先保证「每天一定留下某种结果」，而不是追求「完美运行」。
把支出分成3类处理
如果用同一个标准去检查所有支出，通知就会泛滥成灾，反而没人会去看。所以我把支出分成以下3类处理。
| 类型 | 内容 | 是否检查 |
|---|---|---|
| 固定支出、订阅 | 每月金额几乎不变的付款 | 不检查，排除 |
| 事先已经商量好的大额购物 | 提前跟家人商量过的支出 | 不检查，排除 |
| 其他支出 | 突发的、自主决定的支出 | 检查对象 |
固定支出每月都一样，即使每次检查也没有意义。事先已经商量好的支出，因为已经讨论过了，也不需要通知。真正该检查的，只有「当场发生」的那部分其他支出。
固定支出的代表，通常是房租或通信费。正因为金额几乎不变，才把它排除在每日检查对象之外。
判断不清是订阅还是单次购买的商家，我不会勉强归到「订阅」里，而是另外记一行标记为「判定待定」。这里如果模糊处理，之后整体汇总的可信度就会动摇。
不过，被排除在检查之外的支出也有例外。像通信费这样的固定支出，我反而觉得偶尔重新审视一下才有价值。日常的监控可以自动化，但固定支出本身的水平，终究只能靠自己去调整。
「该商量一下的支出」的判定规则
在检查对象的支出里，只有超过一定金额的，才会被当作「该商量一下的支出」处理。把发给AI的指示通用化后介绍一下。
请从今天的银行卡消费明细中，按以下步骤提取「该商量一下的支出」。
1. 排除已归类为固定支出、订阅的交易
2. 排除已登记在事先商量清单里的交易
3. 在剩下的交易中，提取单笔金额达到一定标准，参考值为1万日元以上的支出
4. 把提取出来的交易，按「金额」「消费商家」「时间」这3项列成清单
如果没有超过标准金额的交易，只需回答「今天没有符合项」。
作为基准的金额，我觉得每个家庭合适的水平都不一样。重要的不是「具体是多少」，而是「事先定好一个基准」这件事本身。没有基准的话，最后每次都要重新讨论「这笔算不算该商量的支出」。
把同步延迟用数值来处理
家计簿SaaS的银行卡对接，反映延迟个几天是常态，连休之后还会更慢。如果把这当作「异常」处理，通知就会全是误报。所以我把延迟用以下指标数值化。
latest_txn_date：该银行卡最近能观测到的交易日期lag_days：今天的日期减去latest_txn_date的天数lag_status：根据lag_days的大小，分成以下4个等级
| 状态 | 参考天数 | 含义 |
|---|---|---|
| normal | 2天以内 | 正常的反映延迟范围 |
| watch | 3到4天 | 连休之后等情况，先观察 |
| delayed | 5到9天 | 长假等情况下可能出现的延迟 |
| stalled | 10天以上 | 长时间没有交易被反映的状态 |
关键是，不要一看到stalled，也就是长时间未反映，就立刻断定是「对接故障」。因为实际上，更多情况只是「那张卡最近没怎么用」而已。
区分「只是没用」和「对接故障」
观测到stalled时，我不会马上下结论，而是先确认过去30天的交易模式。
- 过去30天有1笔以上交易，只是最近这段时间空了10天以上 → 单纯的长期未使用，对接本身仍然正常
- 过去30天完全没有交易，而实际上记得自己确实用过 → 怀疑是对接故障
不过，即便符合后一种情况，也不会立刻断定为「故障」。只有以下3个条件同时成立，才会当作对接故障处理。
- 多张卡同时出现
stalled - 确实留有实际使用记录，比如收据或备忘，但家计簿SaaS里没有显示
- 在家计簿SaaS的界面上，能用肉眼确认到同步错误的提示
只要3个条件没有同时满足，我就会中立地当作「这张卡有N天没用了，属于节约倾向的延续」处理，不会随意发出警报。在加入这层区分之前，每次看到只是没用的卡，我都会不必要地担心「是不是对接坏了」。
给外部API的调用次数设置上限
因为是自动执行的任务，为了避免因为某种意外陷入无限调用API的循环，我给每次执行设置了调用次数的上限。
- 事先数好常规模式，比如获取当天数据、从月初累计获取等，预期会用到多少次调用
- 即使发生意料之外的错误，一旦达到上限次数就停止重试，立刻按「获取失败」兜底
- 「达到次数上限就中止处理」这件事，优先于等待超时
如果不设上限，一旦发生认证错误之类的问题，就会不断重试，持续发出无意义的请求，这个风险不能忽视。我觉得，越是自动执行的机制，越需要这类刹车装置。
区分「异常仍在持续」和「新出现的异常」
我还设置了一条规则：当月内支出超过参考比例时发出通知。但如果直接原样用在每天的通知里，一旦超过一次，之后到月底每晚都会收到同样的通知。这样就分不清「今天刚刚超标」和「本来就已经超标、状态没变」的区别。
所以我会统计超标已经持续了多少天，用「超标持续第◯天」这样的形式附加说明。区分新出现的异常和持续中的异常，在每周回顾的时候，也更容易正确把握状况。
通知内容特意写得很平淡
即使当天真的发现了「该商量一下的支出」，通知内容我也写得很平淡。只列出金额和消费商家，不做好坏的评价。
判断交给我们自己来做。AI的角色，我把它定位在「让人注意到容易被忽略的支出」这一步就够了。
尝试后的感受
最大的效果，是关于大额支出「说了没说」的争执消失了。因为信息当天就会被共享，讨论的时机也不容易错过。
另一方面，基准金额的设定一开始并不完美。设得太低，通知太多就会形同虚设；设得太高，又会漏掉真正值得关注的支出。调整了几次之后，才落到现在这个水平。
适合这样的人
- 家计簿App已经连接了银行卡，但大额支出的共享总是有时间差的人
- 想在家人之间明确划定「支出该商量的界线」的人
- 不排斥花时间逐步调整自动执行任务的误报和漏报的人
总结
排除固定支出和已经商量好的支出，只捞出剩下的大额支出，这个简单的筛选，我觉得正是让通知不会形同虚设的关键。
把同步延迟数值化，用来区分「只是没用」和「故障」的视角，以及给API调用次数设上限的这道刹车，两者看起来都不起眼，但对稳定地长期运行自动化，切实起到了作用。
这个机制捞出来的，终究只是会波动的支出。而通信费这类固定支出，性质不一样。与每次检查相比，一次性重新审视效果应该更持久。在推进自动化的同时，我也打算把目光投向那一边。
本文包含联盟营销广告。如果您通过本站链接申请相关商品或服务，我们可能会从合作企业获得报酬。此外，运营者是乐天集团的员工，也可能通过员工推荐计划获得报酬。文章内容与评价均基于运营者的真实体验与调查完成，与是否存在广告无关，但请您在阅读前了解上述关系。详情请参阅免责声明与联盟营销说明。 免责声明与联盟营销说明
本文包含机器翻译内容。正式条件请以乐天移动官方网站的多语言页面为准。
如果您对乐天移动的通信区域·信号状况有疑问，可以通过官方的 电波改善调查申请表 进行咨询。
