第一次看到“死了么”这三个字的时候我以为是哪个团队又来消费焦虑了。后来把完整产品翻了一遍才发现它其实不是搞笑App也不是某家殡葬公司的拉新页面而是一个把生前遗嘱、医疗预嘱、数字遗产、告别仪式和紧急联系人全部装进手机里的工具。英文社区常把这叫“digital afterlife planner”中文网友给它起了个更直白的名字“死亡版待办清单”。这款App突然爆火我反而觉得需要冷静看一下。死亡这个主题天生低频、高压、私密一个做得好是“身后事的保险箱”、做不好就成了“隐私泄露事故现场”的产品本不应该靠猎奇流量出圈。今天不评价它“该不该火”只从一个产品从业者的角度说说这种App背后的需求、设计、技术和那些容易被流量掩盖的坑。1. “死了么”到底是个什么产品为什么让我这么紧张1.1 它做的不是“等死”而是身后事管理很多人看到名字就划走了觉得“死了么”是在拿死亡找乐子。实际用起来它更像一个“人生信息收纳箱”。用户可以在里面填这些内容个人基本信息、血型、慢性病史、过敏史、常用医院医疗预嘱要不要抢救、要不要插管、器官捐献意愿遗嘱原件或扫描件、保险保单号、银行卡和贷款记录社交账号、邮箱、游戏账号、数字钱包等数字资产清单希望谁来处理后事、葬礼怎么办、骨灰放哪里、想放什么歌这些信息平时看起来没什么用但真出事的时候家属往往连用户买了哪家保险都查不到。我有个做保险理赔的朋友说过现实里最麻烦的不是赔不赔而是家属根本不知道有这份保单存在。这种工具解决的就是“信息断档”问题让一个人在还能清醒规划的时候把最重要的事情交给可以信任的人。1.2 为什么爆火对这类产品是高风险事件流量本身不是坏事但这类产品吃流量会“消化不良”。普通工具App爆火后最多是服务器扛不住而“死了么”这类产品爆火后第一波涌进来的大量用户里有很多不是来认真规划的而是来猎奇、玩梗、截图发社交平台的。这会产生三类风险隐私风险用户上传的身份证、病历、银行卡、遗嘱都是高度敏感信息一旦被当成素材传播后果不是删帖能解决的内容风险用户可能上传他人信息或者拿明星、公众人物的名字来建档很容易变成诽谤或骚扰工具情绪风险真正有医疗困境、亲人离世、自身绝症的用户被猎奇评论包围产品会变成情绪伤害现场所以我说“不该爆火”不是否认它的价值而是说这类产品需要的是安静、信任和克制而不是“全网围观”。2. 这类App的产品设计不能照搬普通App的逻辑2.1 低频刚需产品不能盯着日活看“死了么”不是一个每天都要打开的产品。用户可能只会在几个节点使用刚下载时、大病初愈时、家里出事时、某个深夜突然想把东西整理完时。用常规的次日留存、七日留存去衡量它会把产品带偏。更合理的核心指标应该是有效档案完成率多少人填完了最关键的项目而不是随便注册完就丢委托人触达成功率触发机制确认后委托人能否顺利拿到需要的信息敏感信息泄露事件数这应该比日活更能决定产品生死我见过不少类似的产品为了“活跃”硬加社交、动态、每日签到这是方向性错误。一个用户把信息放在你这里是因为他信任你而不是因为你能让他每天刷到内容。2.2 用户情绪是第一优先级不是转化率这类产品里用户填写内容时可能正处在崩溃边缘。产品文案稍微不合适伤害就比普通产品大得多。我自己在设计中会做三件事所有模块文案都标成“可选项”不写“完成后台任务”之类的压力词不让用户做“倒计时式”操作比如“资料将在3天后过期”这会放大焦虑操作按钮用中性词像“保存并继续”“以后再填”少用“立即确认”“马上开始”还有一个细节不要让产品看起来像“催人死”。比如上传遗嘱后弹窗说“恭喜你完成遗嘱”这显然不合适应该改成“资料已保存您可以随时修改”。2.3 别用物质激励刺激用户提交隐私有些产品为了冲量会搞“填完资料送会员”“邀请好友得礼物”。这类做法放在死亡主题产品里非常危险。一旦用户为了奖品填了不真实的信息后续触发流程就会出大问题。而且让用户为了奖励交出身份证和遗嘱扫描件本身就是一种不尊重。我更推荐的做法是“降低门槛”而不是“加激励”先让用户填一份只有联系人和基本信息的轻量档案再把医疗预嘱、财产清单等功能逐步开放。用户有足够的自主权决定什么时候填、填多深。3. 核心技术细节拆解敏感数据怎么存、怎么触发3.1 数据模型和权限模型要提前设计很多团队会把这类App做成“普通表单文件上传”这是最大的坑。身后事数据不是普通表单它有明确的“解锁时机”和“授权范围”。我在设计时会先梳理核心实体实体核心字段敏感级别说明用户档案姓名、出生日期、紧急联系人高必须加密存储医疗预嘱抢救意愿、病史、医院记录高仅限指定委托人查看财产清单保单、银行卡、贷款记录极高禁止明文输出文件库遗嘱扫描件、证件照片极高单独密钥加密委托人姓名、关系、联系方式中触发后才能看到对应内容权限模型一定要分角色。常见的做法是档案本人拥有全部读写权委托人触发前不可见触发后按授权范围查看平台运营只看得到元数据比如“某用户更新时间”看不到身份证、遗嘱正文客服必须经过二次授权才能进入帮助模式且所有操作留痕我用一个简单的 JSON 描述核心结构方便理解{ version: 1, profile: { displayName: 张三, birthDate: 1990-01-01, medicalPreferences: { resuscitation: false, organDonation: true } }, documents: [ { type: 遗嘱扫描件, path: encrypted://legacy/will.pdf, checksum: sha256:... } ], handlers: [ { name: 李四, relation: 配偶, phoneEncrypted: true, status: pending } ], accessRules: { trigger: dual_death_certificate_confirmation, gracePeriodDays: 7 } }这只是示意图。实际生产环境里“documents.path”不能是明文路径对象存储的地址和文件密钥要分开存放至少做到“数据库泄露了文件也解不开”。3.2 加密、备份和“人没了怎么验证”这类产品最核心的技术难点有两个一个是“数据安全”另一个是“死亡触发”。数据安全方面我的经验是不要在服务器上存明文敏感字段。正确的做法是客户端使用用户口令派生出一个主密钥用这个主密钥对敏感字段进行加密服务器只存密文用户头像、昵称等非敏感信息可以明文存储方便展示密钥不能存在服务器数据库里否则等于没加密但这样会带来一个问题用户忘了密码密钥就丢了。所以需要设计“恢复密钥”。我见过比较合理的方案是“密钥分片”把恢复密钥切成三份分别交给三个不同的委托人任意两个人合作就能找回。这样既避免单个委托人偷看又不会因为一个人失联就让数据永远打不开。死亡触发方面很多团队第一反应是“用户超过30天没登录就判断为死亡”这个方案绝对不能直接用。出差、住院、手机被偷都可能让用户长期不登录误判一次就是事故。更稳妥的触发流程至少要有两步委托人上传死亡证明并填写与用户的关系至少另一位委托人或者平台审核人二次确认同时启动“冷静期”触发完成后系统会等待7天。在这7天内如果用户本人重新登录触发立即取消并且所有委托人都收不到内容。这个设计能把“误报”的伤害降到最低。3.3 “数字遗产”不是单点产品能解决的现在的账号分散在微信、支付宝、抖音、邮箱、游戏、投资平台。单一App无法握住全部入口但可以做一个“数字遗产索引”不存密码正文只存“你有哪些账号、在哪里找回、谁应该负责处理”。比如“支付宝账号在xx手机号下处理人是儿子小王”这种信息即使被泄露也不会直接造成资金损失但能大幅降低家人处理难度。这也是我对“死了么”这类产品最认可的部分它本质上不是“替代平台”而是“信息地图”。用户把地图画好家人按图索骥。4. 一个最小可用版本实操过程和关键实现4.1 开发顺序别搞反如果让我从零搭一个最小可用版本我不会一上来就做完整App而是先跑通“填资料→加密存储→委托人触发”这条主链路。具体顺序大概是注册登录手机号密码二次认证必须记住“没死之前谁都不能看到内容”这个原则基础档案姓名、出生日期、紧急联系人先用一个轻量表单跑通文件上传支持图片、PDF上传后直接加密前端不做内容识别委托人管理可以添加委托人但未触发时他们账号里什么都没有触发流程死亡证明上传二次确认冷静期审计日志谁在什么时候查看过什么内容全部记录第6步经常被忽略但它是事后追责的关键。一旦出现隐私纠纷没有日志就只能靠猜。4.2 文件存储和加密的工程实现思路如果团队不够大我不建议从零写密码学直接用成熟方案。文件加密可以使用“每个文件随机生成一个密钥密钥再由用户主密钥加密后存储”的做法。大概过程是用户上传遗嘱PDF客户端生成一个随机的文件密钥用文件密钥加密PDF上传到对象存储再用用户主密钥加密文件密钥存到数据库触发后委托人输入恢复密钥找回主密钥再解开文件密钥最后下载并解密PDF这套流程虽然比“直接传原图”麻烦但值得。因为最坏情况下服务器被脱库拿到也只是密文无法直接看到遗嘱内容。我甚至建议对文件做“数字水印”比如在PDF页面上嵌入委托人的用户ID一旦截图外传至少能追到是谁做的。4.3 内容风控和敏感信息识别这类产品的风控不只是“过滤违法内容”更多是要管住三类情况用户A上传用户B的身份证或遗嘱涉嫌盗用信息用户填了大量绝望、自伤倾向的文本这是心理危机信号委托人滥用触发机制故意“判定”某人死亡我的处理方案是上传证件类文件时前端先用OCR识别关键字段提示“请确认这是本人资料”对文本内容做异常情绪识别命中后不展示给其他用户而是弹出一个柔和提示引导其联系亲友或专业援助对同一委托人触发多个用户的行为设置阈值超过阈值就要求人工复核不要只靠关键词。像“想死”这句话在不同语境里可能是玩笑、歌词、真实危机。机器负责筛出候选最终判断交给人。5. 常见问题与踩坑记录5.1 用户高频疑问和处理方案用户疑问常见原因处理方案“人没死会不会被误触发”对触发机制不信任明确展示“冷静期本人可反悔”两条规则“填了之后还能改吗”担心信息写死所有内容均标注“可随时修改”减少心理压力“家人不知道这个App怎么办”委托人没有安装App支持短信/邮件通知让委托人通过短链确认身份“平台哪天倒闭了怎么办”对第三方存储不信任提供一键导出加密包和PDF清单把所有权还给用户“手机丢了能找回吗”依赖恢复密钥引导用户在注册时打印纸质恢复密钥并妥善保管其中“平台倒闭”这个问题一定不能回避。用户把最私密的信息放在你这里本质上是把自己的身后事托付给你。产品设置里必须有清晰的导出入口最好支持通用格式而不是把所有数据锁死在私有数据库里。5.2 开发中我踩过的五个真坑第一个坑是“加密后没法搜索”。最初我想让用户快速搜索自己的保单结果发现加密字段根本无法做数据库索引。后来只能改成“只索引标签不索引正文”比如“保单”“遗嘱”“银行”这种用户手动添加的标签可以搜索具体内容只能在解密后查看。第二个坑是“通知文案太惊悚”。有一次测试给委托人发短信文案是“张三已确认死亡请尽快处理”结果立刻就被投诉了。后来改成中性的表述“您有一项来自张三的委托事项需要处理”具体内容放在App内查看。第三个坑是“审核模型误杀”。用户上传的遗嘱里出现“如果呼吸停止不要抢救”这看起来像异常内容但其实是合法的医疗预嘱。不能拿通用的“负面文本模型”直接套必须专门调优死亡和医疗场景的语料。第四个坑是“被人批量注册玩梗”。有段时间出现大量以明星名字命名的档案还配了恶搞遗嘱。我们通过限制同一设备注册数量、同一委托人可被关联的数量以及对明显虚假的出生信息做校验才把批量注册压下来。第五个坑是“导出文件时泄露了关联人信息”。用户导出的PDF里如果把委托人电话直接明文印上这个PDF一旦被转发别人也收到了电话号码。后来我改成默认只输出“委托人称呼最后四位手机号”完整联系方式必须单独验证后才能查看。5.3 上线后最该坚持的一件事如果说有什么原则最不该妥协那就是“默认信息最小化”。系统里不要存任何“暂时用不到”的数据。用户身份证号只在验证身份时需要验证完就可以丢弃或脱敏用户填写的银行账号默认不展示给任何一方只有明确授权后才能查看。我自己的习惯是凡是涉及死亡触发的产品上线前一定要拿假数据把三种场景各跑三遍第一遍正常流程委托人拿到完整资料第二遍本人中途登录触发被取消第三遍多人恶意举报用户死亡系统拒绝触发只有这三种情况全部符合预期我才敢让真实用户使用。说到底“死了么”App能火是因为它踩中了一个真实存在的需求很多人都有“万一我突然走了家里人连我的银行卡和密码都找不到”的恐惧。但恐惧带来的流量从来不是产品护城河。对这类产品来说克制比开放更重要安全比增长更重要信任比日活更重要。如果哪天它真的不火了不是产品失败反而是它开始被认真对待了。