账号模型
家长
学生 A当前
学生 B
01 / 统一身份
家长、学生与多档案必须共用同一账户体系
听写记录属于哪个学生？作文属于谁？积分记到谁名下？家长切换学生后看到什么？这些问题必须由统一的身份模型解决，而不是在每个模块里各写一套。
身份不清，后续所有学习结果都无法可靠归属。
CASE STUDY · K12 LEARNING APP
K12 学习 App 开发案例：打通听写、AI 作文与自然拼读的一体化学习链路
为教育产品方开发并上线一套 K12 学习 App，将家长/学生账号、教材单元、听写任务、点阵笔书写、AI 作文批改、自然拼读评测与积分激励整合到同一套学习数据体系中。难点不在于分别实现这些功能，而是让不同学习场景共享同一套身份、任务、结果和运营体系——不是把功能堆在一起，而是让一套学习产品真正跑起来。
K12 学习 AppPC 管理后台点阵笔集成AI 作文批改自然拼读评测学习积分
Dictation → Writing → Phonics
apple
ant
自然拼读一组
8.5 / 10
项目背景
客户需要的不是几个独立功能，而是一套完整的家庭学习 App
项目需要覆盖按教材单元听写、点阵笔书写、错词复练、AI 作文批改、绘本分享、自然拼读评测、积分闯关，以及管理端持续维护词表、任务与规则——这些功能单独开发并不复杂，但它们不能各自拥有一套账号、一套任务和一套数据。
听写任务
三年级 · 下 · 第四单元
词
19
appleantbook
19 个错词
02 / 任务体系
听写不是页面，而是一项完整的学习任务
教材单元 → 词表 → 音频 → 书写 → 提交 → 结果 → 错词 → 复练——只有把这些状态串起来，听写才真正具备持续运营能力，而不是一次性的练习演示。
任务不断链，内容才能按单元长期更新。
AI 结果模型
对话回复…
…
结构化批改
03 / 结果沉淀
AI 批改不能只是一次性对话
批改结果需要保存、查询、分享、再加工、绘本生成，并回到作品库。我们将 AI 输出结构化，纳入统一作品模型，让一次作文提交能继续被产品使用。
AI 是作品生产链中的处理节点，而非独立功能。
积分引擎
8.5规则 #3
04 / 激励运营
积分规则必须可以运营，而不是写死在代码里
拼读、作文、闯关等不同学习行为都可能产生积分。规则若绑死在业务代码中，每次调整都要重新开发和发布——因此积分规则由管理端配置和维护。
激励层上线后仍可调整，产品才具备长期运营空间。
本项目首先要解决的，是如何让不同学习能力共享同一条产品数据链。
核心架构
按「学习链路」组织 App，而不是按功能堆叠
项目采用五层业务结构：身份层 → 任务层 → 结果层 → 激励层 → 治理层。App 负责学习体验，管理端负责内容和运营——这也是整个项目最重要的架构决策。
按功能堆叠
听写页单独一版
批改接成对话框
拼读模块另起炉灶
各自账号与数据
积分规则写死在代码
五层业务结构
身份层：家长 / 学生 / 多档案任务层：年级 / 学期 / 单元 / 任务结果层：错词 / 作文 / 批改 / 报告激励层：积分 / 闯关 / 学习反馈治理层：词表 / 规则 / 反馈 / 导出
核心链路
三条学习链路，在同一条数据结构上跑通
听写、作文与自然拼读看起来是完全不同的场景，但都被纳入统一任务体系——点阵笔笔迹、AI 批改结果与拼读报告，最终都进入可被后续模块继续使用的学习数据。
听写引擎
词
笔迹已收错词已存
批改流水线
草稿AI绘本分享
拼读 + 积分
8.5
+12
账号层
Student当前
userId: st_042链路共存
三条学习场景，共享同一套底层结构
听写、作文与拼读在任务类型、学习结果和后续动作上各不相同，但底层统一为学生身份 → 学习任务 → 学习结果 → 激励 → 管理。
听写场景→
单元任务
错词复练
作文场景作品沉淀
Pen SDK
+Unit API
作文链路
AI链接绘本
拼读场景
if (type==='phonics') +5积分入账
产品体验
App 负责学习，管理端负责持续运营
教育产品上线之后，持续变化的不只是 App 页面，还有内容、任务、规则和用户反馈。以下界面展示学习端如何聚合任务，以及结果如何沉淀供运营侧使用。
App ↔ 管理端
App学习 App
单元听写
智写作文
拼读报告
- 01单元听写
- 02智写作文
- 03拼读报告
- 04积分入账
业务服务
结果上报规则下发PCPC 管理后台
教材词表
任务配置
- 教材词表编辑
- 任务配置下发
- 积分规则配置
- 用户反馈回复
技术实现
支撑一体化学习链路的技术组合
客户端承载学习体验，核心业务层统一账户、任务、听写、作品与积分，外部能力接入点阵笔、AI 批改与录音评测——共同支撑三条链路在同一数据结构下运行。
Architecture
iOS / Android 学习 App + PC 管理后台 + 点阵笔 SDK + AI 作文批改 + 录音评测
客户端
iOS / Android App（首页 / 听写 / 作文 / 拼读 / 作品 / 积分） · PC 管理后台（内容 / 任务 / 反馈 / 规则 / 导出）
客户端
听写作文拼读
学习 App
内容
任务
规则
管理后台
核心业务
统一账户与学生档案 · 学习任务系统（年级 / 学期 / 单元） · 听写系统（词表 / 笔迹 / 错词） · 作品系统（批改 / 分享 / 绘本） · 积分系统（规则 / 流水 / 对账）
核心业务
1账户
2任务
3听写
4作品
5积分
外部能力
点阵笔 SDK（笔迹采集与任务关联） · AI 作文批改（结构化结果输出） · 录音评测（拼读分析与分组得分）
外部能力
API
点阵笔
AI
AI 批改录音评测
数据沉淀
错词 / 作品 / 批改 / 拼读报告 · 积分流水与运营导出
数据沉淀
错词128
作品56
报告34
积分892
导出
Keywords
K12 学习 App 开发教育类产品定制开发点阵笔集成开发AI 作文批改系统自然拼读评测学习积分系统开发PC 管理后台开发
项目结果
真正完成的，不只是功能上线，而是学习数据开始形成闭环
从多个功能模块，到一套可以持续运营的学习 App——以下交付项说明产品如何在真实环境中跑通，并具备上线后的运营空间。
账号统一
家长
学生 A
学生 B
听写作文拼读
听写闭环
1
单元2
笔迹3
错词4
复练错词复
AI 可沉淀
作文→AI→作品库→绘本
AI …
…
85
绘本
激励可运营
拼读作文闯关
积分流水+12
拼读+4
作文+3
闯关+2
规则 #3管理端
可复用模式
当教育产品同时涉及学习任务、AI 与智能硬件，底层数据结构比功能数量更重要
这套模式适用于需要学生档案 + 学习任务 + AI / 硬件能力 + 学习结果 + 激励机制的教育产品——先建立统一的数据链，再逐步增加新的学习能力。
K12 教辅 App
按教材单元组织练习、错题本、学习报告与家长端
K12 教辅 App
U1
U2
U3
U4
三年级 · 第四单元错词 12
周报身份任务结果激励
AI 作业 / AI 批改产品
结构化批改、作品分享、管理端检索与回复
AI 批改产品
作文…
88
分享检索
身份任务结果激励
智能笔学习产品
笔迹提交、页码校验、任务与错词联动
智能笔作业
P.12
点阵笔已同步
身份任务结果激励
语言学习 App
听写 / 拼读 / 录音评测 + 积分激励
语言学习 App
8.6
拼读
+8
身份任务结果激励
教培机构自有学习平台
学员档案、任务下发、作品展示与后台运营
教培学习平台后台
123
3 位5 项待办
5 项待办
5 项待办
身份任务结果激励
聊聊你的产品
不只是把功能做出来，而是先把一条学习链跑通
如果你正在规划 K12 学习 App、AI 作业产品、智能硬件学习系统或家庭教育产品，真正需要优先确定的通常不是「先开发哪个页面」——而是谁在学、学什么、怎么形成任务、结果保存在哪里、还能继续做什么、后台怎么持续运营。我们可以从你的核心学习场景出发，先拆出一期 MVP，再确定账号、任务、数据以及 AI / 硬件能力的边界。
- 谁在学 · 学什么账号模型、学生档案与教材结构
- 任务 · 结果 · 后续主链路怎么串、数据落在哪
- 运营 · 扩展后台配置、AI 与硬件接入节奏
