交接与数字遗产：应急联系人、资产文档、出售与关停移交

前九篇讲的是「东西丢了怎么找回来」。这一篇讲的是更极端的情况：你暂时或永久无法工作，产品怎么办。

一、住院的第三个月

这是为解释机制构造的假设案例，人物、引语、收入和耗时均为教学设定，不是对真实事件的调查记录。

一位开发者独自运营一款订阅制工具，付费用户几百人。某天他因急病住院，原本以为两周就能回来，结果住了三个月。

产品在这三个月里没有挂：服务器在跑，自动续费在扣，用户还能登录。但——

• 没有人回复支持邮件。
• 没有人处理退款请求。
• 没有人修一个已知的登录 bug。
• 没有人更新即将过期的证书。
• 没有人知道服务器续费绑的是哪张卡。

第三个月，证书过期，HTTPS 中断，用户开始流失。他的家人知道他在做「一个网站」，但不知道从哪登录、钱在哪里、客户怎么联系。

他康复后说：「我以为产品会自动运行。它确实自动运行了三个月，然后开始自动死亡。」

二、什么叫「可交接状态」

一个可交接的产品，不是「代码写得清楚」，而是另一个人在不问你任何问题的情况下，能维持它运行 30 天。

用四个问题检验：

1. 一个懂技术的人，能否按文档部署、回滚、恢复数据？
2. 一个不懂技术的人，能否找到账号、联系服务商、处理退款？
3. 客户能否找到一个明确的联系人，而不是石沉大海？
4. 法律与财务上，谁有权代表这个产品做决定？

四个问题里任何一个答不上来，产品就还没有进入可交接状态。

三、四份交接文档

3.1 资产清单

就是第 01 篇那张表，但要更完整：

3.2 运行手册

运行手册不是架构文档，而是「出事时照着做」的步骤：

• 如何部署一个新版本。
• 如何回滚到上一个版本。
• 如何从备份恢复数据库。
• 如何续期证书与域名。
• 如何查看监控与告警。
• 如何联系关键供应商。
• 常见故障的排查顺序。

每一步都要有可执行的命令或可点击的入口，不要写「检查服务器状态」这种无法验收的话。

3.3 供应商与合同

3.4 客户与法律

• 客户名单与联系方式（注意隐私与合规）。
• 退款政策与服务条款。
• 未完成的承诺与合同。
• 数据导出与删除流程。
• 谁有权代表产品对外沟通。

四、应急联系人

4.1 不是「填个名字」

很多服务允许你填一个「紧急联系人」，但真正出事时，联系人不知道自己要做什么。应急联系人至少要满足三个条件：

1. 知道自己在名单上。 你提前告诉过对方。
2. 知道入口在哪。 有一张纸或一个离线文档，写着服务商、账号标识、联系路径。
3. 有明确的授权边界。 能做什么、不能做什么、什么情况下触发。

4.2 授权边界表

授权要写在纸上，并咨询专业人士。 不同司法辖区对代理、继承、公司治理的规定不同，本文不提供法律意见。

4.3 密码管理器的紧急访问

紧急访问依具体产品和套餐。以 Bitwarden 为例，要先邀请并确认联系人、选择等待和 View/Takeover；不是仅因“失联”就自动赋予所有业务权限。1Password 的 Emergency Kit、恢复代码和家庭/团队恢复是不同机制。

配置时注意：

• 等待期要覆盖你正常出差或休假的时长。
• 联系人要完成过一次流程演练。
• 先核对覆盖范围：Bitwarden View 不应被描述为仅分享自选条目。需要最小交接范围时，另设计业务共享空间和授权，不依赖一个不存在的通用开关。
• 联系人自己的账号也要有 2FA 与恢复码。

4.4 密封信封

对不懂技术的联系人，一份纸质材料往往比密码管理器更可靠：

• 关键账号清单（不含密码）。
• 服务商客服电话。
• 「第一步做什么」的一页说明。
• 律师、会计、合伙人的联系方式。
• 密封存放，定期更新。

五、个人账号的数字遗产

Apple、Google 等个人账号体系提供数字遗产或不活跃账号管理功能，允许你指定联系人，在自己身故或长期不活跃后访问部分数据。

但要注意：

不要把「个人数字遗产」当成「商业交接方案」。 商业资产需要合同、授权、公司治理文件，而不是账号层面的继承设置。

六、三种退出路径

6.1 出售

出售前要确认：账号能否转让、数据能否迁移、客户合同是否允许主体变更。 这些往往比价格更影响交易能否完成。

6.2 关停

关停的核心不是「关」，而是「让用户能带走自己的东西」。

6.3 开源

开源不是「把代码扔出去」，而是「让别人能接手维护」。

七、30 天交接演练

用测试项目模拟你失联 30 天，让受授权联系人按文档操作；重启、回滚、退款默认在隔离/沙箱环境，不实际关停生产或退真实订单。

7.1 演练清单

• 联系人能在 1 小时内找到资产清单与运行手册。
• 联系人能登录监控，看到服务状态。
• 联系人能按手册重启或回滚一次。
• 联系人能回复一封客户邮件。
• 联系人能在支付沙箱处理一次测试退款并记录幂等结果。
• 联系人能找到证书与域名的到期日。
• 联系人能联系到至少一个供应商的真人支持。
• 联系人知道哪些事不能做。

7.2 记录

演练的目的不是「证明文档完美」，而是发现那些你以为写清楚了、其实只有你懂的地方。

八、常见错误

九、行动清单

• 写一份资产清单，确保另一个人能看懂。
• 写一份运行手册，覆盖部署、回滚、恢复、续期。
• 指定一位应急联系人，告知流程并做一次演练。
• 配置密码管理器的紧急访问。
• 准备一份密封信封，放在联系人能找到的地方。
• 确认商业账号的转让/继承路径，必要时咨询专业人士。
• 为出售、关停、开源各写一份清单。
• 每年做一次 30 天交接演练，记录卡点。

十、这个系列的收束

十篇文章，其实只讲了一件事：

资产不是「你拥有什么」，而是「你丢了之后还能恢复什么，以及你不在时别人还能接手什么」。

回到第 01 篇的那句话：一个人做产品，最贵的不是服务器，也不是流量，而是只有你知道怎么恢复。

如果你只记住三句话：

1. 身份是根。 主邮箱、密码管理器、2FA 恢复码，决定了其他五层资产能不能找回来。
2. 备份要演练。 没演练过的备份不算备份，只能算希望。
3. 交接要提前。 可交接状态不是给「以后」准备的，是给「明天就可能发生的事」准备的。

平台会变，账号会丢，人会生病。这些都不是失败。没有为它们做准备，才是。

使用边界与实操验收

知道密码、被设为恢复联系人与获得合法处分权不是同一件事。平台条款、公司授权、代理与继承规则需要分别满足。

交接验收样例：联系人在一小时内定位只含测试数据的资产表，使用独立测试角色查看监控、回滚测试部署、处理沙箱退款并导出日志。验收表记录“技术能做、授权可做、平台允许”三列；任一列未知就不能真实出售、转域名或删除客户数据。

关键参考与核验范围

以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。

• Bitwarden 紧急访问 ：联系人、View/Takeover 和请求流程。
• 1Password Emergency Kit ：套件保存与登录材料，不等同于无限制继承。
• 公司法 ：责任、治理、出资和股权转让以相应条文为准。

系列导航

• 上一篇：事故响应：被盗、被封、被停机、域名劫持的 72 小时
• 回到目录：独立开发者的资产韧性
• 相关阅读：平台风险与迁移：把渠道依赖变成可退出结构 、独立开发者生存指南