【OpenHarmony/HarmonyOs 】端侧 AI 与元服务思路数学视界的人脸识别开放能力、智能练习与轻量化入口设计项目类型OpenHarmony / HarmonyOS ArkTS 数学学习应用文章主题人脸识别开放能力、端侧 AI、元服务能力集成说明当前项目没有直接接入人脸识别或云端 AI本文重点分享“如何基于现有项目结构设计可扩展方案” 一、先说结论学习应用不一定要上来就做人脸识别“人脸识别开放能力、端侧 AI、元服务”这些词听起来都很强但落到数学学习 App 上不能为了接能力而接能力。对数学视界来说更合理的路线是先把端侧学习数据组织好用本地规则实现“智能练习”和“学习反馈”在需要保护个人学习数据时再考虑系统级用户认证把最高频、最轻量的学习入口改造成元服务能力。也就是说人脸识别不是用来“识别学生是谁并上传数据”而更适合用于本地敏感入口保护例如打开个人学习报告前做本机认证查看长期学习统计前做认证导出学习数据前做认证家长模式或教师模式切换前做认证。端侧 AI 也不一定等于大模型。对一个数学学习工具来说基于本地答题数据做题目推荐、知识点掌握度分析就是非常实用的端侧智能。二、项目当前的智能基础挑战结果与掌握度统计数学视界的挑战答题并不是简单判断对错它会记录挑战次数、题目数量、正确数量、耗时、最好成绩、连续通过次数、掌握年级和掌握知识点。核心数据结构在AppState.etschallengeStats:ChallengeStats{totalChallenges:0,totalQuestions:0,totalCorrect:0,totalTimeSpent:0,averageScore:0,bestScore:0,currentStreak:0,longestStreak:0,masteredGrades:[],masteredKnowledge:[],recentResults:[],categoryStats:{},}每次挑战结束后项目会更新统计recordChallengeResult(result:ChallengeResult):void{conststatsthis.challengeStatsstats.totalChallengesstats.totalQuestionsresult.totalCountstats.totalCorrectresult.correctCountstats.totalTimeSpentresult.totalTimeif(result.totalCount0) {stats.averageScoreMath.round((stats.totalCorrect/stats.totalQuestions) *100)}if(result.scorestats.bestScore) {stats.bestScoreresult.score} }这就是端侧智能的第一步先有高质量本地数据。三、端侧 AI 思路一用本地规则生成学习建议项目里已经有知识点正确率计算privategetKnowledgeCorrectRate(knowledgeId:string): number{lettotal 0letcorrect 0for(leti 0; i this.challengeStats.recentResults.length; i) {constr this.challengeStats.recentResults[i]for(letj 0; j r.questions.length; j) {if(r.questions[j].question.knowledgeIds.indexOf(knowledgeId) 0) { totalif(r.questions[j].isCorrect) correct } } }returntotal 0? correct / total :0}基于这个函数可以继续做一个本地推荐器interfaceStudySuggestion {type:review|practice|challengetitle:stringreason:stringknowledgeId?:string} function buildSuggestion(rate: number, knowledgeName:string): StudySuggestion {if(rate 0.6) {return{type:review, title:建议复习 knowledgeName, reason:最近正确率偏低先看公式和例题会更稳, } }if(rate 0.8) {return{type:practice, title:继续练习 knowledgeName, reason:已经入门可以通过 10 题练习巩固, } }return{type:challenge, title:挑战更高难度, reason:当前知识点掌握较好可以尝试限时题, } }这不是大模型但它很实用不需要网络不需要上传学习数据解释性强对低龄学生更可控可以直接和现有题库、成就系统结合。四、端侧 AI 思路二智能组卷挑战配置页中用户可以选择年级、知识点、题目数量、难度、限时constconfig: ChallengeConfig { gradeId:this.selectedGradeId, knowledgeIds:this.selectedKnowledgeIds, questionCount: questions.length, timeLimit:this.timeLimit, difficulty:this.selectedDifficulty, }现在的组卷逻辑是从题库中筛选并打乱let pool: Question[] getQuestionsByGradeAndKnowledge(this.selectedGradeId,this.selectedKnowledgeIds)if(this.selectedDifficulty 0) { pool pool.filter((q: Question): boolean q.difficulty this.selectedDifficulty) }constquestions: Question[] shuffleQuestions(pool,this.selectedCount)后续可以升级为“智能组卷”最近错得多的知识点提高权重太简单的题降低出现概率长时间没练的知识点重新加入限时模式下优先选择计算量适中的题复盘模式下优先展示曾经做错的题。示意逻辑function getQuestionWeight(q: Question, weakKnowledge: string[]): number { let weight 1q.knowledgeIds.forEach((kid: string) {if(weakKnowledge.indexOf(kid) 0) { weight 2} })if(q.difficulty4) { weight 0.5} return weight }这种端侧 AI 更像“学习策略引擎”。它不需要识别用户照片也不需要把答案上传到服务器却能明显提升个性化体验。五、人脸识别开放能力更适合做本机认证而不是业务识别人脸识别能力在学习 App 中要非常谨慎。我的建议是不要自己采集和管理人脸图片不要把人脸模型作为业务数据保存而是优先使用系统级用户认证能力。适合接入的场景 查看学习报告前认证 导出学习数据前认证 家长模式切换前认证 清空历史记录前认证。业务层可以先定义一个认证入口而不是直接把人脸逻辑写进页面interfaceAuthResult {success:booleanmessage:string}classLocalAuthGuard{asyncverifyBeforeExport():PromiseAuthResult {// 这里预留系统用户认证能力接入点return{success:true,message:认证通过} } }这样后续无论使用人脸、指纹、锁屏密码还是系统统一认证业务页面都不需要大改。六、为什么不建议在项目里保存人脸数据学习类应用的核心是学习不是身份系统。自己保存人脸数据会带来很重的责任人脸属于高度敏感个人信息需要明确采集目的、保存周期和删除方式一旦泄露风险极高对未成年人场景尤其敏感很多学习功能其实不需要人脸识别。所以更好的设计是应用只关心“系统告诉我认证是否通过”不关心“用户的人脸长什么样”。这也符合最小化原则不采集、不保存、不传输就不会产生额外风险。七、元服务能力把高频学习动作做轻数学视界目前是完整应用形态包含首页、挑战、成就、收藏、我的、画板、公式、计算器等页面。如果要做元服务化我不会把整个应用都塞进去而是拆出轻量入口元服务入口适合功能原因今日一题每天一道数学题高频、轻量、可快速完成公式速查常用公式卡片不需要完整 App 路径单位换算长度、面积、体积换算工具属性强今日目标查看学习进度信息短、打开快错题复习最近 3 道错题任务明确对应到当前项目很多能力已经有基础题库来自AppState.ets单位换算已有独立页面今日目标来自studyData.dailyGoal和todayCount收藏公式已有FavoriteItem挑战结果已有recentResults。元服务不是“缩小版 App”而是把某个明确任务做到最短路径。八、从完整应用到元服务的拆分思路以“今日一题”为例可以这样拆从本地题库中选一道适合当前年级的题展示题目、选项、提交按钮答完后显示解析更新本地学习统计提供“打开完整应用继续练习”入口。业务模型可以复用现有QuestionexportinterfaceQuestion {id:stringtype:stringgradeId:stringknowledgeIds:string[]difficulty:numbertitle:stringanswer:stringanalysis:stringcreatedAt:numberusageCount:numbercorrectRate:number}这样元服务和完整应用共享同一套题目结构后续维护成本会低很多。九、架构建议把 AI、认证、元服务都变成可替换模块如果继续演进我建议把项目拆出几个服务类classStudyInsightService{ buildSuggestions(): StudySuggestion[] {return[] } }classSmartQuestionService{ pickQuestions(config: ChallengeConfig): Question[] {return[] } }classLocalAuthService{ async verify(reason:string): Promiseboolean {returntrue} }classAtomicEntryService{ getTodayQuestion(): Question {return{} as Question } }这样页面只负责展示和交互智能推荐、认证、元服务入口都可以独立演进。十、总结围绕“人脸识别开放能力、端侧 AI、元服务能力集成”数学视界可以采用一条比较稳的路线 端侧 AI先基于本地答题数据做掌握度分析和智能组卷 人脸识别只作为系统级本机认证入口不保存人脸数据 元服务拆出“今日一题、公式速查、单位换算、错题复习”等轻量任务 架构上把推荐、认证、元服务拆成独立服务类避免和页面强耦合 隐私上默认本地处理敏感能力用户主动触发。对学习类应用来说最好的智能不是“看起来用了多少 AI”而是用户每次打开时都能更快进入适合自己的学习任务。数学视界的下一步也会围绕这个方向继续打磨。✨
