独立案例
Trip Balance 与 Splitwise 没有隶属、合作或背书关系，也不是完整替代品。案例使用原创名称、界面和虚构数据，不处理付款、不连接银行，也没有建立多人共享的云账户。
1 · 创建
说清楚参与者、
开销和余额。
在 Etono 中新建应用，输入需求，并在生成时保持应用打开。生成需要联网和 Credits（积分），结果与用量可能不同。实际操作使用英文；本页可复制的中文需求是实测英文指令的译文，未单独验证中文生成。完整英文原文见对应英文页面。
本次首次生成在保存可运行的应用后遇到积分不足。补充测试积分后才继续。这是经过修复的实际试跑，不是瞬间完成或全程无中断的生成。
创建一个名叫 Trip Balance 的旅行开销应用。我可以添加参与者、记录每笔开销由谁付款、将总额平均分摊，并查看每个人的余额。
2 · 检查
先用一组能手算的
数据检查结果。
打开生成的应用，在 People 中添加 Alex、Blair 和 Casey。记录三笔开销：Lodging（住宿）120 美元，由 Alex 支付；Dinner（晚餐）60 美元，由 Blair 支付；Taxi（出租车）30 美元，由 Casey 支付。每笔都包含这三个人。
实际界面显示总额 210 美元，平均每人承担 70 美元。先检查余额，再修改规则。
实测均摊结果
- Alex 支付 120 美元：应收回 50 美元。
- Blair 支付 60 美元：还需承担 10 美元。
- Casey 支付 30 美元：还需承担 40 美元。
正数表示已付金额超过自己承担的份额。三人的净余额合计为零；请核对你生成的版本如何表示正负数。
3 · 修改
改成按份数分摊，
保留已有开销。
返回对话，发送这条后续需求。修改后，People 中出现了份数控件，编辑开销时也增加了 By shares（按份数）选项。
第一次修改需要修复：控件已经出现，但调整份数时报错。我们正常停止了较长的检查过程，发送下面这条针对性请求，再亲自操作界面验证。
让我可以为每个人指定承担的份数，而不是全部平均分摊，并保留已有的所有参与者和开销。
修改失败时
描述具体问题，
明确要保留的数据。
下面是实际修复请求的中文译文。你可以换成自己遇到的可见错误和数据。等生成结束，或正常停止生成后，再手动编辑测试记录；这次试跑发现，两边同时操作会影响检查。
刷新后出现了份数控件，但点击 Alex 的 + 按钮会显示“Unknown endpoint”，份数仍为 1。请修复正在运行的应用，必要时重启这个应用的服务。保持 Alex、Blair、Casey 和三笔开销不变。请针对份数调整和保存完成检查，不要再花很长时间重写测试工具。
4 · 设置规则
Alex 承担两份，
另外两人各一份。
在 People 中将 Alex 调成 2 份，Blair 和 Casey 保持 1 份。本次生成的控件每次调整半份。这些设置是新开销的默认值，不会改写旧账单。
对已有的每笔开销点击 Edit，选择 By shares，把 Alex 设为 2，另外两人设为 1，再保存。保持原金额和付款人。实测三笔开销及其名称均保留。
实测 2:1:1 分摊结果
- 住宿 120 美元 → 60 / 30 / 30 美元。
- 晚餐 60 美元 → 30 / 15 / 15 美元。
- 出租车 30 美元 → 15 / 7.50 / 7.50 美元。
- 合计承担：Alex 105 美元；Blair、Casey 各 52.50 美元。
净余额为 Alex +15、Blair +7.50、Casey −22.50 美元。建议结算为 Casey 付给 Alex 15 美元、Blair 7.50 美元。这只是计算结果，应用不会实际转账。
5 · 使用与重开
在 Etono 中使用，
重开后再检查。
打开“运行”使用应用。离开并重新打开同一个项目，核对参与者、开销数量、金额和余额。本次还重新打开了 Etono，三笔按份数分摊的开销与金额仍在。生成检查停止后，再次离开并打开项目，Alex 的默认 2 份也保留了。
已在实际界面完成的检查
- 均摊和 2:1:1 结果与手算一致。
- 30 美元按 1.5:1:1 预览时，舍入为 12.86 + 8.57 + 8.57 = 30。
- 金额为零的草稿被拒绝，没有保存。
- 最终总额仍为 210 美元，三位参与者、三笔开销。
这是一个实测案例，不保证每次生成都相同。我们没有只凭自动检查就认定成功。
范围与使用条件