最近有两位客户前后脚来咨询，需求表面很像，架构差很远：一位是自己讲职场课的独立讲师，另一位想做本地教育机构聚合平台，让十几个机构都来开课卖课。这两个人如果用同一套系统，必有一方花冤枉钱。做知识付费小程序，角色体系得先想清楚。
单讲师模式，简单但别偷懒
一个人的知识店铺，后台只需要：管理员、助教、普通用户三种角色就够了。管理员管内容和财务，助教管答疑和批改作业。很多个人讲师把账号密码直接给助教共用，出了纠纷连操作记录都查不到。哪怕只有两三个人用，也要把权限分开，操作日志留痕，这是成本极低但关键时刻救命的设置。哪怕将来要引入外部讲师，这套权限框架也能直接复用，不用推倒重来。
机构入驻模式，复杂度翻几倍
- 机构端要有独立后台：上传课程、设置价格、看自己的订单和流水
- 平台要管审核：机构资质、课程内容、价格变动都要过一道
- 分账是核心难题：平台抽成多少、结算周期多长、退款怎么扣回
- 用户体系要打通：一个用户可以同时是多家机构的学员
分账这块多说一句。机构和平台之间的钱走什么路径，直接决定项目能不能过审：合规做法是接入有分账能力的支付方案，订单资金按规则自动清分，平台不经手挪用。有个做兴趣课程聚合的客户，一开始用手工对账，月底财务加班三天还老出错，后来改成自动分账，对账时间缩到半小时，机构信任度也上来了。
安全和数据隔离也别大意。不同机构的后台数据要严格隔离，A机构看不到B机构的学员和订单，这是入驻模式的信任底线。平台方手里则要有一块总览看板：全平台的成交、退款、投诉数据集中呈现，哪个机构数据异常一眼可见。数据这东西，分得清才合作得久。
模式可以演进，架构要留余地
常见路径是先做单讲师跑通业务，验证模式后再开放机构入驻。如果初期就选定制开发，可以按平台化架构设计，先只开一个管理员账号，后面扩展不动底层。反过来，先用模板做着，将来要平台化，基本等于重做。
两条建议：一是想清楚三五年后的业务形态再定架构，别只看当下；二是无论哪种模式，找比格网络这类做过单讲师店铺和多机构平台两种案例的团队聊聊，让架构师帮你把演进路线画出来，前期多想一步，后期少返工一半。模式没有高下，合适的就是最好的。
