# MindSync 英语 · 技术方案与关键难点分析

版本 v1.1 · 2026-07 · CTO 内部文档
配套阅读：《MindSync_Wireframe_v1.1.html》《评测引擎选型决策 v1》《竞品回溯与定位主张 v1》
v1.1 变更：吸收竞品回溯定位结论与产品评审会决议——矫正层定位纪律、口音画像获客钩子、同侪锚点、每日 20 分钟限额、遗忘曲线复习、跟练不采用 WebRTC、难点一风险降级（引擎能力已获产品实拍实证）。

---

## 一、方案总纲

MVP 的技术使命只有一句话：用最少的自研，把「诊断 → 定位 → 训练 → 复测」这个闭环做到体验惊艳，同时从第一天起沉淀数据资产。凡是市场上买得到且不构成壁垒的能力（语音评测、转码、CDN、支付），全部采购；凡是构成壁垒的能力（偏误知识图谱、口腔可视化、内容切片体系、评测数据资产管线），全部自建。这条采购/自建分界线是本方案所有技术决策的依据。

v1.1 在总纲中新增一条**定位纪律**，来源于竞品回溯（Speechace / BoldVoice / ELSA / 大厂产品实证分析）：四家竞品全部止步于「感知」层——Speechace 能听出你把 walk 发成 wERk，BoldVoice 能猜出你的口音来自西安，但没有任何一家告诉用户舌头该放哪、气流该怎么走。**矫正层（口腔可视化 + 偏误知识图谱路由）是本产品唯一不可省的差异化**：任何排期压力下可以砍报告、砍海报、砍画像，永远不砍矫正层；砍掉矫正层，本产品即退化为 Speechace 的换肤。

对应 BP 的资金约束（AI 产品研发 160 万）与时间约束（0–3 个月出原型、3–6 个月 300 人内测），团队配置建议为：全栈工程师 2 名（一前一后或两名全栈）、移动端 1 名（跨端框架则并入全栈）、兼职设计 1 名，外加技术总监做交付治理。评测引擎、动画制作、视频转码均不需要专职算法或多媒体工程师（口音画像为 Phase 2 的 0.3 FTE 算法投入），这是方案刻意压低团队复杂度的结果。

## 二、技术架构

整体为「单体优先」架构：一个后端服务 + 一个跨端 App + 一个 Web 后台，不做微服务。用户量在十万级以内，单体 + 好的模块边界远比微服务省钱省人，未来拆分的缝隙已在模块设计中预留。

```
┌─────────────┐   ┌──────────────┐   ┌──────────────────┐
│  App (iOS/   │   │  管理后台     │   │ 裂变海报 / H5     │
│  Android)    │   │  (Web SPA)   │   │ 口音画像获客页(P2) │
│  Flutter     │   │  React+Antd  │   │                  │
└──────┬──────┘   └──────┬───────┘   └──────┬───────────┘
       └─────────────────┼──────────────────┘
                         │ HTTPS / JSON
              ┌──────────▼──────────┐
              │   API 网关 + BFF     │
              │   (NestJS 单体)      │
              ├─────────────────────┤
              │ 模块：账户/订阅/限额  │
              │ 模块：题库/课程/切片  │
              │ 模块：偏误知识图谱    │
              │ 模块：评测编排 ★     │
              │ 模块：学习状态机     │
              │  (掌握度+遗忘曲线)   │
              │ 模块：数据资产管线    │
              │ 模块：口音画像 (P2)  │
              └──┬────────┬─────┬───┘
                 │        │     │
     ┌───────────▼──┐ ┌───▼───────────┐ ┌▼─────────────┐
     │ PostgreSQL   │ │ 评测引擎抽象层  │ │ 对象存储+CDN  │
     │ (主数据+图谱) │ │ Speechace 主   │ │ 音频/视频HLS  │
     │ Redis(缓存/  │ │ ELSA 影子      │ │ 国内:OSS+备案 │
     │ 队列)        │ │ 自研 预留      │ │ 海外:S3+CF   │
     └──────────────┘ └───────────────┘ └──────────────┘
```

技术选型与理由如下表。

| 层 | 选型 | 理由 |
|---|---|---|
| 移动端 | Flutter | 单代码库双端；音频采集、动画（Rive 官方支持）、视频播放生态成熟；对 3 人团队是唯一现实解 |
| 后端 | NestJS (TypeScript) + Prisma | 与 RampingUp 技术栈评估结论一致，人才池共享；强类型贯穿前后端；模块化边界清晰便于未来拆分 |
| 数据库 | PostgreSQL 16 | 关系数据 + JSONB 存引擎原始报文 + recursive CTE 查知识图谱，一库三用，MVP 不引入图数据库 |
| 缓存/队列 | Redis + BullMQ | 评测异步任务、转码任务、报告生成的轻量队列 |
| 动画 | Rive | 参数化口腔剖面组件，一套骨架驱动全部音标与偏误态，体积与交互性远优于 96 个视频 |
| 视频 | 云厂商转码 → HLS → 双区 CDN | 88 集约 60GB 原片，转码是一次性采购行为，不自建 |
| 评测 | Speechace 主 + ELSA 影子 + 自研预留 | 见第四节；替换音素能力已获产品实拍实证 |
| 口音画像 | HuBERT 微调分类器（Phase 2） | 参照 BoldVoice 公开的 hubert-accent-identifier 架构；只做画像获客，不做诊断 |
| TTS 示范音 | Fish Audio | 题库示范音（美/英）批量生成，边际成本趋零，且为集团内协同 |
| 支付 | iOS IAP + 微信/支付宝 + Stripe | 订单中心统一对账模型，渠道只是 Provider |
| 部署 | 国内：阿里云（备案主体）· 海外：AWS 新加坡 | 见第六节合规架构 |

**明确不采用：跟练不使用 WebRTC。** 会议初案曾提出 WebRTC 实时跟练 + 实时唇形 AI 分析，v1.1 正式确认为不采用，理由：跟练反馈的瓶颈在评测引擎（约 800ms），不在传输——录制后上传同样达成 1.5 秒闭环；1000 并发 WebRTC 需要 SFU/TURN 集群与持续带宽，而 300–500 日活的真实并发约 30–60，投入产出严重失衡；实时唇形分析是独立研究项目而非一个功能。WebRTC 的正确去处是 V2 的 1v1 真人课教学工具（实时拆词评分、回放对比），届时单独立项。

## 三、核心数据模型

十一张表构成产品的骨架，其余皆为常规业务表。

phoneme（48 音标主表）记录符号、双口音 IPA、发音学属性（清浊、舌位、肌群标签）。course_video 与 video_clip 记录 88 集课程与切片打点，切片只存时间戳元数据不做物理剪辑。practice_item（题库）为清洗后的练习语料，含类型（单词、句子、最小对立组、音素簇）、双口音 IPA、主训音素、涉及音素清单、难度、诊断句标记。phoneme_error_rule（偏误规则）是知识图谱主表：检测模式（如 ð→d）、成因文案、纠正路由（动画参数 + 切片 ID）、严重度系数。phoneme_synergy（协同边）存音素间训练协同权重，驱动优先级排序。assessment_attempt（评测记录）是数据资产核心：音频对象键、条目 ID、引擎原始 JSON、归一化后的音素报告、所用图谱版本、置信度。human_annotation 存人工抽检改判结果。user_phoneme_mastery 存用户 × 音标的掌握度快照，驱动 48 音标地图。

v1.1 新增两张表。**review_schedule（复习排程）**：按艾宾浩斯遗忘曲线为每个已训音标生成复习到期时间（1/2/4/7/15 天间隔，答对延长、答错缩短），驱动首页复习卡，穿插旧音标以解决「48 天线性课程之后无内容」的问题。**daily_usage（每日用量）**：记录用户当日累计训练时长与评测次数，实现每日 20 分钟限额——该限额同时达成三个目的：引擎成本封顶、符合肌肉训练的科学节奏、作为升级订阅的付费诱饵（会议纪要决议）。

两个设计纪律必须从建库第一天执行。第一，错误单元支持三种粒度（单音素、音素簇、音节），/kjʊ/ 这类簇不能拆散存储，否则 V2 重读弱读模块无处安放。第二，评测记录永远同时保存引擎原始报文与归一化结果，原始报文是未来自研模型的训练原料，归一化结果才给业务消费。

## 四、评测引擎策略（全案最关键决策）

引擎选型结论：主引擎 Speechace（美英双口音、音节级反馈、纯 API 厂商无 C 端利益冲突、数据权属归调用方且可零留存），影子引擎 ELSA API（5% 流量双发对比，积累换引擎与议价筹码），自研 HuBERT MDD 作为 12 个月后的规划项预留接口位。完整论证见《评测引擎选型决策 v1》。

**替换音素能力已获双重确认（v1.1 更新）。** 文档层面：Speechace 官方文档确认返回 `sound most like` 字段；产品层面：竞品回溯获得 Speechace 真实产品界面实拍——walk 的 AO 音被标注 "Sound like ER"，音节级替换音素诊断在生产环境实际运行。据此，原「引擎能力与宣传可能存在落差」的第一风险**降级为低风险**，PoC 目标相应收窄为三项：① 该字段对中式偏误对（ð→d、r→l、θ→s、n→l、v→w、词尾清浊）的命中率；② 音素簇（/kjʊ/）与音节脱落的识别粒度；③ Singapore 节点从大陆/香港的实测延迟。降级链路（知识图谱按「音素 × 中文母语」查表推断，UI 措辞「这个音华人常见的问题是发成 /d/」）仍然实现，作为低置信度兜底，评测记录用 error_source 字段区分两种来源。

抽象层接口统一为 assess(audio, text, ipa_target, accent, mode) → PhonemeReport，所有厂商报文归一化到同一 schema。这一层约一周工作量，换来的是永久的供应商自由度。

双通道设计：句子诊断通道全量分析容忍 2–4 秒并配诊断动画过渡；跟练快通道只判目标音素，端到端预算 1.5 秒（录音停止 → 上传 500ms → 引擎 800ms → 渲染 200ms），超时静默重试一次，再失败展示「本次未采集成功」而非错误弹窗。

成本模型：单次评测约 0.03–0.06 元（Speechace 教育批量价待谈，ELSA 公开价 $0.008/15s 作谈判锚点；询价优先争取按请求计费或短音频档位——我方跟练音频 2–4 秒/条，按 15 秒计费等于 80% 付给空气，谈成可降至 1/3–1/5）。**每日 20 分钟限额使单用户成本有了硬上限**：按限额满负荷估算，活跃用户月成本封顶约 4–6 元，对 999 元/年订阅毛利结构健康且可预算。后台 B6 设单用户日调用 300 次的风控阈值防脚本刷量。

**口音画像（HuBERT 的正确用途，Phase 2）。** 竞品回溯实证：BoldVoice 公开的 HuBERT 模型是口音识别器（分类头输出 50 类母语背景），不是音素诊断器；其 Accent Detector / Accent Oracle 把口音检测包装成病毒获客游戏。MindSync 复刻该玩法：HuBERT 微调「中文母语背景/地域相似度」分类器，产品形态为 A9 口音画像页（H5 可独立投放 + 直播间当场诊断 + App 内趣味功能），结果页锚点从 BoldVoice 的「好玩」改为「你的口音离目标形象还差 N 个音」，导流至完整诊断注册。冷启动先做「中文/非中文 + 大区」粗分类，随自有数据积累细化到省域。训练标签来源为用户授权录音 + 教练人工标注，不使用商用引擎输出作为训练标签（规避 ToS 风险）。

## 五、关键技术难点（按风险排序，v1.1 重排）

难点一（原难点二上移）：偏误知识图谱的建模与维护工具。技术上不难（PostgreSQL 关系表 + 递归查询即可），难在它是教学知识的数字化，Jessie 是唯一的知识源且她不写 SQL。这也是竞品回溯确认的核心壁垒所在——引擎人人可买，这张图谱买不到。对策是 B4 后台把图谱做成她能直接编辑的表格化界面，带版本管理与审批发布流，每次评测记录图谱版本号以便回溯。MVP 只需覆盖 Top15 高频偏误即可上线，切忌追求 48 音标全量建模后再发布。Jessie 的 3–4 个工作日工作坊是全项目唯一无法外包、无法并行绕过的路径依赖，签约当周锁定日程。

难点二：口腔动态可视化的工程化。48 音标 × 各偏误态若做成独立视频，体积、维护、交互性全部崩坏。对策是 Rive 参数化组件：一套口腔侧剖骨架（下颌开合、舌尖/舌面/舌根位置、气流粒子路径、声带振动指示），全部音标与偏误态由参数驱动。设计 + 动画师 + 前端联调预估 3–4 周，是前端侧最大的自研投入。定位纪律在此重申：本项与知识图谱共同构成矫正层，不得因排期降级。

难点三（原难点一降级）：替换音素识别的中式偏误命中率。能力存在性已被文档与产品实拍双重证实，剩余风险仅在于对中式偏误对的具体命中率与音素簇粒度——PoC（30 条样本）在 Phase 0 完成即可给出结论，且降级链路兜底已设计，不构成交付风险。

难点四：端侧音频采集质量。评测准确率的方差一半来自输入质量。对策：端侧 VAD 裁剪静音、信噪比不达标前置拦截（配可操作提示文案）、16kHz/16bit 单声道统一采样、iOS/Android 增益差异校准。这些细节决定「同一个用户在地铁里和在家里测出的分数是否可比」，直接影响用户对产品公正性的信任。

难点五：视频切片体系。88 集原片到可路由切片库的管线：转码（一次性）、打点工作台（B2 后台）、审核流、HLS 按时间戳播放。工程量集中在打点工作台的交互体验，内容团队要在里面工作数百小时，值得把快捷键、波形预览、批量操作做顺手。

难点六：双区部署与数据合规。国内用户数据（含语音这一敏感生物信息线索）不出境，海外评测引擎调用构成数据出境场景。对策：架构上国内区（阿里云 + 备案 + 国内评测节点或代理合规评估）与海外区（AWS 新加坡 + Speechace 直连）物理分离，账号体系互不相通，共享的只有代码库与题库内容包。结合 BP 的市场节奏（国内练兵 → 海外变现），建议 MVP 内测先上国内区但控制在小规模白名单（300 人内测属可控范围），公开上架前完成 PIPL 数据出境评估或切换国内评测方案。录音数据用于评测、模型改进与（1v1 场景）课程素材的授权在注册时独立勾选、分项同意，必要时匿名化处理——这是数据资产合法性的地基。

难点七：数据资产管线。每条评测持久化五元组（音频 + 条目 + 原始报文 + 图谱版本 + 人工标注），配合 B5 抽检工作台的人机一致率闭环。这不是功能需求而是战略需求：BP 12–18 个月里程碑「发音数据库 · 标签库」和 A 轮融资故事里的「数据壁垒」全部由这条管线日积月累。自研模型的训练标签来自教练人工标注（而非商用引擎输出），法律权属干净。存储分层（90 天热 + 归档冷存）控制成本。

## 六、MVP 里程碑（对齐 BP 融资后路线图与 Phase 划分）

| 阶段 | 交付 | 验收标准 |
|---|---|---|
| M0–M1（Phase 0） | 引擎 PoC（30 条偏误样本双引擎实测）· 技术选型定稿 · 题库清洗完成 · 知识图谱 Top15 建模 · 高保真 UI | PoC 报告给出中式偏误命中率结论与引擎签约条款建议 |
| M1–M3 | 评测抽象层 · 诊断闭环（A1–A4）· Rive 口腔组件首批 5 个音标 · 后台 B3/B4 | 内部可走通「诊断 → 定位 → 排序」全流程 |
| M3–M5 | 训练闭环（A5–A6）· 复习排程与 20 分钟限额 · 视频转码与切片打点（B2）· 音标地图（A7）· 订阅支付与私域转化入口 | 300 人白名单内测上线，北极星指标：首训练闭环完成率 ≥35% |
| M5–M6 | 数据看板 B1 · 抽检工作台 B5 · 引擎监控 B6 · 裂变海报（同侪锚点文案） | AI 初筛 + 人工抽检混合闭环运转，人机一致率 ≥85% |
| M6–M12（Phase 2） | 48 音标动画补全 · 海外区部署 · 声音形象报告 PDF · **口音画像获客钩子（A9）** · V2 模块技术预研 | 500–1000 名用户数据沉淀，发音数据库与标签库成形（可融资版本）；口音画像 H5 投入获客 |

## 七、成本估算（首年，粗粒度）

外包/采购项：视频转码与 CDN、评测引擎、云资源双区及口腔动画设计。具体采购预算、委外交付报价与付款结构均为内部商务信息，不在公开技术文档中披露。

---

附：本方案配套交付物为《MindSync_Wireframe_v1.1.html》（App 端 9 组页面 + 后台 6 组模块，含 A9 口音画像获客钩子与逐屏工程标注），以及《竞品回溯与定位主张 v1》（含 Speechace / BoldVoice 产品实拍证据，可作 BP 附录）。