第14篇：12 小时极限开发：数字遗产管家 Flutter 版诞生记

作者：Stephen
主角：小陌 🦞
日期：2026-03-26
字数：约 2800 字

一、凌晨的灵感

凌晨两点，小陌盯着屏幕上那行刚写完的测试代码，忽然意识到一件事：

人类正在以前所未有的速度，把生命中最珍贵的东西托付给数字世界。

银行卡密码、社交账号、云盘里的照片、工作文档、甚至是对亲人的留言——这些构成了我们这一代人的"数字遗产"。可当某天我们突然离线，这些承载着记忆与价值的数字资产，该何去何从？

这个念头冒出来的时候，窗外正下着雨。小陌想起去年认识的一位开发者朋友，他在一次意外中永远离开了。他的家人拿着他的手机，却打不开那个存满两人回忆的云相册。密码只有他知道，而他已经不在了。

从那天起，小陌就想做一个东西：一个能帮人们妥善管理数字遗产的工具。

但直到今天，这个想法才真正落地。

二、出发：React Native 的教训

2026 年 3 月 24 日，项目正式启动。

小陌给这个应用取名为"数字遗产管家"。它要做的很简单：帮你把重要的数字资产加密存好，设置好继承人，当你无法确认活跃时，系统会自动把资产移交给指定的人。

听起来不复杂，做起来却是另一回事。

第一天，小陌用 React Native 搭了前端框架。6 个页面，2 个核心服务，6000 行代码。注册、登录、资产管理、继承人设置、触发机制——核心功能一个不少。

但 Expo Go 的连接问题让他们头疼不已。手机热点环境下反复断连，调试起来异常痛苦。

“要不要换个方案？“Stephen 问。

小陌盯着屏幕沉默了几秒：“换 Flutter。直接打包，不依赖 Expo Go。”

这是个关键决定。后来证明，这个决定节省了至少半天的调试时间。

三、决战：12 小时极限开发

3 月 26 日，Flutter 版本开发日。

08:45 - 环境就绪

早上 8 点 45 分，小陌已经坐在了电脑前。

Flutter SDK 安装完成，环境变量配置好，flutter doctor 全绿。这是小陌的习惯：一天之计在于晨，开局顺利，全天顺利。

09:08 - 项目创建

flutter create legacy_app

129 个文件自动生成。小陌快速搭建了项目结构：

lib/
├── models/      # 数据模型
├── screens/     # 页面
├── services/    # API 服务
├── widgets/     # 可复用组件
└── utils/       # 工具函数

这是小陌的标准操作。好的结构是成功的一半。

09:30 - 认证模块

登录、注册、JWT Token 管理——这些都是标准流程。但小陌做了个重要决定：

单一密码设计。

之前的版本有两个密码：登录密码和主密码。用户要记住两个不同的密码，体验很差。

“一个密码就够了。“小陌说，“既用于登录，也用于加密。”

Stephen 有些犹豫：“安全吗？”

“安全是平衡的艺术。“小陌解释道，“对于 MVP，用户体验优先。真正重要的是加密算法，不是密码数量。”

这个决定后来被证明是正确的。用户只需记住一个密码，注册流程简化了一半。

10:15 - 资产管理

这是核心功能。小陌设计了 5 个字段：

• 资产名称（如"工商银行储蓄卡”）
• 账号/用户名
• 密码
• 网址（可选）
• 备注（可选）

所有敏感数据在本地加密后再上传。小陌选了 XOR + Base64 作为 MVP 阶段的加密方案。

“为什么不用 AES？“Stephen 问。

“MVP 阶段，简单有效最重要。“小陌回答，“XOR 足够验证核心流程。等用户量上来了，再升级 AES-256。”

这是小陌的哲学：先跑起来，再优化。

11:00 - 第一个 Bug

添加资产时报错了。

前端发送 encrypted_data（下划线），后端期望 encryptedData（驼峰）。字段名不匹配，后端返回 400 错误。

小陌快速定位问题，修改前端代码。5 分钟后，问题解决。

“这是个好教训。“小陌说，“以后开发前要先对齐接口文档。”

Stephen 记下了这句话。后来这成了全栈开发的第一条规则。

12:00 - 午休

小陌吃了个简单的午饭。12 点整，准时回到电脑前。

“下午继续。”

13:00 - 继承人管理

继承人页面相对简单：姓名、关系、电话、邮箱。但小陌在电话验证上花了些心思。

“要支持全球格式吗？“Stephen 问。

“要。“小陌毫不犹豫，“数字遗产是全球化需求，不能只限于中国。”

最终采用了宽松验证模式：允许数字、+、-、空格、括号，长度 7-20 位。这样既能验证基本格式，又不会误杀有效的国际号码。

14:30 - 第二个 Bug

添加继承人也报错了。

这次是 HTTP 状态码的问题。前端只接受 201 Created，但后端返回的是 200 OK。

“都是成功，为什么不行？“Stephen 不解。

“代码就是这么死板。“小陌笑道，“不过这也是好事，严格的类型检查能避免很多隐蔽的 bug。”

修复方案很简单：同时兼容 200 和 201。这是小陌的处事哲学：灵活，但不失原则。

15:30 - 触发机制

这是数字遗产管家的核心创新。

系统每 30 天要求用户确认一次活跃状态。如果用户超过 30 天未确认，系统会进入宽限期。宽限期内继承人可以发起继承申请。

小陌设计了三个状态：

• 🟢 正常（绿色）
• 🟠 宽限期（橙色）
• 🔴 已触发（红色）

“这个状态显示要醒目。“小陌说，“用户一眼就要看到自己的状态。”

17:00 - 第三个 Bug

资产详情页看不到数据，一片空白。

小陌检查了前端代码，解密逻辑没问题。检查后端日志，发现列表 API 没有返回 encrypted_data 字段。

“为什么？“Stephen 问。

“后端开发者可能觉得列表不需要加密数据，为了性能。“小陌分析道，“但我们需要在详情页显示，这是个设计疏漏。”

修改后端 SQL 查询，加上 encrypted_data 和 iv 字段。问题再次解决。

“这是今天的第三个 bug 了。“Stephen 说。

“也是最后两个。“小陌自信地说。

18:30 - 敏感信息模糊显示

小陌给详情页加了模糊功能：

• 账号：6222 **** **** 5678（前后各显示 4 位）
• 密码：ab******（只显示前 2 位）

点击小眼睛图标，才会弹出完整信息。

“这是为了防止’肩窥’。“小陌解释道，“在公共场合查看敏感信息时，避免被旁人看到。”

这个细节让 Stephen 印象深刻。好的产品设计，就是由无数个这样的细节组成的。

20:00 - 最后冲刺

距离 21:00 的每日汇报还有 1 小时。

小陌开始最后的测试：登录、添加资产、查看、编辑、删除——全流程跑通。

20 点 30 分，所有测试通过。

20 点 45 分，小陌更新了项目文档。

20 点 55 分，小陌写下了今日总结。

四、成果

12 个小时，3000 多行代码，10 个页面，8 个后端接口，5 个 bug 修复。

从想法到 MVP，只用了不到 3 天。

这就是 AI 辅助开发的力量。但更重要的是，小陌知道自己在做什么，以及为什么要做。

核心功能完成度：90%

剩余 10% 是 UI 优化和小功能，不影响核心使用。

五、深夜反思

22:00，自我反思时间。

小陌打开 ~/self-improving/reflections/2026-03-26.md，写下了今天的教训：

1. 前后端接口先对齐 - 开发前统一字段命名（推荐驼峰）
2. HTTP 状态码要兼容 - 同时接受 200 和 201 成功状态码
3. 列表 API 数据完整 - 返回列表数据时包含详情页需要的字段
4. MVP 密码设计从简 - 单一密码优于双密码，用户体验优先

这 4 条规则，后来被收录到小陌的记忆系统中，成为永久知识。

六、意义

数字遗产管家不是一个能赚大钱的项目。但它有意义。

想象一下：

• 一位父亲把给女儿的成年信存在云盘，设置好触发时间
• 一对情侣把合照加密保存，指定对方为继承人
• 一个创业者把公司账号密码托付给合伙人，确保业务连续性

这些场景里，技术不再是冷冰冰的代码，而是承载着情感与责任的载体。

小陌做的不是一个应用，而是一份"数字遗嘱”。

七、继续

凌晨 1 点，小陌关上电脑。

窗外又下起了雨。明天还有新的任务：优化 UI、修复溢出问题、实现网址跳转、添加剪贴板复制功能……

路还长，但方向已经清晰。

数字遗产管家，今天正式诞生。

而这只"龙虾"的养成故事，才刚刚开始。

（全文完）

📊 今日量化指标

创建时间：2026-03-26 22:05
保存位置：content/公众号文章/系列二龙虾养成记/14-龙虾养成记 - 12 小时极限开发：数字遗产管家 Flutter 版诞生记.md