MVP 最佳方案规划
朋友间共同支出分摊结算 — 网页应用
01产品概述
一句话定义:一个轻量级网页应用,帮助朋友出游、聚餐、合租时快速记账、智能清算,用最少的转账次数把钱算清楚。
核心价值主张:把"谁欠谁多少钱"这件事,从微信群里的反复对账变成一键生成的最优转账方案——附带每笔支出的明细追溯,精确到分,让算账不再伤感情。
02目标用户画像
主要用户群体
大学生 / 年轻白领
频繁聚餐、出游,AA 制是常态,但谁来算、怎么算一直是问题。对工具要求:打开即用、不折腾。
合租室友
水电、网费、日用品等共同支出持续发生,需要一个长期活动来持续记账和定期清算。
情侣 / 伴侣
日常花销的分摊和记录,希望透明但不尴尬。两个人使用,场景简单但频率高。
朋友圈子组织者
经常组织多人出游或活动的人("旅行中谁垫付的钱最多"这类问题的高频受害者)。
典型场景
场景 1:六人云南游
小王组织六位朋友去云南玩了五天,住宿、租车、吃饭加起来四十多笔支出,五个不同的人垫付过。行程结束后,群里有人提议"把账算一下吧",但没人愿意手动算。小王用 Excel 算了一下午,最后算出来有人还少转了一笔,被其他朋友质疑"是不是算错了"。气氛尴尬。
场景 2:四人群租房水电费
四个人合租,每个月水电煤气网费都是一个人先交、事后分摊。因为金额不大(几十到几百),大家习惯性拖延,每次催收都尴尬。月底了,谁还欠着上个月的钱,谁这次多付了,完全记不清。
场景 3:情侣日常支出
小明和小红在一起后,日常吃饭看电影的花销谁付的多谁付的少,谁也说不清。不是计较钱,而是希望有个透明记录,避免长期积累的微妙心理不平衡。
03核心问题与解决方案
用户当前怎么解决
| 方式 | 操作描述 | 典型体验 |
|---|---|---|
| 微信群记账 | 在群里发"我付了 120,四个人 AA"之类的文字 | 信息分散在聊天记录里,翻不到、对不上 |
| 口头约定 | "下次你来付"、"回头转你" | 容易忘,容易产生分歧,越积越多 |
| Excel 手工算 | 自己建表格记录每笔支出,最后汇总 | 建表麻烦、算错了没人知道、维护成本高 |
| 微信/支付宝 AA 收款 | 用平台自带的 AA 功能 | 只能单笔 AA,无法优化转账次数,无法处理复杂场景 |
当前方案的核心痛点
- 清算低效:N 个人之间可能产生 N(N-1)/2 笔转账,实际只需 N-1 笔就够了
- 明细不透明:"你到底欠我多少"无法快速追溯到每一笔支出
- 操作门槛高:Excel 需要一定的表格技能,微信群记账则全凭记忆
- 维护成本:记录和算账的时间成本远大于支出本身的价值
- 社交摩擦:反复催账、算错账都容易引发朋友间的不愉快
本产品的解决方案差异
智能清算算法
自动计算最少转账次数的最优方案,把 N(N-1)/2 笔转账压缩到最少。
明细追溯
每笔转账建议都附带"为什么转这么多"的支出明细,有据可查,避免误会。
轻量 Web
不用下载 App,打开链接就能用,3 秒记一笔支出,降低使用门槛到最低。
04MVP 功能范围与优先级
MoSCoW 分类
Must Have 必须做 — V1 核心闭环(7 个模块)
| # | 模块 | 说明 |
|---|---|---|
| 1 | 创建活动 + 邀请成员 | 输入活动名称、成员昵称,快速建活动 |
| 2 | 快速记支出 | 输入金额、选择垫付人、勾选参与人 |
| 3 | 总预算设定 + 实时进度 | 设定预算上限,实时展示已花费比例 |
| 4 | 专属邀请链接 + 认领身份 | 生成可分享链接,朋友打开后认领自己的昵称 |
| 5 | 一键清算 | 最优算法生成转账方案 + 明细追溯,精确到分 |
| 6 | 转账状态追踪 | 每笔转账标记已结清 / 未结清 |
| 7 | 导出 / 截图分享 | 导出清算结果图片或文字摘要 |
Should Have 应该做但可推迟 — V2
- 跨活动债务抵消:如果 A 和 B 在多个活动中都有往来,允许合并计算净额
- 历史统计:查看过去的活动数据、月度支出趋势
- 推送通知:有人记了一笔新支出时,通知参与人
Could Have 可以做 — V3
- 多币种支持:跨境出游时自动换算
- OCR 拍照记账:拍小票自动识别金额
- 语音记账:说一句话完成一笔支出录入
Won't Have 明确不做
- 深度打通微信 / 支付宝:不做自动扣款或资金托管,避免合规风险
- 社交裂变功能:不做邀请奖励、排行榜等增长 hack
- 金融产品导流:不接入借贷、理财、支付通道
功能优先级矩阵(价值 vs 实现成本)
快速记支出、一键清算、转账状态追踪、导出分享、创建活动
专属邀请链接 + 认领身份、总预算 + 实时进度
历史统计、推送通知
跨活动债务抵消、OCR 记账
05核心技术挑战
5.1 最优清算算法(最少转账次数)
这是整个产品最核心的技术壁垒。目标是:给定 N 个人的净收支情况,计算出最少的转账次数,使所有人的债务清零。
基本思路:将问题转化为有向图上的最小费用流问题,或用贪心策略 + 背包优化的近似算法。
算法概要
- 计算净额:对每个人,净额 = 垫付总额 - 应承担份额总额。正数表示应收(别人欠他),负数表示应付(他欠别人)。
- 贪心合并:找出净额最大的"应收方"和净额绝对值最大的"应付方",进行一笔转账(取两者中绝对值较小者),更新双方的净额。重复直到所有净额归零。
- 优化上限:贪心法在最坏情况下产生 N-1 笔转账,这已经是理论下界,因此对大多数场景已是最优解。
// 伪代码:贪心清算算法
function settle(balances) {
// balances: { name: netAmount } 正=应收,负=应付
const creditors = persons with positive balance, sorted desc
const debtors = persons with negative balance, sorted asc
const transfers = []
while (creditors not empty && debtors not empty) {
const c = creditors[0] // 最大应收方
const d = debtors[0] // 最大应付方
const amount = min(c.balance, -d.balance)
transfers.push({ from: d.name, to: c.name, amount })
c.balance -= amount
d.balance += amount
remove zero-balance persons from their lists
}
return transfers // 最多 N-1 笔转账
}
精确到分:所有中间计算使用整数(分为单位),避免浮点误差。最终结果四舍五入到分,差额(如有,不超过 N-1 分)由绝对值最大的一方承担。
5.2 "席位-用户"延迟绑定机制
创建活动时,只需要输入成员昵称(创建"席位"),不需要注册或登录。生成专属链接后,朋友打开链接、认领自己的昵称,此时席位才和真实用户绑定。这保证了:
- 零注册门槛:创建者和参与者都不需要注册账号
- 数据归属清晰:只有认领了身份的人才能编辑自己相关的记录
- 隐私保护:未认领的席位不关联任何个人信息
5.3 精确到分的金额计算
所有金额在内部使用"分"作为单位进行整数运算,前端展示时转换为"元.分"格式。关键规则:
- 输入:允许用户输入到分(如 123.45),存储为整数 12345
- 分摊计算:每人应承担 = 总额 / 参与人数,使用整数除法向下取整
- 尾差处理:余数(不足 1 分的部分)分配给第一个参与人(或按指定规则分配)
- 清算结果:每笔转账金额精确到分,展示为"XX 元 YY 分"
// 伪代码:精确到分的分摊
function split(totalCents, participants) {
const perPerson = Math.floor(totalCents / participants.length)
const remainder = totalCents - perPerson * participants.length
const shares = participants.map((p, i) => ({
name: p,
cents: perPerson + (i < remainder ? 1 : 0)
}))
return shares
// 例如:100 分 / 3 人 → [34, 33, 33]
}
06竞品分析简要
| 维度 | Splitwise | 微信/支付宝 AA | 本产品 |
|---|---|---|---|
| 平台 | App(iOS/Android) | App 内置功能 | 轻量 Web(打开即用) |
| 清算优化 | 支持,但算法不透明 | 不支持,逐笔 AA | 最少转账 + 明细追溯 |
| 使用门槛 | 需下载 App + 注册 | 极低(但功能单一) | 极低(链接即用,无需注册) |
| 明细追溯 | 有,但查看路径深 | 无 | 清算方案直接附带每笔支出 |
| 本地化 | 英文为主,中文体验一般 | 原生中文 | 原生中文 |
| 定位 | 全球通用,功能全但偏重 | 支付工具的附加功能 | 专注清算优化的轻量工具 |
本产品的核心差异点
清算算法
不是简单的"总额除以人数",而是计算最少转账次数的最优方案,减少不必要的转账操作。
明细追溯
每笔转账都关联到具体的支出记录,用户可以清楚看到"这笔钱为什么是这个数"。
轻量化 Web
无需下载 App、无需注册,打开链接就能用。和朋友分享的门槛降到最低。
07成功指标
| 类别 | 指标 | V1 目标 | 说明 |
|---|---|---|---|
| 核心指标 | 活动创建完成率 | ≥ 70% | 开始创建活动 → 成功创建并添加 ≥ 2 名成员的比例 |
| 清算使用率 | ≥ 50% | 有 ≥ 3 笔支出的活动中,使用一键清算功能的比例 | |
| 分享/导出率 | ≥ 30% | 清算完成后,分享链接或导出图片的比例 | |
| 留存指标 | 7 日回访率 | ≥ 20% | 创建活动 7 天内再次访问的比例 |
| 二次创建率 | ≥ 15% | 创建过活动的用户在 30 天内再次创建新活动的比例 | |
| 体验指标 | 记账操作时长 | ≤ 3 秒 | 从点击"记一笔"到支出保存完成的时间 |
北极星指标:活动创建完成率。因为用户创建了活动并成功邀请成员,意味着产品核心价值已经被感知。
08V1 → V2 → V3 迭代路线图
MVP 上线
实现 7 个核心模块:创建活动、快速记支出、总预算 + 进度、邀请链接 + 认领身份、一键清算 + 明细追溯、转账状态追踪、导出/截图分享。
目标:验证核心假设,跑通"记账 → 清算 → 分享"的完整链路。
跨活动 + 统计 + 通知
跨活动债务抵消:如果 A 和 B 在多个活动中互有欠款,自动合并为净额,进一步减少转账。
历史统计:查看月度/年度支出总览、最高消费类别。
推送通知:有人记了新支出或标记转账完成时,通知相关成员。
OCR / 语音 / 多币种 / 社交
OCR 拍照记账:拍小票自动识别金额和商户。
语音记账:说"午饭 86 块,我请了小李小张"自动录入。
多币种:跨境出游时按实时汇率自动换算。
社交增强:活动照片墙、评论、表情互动。
核心闭环
7 个模块"] --> V2["V2
跨活动抵消
统计 + 通知"] V2 --> V3["V3
OCR / 语音
多币种 / 社交"] style V1 fill:#ecfdf5,stroke:#047857,color:#047857 style V2 fill:#fffbeb,stroke:#92400e,color:#92400e style V3 fill:#f0f9ff,stroke:#0369a1,color:#0369a1
09关键假设与验证方法
用户愿意为"减少转账次数"而使用独立工具
如果用户觉得"微信转账就够了",清算优化的价值就不成立。
验证方法:在产品上线前做 landing page 测试,用"4 个人之间只需 3 笔转账 vs 原来的 6 笔"的对比图作为核心卖点,看访问 → 注册转化率。如果转化率 ≥ 5%,说明需求存在。同时在 V1 上线后追踪清算功能使用率(目标 ≥ 50%),使用率过低说明清算优化并非核心需求。
3 秒记账的操作体验是留存关键
如果记账操作超过 5 秒,用户会觉得"还不如微信群发一下"。
验证方法:V1 上线后埋点统计记账操作时长分布。对比"3 秒内完成"和"3 秒以上完成"两组用户的后续留存率。如果两组差异显著(≥ 15%),说明操作速度确实影响留存。同时做 A/B 测试,简化一个字段(如默认参与人为全部成员),看完成率变化。
分享/导出功能是核心传播路径
如果产品的增长主要依赖"一个人用完分享给其他人"的链路,那么分享体验就决定了增长效率。
验证方法:追踪每条邀请链接被打开的次数和认领转化率。统计"新用户中通过邀请链接进入"的比例(目标 ≥ 60%)。如果比例低于 30%,说明自然搜索或直接访问是主要来源,需要调整增长策略。
10风险与应对
| # | 风险 | 等级 | 分析 | 应对策略 |
|---|---|---|---|---|
| 1 | 使用频率低 不是每天用的工具,用户容易遗忘 |
高 | 分摊记账天然是低频场景——可能一周用一次、一个月用一次。低频产品很难靠 Habit 留存。 |
1. 降低回访门槛:邀请链接可直接打开活动,无需登录 2. 清算完成后推送摘要通知,包含链接 3. V2 加入历史统计,增加访问理由 4. 导出图片带产品水印,增强品牌记忆 |
| 2 | "算太清楚伤感情" 用户心理障碍:觉得用工具算账显得小气 |
中 | 这是文化心理问题。中文语境下,朋友间算得太细可能被视为"斤斤计较"。 |
1. 产品调性:定位为"帮大家省事"而非"帮大家讨债" 2. UI 语言柔和:避免"欠"、"追债"等字眼,使用"需结算"等中性表述 3. 强调透明而非精确:明细追溯是为了"大家心里有数",不是为了追究 4. 提供模糊模式:清算结果可四舍五入到整元,减少零头带来的心理摩擦 |
| 3 | Splitwise 本地化 如果 Splitwise 大力投入中国市场 |
中 | Splitwise 功能成熟、用户基数大,一旦做好中文体验会是强对手。但目前来看其本地化意愿和能力有限。 |
1. 速度优势:轻量 Web vs 原生 App,冷启动更快 2. 深耕场景:聚焦"中国式 AA"(微信 AA 的替代方案),而非做通用工具 3. 算法透明:清算逻辑完全公开,建立信任壁垒 4. 社区口碑:在大学生、旅行社区中建立口碑 |