【OpenHarmony/HarmonyOs 】端侧 AI 与元服务思路：数学视界的人脸识别开放能力、智能练习与轻量化入口设计

项目类型：OpenHarmony / HarmonyOS ArkTS 数学学习应用
文章主题：人脸识别开放能力、端侧 AI、元服务能力集成
说明：当前项目没有直接接入人脸识别或云端 AI，本文重点分享“如何基于现有项目结构设计可扩展方案” 🧠

一、先说结论：学习应用不一定要上来就做人脸识别

“人脸识别开放能力、端侧 AI、元服务”这些词听起来都很强，但落到数学学习 App 上，不能为了接能力而接能力。

对数学视界来说，更合理的路线是：

1. 先把端侧学习数据组织好；
2. 用本地规则实现“智能练习”和“学习反馈”；
3. 在需要保护个人学习数据时，再考虑系统级用户认证；
4. 把最高频、最轻量的学习入口改造成元服务能力。

也就是说，人脸识别不是用来“识别学生是谁并上传数据”，而更适合用于本地敏感入口保护，例如：

• 打开个人学习报告前做本机认证；
• 查看长期学习统计前做认证；
• 导出学习数据前做认证；
• 家长模式或教师模式切换前做认证。

端侧 AI 也不一定等于大模型。对一个数学学习工具来说，基于本地答题数据做题目推荐、知识点掌握度分析，就是非常实用的端侧智能。

二、项目当前的智能基础：挑战结果与掌握度统计

数学视界的挑战答题并不是简单判断对错，它会记录挑战次数、题目数量、正确数量、耗时、最好成绩、连续通过次数、掌握年级和掌握知识点。

核心数据结构在AppState.ets：

challengeStats: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{conststats=this.challengeStatsstats.totalChallenges++stats.totalQuestions+=result.totalCountstats.totalCorrect+=result.correctCountstats.totalTimeSpent+=result.totalTimeif(result.totalCount>0) {stats.averageScore=Math.round((stats.totalCorrect/stats.totalQuestions) *100)}if(result.score>stats.bestScore) {stats.bestScore=result.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) { total++if(r.questions[j].isCorrect) correct++ } } }returntotal >0? correct / total :0}

基于这个函数，可以继续做一个本地推荐器：

interfaceStudySuggestion {type:'review'|'practice'|'challenge'title: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.difficulty>=4) { weight +=0.5} return weight }

这种端侧 AI 更像“学习策略引擎”。它不需要识别用户照片，也不需要把答案上传到服务器，却能明显提升个性化体验。

五、人脸识别开放能力：更适合做本机认证，而不是业务识别

人脸识别能力在学习 App 中要非常谨慎。我的建议是：不要自己采集和管理人脸图片，不要把人脸模型作为业务数据保存，而是优先使用系统级用户认证能力。

适合接入的场景：

• 🔐 查看学习报告前认证；
• 📤 导出学习数据前认证；
• 👨‍👩‍👧 家长模式切换前认证；
• 🧾 清空历史记录前认证。

业务层可以先定义一个认证入口，而不是直接把人脸逻辑写进页面：

interfaceAuthResult {success:booleanmessage:string}classLocalAuthGuard{asyncverifyBeforeExport():Promise<AuthResult> {// 这里预留系统用户认证能力接入点return{success:true,message:'认证通过'} } }

这样后续无论使用人脸、指纹、锁屏密码还是系统统一认证，业务页面都不需要大改。

六、为什么不建议在项目里保存人脸数据？

学习类应用的核心是学习，不是身份系统。自己保存人脸数据会带来很重的责任：

• 人脸属于高度敏感个人信息；
• 需要明确采集目的、保存周期和删除方式；
• 一旦泄露风险极高；
• 对未成年人场景尤其敏感；
• 很多学习功能其实不需要人脸识别。

所以更好的设计是：

应用只关心“系统告诉我认证是否通过”，不关心“用户的人脸长什么样”。

这也符合最小化原则：不采集、不保存、不传输，就不会产生额外风险。

七、元服务能力：把高频学习动作做轻

数学视界目前是完整应用形态，包含首页、挑战、成就、收藏、我的、画板、公式、计算器等页面。

如果要做元服务化，我不会把整个应用都塞进去，而是拆出轻量入口：

对应到当前项目，很多能力已经有基础：

• 题库来自AppState.ets；
• 单位换算已有独立页面；
• 今日目标来自studyData.dailyGoal和todayCount；
• 收藏公式已有FavoriteItem；
• 挑战结果已有recentResults。

元服务不是“缩小版 App”，而是把某个明确任务做到最短路径。

八、从完整应用到元服务的拆分思路

以“今日一题”为例，可以这样拆：

1. 从本地题库中选一道适合当前年级的题；
2. 展示题目、选项、提交按钮；
3. 答完后显示解析；
4. 更新本地学习统计；
5. 提供“打开完整应用继续练习”入口。

业务模型可以复用现有Question：

exportinterfaceQuestion {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): Promise<boolean> {returntrue} }classAtomicEntryService{ getTodayQuestion(): Question {return{} as Question } }

这样页面只负责展示和交互，智能推荐、认证、元服务入口都可以独立演进。

十、总结

围绕“人脸识别开放能力、端侧 AI、元服务能力集成”，数学视界可以采用一条比较稳的路线：

• 🧠 端侧 AI：先基于本地答题数据做掌握度分析和智能组卷；
• 🔐 人脸识别：只作为系统级本机认证入口，不保存人脸数据；
• 🚀 元服务：拆出“今日一题、公式速查、单位换算、错题复习”等轻量任务；
• 📦 架构上：把推荐、认证、元服务拆成独立服务类，避免和页面强耦合；
• 🛡 隐私上：默认本地处理，敏感能力用户主动触发。

对学习类应用来说，最好的智能不是“看起来用了多少 AI”，而是用户每次打开时，都能更快进入适合自己的学习任务。数学视界的下一步，也会围绕这个方向继续打磨。✨