---
title: "身后事清单"
date: "2026-07-19"
canonical: "https://raytally.com/ideas/2026-07-19-death/"
generator: "萤录 RayTally · dev-prompt-v4"
signal:
  query: "death"
  observed_at: "2026-07-19T01:32:59.650Z"
  active: false
  ended_at: "2026-07-18T15:20:00.000Z"
  window_hours: 168
sources:
  - url: "https://developer.apple.com/documentation/vision/recognizing-text-in-images"
    boundary: "来源记录未提供发布时间。"
  - url: "https://www.empathy.com/solutions/loss-support"
    boundary: "来源记录未提供发布时间。"
  - url: "https://www.settld.care/faq-items/what-services-does-settld-provide/"
    boundary: "发布于 2021-08-18T00:00:00.000Z。"
  - url: "https://www.ssa.gov/personal-record/when-someone-dies"
    boundary: "来源记录未提供发布时间。"
notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。"
---

[在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-07-19-death/)

使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。

你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。

## 灵感

身后事清单
亲人离世后拍下收到的文件，产品排出手续优先级并把待办分给合适的家人。

## 产品概念

亲人离世后的第一周，家人把收到的信件、账单和手机截图拍进来。产品从每份通知中提取截止日期、机构和待办事项，按“必须马上做、等待回复、可以稍后处理”归档，再把少数需要共同决定的事推到共享清单。敏感内容默认留在设备上，家人只看到明确分给自己的事项，让手续有序推进而不打扰哀伤。

## 为什么是现在（有事实支撑）

在截至2026年7月19日的168小时观察窗口内，“death”的搜索量标记为1000+、增幅200%，这轮活跃状态于2026年7月18日15:20（UTC）结束。它只表明该时段出现过短暂的注意力集中，不证明长期市场需求，但形成了验证“搜索身后事信息后立即整理来信”这一入口的时机。

## 方向判断（以下为模型推断，未经独立验证）

目标用户：刚失去亲人、实际承担手续的配偶、成年子女或遗产执行人，会在第一批账单、保险信、福利通知和账户邮件陆续到达，却还无法判断先后顺序时打开它；其他家人通常只在被分配事项或需要共同决定时进入。

最小切入点：先做 iPhone 版的本地文件收件箱：用 Apple Vision 在设备上识别照片中的文字，标出机构、日期和疑似行动项，再要求用户逐项确认后进入三个优先级队列；首版不代替用户向机构提交申请，也不判断法律义务。Vision 支持离线、设备端文字识别，适合兑现敏感原件不上传的边界。

最强反方：最危险的不是识别不出文字，而是把日期或机构要求识别错后仍给出确定优先级。身后事务还取决于管辖地、账户关系和执行人权限，同一封信未必意味着收件人有权行动；产品若不能把原文、置信提示和人工确认放在结论之前，很难获得处理财务与身份材料所需的信任。

以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。

## 以小博大（模型推断）

围绕“收到某类身故通知后该做什么”制作可搜索的一页式处理模板，并向遗产律师、临终关怀机构和殡仪服务人员提供可直接交给家属的二维码版本；入口直接打开拍照整理流程，不要求家属先配置完整档案。

## 竞品与缝隙（模型推断）

- Empathy Loss Support：Empathy 已提供个性化行动计划、家人协作和人工照护支持，但覆盖的是完整丧亲服务；切入空间在于把新收到的纸质信件和手机截图直接变成少量、可核对的近期事项，并默认只共享任务而非原件。
- Settld：Settld 侧重一次通知多个非政府机构并跟踪账户关闭或转移，主要服务英国用户；缝隙是处理通知前的家庭收件箱，把尚未标准化、暂时不能提交给机构的材料先分级和分工。

## 怎么赚钱（模型推断）

按单次身后事档案收费，包含文件整理、家庭成员协作和档案导出；不把用户锁进长期订阅。

## 趋势背景

主题：死亡
触发的搜索词（英文原文）：death
近似搜索量级：1000+（近似值）
近似增幅：+200%（近似值）

趋势数据是抓取时刻的历史快照，量级与增幅均为近似值，只用于理解「为什么是现在」，不要写进产品文案当作精确的市场数字。

## 来源清单

- Recognizing Text in Images（https://developer.apple.com/documentation/vision/recognizing-text-in-images）
- Empathy Loss Support | The new standard in bereavement care（https://www.empathy.com/solutions/loss-support）
- What services does Settld provide?（https://www.settld.care/faq-items/what-services-does-settld-provide/）
- What to do when someone dies（https://www.ssa.gov/personal-record/when-someone-dies）

## 交付要求

- 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。
- 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。
- 页面或接口里不要展示未经验证的市场数字。
- 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。
- 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。
- 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。
- 完成后说明改了什么、如何运行、如何验证。
- 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。