MVP 最佳方案规划

朋友间共同支出分摊结算 — 网页应用

版本 1.0  |  2026-06-27  |  面向产品决策者与核心团队

01产品概述

一句话定义:一个轻量级网页应用,帮助朋友出游、聚餐、合租时快速记账、智能清算,用最少的转账次数把钱算清楚。

核心价值主张:把"谁欠谁多少钱"这件事,从微信群里的反复对账变成一键生成的最优转账方案——附带每笔支出的明细追溯,精确到分,让算账不再伤感情。

02目标用户画像

主要用户群体

群体 A

大学生 / 年轻白领

频繁聚餐、出游,AA 制是常态,但谁来算、怎么算一直是问题。对工具要求:打开即用、不折腾。

群体 B

合租室友

水电、网费、日用品等共同支出持续发生,需要一个长期活动来持续记账和定期清算。

群体 C

情侣 / 伴侣

日常花销的分摊和记录,希望透明但不尴尬。两个人使用,场景简单但频率高。

群体 D

朋友圈子组织者

经常组织多人出游或活动的人("旅行中谁垫付的钱最多"这类问题的高频受害者)。

典型场景

场景 1:六人云南游

小王组织六位朋友去云南玩了五天,住宿、租车、吃饭加起来四十多笔支出,五个不同的人垫付过。行程结束后,群里有人提议"把账算一下吧",但没人愿意手动算。小王用 Excel 算了一下午,最后算出来有人还少转了一笔,被其他朋友质疑"是不是算错了"。气氛尴尬。

场景 2:四人群租房水电费

四个人合租,每个月水电煤气网费都是一个人先交、事后分摊。因为金额不大(几十到几百),大家习惯性拖延,每次催收都尴尬。月底了,谁还欠着上个月的钱,谁这次多付了,完全记不清。

场景 3:情侣日常支出

小明和小红在一起后,日常吃饭看电影的花销谁付的多谁付的少,谁也说不清。不是计较钱,而是希望有个透明记录,避免长期积累的微妙心理不平衡。

03核心问题与解决方案

用户当前怎么解决

方式操作描述典型体验
微信群记账 在群里发"我付了 120,四个人 AA"之类的文字 信息分散在聊天记录里,翻不到、对不上
口头约定 "下次你来付"、"回头转你" 容易忘,容易产生分歧,越积越多
Excel 手工算 自己建表格记录每笔支出,最后汇总 建表麻烦、算错了没人知道、维护成本高
微信/支付宝 AA 收款 用平台自带的 AA 功能 只能单笔 AA,无法优化转账次数,无法处理复杂场景

当前方案的核心痛点

  1. 清算低效:N 个人之间可能产生 N(N-1)/2 笔转账,实际只需 N-1 笔就够了
  2. 明细不透明:"你到底欠我多少"无法快速追溯到每一笔支出
  3. 操作门槛高:Excel 需要一定的表格技能,微信群记账则全凭记忆
  4. 维护成本:记录和算账的时间成本远大于支出本身的价值
  5. 社交摩擦:反复催账、算错账都容易引发朋友间的不愉快

本产品的解决方案差异

智能清算算法

自动计算最少转账次数的最优方案,把 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 实现成本)

低成本
高成本
高价值
Quick Win(优先做)
快速记支出、一键清算、转账状态追踪、导出分享、创建活动
战略投入
专属邀请链接 + 认领身份、总预算 + 实时进度
中价值
填充项
历史统计、推送通知
慎重评估
跨活动债务抵消、OCR 记账

05核心技术挑战

5.1 最优清算算法(最少转账次数)

这是整个产品最核心的技术壁垒。目标是:给定 N 个人的净收支情况,计算出最少的转账次数,使所有人的债务清零。

基本思路:将问题转化为有向图上的最小费用流问题,或用贪心策略 + 背包优化的近似算法。

算法概要

  1. 计算净额:对每个人,净额 = 垫付总额 - 应承担份额总额。正数表示应收(别人欠他),负数表示应付(他欠别人)。
  2. 贪心合并:找出净额最大的"应收方"和净额绝对值最大的"应付方",进行一笔转账(取两者中绝对值较小者),更新双方的净额。重复直到所有净额归零。
  3. 优化上限:贪心法在最坏情况下产生 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 "席位-用户"延迟绑定机制

创建活动时,只需要输入成员昵称(创建"席位"),不需要注册或登录。生成专属链接后,朋友打开链接、认领自己的昵称,此时席位才和真实用户绑定。这保证了:

  • 零注册门槛:创建者和参与者都不需要注册账号
  • 数据归属清晰:只有认领了身份的人才能编辑自己相关的记录
  • 隐私保护:未认领的席位不关联任何个人信息
sequenceDiagram participant C as 创建者 participant S as 系统 participant F as 朋友 C->>S: 输入活动名 + 成员昵称列表 S->>S: 创建活动,生成 N 个"席位" S-->>C: 返回活动 ID + 专属邀请链接 C->>F: 分享邀请链接(微信/短信等) F->>S: 打开链接,看到席位列表 F->>S: 认领自己的昵称("我是小王") S->>S: 绑定:席位 "小王" ←→ 用户身份 S-->>F: 认领成功,可查看明细 C->>S: 记支出 / 一键清算

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 迭代路线图

V1 — 核心闭环

MVP 上线

实现 7 个核心模块:创建活动、快速记支出、总预算 + 进度、邀请链接 + 认领身份、一键清算 + 明细追溯、转账状态追踪、导出/截图分享。

目标:验证核心假设,跑通"记账 → 清算 → 分享"的完整链路。

V2 — 留存增强

跨活动 + 统计 + 通知

跨活动债务抵消:如果 A 和 B 在多个活动中互有欠款,自动合并为净额,进一步减少转账。

历史统计:查看月度/年度支出总览、最高消费类别。

推送通知:有人记了新支出或标记转账完成时,通知相关成员。

V3 — 体验扩展

OCR / 语音 / 多币种 / 社交

OCR 拍照记账:拍小票自动识别金额和商户。

语音记账:说"午饭 86 块,我请了小李小张"自动录入。

多币种:跨境出游时按实时汇率自动换算。

社交增强:活动照片墙、评论、表情互动。

graph LR V1["V1
核心闭环
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关键假设与验证方法

假设 1

用户愿意为"减少转账次数"而使用独立工具

如果用户觉得"微信转账就够了",清算优化的价值就不成立。

验证方法:在产品上线前做 landing page 测试,用"4 个人之间只需 3 笔转账 vs 原来的 6 笔"的对比图作为核心卖点,看访问 → 注册转化率。如果转化率 ≥ 5%,说明需求存在。同时在 V1 上线后追踪清算功能使用率(目标 ≥ 50%),使用率过低说明清算优化并非核心需求。

假设 2

3 秒记账的操作体验是留存关键

如果记账操作超过 5 秒,用户会觉得"还不如微信群发一下"。

验证方法:V1 上线后埋点统计记账操作时长分布。对比"3 秒内完成"和"3 秒以上完成"两组用户的后续留存率。如果两组差异显著(≥ 15%),说明操作速度确实影响留存。同时做 A/B 测试,简化一个字段(如默认参与人为全部成员),看完成率变化。

假设 3

分享/导出功能是核心传播路径

如果产品的增长主要依赖"一个人用完分享给其他人"的链路,那么分享体验就决定了增长效率。

验证方法:追踪每条邀请链接被打开的次数和认领转化率。统计"新用户中通过邀请链接进入"的比例(目标 ≥ 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. 社区口碑:在大学生、旅行社区中建立口碑