教学平台原型做到什么程度，学校才适合确认开发？

教务主任在原型页面上点完一遍，颜色和布局看起来都不错。开发开始后，教师才问：“学生补交以后，原来的分析会不会更新？”这个问题原型里没有呈现，双方也没有讨论，返工就从一个被忽略的异常场景开始。

核心结论

教学平台原型达到可确认状态，不是因为页面已经像成品，而是学校已看清谁在什么场景使用、任务怎样流转、数据代表什么、异常由谁处理以及完成后如何验收。主流程和关键边界未确认时，视觉再精细也不宜直接进入全面开发。

原型要验证业务，不是提前挑装修

原型的价值是把抽象需求变成可讨论的工作过程。学校说“需要学情分析”，原型应进一步呈现教师从哪里进入、选择什么范围、看到哪些证据、分析以后怎样安排讲评或复练。

如果会议大部分时间都在讨论按钮颜色和卡片大小，真正影响使用的角色、数据和异常就容易被忽略。视觉体验需要确认，但应建立在业务流程清楚之后。

学校评估产品能力或定制方案时，可以用同一条真实教学链路演示，判断标准能力、配置和开发分别承担哪一部分。

五项内容清楚后再确认开发

确认内容	学校应能回答的问题
使用角色	谁发起、谁复核、谁查看、谁无权操作
主流程	从任务开始到结果进入教学动作怎样流转
数据口径	页面数字来自哪里，范围和更新时间是什么
异常处理	漏交、补交、识别错误和权限变化如何处理
验收条件	用哪些角色、数据和结果证明功能可用

这五项不要求写成技术文档。项目组可以在原型旁用简短注释说明，也可以用场景表补充。关键是确认记录能够被开发、测试和学校验收人员共同理解。

原型中的参考数据要接近真实结构，但可以构造或脱敏。全是整齐的理想数据，只能证明正常页面能展示，无法发现日常教学里的边界问题。

先走一条完整链路，再扩页面数量

原型确认不必一次覆盖全平台。选一条高价值流程，例如“布置作业—学生完成—教师复核—班级讲评—错题复练—管理查看”，比先画几十个互不相连的页面更有效。

主流程跑通后，再增加其他题型、学科、角色和管理视图。每增加一部分，都要说明它接在原流程哪里，会不会改变已有数据和权限。

对于教育集团，还要分别验证总部、校区和教师看到的范围；对于复读学校，则要确认诊断、分层和复练怎样跟教学周期衔接。原型不是统一模板，而是把真实业务差异显出来。

流程推演，一次补交场景怎样被确认

以下为流程参考，不代表具体项目成果。

原型演示学生提交作业后，教师发现一名学生漏交。项目组继续追问：学生补交入口在哪里，教师是否收到提醒，原班级完成率何时更新，已经生成的复练任务是否需要重算。

双方在原型中补上状态变化，并写明教师有权确认补交，学生不能直接修改判定结果。验收脚本也加入正常提交、漏交和补交三种测试数据。

这个讨论没有增加复杂页面，却避免了开发结束后才发现流程断裂。学校确认的是行为与结果，而不是一句“支持补交”。

确认签字也要保留变更出口

原型确认后仍可能出现新情况。项目应约定哪些属于已确认范围内的澄清，哪些会影响周期、费用或数据结构，需要进入变更评估。

确认记录要带版本和日期。旧截图、口头意见与新版原型混在一起，开发和验收人员很难知道哪个结论有效。

学校可以结合教学质量闭环选择首条验证链路，通过解决方案了解不同学校场景；若已有原型或需求清单需要评估完整性，可在联系页面说明当前阶段和最关键的教学流程。

实践说明

本文适用于学校采购、配置或定制开发教学平台时的原型评审。文中的确认表和补交场景为流程参考，不替代双方正式需求文件、项目合同和验收约定。

作者信息

作者：华慕智学教研团队
更新时间：2026年08月11日
适用对象：学校项目负责人、教务负责人、教师代表、信息化负责人和教育软件实施团队