按摩 / 厨具 / 游泳散落多处
- 角色
- 产品设计与设计工程（服务架构 / 数据迁移）
- 时间
- 2026 · 24h first release, ongoing
- 平台
- Mobile Web / Desktop Web / PWA
一条轨道处理每天的记录；另一条轨道确保这些数据仍然属于自己。
01 / Context
不是再做一个记账界面
真正的问题是把多年私人数据从封闭工具迁出，同时保留手机快速录入、桌面分析和长期可恢复性。
早期 demo 已有视觉方向，但数据、同步和历史能力仍是假的。
早期移动图表验证了黑白黄语言，也暴露周期拥挤和状态反馈问题。
02 / Framing
先统一分类，再压缩录入决策
- 大类只表达消费领域，小类只表达具体事项。
- 同一事项只有一个归属，降低记账犹豫和分析噪音。
一个事项，一个稳定归属
分类从场景、物品、行为混用，重构为 12 个消费领域。
03 / Decision
一套 PWA，两种使用密度
- 手机负责快速记录、搜索和刷新。
- 桌面负责周期判断、类别下钻和整理。
- 不做原生 App，也不引入完整离线写冲突。
桌面端把周期判断、趋势和类别下钻放在同一工作台。
记一笔是全局动作，金额、类别、事项和日期在一个底部流程中完成。
移动端保留同一分析逻辑，但只显示当下决策所需的周期和指标。
搜索跨备注、具体事项和大类，以稳定游标渐进读取全部历史。
D1 保持事实一致，IndexedDB 让历史内容本机立即可见。
04 / System
本机立即可见，云端保持事实
结构化私人数据不进入 Service Worker HTTP cache；IndexedDB 负责本地读取，Worker 与 D1 负责认证和事实一致性。
先显示本机历史，后台静默校验；退出即清除私人缓存。
先读本机，后台校验；退出登录时清除私人缓存。
幂等写入
主库读取
周期查询
鉴权生成
备份校验
USER / FRONTSTAGE / BACKSTAGE
录入、同步、分析、导出和恢复被当作一条服务链，而不是孤立页面。
05 / Iteration
真实使用暴露了等待感
移动端慢并不只是接口延迟。固定周期、重复网络读取和过大的 loading 都会放大失控感，因此逐步改为全历史游标、本地优先和原位反馈。
大型 spinner
原位进度与低对比骨架
大型 spinner 被替换为原位进度与低对比骨架。
06 / Delivery
完成意味着数据能回来
- 真实登录、CRUD、搜索、导出和类别管理。
- migration、备份、恢复和发布 smoke。
- 私人产品，不开放注册，不伪造商业验证。
测试、迁移、导出、备份和恢复共同定义“完成”。
体验深描
痛点、用户故事与交互设计
这一段不讲技术栈，只讲「人在什么处境下用它、哪里卡住、我做了什么回应」。
我的痛点
这些项目都从我自己被卡住的地方开始。
- P01
多年账本锁在一个封闭 App 里：导不出、改不动，换设备等于从头再来。
- P02
记一笔要选账户、选分类、选子类、填金额、再确认——站在收银台前根本记不完，回家就忘了。
- P03
想回答「上个月餐饮花了多少、具体是哪几笔」，得在报表页和明细页之间来回跳。
- P04
原来的分类体系把场景和物品混在一起（「外卖」和「食品」同级），每次记账都要犹豫选哪个。
- P05
云端账本意味着我的真实财务数据放在别人服务器上——这件事我不接受。
用户故事
写成「作为…我想…以便…」，每条对应一个可验证的产品动作。
- US01
作为站在收银台前的人，我想几秒内记完一笔并立刻在当天流水里看到它，以便不必事后回忆。
- US02
作为做月度复盘的人，我想从年 / 月 / 周趋势直接下钻到某个类别的具体交易，以便看清钱究竟花在哪。
- US03
作为只记得模糊印象的人，我想用关键词搜全部历史备注，以便凭「上次那家店」找回那一笔。
- US04
作为数据的所有者，我想随时导出并恢复完整账本，以便这套系统哪天坏了我也不会失去多年记录。
- US05
作为跨设备使用者，我想手机负责记、桌面负责整理，以便每个设备只做它擅长的事。
用户体验旅程
按真实使用顺序展开：此刻在做什么 / 哪里有摩擦 / 产品怎么回应。
阶段此刻在做什么摩擦点产品回应
01记一笔
在店里单手拿着手机，需要在几秒内把这笔记下来。
多数记账工具要走完五步才落库，站着操作极易半途放弃。
记账是移动端的第一优先级：金额优先输入，写入使用幂等键，弱网重试也不会记重。
02同步
手机记完，晚上在桌面接着整理。
整屏 loading 会把「再记一笔」的连续动作打断。
去掉整屏 loading，进度改为安静的内联指示器；IndexedDB 走 stale-while-revalidate，本地先出、后台再校准。
03复盘
月末想知道这个月的钱去了哪里。
报表和明细常是两张割裂的页面，看到异常也点不进去。
年 / 月 / 周趋势与类别、日期、交易之间保持连续下钻，任何一个数字都能点开看到构成它的每一笔。
04查找
只记得「上次那家店」，想不起金额和日期。
分类检索对模糊记忆无能为力。
全局关键词搜索覆盖备注、具体事项与类别；稳定游标分页让全部历史与搜索结果渐进加载。
05归属
想确认这套系统不会反过来绑架我。
封闭工具的导出往往是残缺格式，换工具就等于丢历史。
导出、备份、恢复与 migration 保留在发布流程里；线上保持私人登录、不开放注册。
交互细节
决定「用起来顺不顺」的微观判断。
- 金额优先
- 进入记账页光标已经落在金额输入框，直接是数字键盘；分类默认沿用上一次的选择。
- 不做整屏 loading
- 加载状态用内联细指示器承载，内容永远先于进度出现。
- 幂等写入
- 每笔提交都带幂等键，弱网重试和重复点击都不会产生第二条账目。
- 本地先答
- IndexedDB 采用 stale-while-revalidate，明细、图表、搜索和类别详情在本机立即可见。
- 稳定游标分页
- 全部历史与搜索结果渐进加载，新增数据不会让正在滚动的列表错位。
- 设备分工
- 手机只承担「记」；类别管理、导出与批量整理放在桌面端完成。
设计细节
视觉系统、状态语言与节奏上的取舍。
- 黑白工作台 + 单一强调色
- 视觉延续黑白工作台，黄色只标记记账、选中、同步三类关键状态，不作装饰使用。
- 金额用整数分
- 金额以整数分存储与显示，避免浮点显示漂移，等宽数字让纵向对比更容易扫读。
- 分类体系重构
- 从混合场景与物品的旧体系，重构为 12 个消费领域与唯一归属的具体事项，消除同级歧义。
- 趋势与明细同一套视觉
- 图表与列表共用同一组色阶和排版尺度，从趋势下钻到交易时视觉不断层。
- 两套密度
- 移动端放大触控目标、单手可达；桌面端提高信息密度，服务分析与批量管理。