--- title: "聚餐账单口述分摊" date: "2026-08-03" canonical: "https://raytally.com/ideas/2026-08-03-finamie/" generator: "萤录 RayTally · dev-prompt-v4" signal: query: "Finamie" observed_at: "2026-08-03T00:33:14.344Z" sources: - url: "https://www.producthunt.com/products/finamie-know-your-money-for-real" boundary: "观测于 2026-08-03T00:33:14.344Z。" - url: "https://developer.mozilla.org/en-US/docs/Web/API/MediaRecorder" boundary: "发布于 2024-07-26T00:00:00.000Z。" - url: "https://www.splitwise.com/" boundary: "来源记录未提供发布时间。" - url: "https://www.quassama.com/" boundary: "来源记录未提供发布时间。" notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。" --- [在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-03-finamie/) 使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。 你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。 ## 灵感 聚餐账单口述分摊 聚餐或旅行后说清总额和例外，立即得到每个人的分摊明细与收款链接。 ## 产品概念 朋友聚餐、旅行拼车或合租采购后，最难算的往往不是总金额，而是例外：有人没喝酒，有人只参加后一段，还有一笔钱由某人先垫。大家各自打开表格补数字，容易把尴尬拖成一串来回追问。 垫付者直接说出一句完整的话，例如“晚饭 680，我先付，小李没喝酒，酒钱其他三人分”。产品从口述中识别金额、垫付人、参与者和例外项目，把不确定的部分变成一个具体追问，例如“酒钱是多少”。用户确认后，账单立刻拆成每个人的明细。 每位参与者收到自己的项目、应付金额和收款链接。有人质疑分摊时，可以点开看到“未喝酒”或“只坐了半程”这类计算依据，而不是只看到一个结果数字。付款状态会回到同一张账单，垫付者不用在群聊里逐个催问。 第一版先覆盖人民币金额、固定参与者和常见的按人头或按项目例外。它不替用户猜测谁该承担什么，也不代替复杂报销规则；关键是把当场说清的一句话立刻变成人人看得懂的分摊。 ## 为什么是现在（有事实支撑） 截至8月3日观察时，Finamie 位于 Product Hunt 新品流第10位，页面主张用口述记录开支并即时获得洞察。 这让“说一句就录入”更容易被用户拿来比较，也把多人账单仍需手填例外的问题推到眼前。 ## 方向判断（以下为模型推断，未经独立验证） 目标用户：主要用户是聚餐或短途旅行中先垫钱的人，尤其是临散场才发现分摊有例外的人。此时大家急着离开，重新建表或逐个询问项目很容易拖延。合租采购的固定群组也适合，成员经常不同，承担项目又不完全一致。价值来自当场确认规则，让付款依据留在同一张账单里。 最小切入点：网页端先用 MediaRecorder 采集短音频，它在主流浏览器已有较广支持。 转写后只抽取总额、币种、垫付人、参与者、项目和排除规则。数据保存为结构化账单，不让模型直接计算最终金额。规则引擎仅支持等分、指定金额、按项目排除和分段参与。缺少必要字段时，只生成一个具体追问。确认页展示原话、解析结果和逐人算式，修改后立即重算。收款链接先落到共享账单页，并附垫付者收款码。付款状态由双方确认，首版不接资金清算。 最强反方：口语里的省略最容易算错，例如“其他三人”依赖前文名单。一次错误分摊就会引发追问，发起人反而要逐项修正。酒钱、优惠、服务费和后到早退常会叠加，规则组合会迅速膨胀。收款码只能完成转账，无法可靠回传到账状态。改用双边确认又会增加操作。语音与账单涉及敏感关系和消费信息，存储、删除与访问权限必须讲清。若多数项目最终仍要手工核对，语音入口的速度优势就不成立。 以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。 ## 以小博大（模型推断） 首批用户更可能来自旅行搭子群、合租群和桌游局组织者。用真实长句制作短视频，让观众看到系统只追问缺失的“酒钱是多少”。参与者账单页应免注册打开，付款人从群链接进入即可核对，发起人会自然完成一次传播。再围绕“有人没喝酒”“只坐半程”等例外制作可搜索模板。 ## 竞品与缝隙（模型推断） - Splitwise：Splitwise 已覆盖群组、垫付、等额与不等额分摊，也支持按比例和份数计算。其付费功能还有收据扫描、逐项分配、币种转换和交易导入。 它的账本、余额与结算链路已经成熟，用户也能回看和修改旧账。现有流程仍要求先建费用，再选择付款人和分摊方式。收据逐项分配适合对着小票操作，却没有替发起人理解口头例外。公开功能也未展示针对缺失条件的单点追问。每个人通常看到余额和费用记录，还需自行理解为何承担某一项。可利用的缝隙是口述建账与解释层，而不是重做完整余额系统。解析结果若能导出，也可以与其并存。 - Quassama：Quassama 已把语音记账、群组费用、百分比分摊、收据识别和余额计算放在同一产品中。 它说明“说出开支”和“多人分账”已有直接相邻产品。公开页面强调语音捕捉金额与明细，也展示五五分或按比例拆分。页面没有展示一句话同时识别垫付人、参与者和排除项。也没有展示在酒钱缺失时，只追问这一个条件。缝隙因此很窄，重点是中文关系指代与例外规则。产品不应扩成泛化的语音财务助手。若只能完成“晚饭六百八”这类单笔录入，差异会立即消失。还要用可展开的算式证明解析结果，否则用户会回到手工分摊。 ## 怎么赚钱（模型推断） 基础拆账免费；向经常组织旅行、合租或活动的发起人收取月度订阅费，解锁账单归档、重复群组、批量提醒和数据导出。 ## 来源背景 主题：语音记账与消费洞察工具 Finamie 触发的 Product Hunt 新品：Finamie — Speak your expenses and get instant spending insights 以上只记录新品出现在 Product Hunt 公开 feed 与被观测的事实；该 feed 不提供票数，不要把 feed 顺序描述成热度或市场需求。 ## 来源清单 - Finamie — Speak your expenses and get instant spending insights（https://www.producthunt.com/products/finamie-know-your-money-for-real） - MediaRecorder - Web APIs（https://developer.mozilla.org/en-US/docs/Web/API/MediaRecorder） - Split expenses with friends（https://www.splitwise.com/） - Quassama - Speak Your Expenses（https://www.quassama.com/） ## 交付要求 - 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。 - 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。 - 页面或接口里不要展示未经验证的市场数字。 - 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。 - 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。 - 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。 - 完成后说明改了什么、如何运行、如何验证。 - 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。