Lazy Susan

Lazy Susan 分摊餐馆账单时既不用打字，也不用把小票上传到任何地方：给小票拍张照片，Donut——一个在你的浏览器标签页里运行的开放权重文档模型——就会把每一行直接读成「名称+价格」的条目。选一个人，点一点他吃了什么（合吃的菜就给每个分吃的人都点上），税费、服务费和小费按比例分摊，精确到分；点一个按钮，就能把分摊结果复制成一条消息发到群聊里。

诀窍在于：由小票来检验模型。各行金额必须加起来等于小计，或者加上税费、服务费和折扣后等于总计；如果 Donut 读出的数字对不上，第二个开放模型 Florence-2 会再读一遍照片，能对上账的那份读取胜出。只有当恰好有一种修正能让账目成立时，应用才会应用它——并且会告诉你，例如它省略了酒吧的地址，因为那是唯一让账对不上的行——而当怎么算都对不上时，它会如实说明、显示差了多少，并把缺失的金额作为一行列出来，而不是靠猜。

Vibe coding 的证据来自作者在 DEV 上的原话（2026 年 10 月 24 日）：「I built this with Claude Code as a pair programmer, and did not save the session to DevRelay, so here is the next best thing: every number in this post can be re-run.（这是我用 Claude Code 作为结对编程伙伴做的，我没有把会话保存到 DevRelay，所以退而求其次：这篇帖子里的每个数字都可以重新跑一遍验证。）」作者用一个可复跑的测试框架来支撑这一说法：在 472 张 WildReceipt 测试小票加 100 张 CORD 测试小票上，Donut + Florence-2 + 算术校验能在 33% 的美国小票上把每一行都读对；而在应用标记为「账目成立」的小票上，每一行都读对的比例是 93%。GitHub star 数：截至 2026 年 10 月 29 日核查时为 0（github.com/VanshajPoonia/lazy-susan；MIT；创建和最近推送均为 2026 年 10 月 24 日）。

如实说明的局限：第一张照片需要一次性下载 Donut（219 MB），只有当某张小票需要二次读取时才会下载 Florence-2（266 MB），所以第一次运行很慢——在作者的 M4 笔记本上，用 Chrome 读一张清晰小票要 8 到 12 秒，二次读取要 21 到 26 秒，在手机上更慢（未测量）。约三分之一的美国小票仍然很难读——褪色的热敏纸、倾斜的照片、过小的图片——而且浏览器版本明显弱于 Node 测试框架（同样的前 50 张小票，全对率 23% 对 36%），作者选择公开这个差距，而不是藏起来。