【听见课堂 HarmonyOS NEXT 实战系列 43】拒绝、撤销拒绝、稍后处理：任务候选的非破坏性交互

【听见课堂 HarmonyOS NEXT 实战系列 43】拒绝、撤销拒绝、稍后处理任务候选的非破坏性交互课堂里的自动候选不可能每一条都准确。如果“不是任务”直接等同于数据库删除用户误触后将失去来源证据也无法区分“这次不想处理”和“永远不要再出现”。对尚未验证准确率的规则或模型来说破坏性拒绝尤其危险。听见课堂当前把拒绝和稍后处理设计为页面内隐藏正式任务不会增加底层候选也不会删除用户可以立即撤销。这个方案适合演示和低风险验证但它还不是完整的持久化候选状态机。本文把已实现行为和后续演进边界分开说明。一、“不是任务”为什么不能直接 delete候选可能来自误识别也可能只是用户暂时不想处理。直接删除会丢失判断依据还可能让同一条规则在下次刷新时重新生成形成“删了又来”的循环。非破坏性操作先改变可见性给用户保留撤销机会也为后续分析候选质量留下空间。二、当前拒绝集合保存在页面状态P08 使用hiddenCandidateTaskIds记录本次被隐藏的任务 ID。拒绝函数只向数组追加 ID并清理当前选择privaterejectCandidateTask(taskId:string):void{if(!this.hiddenCandidateTaskIds.includes(taskId)){this.hiddenCandidateTaskIds[...this.hiddenCandidateTaskIds,taskId];}if(this.selectedCandidateTaskIdtaskId){this.selectedCandidateTaskId;}this.notice候选任务已暂不加入本次演示可立即撤销。;}这里没有 Repository 调用所以数据库记录保持不变。三、visibleCandidateTasks 负责展示过滤候选原始集合来自 Service页面只在渲染前过滤隐藏 IDreturnthis.candidateTasks.filter((task:TaskItem)!this.hiddenCandidateTaskIds.includes(task.id));显示集合和 canonical data 分开后撤销只需恢复过滤状态不需要重新插入一条任务。四、撤销拒绝为什么成本很低undoRejectedCandidates()将隐藏 ID 数组清空并显示“候选任务重新显示”。因为原记录从未被删除撤销不涉及数据库恢复、主键重建或来源补写。这是可逆交互最直接的工程收益。五、全部稍后处理不是批量删除deferAllCandidateTasks()把当前候选 ID 全部写入隐藏数组同时清空选中项和编辑项。页面明确提示“未写入正式任务”。它表达的是“这批先不处理”不是“这些候选无效”。用户仍可点击“撤销稍后处理”恢复。六、逐项拒绝与批量稍后处理语义不同逐项“不是任务”表示用户对某条候选做了负向判断“全部稍后处理”更接近延迟决策。当前两者都落到同一个隐藏数组交互可用但业务语义尚未持久化区分。如果未来要评估规则质量必须记录不同原因而不能只看到“不可见”。七、确认操作才会修改正式数据状态“确认加入”调用 Service 和 Repository把confirmed更新为真拒绝与稍后处理都不改confirmed。因此 P09 正式任务中心只会新增经过人工确认的记录。这保证了隐藏候选不会因为页面操作失误进入待办统计。八、AI 建议开关是另一层可见性控制当aiSuggestionsEnabled关闭时visibleCandidateTasks()直接返回空数组但候选数据仍在本机。开关控制是否展示建议不应被理解为清空数据库。重新开启后未确认且未被本次页面状态隐藏的候选可以继续复核。九、页面刷新和应用重启的边界refreshData()会重新读取候选但不会主动清空当前页面的隐藏 ID因此同一页面生命周期内的隐藏通常仍然有效。应用进程重启后短生命周期数组会恢复默认值候选可能重新出现。文章必须明确当前是可演示的临时撤销机制不是已经持久化的拒绝历史。十、为什么当前方案仍有产品价值在候选生成能力尚处于规则模拟阶段先验证“用户不会被迫接受”“可以撤销”“正式数据不被污染”比急着设计复杂拒绝表更重要。它以较小实现成本建立了正确的权限方向并为后续 schema 演进保留空间。十一、后续 schema 可以怎样演进可以为任务增加candidate_status取值如pending、confirmed、rejected、deferred再增加decision_at、decision_reason和可选的生成器版本。正式任务的confirmed仍可保留或在迁移后由状态字段统一表达。迁移必须兼容已有记录与内存降级实现。十二、拒绝记录不等于训练数据授权即使持久化用户的拒绝原因也不能默认把这些数据上传用于模型训练。课堂字幕、任务标题和来源可能含个人信息或课程隐私。若将来要做质量分析应先定义本机统计、匿名化范围、用户选择和删除机制。十三、批量操作需要稳定快照当前“全部稍后处理”从candidateTasks直接提取所有 ID。如果未来候选在后台异步更新批量操作应基于用户点击时的可见快照并记录实际影响数量。这样新增候选不会被一次旧操作意外隐藏。十四、错误恢复应区分本地态和存储态页面隐藏操作本身不会失败但未来持久化后可能遇到写入异常。界面应明确“仅本次隐藏”还是“已保存决定”不能在保存失败时仍展示永久成功文案。最安全的做法是先写 Repository成功后再更新可见集合失败则保留候选并提供重试。十五、验收清单至少验证单条拒绝立即隐藏、撤销后恢复、全部稍后处理不进入任务中心、撤销批量操作恢复、确认任务不再出现在候选、AI 开关不删除数据、页面重启后临时隐藏状态按设计恢复。如果引入持久化还要补迁移、重复点击、并发更新、清除数据和隐私导出检查。十六、总结候选任务的“拒绝”首先应该保护用户而不是保护算法输出。听见课堂当前用页面隐藏实现低风险、可撤销、不污染正式待办的交互并明确它只在短生命周期内有效。下一篇转向截止时间如何把“今晚”“明天 20:00”“本周五”等中文表达解析为可排序、可判断过期的本地时间同时避免夸大规则解析能力。