我用 vibe coding 开发了一个多人记账小程序
最近我用 vibe coding 的方式开发了一个微信小程序：猫猫鱼记账。
它不是一个“记一笔收入支出”的通用账本，而是专门解决一个很具体、也很真实的问题：
多人出游时，谁垫了钱？谁参与分摊？情侣、家庭、朋友之间怎么合并结算？最后到底谁该转给谁多少钱？
如果你经历过旅行结束后在群里翻账单、拉 Excel、手算 AA、反复对齐“这顿饭谁没吃”的痛苦，大概就能理解我为什么想做这个小程序。
为什么要做多人出游记账？
普通记账软件更关心“我花了多少钱”，但多人出游更关心的是：
- 这笔钱是谁垫付的？
- 哪些人需要参与分摊？
- 有些人是一家人，最后能不能按家庭统一结算？
- 有公共基金，应该怎么公平抵扣？
- 行程结束后，能不能生成清晰的最终转账建议？
所以猫猫鱼记账的核心不是“分类统计”，而是 协作记账 + 结算算法。
vibe coding 在这个项目里怎么用？
我理解的 vibe coding 不是“让 AI 随便生成一个 demo”，而是：
人负责产品判断、业务边界和体验取舍，AI 辅助快速实现、重构、补测试和验证细节。
在这个项目里，我主要把精力放在这些问题上：
- 多人记账的真实业务流是什么？
- 哪些权限必须后端兜底？
- 账单、成员、家庭、基金之间的数据关系怎么设计？
- 结算算法如何保证一分钱不差？
- 小程序页面如何避免变成一堆混乱按钮？
AI 则更多参与：
- TypeScript 类型建模
- 云函数 action 实现
- 小程序页面和组件拆分
- 结算算法测试用例补充
- 表单逻辑和状态处理
- 文档同步和代码检查
这种模式很适合中小型产品原型到可用版本的开发：节奏快，但不牺牲基本工程质量。
技术栈
猫猫鱼记账目前采用的是比较朴素但稳定的技术方案：
微信原生小程序
TypeScript
CloudBase 云函数
CloudBase 数据库
pnpm workspace
共享 domain 包
一些工程实践
这个项目虽然体量不大，但我还是尽量按真实产品来做。
类型先行
成员、账单、队伍、家庭、结算结果都用 TypeScript 明确定义，减少前后端字段漂移。
权限后置兜底
小程序端可以根据权限隐藏按钮，但云函数必须重新校验。
比如：
- 归档队伍不能再新增账单
- 普通成员只能编辑自己创建的账单
- 管理员不能被移出
- 有账单引用的成员不能直接删除
- 邀请加入必须校验 token
金额整数化
结算场景里最怕浮点误差。
所以算法内部统一使用“分”作为整数单位，最终展示时再转回“元”。
归档不可变
已归档账本只能查看，不能继续协作，避免历史账务被误改。
vibe coding 带来的感受
这次开发最大的感受是：
AI 很适合帮你把已经想清楚的东西快速落地，但不适合替你想清楚产品本身。
比如“多人出游记账”这个场景，看起来简单，实际会遇到很多细节：
- 被邀请人有没有身份？
- 管理员能不能预置成员？
- 普通成员能不能管理家庭？
- 账单创建者离队了怎么办？
- 删除队伍是真的删除还是逻辑删除？
- 归档后算法变化怎么办？
- 基金抵扣怎么保证公平？
这些问题如果不先想清楚，AI 生成代码只会越写越乱。
但当产品规则、数据模型和权限边界明确之后，AI 的效率就非常高。它可以快速补齐页面、服务封装、测试和文档，让开发者把注意力更多放在架构和体验上。
总结
猫猫鱼记账是一个用 vibe coding 做出来的多人出游记账小程序。
它目前支持：
- 创建出游队伍
- 邀请成员加入
- 成员身份认领
- 多人协作记账
- 猫猫基金抵扣
- 家庭合并结算
- 最终转账建议
- 队伍归档快照
这个项目让我更确信一件事：
vibe coding 不是偷懒写代码，而是把人的判断力和 AI 的执行力组合起来。
当你能清楚描述业务规则、边界条件和用户体验时，AI 会变成一个非常强的工程搭档。
如果你也有一个搁置很久的小产品想法，现在可能真的是把它做出来的好时候。
