# H5 语音访谈 MVP

## 目标

快速做出一个适合微信内打开的 H5 原型，用来验证老人和家属是否愿意通过“引导式语音访谈”来制作人生故事书。

第一版先避开微信小程序注册、类目、审核等流程，直接用 H5 页面作为试验入口。链接可以通过微信消息或二维码发给家属和老人。

## 产品定位

暂定名称：人生访谈体验版

7 天体验版承诺：

- 7 天引导式语音访谈。
- 每天生成给家属看的故事卡。
- 形成一条人生时间线草稿。
- 形成一篇 3000-5000 字人物小传草稿。
- 给出后续深挖访谈方向。

原型要卖的不是“填表”，而是“有人温和地陪老人把故事讲出来”的感觉。

## 第一版用户流程

1. 家属打开 H5 链接，创建一个人生故事项目。
2. 老人在微信里打开同一个链接。
3. 页面每次播放或展示一个温和的问题。
4. 老人录音回答。
5. 原型先把录音保存在本地浏览器。
6. 页面根据回答生成故事卡占位。
7. 家属查看故事卡、补充备注、上传照片、标记重要故事。
8. 运营人员通过后台页面查看访谈记录、项目状态和章节草稿。

## MVP 范围

已包含：

- 移动端优先的 H5 访谈页面。
- 大字号、少按钮，适合老人使用。
- 浏览器支持时使用 `MediaRecorder` 录音。
- 录音不可用时提供文字记录兜底。
- 对话式引导访谈流程。
- 访谈阶段、温和追问和人工追问方向按钮。
- 项目信息表单。
- 照片和材料上传占位。
- 故事卡列表。
- 参考 Remento 的“原声保留”体验，加入可回放的会说话故事卡。
- 原型数据保存在本地浏览器。
- 运营后台读取同一浏览器里的本地数据。
- 支持导出 JSON。

暂不包含：

- 真实账号系统。
- 云数据库。
- 真实语音转文字。
- 真实大模型调用。
- 真实书页二维码生成。
- 微信支付。
- 印刷供应商对接。
- 多设备同步。

## 推荐生产架构

前端：

- 第一阶段先做 H5。
- 访谈流程验证后，再考虑微信小程序。

后端：

- Node.js 或 Python API。
- PostgreSQL 保存结构化数据。
- 对象存储保存音频和照片。
- 任务队列处理转写、总结和草稿生成。

AI 流程：

1. 上传音频。
2. 语音转文字。
3. 生成本次访谈摘要。
4. 提取故事卡。
5. 更新人生时间线和人物表。
6. 规划下一轮追问。
7. 生成章节草稿。

人工审核：

- 所有付费项目在交付前都应该经过人工编辑审核。
- AI 输出不能未经审核直接作为最终书稿交给客户。

## 语音体验决策

第一版先采用异步语音轮次：

- AI 或访谈师先问一个问题。
- 老人录音回答。
- AI 给一句简短回应，再追问一个更具体的问题。
- 运营人员或家属可以通过“问地点、问人物、问年份、问困难、问经验”等方向按钮来控制下一句追问。

这种方式比实时语音通话更适合 MVP，因为它延迟风险更低，老人可以慢慢想，长故事更容易保存和审核。

实时语音以后可以作为陪伴式体验测试，但“做书”这个流程更需要可保存、可回放、可整理的访谈片段。

## 合规注意事项

真实产品需要对以下事项取得明确授权：

- 采集和保存声音。
- 采集和保存照片。
- 处理敏感个人信息。
- 将材料分享给编辑或印刷供应商。
- 将故事用于私人家庭项目以外的用途。
- 任何公开发表、改编、转售或版权授权。

当前 MVP 里已有明显的授权确认步骤，但正式收费前仍需要做法律审查。

## 竞品功能切片

当前最佳参考：Remento。

我们借鉴的不是视觉设计，而是核心价值闭环：讲出一段记忆，保留原声，生成家属能看的故事卡，并让它未来可以变成书页里的扫码听原声。

已实现的原型行为：

- 每条录音故事可以在故事卡里直接回放。
- 故事卡显示“扫码听原声”的书页占位。
- 可以生成家属分享文案。
- 运营后台可以看到每条故事是否保留了原声。

## 验证指标

前 20-30 个试用家庭重点观察：

- 老人是否完成至少 3 次访谈。
- 每次回答的平均时长。
- 家属对每张故事卡的纠错次数。
- 家属是否觉得故事卡“像本人”。
- 家属是否愿意为完整成书付费。
- 用户最常在哪一步流失。
- 语音是否明显优于文字输入。

## 构建计划

1. 创建静态 H5 原型。
2. 创建本地运营后台。
3. 验证录音兜底和本地数据流。
4. 找 3-5 个熟人家庭试用。
5. 验证流程成立后，把本地存储替换成小后端。