【生活娱乐+社会公益】拾光·Echo —— 让长辈亲口讲的故事，成为可保存、可续写、可分享的数字回声
【标签】生活娱乐 社会公益
作者介绍
我是宇航，一名在校学生，全程使用 TRAE Work / TRAE IDE 独立完成拾光·Echo 的产品设计、后端架构、前端交互、安全与部署。这个项目是我从 0 到 1 一点一点做出来的——从最初的创意方案，到上线运行与反复迭代，几乎每一行代码都由我借助 TRAE 完成。
我并非传统意义上的程序员出身，而是靠 TRAE 的 AI 辅助，把"想让老人讲故事被留下来"这个念头，做成了一个能真实使用、完整上线的产品。使用 TRAE 开发大约半年，因为它，我学会了一个人可以完成从想法到产品的全流程。
初赛的 Demo 验证了"AI 引导长辈讲故事"这个想法能成立；复赛我把 Demo 打磨成了一个能真实使用、经得起一遍遍重复操作的完整产品，并完成了上线运营与真实用户验证。
产品简介
是什么
拾光·Echo 是一个面向家庭口述史与数字记忆传承的 AI Web 应用。用户用文字或实时语音讲述往事，系统以来源证据为边界，把口述历史加工成可核对、可保存、可续写、可分享的"记忆回声"。
它最关心的不是"写得好看"，而是：故事里的事实来自讲述者本人，系统不乱编，家人能共同保存，让这段人生被永远记住。
核心闭环：长辈讲述 → 证据门控生成 → 记忆卡片 → 扫码分享 → 家人续写，形成一条完整可循环的传承路径：
面向谁
-
核心用户：60 岁以上长辈（讲述者）、26-45 岁子女（记录者与传承者）
-
典型场景：日常陪伴采访、寿辰宴席家庭补充、节日团聚、远程尽孝、养老机构服务、追思纪念
-
痛点：长辈的故事没人听、听了记不住、记住了传不下去；子女想记录却不知如何开口
完整功能清单
-
文字与实时语音访谈——像打电话一样自然的对话，长辈不用打字，直接说话就行；支持6 种方言识别（粤语/四川话/上海话/闽南话/陕西话 + 自动识别）。
-
只倾听模式——长辈独白时，拾光安静记录、不插话打断，老人更自然地连续讲述。
-
证据门控五阶段流水线——
事实抽取 → 章节策划 → 自传撰写 → 忠实度审校 → 结构化卡片，生成结果以来源证据为边界，可核对、可追溯。 -
克制的自传表达——允许调整顺序、补充连接句和节奏，但不把模型臆测当成讲述者的真实经历。
-
异步生成与阶段进度——耗时模型调用在后台执行，前端按五阶段展示真实生成进度。
-
结构化"拾光卡"——每段故事自动生成带图、带金句、带时间地点标签的记忆卡片。
-
分级分享与权限控制——同源生成分享二维码，故事阅读与继续讲述独立权限，支持密码保护与失效控制。
-
默认图 / AI 图 / 真实照片三选一——卡片默认使用内置图片；Owner 可明确选择 AI 配图或上传经过安全重编码的真实照片。
-
“拾光替你说”——从已发布且可追溯的卡片内容派生朗读文本，用户主动生成和播放；音频失败不阻塞卡片阅读。
-
家族共享故事线——各成员把自己拥有的卡片汇入同一时间轴，扫码显式加入，共同守护一段家族记忆。
产品界面速览
① 首页 —— 水墨暖金风格，大字引导，一眼看懂"开始讲述"
② 实时语音访谈 —— 像打电话一样自然，长辈说话、AI 主动引导
③ 结构化记忆卡片 —— 带图、带金句、带时间地点标签
相比初赛 Demo 的升级
初赛的 Demo 验证了"AI 引导长辈讲故事"这条核心想法能成立。复赛中，我把 Demo 打磨成了一个能被真实使用、五脏俱全的完整产品：
-
从"能演示"到"可稳定使用"：核心链路不再是一条演示路径，而是功能齐全、流程顺畅、经得起反复操作的完整产品。
-
从"跑通一条链路"到"核心功能闭环"：新增证据门控五阶段流水线、异步生成进度、分级分享权限、家族共享故事线、朗读。
-
从"能演示"到"完整交付"：以版本化 API 契约为边界，一个人也能把产品打磨成工程结构清晰、可稳定运行、可上线迭代的完整作品。
初赛 → 复赛功能对比表
| 维度 | 初赛（Demo） | 复赛（完整产品） |
|---|---|---|
| 核心链路 | 实时语音 → 单卡片生成 → 分享，可演示但缺少错误处理 | 完整闭环：只倾听模式 → 方言识别 → 五阶段流水线 → 异步生成 → 卡片 → 分享 → 家族续写，可反复使用 |
| 生成质量保证 | 直接一次生成，无证据门控 | 证据门控五阶段流水线，审校不通过回流重写，每段输出可追溯原始对话证据 |
| 分享机制 | 单卡片分享，无权限分级 | 同源二维码，阅读/续讲独立权限，支持密码保护与失效控制 |
| 产品功能 | 基础语音对话 + 卡片生成 | 10项完整功能：方言识别（6种）、只倾听模式、异步进度、三选一配图、拾光替你说朗读、家族共享故事线… |
| 工程可靠性 | 无测试，无静态检查 | pytest 单元测试 + Playwright E2E + Ruff 静态检查，核心路径全覆盖 |
| 并发安全 | 无幂等处理，弱网可能重复提交 | 内容绑定幂等键（长度受控），支付订单原子事务创建，fail-closed 配置 |
| 隐私安全 | 二维码携带密钥，有泄露风险 | 二维码不携带敏感信息，owner token 不落明文，分享接口字段级过滤 |
| 真实运营 | Demo 验证，无真实用户 | 上线运行一个半月，84+ 注册会话，536+ 条对话记录，真实用户验证 |
真实运营数据（截至 2026 年 8 月）
产品已于 2026 年 6 月 18 日正式上线，接受真实用户的使用检验：
| 指标 | 数值 | 说明 |
|---|---|---|
| 线上注册会话 | 84+ | 较初期增长 171% |
| 真实用户对话记录 | 536+ 条 | 含语音与文字 |
| 已生成记忆卡片 | 10+ 张 | 经五阶段流水线生成 |
| 水墨插画配图 | 26+ 张 | AI 自动生成 |
| 支持方言 | 6 种 | 粤语/四川话/上海话/闽南话/陕西话 + 自动识别 |
用户说：“AI 问的问题很专业，像真正的记者一样”“我妈说四川话也能听懂”“水墨画的风格很漂亮，很有中国风”。
产品演示视频
【(https://v.douyin.com/51flUgkoXfQ/) —— 1-5 分钟录屏，清晰展示从"长辈讲述 → 证据门控生成 → 记忆卡片 → 分享"的完整核心流程】
视频内容要点：① 老人语音对话，AI 主动引导访谈；② 多方言识别演示；③ 触发记忆卡片生成、五阶段流水线工作；④ 生成水墨记忆卡片（章节/金句/插画）；⑤ 子女扫码查看、听到 AI 朗读故事；⑥ 卡片授权续讲补充记忆。
产品创作历程
这个项目的起点，其实是一次真实的遗憾。
2025 年，我在最亲的奶奶离世后整理遗物，想找一些关于她的照片和故事，翻遍相册和聊天记录，只找到零散的照片。那一刻才意识到：老人的故事，原来这么容易就彻底消失了。 后来做社区志愿者，一位 80 岁的奶奶拉着我说："我今年多大了，我都记不清了……"那一刻，做这个产品的念头就确定了。
2025 年：TRAE@Frends 线下活动上，想给家里人做一份自传，于是用 TRAE 做了一个"多模态日记"，把文字、图片等生活片段收集起来。这是拾光最初的原型，也确定了最初的方向：不是替家人编故事，而是先把真实片段保存下来。
2026 年 6 月：TRAE AI 创造力大赛启动，火山引擎端到端实时语音让"长辈不用打字、直接说话"成为可能，技术终于追上了想法。拾光·Echo 不是"多模态日记"的翻版，而是它的灵魂延续与技术进化。
初赛（Demo）：用 TRAE 打通了"实时语音访谈 → 水墨记忆卡片 → 二维码分享"的核心链路。当时最大的技术难点是火山引擎 Realtime API 的二进制协议栈——严格的事件序列（StartConnection → StartSession → AudioTask → FinishSession）和 GZIP 压缩，前后花了 3 天才打通。
复赛（完整作品）：我围绕"真实、可信、可传承"三个词做了深度打磨——引入证据门控五阶段流水线保证系统不乱编，加入分级分享、家族共享故事线、朗读补齐产品闭环，并在上线后接受真实用户的使用检验。
技术终将迭代，但人类对"被记住"的渴望永远不变。我想做的，就是让每个普通家庭都能拥有属于自己家族的"数字回声"。
TRAE 实践过程
整个项目全程使用 TRAE Work / TRAE IDE 开发。从创意方案、后端架构、二进制协议实现、前端音频处理，到复赛的多阶段流水线、家族故事线、分享与朗读，几乎每一行代码都由 TRAE 协助完成。
关键开发步骤（附截图）
-
创意方案与技术架构：用 TRAE Work 生成完整产品提案与技术架构。
-
后端五阶段流水线：事实抽取、章节策划、自传撰写、忠实度审校、结构化卡片，全部用 TRAE 实现并接入证据门控。
-
前端交互与进度展示：实时语音对话、异步生成进度、记忆卡片、分享二维码、家族故事线。
-
反复测试与回滚：上线后反复验证核心链路，定位并修复 P0/P1 级问题，保证功能闭环。
开发过程截图（方案、代码、验证、审核、部署等真实过程）：
① 创意方案生成（TRAE Work 生成夺标方案与复赛方案）
② 代码开发（TRAE 实现五阶段流水线与前后端）
③ 方言运营与规则研究（抖音运营、大赛规则核查）
④ 产品形式选型与反复测试（拾光形式选择、上线前反复测试与回滚）
⑤ 全量审查与提交（GitHub 项目全量审查、大赛提交）
关键任务 Session ID（不少于 3 个）
-
方案生成（TRAE Work 生成夺标方案与技术架构）：
3446337810203088:fad50940cfa71193fb3bdb74008fb76a_6a316ea33da98d03d0849f2e.6a38d82e2ea5fe383537dc8d.6a38d82e2ea5fe383537dc8b:TRAE Work CN.0.1.21.no_sid.no_ppe.T(2026/6/22 14:37:34) -
代码开发（TRAE 实现五阶段流水线与前后端）：
3446337810203088:ec696741479dcee27b9316eada1f6d74_6a32068a3da98d03d084a26f.6a38d35a2ea5fe383537da57.6a38d35a2ea5fe383537da55:TRAE Work CN.0.1.21.no_sid.no_ppe.T(2026/6/22 14:16:58) -
抖音运营（方言运营与内容策略研究）：
3446337810203088:397f32428e546750b56a195798984513_6a352d56bde54a8bc6494005.6a37b0e22ea5fe383537d6dc.6a37b0e22ea5fe383537d6da:TRAE Work CN.0.1.21.no_sid.no_ppe.T(2026/6/21 17:37:38) -
规则研究（大赛规则核查与合规）：
3446337810203088:f91f81acbf5d6671fe37aae47d6fb6b9_6a31fcc83da98d03d084a20d.6a3217013da98d03d084a28c.6a3217013da98d03d084a28a:TRAE Work CN.0.1.21.no_sid.no_ppe.T(2026/6/17 11:39:45) -
代码验证（上线前后反复验证核心链路）：
3446337810203088:2c85faafc7a199291f8ae13ef121a7b2_6a6c6feac1d8db4c18ed1eea.6a6de12870f81ca73cf81bdd.6a6de12770f81ca73cf81bdb:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/8/1 20:06:00) -
审核与讨论（全量代码审查与修复排期）：
3446337810203088:e951809fc8f87c998d79085904f96965_6a6b8ba4bc4233c91ff0d99e.6a6c6af3c1d8db4c18ed1edd.6a6c6af3c1d8db4c18ed1edb:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/31 17:29:23) -
比赛提交（大赛提交与材料整理）：
3446337810203088:2f8e0dbc3a2c5c7324d17fb59d8df6ae_6a5de03deb830af694457a47.6a6b5e0a9857532263b88bc8.6a6b5e0a9857532263b88bc6:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/30 22:22:02) -
拾光形式选择（产品形式选型与关键决策）：
3446337810203088:1d23eb6a6dab39c5d16c5d9e77b4e961_6a5de6ebeb830af694457cf4.6a5f50adeb830af6944588b0.6a5f50adeb830af6944588ae:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/21 18:57:49) -
复赛方案（复赛升级方案设计）：
3446337810203088:c63f0b4fee5a55bf3b5a47923176c0aa_6a63857d3719756a33b8b300.6a6a3b1921793124706f8e14.6a6a3b1921793124706f8e12:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/30 01:40:41) -
反复测试与回滚（上线前验证与回滚保障）：
3446337810203088:3a6593a3200f4ffb1acc872a7015d24c_6a536cff78118a2d148b172c.6a5da5ee5e27a7e6104956fd.6a5da5ee5e27a7e6104956fb:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/7/20 12:37:02)
技术栈与工程实践
这个项目不是用"炫技"堆出来的，而是以"真实、可信、可传承"为底线，做出来的一个完整、可上线、可长期维护的工程。技术栈全部围绕这三个词选择：
| 层次 | 选型 | 为什么这么选 |
|---|---|---|
| 后端 | Python + Flask + WebSocket | 单人可维护，WebSocket 承接实时语音二进制流 |
| 实时语音 | 火山引擎端到端实时语音大模型 | 长辈免打字、直接说话，端到端低延迟 |
| 方言识别 | 6 种方言（粤语/四川话/上海话/闽南话/陕西话 + 自动识别） | 跨越数字鸿沟，让只会方言的老人也能开口 |
| 数据库 | SQLite + 原子迁移 | 家庭场景数据量小但隐私要求高，零运维成本、可整体备份 |
| 前端 | 原生 JS + CSS + 水墨暖金设计系统 | 无重型框架，加载快、大字界面适配长辈 |
| 配图 | PIL 图像处理 + 可选 AI 配图 | 默认内置水墨插画，不自动产生模型费用 |
| 分享 | 同源生成二维码（python-qrcode） | 二维码不携带 owner token 与访问密码，隐私安全 |
| 支付 | Z-Pay 聚合支付（MD5 签名校验） | 按需付费，fail-closed 配置，漏配密钥时不开放付费功能 |
| 测试 | pytest + Playwright Chromium E2E + Ruff | 覆盖后端契约、浏览器流程与静态检查 |
| 部署 | Nginx + systemd，发布包显式允许清单 | 可回滚、可审计、密钥不落库 |
关键实现思路（为什么"可信"能成立）：
-
证据门控五阶段流水线：
事实抽取 → 章节策划 → 自传撰写 → 忠实度审校 → 结构化卡片。本质不是"让 AI 写一篇漂亮文章"，而是以来源证据为边界——每一段输出都可追溯到原始对话证据，审校阶段不通过就回流重写，保证这是"记忆"而非"小说"。 -
实时语音二进制协议栈：严格按火山引擎 Realtime API 的事件序列（StartConnection → StartSession → AudioTask → FinishSession）对接，配合 GZIP 压缩处理音频流，前后花了 3 天才打通——这是初赛最大的技术难点。
-
异步生成与阶段进度：耗时模型调用在后台执行，前端按五阶段展示真实生成进度，长辈不会面对"转圈"干等。
-
幂等与并发安全：故事碎片提交带内容绑定的幂等键（长度受控），防止弱网重复提交污染记忆；支付订单创建用原子事务，防止并发重复扣款。
-
隐私与安全设计：owner token 与访问密码不落明文、不随二维码泄露；分享接口只返回允许字段；支付失败时默认关闭付费功能（fail-closed）。
可复用的技术决策与风险反思（这些"坑"是上线后踩出来的，也是我最想分享的）：
-
支付必须 fail-closed：一旦支付密钥漏配，默认关闭付费功能，而不是静默免费开放。付费功能必须"先付费、后开放"，否则利益边界会被绕过。
-
幂等键要绑定内容哈希：只查"同一个键"不够，还要核对内容是否一致——否则弱网重发会静默吞掉新记忆。幂等键长度受后端限制，需要截断。
-
支付订单创建要原子化：并发场景下"先查后建"会重复扣款，必须用事务锁住创建过程；回调金额与订单金额不一致要拒绝。
-
会话删除要级联清理：删会话时把关联支付订单一并清理，避免数据残留。
-
普通函数别用 await：前端一个普通函数里误用
await，会直接导致整站 JS 解析失败——这是上线后整站白屏的根因，教训深刻。 -
验收前不替换线上稳定版：把"反复验证、回滚到位"作为上线前准入门槛，宁可晚发布也不带着未经验证的改动上线。
技术方案与创新点
-
证据门控五阶段流水线：不是"自动生成一篇漂亮文章"，而是以来源证据为边界，经过事实抽取、章节策划、自传撰写、忠实度审校、结构化卡片五步，保证生成内容可溯源、不乱编。每条输出可追溯到原始对话证据，确保这是"记忆"而非"小说"——这是家庭信任场景的底线要求。
-
端到端实时语音：接入火山引擎实时语音大模型，长辈直接说话即可，不用打字。
-
克制的 AI 表达：AI 只负责整理与表达，不替长辈创造事实。
-
分级分享与隐私保护：同源生成二维码，阅读与续讲独立权限，密码保护与失效控制，不泄露 owner token 与访问密码。
社会价值与产品迭代规划
社会价值：在中国，有 2.8 亿 60 岁以上的老人，他们每个人的一生都是一本书，但绝大多数家庭没有留下任何口述历史。我希望通过语音交互、大字界面、AI 主动引导，让科技跨越数字鸿沟，帮每一个普通家庭留住长辈的故事与智慧——因为每一个普通人的故事，都值得被记住。
产品迭代规划：
-
人生树多人共建：单人物"人生树"代码候选已完成，正在灰度验证——一棵树只记录一位被记录者，家人分别提交记忆碎片，管理员核对来源与冲突后，AI 才整理成可审核、可发布的完整故事。
-
故事质量评测：建立面向忠实度、连贯性和叙事节奏的可复现评测体系。
-
场景验证：在养老机构、社区和内容传播中验证真实需求，不提前承诺商业结果。
社会价值
在中国，有 2.8 亿 60 岁以上的老年人。
他们经历过战乱、饥荒、建设、改革开放，每一个人的一生都是一本书——但绝大多数普通家庭，没有留下任何口述历史。照片会发黄，记忆会褪色，当老人走了，那些故事也就跟着走了。这是我在奶奶离世后亲身经历的遗憾，也是做这个产品的起点。
科技跨越数字鸿沟
我注意到一个现象：很多长辈只会说方言，不会打字，甚至不会用智能手机。他们不是不想分享，而是被数字时代挡在了门外。
拾光·Echo 从第一天设计就考虑了这一点：
- 免打字：实时语音直接说，长辈拿起手机就能讲
- 多方言支持：支持粤语、四川话、上海话、闽南话、陕西话，覆盖了主要方言区
- 大字界面：水墨暖金风格，对比度高，长辈看得清楚
- AI 主动引导：不用长辈想"接下来该讲什么"，AI 像记者一样顺着话题提问
每一个普通人的故事，都值得被记住
现在的 AI 应用喜欢"创作"、“编故事”，但在家庭记忆这个场景下，"不乱编"比"写得好"更重要。
拾光·Echo 的核心理念是：
- AI 的任务是整理记忆，不是创造记忆
- 每一句话都能追溯到讲述者的原始对话
- 臆测出来的内容过不了审校这一关，必须回流重写
- 家人可以共同核对、补充、续写，保证故事的真实性
这不是一本 AI 写的小说，这是家人共同守护的真实记忆。
家族传承的数字底座
当一代人把故事讲出来，下一代把碎片补上去，这个过程本身就是一种连接：
- 节日团聚，一家人坐在一起，每个人补充一段，比刷手机更有意义
- 追思纪念时，后人能听到长辈自己讲的故事，而不是只看到墓碑上的生卒年月
- 多年以后，子孙还能通过这些声音和文字，知道"我们从哪里来"
技术终将迭代，但人类对"被记住"的渴望永远不变。我希望通过拾光·Echo，帮每一个普通家庭留住长辈的故事与智慧——让回声不消散，让记忆不消失。
如果你也被这个想法打动，欢迎在评论区聊聊：你家里有没有一段，你觉得应该被记录下来的故事？
—— 拾光·Echo · 宇航