Smart Ledger
付款记录到长期账本的交互探索
以付款凭证接入账本为设计假设，设计 AI 草稿、人工确认、账本与分析的交互结构，用前端原型检查一笔记录的完整路径。
独立概念项目 · 使用样例数据展示录入、核对、写入与分析的交互流程。
关键设计判断
怎样把付款凭证变成可追溯、可确认的账目？
- 设计出发点
- 以截图和自然语言录入的个人记账场景为出发点，围绕一笔账目组织凭证、金额、商户与时间，减少重复填写并保留核对入口。
- 关键取舍
- AI 只生成可编辑草稿，经用户确认后才写入账本；预算与分析回到已确认记录。保留人工确认，避免错误事实直接进入后续分析。
- 原型走查
- 交互原型使用样例数据，逐步展示录入、核对、写入与追溯；原始凭证、字段草稿与确认记录相互对应。
典型界面讲解
付款信息，先进入核对
这个入口承接已有付款凭证：AI 先生成草稿，用户核对后才写入。示例用于说明结构与状态。
快速记录AI 生成草稿，由你确认。
午餐 Northstar Cafe，38 元，示例卡 4242
待确认付款凭证作为依据
先有商户、金额与时间等付款信息，再进入记账。
AI 先准备草稿
把生成与确认区分开，避免将草稿当成正式记录。
核对后才写入
将核对动作保留在入口，确认后再进入长期账本。
先核对草稿，再写入账本
付款信息先生成可编辑草稿，由用户核对后才成为正式记录。以下原型使用示例数据呈现这条边界。
把 AI 放在起草的位置
我将自动提取与正式记账分开。凭证中的金额和商户可以成为草稿，但还需要用户核对，不能把提取成功等同于记录正确。
快速记录AI 生成草稿，由你确认。
午餐 Northstar Cafe，38 元，示例卡 4242
待确认把写入决定留给人
用户确认是草稿进入账本的边界。我用这个边界约束后续预算与分析，避免尚未核对的内容被当作可靠记录。
Northstar CafeDining · Demo card 4242
-¥38.0001Green Line MetroTransit · Demo wallet
-¥6.0002Paper & PineShopping · Demo card 4242
-¥126.0003让记录、预算和分析回到同一份账本
记录确认后，用户还需要查找来源并理解支出。我设计账本、规划与分析的信息结构，保留凭证关联，使后续判断能够追溯到已确认的记录。
总览May 2026
示例数据快速记录AI 生成草稿，由你确认。
午餐 Northstar Cafe，38 元，示例卡 4242
待确认Northstar CafeDining · Demo card 4242
-¥38.0001Green Line MetroTransit · Demo wallet
-¥6.0002Paper & PineShopping · Demo card 4242
-¥126.0003AI 草稿与正式记录分开呈现
付款信息先进入草稿，核对后才进入账本。我将快捷录入留在独立入口，明确表达 AI 起草、用户确认的分工，避免未核对的信息直接混入分析。
快速记录AI 生成草稿，由你确认。
午餐 Northstar Cafe，38 元，示例卡 4242
待确认账本只显示已确认的记录
我把确认标记与记录列表放在一起，让用户区分可使用的账本数据和待核对的输入。预算与分析围绕这份已确认记录组织。
Northstar CafeDining · Demo card 4242
-¥38.0001Green Line MetroTransit · Demo wallet
-¥6.0002Paper & PineShopping · Demo card 4242
-¥126.0003