【听见课堂 HarmonyOS NEXT 实战系列 41】任务候选不能直接进待办：confirmed 字段的产品与数据意义

【听见课堂 HarmonyOS NEXT 实战系列 41】任务候选不能直接进待办confirmed 字段的产品与数据意义从课堂字幕里发现“周五提交实验报告”只是得到一条可能的任务线索并不等于用户已经同意把它加入正式待办。如果应用把规则或模型生成的候选直接写进任务中心误识别、断句错误和上下文缺失都会变成正式数据最终让用户不再信任自动整理功能。听见课堂在TaskItem中使用confirmed把“待人工确认的候选”与“正式任务”分开。当前任务提取仍是明确标注的规则模拟不是已经验证的真实 AI 模型。本文从领域模型、Service 过滤、Repository 写入和页面反馈四层拆解这条人工确认边界。一、同一条任务为什么需要两种身份候选区回答的是“系统认为这句话可能是一项任务吗”任务中心回答的是“用户是否认可并愿意管理这项任务”。二者的责任不同不能只靠页面位置区分。confirmedfalse表示候选confirmedtrue表示正式任务。字段进入领域模型和数据库后即使页面重构、路由变化或设备宽度变化业务语义仍然一致。二、TaskItem 的最小状态集合项目中的任务模型包含标题、截止时间原文、来源、确认状态、完成状态和规范化截止时间exportclassTaskItem{id:string;title:string;dueText:string;source:string;confirmed:boolean;completed:boolean;dueAtMillis:number;}confirmed控制是否进入正式管理链路completed只对正式任务有意义source则保留它从哪段课堂证据产生。三、Service 用过滤规则生成两种视图页面不直接对数据库结果散写过滤条件。ClassroomService分别暴露asyncgetCandidateTasks():PromiseArrayTaskItem{consttasksawaitthis.repository.getTasks();returntasks.filter((item:TaskItem)!item.confirmed);}asyncgetConfirmedTasks():PromiseArrayTaskItem{consttasksawaitthis.repository.getTasks();returntasks.filter((item:TaskItem)item.confirmed);}这样 P08 候选确认页与 P09 任务中心消费的是同一份 canonical data只是业务视图不同。四、任务中心再次执行 confirmed 门禁getTaskCenterSnapshot()会读取全部任务但第一步就是.filter(task task.confirmed)。统计、周历、过期判断和完成切换都只在正式任务集合上进行。这道二次门禁很重要即使某个页面误把候选传给任务中心组件Service 仍不会把未确认数据计入待办总数。五、确认动作只修改一个业务事实页面点击“确认加入”后调用confirmCandidateTask()再由 Service 转交 RepositoryasyncconfirmTask(taskId:string):Promiseboolean{constvalues:ValuesBucket{confirmed:1};returnthis.updateById(TABLE_TASKS,taskId,values);}确认不会重新生成标题也不会丢掉来源。它只改变“用户是否认可”这一事实然后页面重新读取候选、正式任务和聚合快照。六、写后刷新比手工搬卡片可靠确认成功后页面没有把卡片从数组 A 手工移动到数组 B而是调用refreshData()。候选列表、正式任务列表、复盘指标和任务中心统计都会从 Repository 重新计算。这避免了页面局部状态和数据库状态不一致也让 RelationalStore 与内存降级实现遵循同一条刷新路径。七、撤销确认为什么要同时清理 completed项目允许在确认成功后立即撤销。Repository 的unconfirmTask()会把confirmed和completed都重置为 0。原因是一条重新回到候选区的记录不应该继续携带“已完成”身份。否则再次确认时它会绕过用户的待办阶段直接出现在已完成列表。八、候选、正式任务与历史证据不是一回事候选区用于人工判断任务中心用于状态管理复盘与历史页用于解释来源。历史时间线可以展示任务证据并根据confirmed标注“待人工确认”或“已人工确认”。因此确认状态既影响操作权限也影响证据解释但不会删除原始课堂来源。九、来源字段让确认决定可追溯用户确认任务时需要看到标题之外的信息例如来源字幕、课堂时间或板书上下文。当前source与reviewSourceTime()支撑基本跳转P08 也能打开对应复盘节点。这种设计比只保存一个标题更可靠但当前来源时间仍有字符串解析成分后续应演进为结构化证据 ID 和时间字段。十、当前“智能提取”必须按规则模拟表述getCapabilityStatus()明确把“任务智能提取”标为未完成来源为“规则模拟”说明文字是依据时间和关键词生成候选任务。所以文章可以验证候选—确认—任务中心的业务闭环不能据此声称已经接入大模型、具备真实语义理解或达到某个提取准确率。十一、为什么不能让模型直接写 confirmedtrue模型输出天然存在误判。若远端 AI、规则引擎或本地模型拥有直接写正式数据的权限一次错误就可能创建虚假截止时间、重复任务甚至触发后续提醒。更安全的架构是生成器只产出候选 DTO业务 Service 保存为confirmedfalse只有明确的用户动作才能提升为正式任务。十二、完成状态也有 Repository 门禁setTaskCompleted()会先查找任务并拒绝不存在或尚未确认的记录。这样候选任务无法绕过确认流程直接变成“已完成”。页面按钮是否隐藏只是体验层保护Repository 的状态检查才是最终数据边界。十三、AI 建议开关不会删除候选页面的visibleCandidateTasks()在“智能整理”关闭时返回空数组但底层候选仍保留。重新开启后未确认记录可以再次出现。开关控制的是展示与建议能力不应静默删除用户可能需要复核的数据。十四、当前实现仍需补强哪些校验confirmTask()当前直接按 ID 更新没有先检查记录是否已确认重复点击主要依赖页面状态和刷新避免。后续可以增加旧值条件例如只允许confirmed0的一行更新并要求影响行数恰好为 1。如果将来加入多设备同步还需要版本号或乐观锁防止两个设备同时确认、撤销造成覆盖。十五、验收应覆盖完整状态闭环至少验证候选初始不进入任务中心、确认后候选消失且任务中心出现、统计同步变化、撤销后回到候选、完成状态被清理、来源证据仍可打开、重启后 RelationalStore 状态保持。项目既有 P08/P09 证据覆盖确认、撤销和任务中心刷新这不等于真实 AI 候选质量已经验收。十六、总结confirmed不是一个为了方便筛选的布尔值而是自动建议与用户正式数据之间的权限边界。听见课堂让规则或未来模型只能提出候选让用户决定是否进入待办再通过 Repository 门禁和写后刷新保持数据一致。下一篇继续分析为什么候选标题和截止时间只能在确认前编辑以及这条限制如何由页面、Service 和 Repository 共同执行。