【听见课堂 HarmonyOS NEXT 实战系列 01】从“听不清”到“可追溯”：听障课堂助手如何建立证据闭环

对听障学生来说，课堂中的困难往往不是单纯“没听清一句话”，而是信息在短时间内连续流失：教师讲解没有留下文字，黑板内容来不及抄，口头布置的作业散落在不同时间点，课后也无法确认某条记录到底来自课堂原话、板书照片还是人工补录。

“听见课堂”是一个面向 HarmonyOS NEXT 的多模态无障碍课堂助手。它没有把实时字幕、板书扫描和任务整理做成三个彼此孤立的工具，而是围绕一条更重要的主线展开：让课堂信息从瞬时内容变成可确认、可回看、可追溯的证据。

一、产品目标不是“功能越多越好”

如果只看功能列表，这类应用很容易被设计成录音、OCR、待办事项的集合。但真实课堂中，用户最关心的是三个问题：

1. 这段文字来自哪里？
2. 它发生在什么时候？
3. 它是否已经经过我的确认？

因此，听见课堂把产品主流程归纳为四个阶段：

• 实时字幕：把课堂语音转成可阅读的文本片段；
• 板书扫描：把黑板、投影或纸面内容转成图像证据和识别文本；
• 人工确认：用户对机器生成的内容进行修正、确认或删除；
• 任务沉淀：将已确认的信息整理成课后任务，并保留来源关系。

这个顺序很关键。机器识别结果不能直接成为“事实”，任务也不能脱离来源自动出现。系统可以辅助提取，但最终确认权应留给用户。

二、领域模型先记录来源，再追求界面好看

项目在 common-core 模块中定义了课堂核心数据。以字幕片段和扫描笔记为例，模型不只包含展示文本，还记录了时间、说话人、重点标记、识别置信度和来源：

export class TranscriptSegment {
  id: string;
  timestamp: string;
  speaker: string;
  text: string;
  isKeyPoint: boolean;
}

export class ScanNote {
  id: string;
  title: string;
  text: string;
  confidence: number;
  source: string;
}

这里的 timestamp、speaker、confidence 和 source 不是多余字段。它们决定了后续能否回答“这条内容来自哪里”“这段信息是否需要复核”等问题。当前模型以 TaskItem.confirmed 表示任务是否确认，以 TranscriptSegment.isKeyPoint 表示人工重点标记；它没有伪造一个统一的“所有证据均已确认”字段。

在界面层，用户看到的是一段字幕、一张扫描卡片或一个任务；在数据层，它们必须仍然能回到对应课程、时间点和原始证据。这样设计后，复习页不只是信息堆叠，而是一条能够解释自身来源的证据链。

三、人工确认是闭环的核心节点

无障碍场景中的 AI 结果尤其不能被包装成绝对准确。教室噪声、多人说话、方言、远距离收音、模糊板书和反光都会影响识别结果。

听见课堂把人工确认落在任务流中，并在复习快照里统一聚合字幕重点、扫描数量、完成率和待办数量。Service 层负责业务计算，页面只消费处理后的结果：

async getReviewSnapshot(): Promise<ReviewSnapshot> {
  const course: CourseSummary = await this.repository.getTodayCourse();
  const transcript: Array<TranscriptSegment> = await this.repository.getTranscript();
  const scans: Array<ScanNote> = await this.repository.getScanNotes();
  const tasks: Array<TaskItem> = await this.repository.getTasks();
  const confirmedTasks = tasks.filter((item: TaskItem) => item.confirmed);
  const keyPointCount = transcript.filter((item: TranscriptSegment) => item.isKeyPoint).length;
  // 后续统一计算完成率、掌握度、待办数与复习时间线
}

这段分层带来两个好处：

• 页面不需要重复编写统计规则，手机、平板和 2in1 可以共享同一业务口径；
• 未来增加更细粒度的证据确认状态时，可以先扩展领域模型和 Service，而不是在多个页面中各写一套判断。

四、本地优先，不等于忽略能力边界

项目采用本地优先策略，课程、字幕、扫描记录和任务由本地 Repository 管理。这样可以降低网络不稳定对课堂主流程的影响，也能减少敏感课堂内容不必要的外传。

但“本地优先”不能被写成“所有 AI 能力都已离线且完全可用”。项目对能力状态做了明确区分：

• 字幕链路已经接入应用结构，但真实课堂中的识别质量仍需持续用设备验证；
• OCR 已接入扫描流程，但清晰度、反光和拍摄角度仍会影响成功率；
• 任务规则当前属于可验证的本地规则能力，不应描述成已经接入云端大模型；
• 多设备能力当前主要体现在手机、平板、2in1 的布局适配，不应等同于跨设备协同已经上线。

这类边界最好直接体现在产品状态中，例如“能力准备中”“识别结果待确认”“当前设备不支持”，而不是让按钮看起来能用、点击后却没有明确反馈。

五、从一次课堂到一次完整回看

一条理想的用户路径可以这样串联：

1. 用户进入课程并启动实时字幕；
2. 系统持续生成带时间戳的字幕片段；
3. 遇到重点板书时，用户拍照并保存识别结果；
4. 课后进入复习页，对字幕重点、OCR 文字和任务候选进行人工复核；
5. 已确认任务进入任务中心，字幕与扫描作为复习证据保留；
6. 用户可以从任务回到对应课程证据，而不是只看到一条失去上下文的待办。

这个闭环把“识别能力”转化成了“可用的学习过程”。对无障碍产品来说，真正的价值不是 AI 输出了多少文字，而是用户能否理解、修正并掌控这些文字。

六、验证时要把四种证据分开

这类项目至少应区分四个验证层级：

验证层级	能证明什么	不能证明什么
静态检查	模型、路由、资源和 ArkTS 规则基本正确	真机上的能力可用性
hvigor 构建	工程能够产出 HAP/APP	页面一定可操作、AI 结果一定准确
真机冷启动	Ability、模块安装和首页加载正常	所有课堂环境都稳定
场景测试	某台设备、某类噪声或图片下流程可用	所有设备和所有场景均已覆盖

听见课堂现有交付记录已经分别保存构建、真机与能力验证结果。写文章时也要保留这种边界：已集成不等于已在所有设备验证，成功构建也不等于真实课堂效果已经达标。

总结

听障课堂助手的核心不是把字幕、OCR、任务三个功能放在同一个首页，而是用统一的数据模型和确认流程，把它们连成一条可信的课堂证据链。

下一篇将拆解听见课堂的 Stage Model 多模块架构，看看 entry、common-core、common-ui 和 shared-business 如何分工，以及 HAR 与 HSP 在真实安装流程中分别承担什么角色。