校园墙的日常是这样的：投稿排在私信里，报名靠群接龙，名单靠截图，统计靠 Excel，出了事只能删消息。这些都不是运营不努力，是手上没有一件趁手的工具。
微校 WeSmile 想把这件事补上——不是再做一个群，而是给校园社区一套真正能长期运营的系统。
十二个模块，四个端
新鲜事、匿名树洞、活动报名、闲置、评课、一周 CP、私信、学生认证、积分、社团、运营位、举报与审核。每一块都做到能交给真实学生用的程度，而不是把功能名字凑齐。
- 小程序 89 个页面，主包放高频页面，八个分包按业务域切开。
- 网页版把这 89 个页面收敛成 35 条路由，按能力组织而不是按页面。
- 运营台按「角色 × 作用域」发权限，校级管理员自己就能用起来。
- 服务端 148 个接口、16 个业务域纵向切分，改树洞只需要打开一个目录。
判据放在服务端
四个端要长期同源，只有一个办法：客户端不自己推导规则。它问一次「我现在能做什么」，拿回一份能力清单；「没认证所以不能发帖」这类判断一旦下放到客户端，就会在四个端上分叉成四个版本。
跨作用域的资源一律返回「不存在」，和真的不存在长得一模一样——否则光靠报错就能试探出别的学校有什么。
社区能活多久，取决于出事那天
功能决定它能不能开张，治理决定它能不能开一年。所以举报、审核、分级处罚每一步都留痕，删除是软删、可恢复，驳回理由必填并原样回给当事人。
后台那个输入框里写什么，就等于回给一个学生什么。这件事我想了很久，最后决定把它做成硬性要求。
校园墙的日常是这样的：投稿排在私信里，报名靠群接龙，名单靠截图，统计靠 Excel，出了事只能删消息。这些都不是运营不努力，是手上没有一件趁手的工具。
微校 WeSmile 想把这件事补上——不是再做一个群，而是给校园社区一套真正能长期运营的系统。
十二个模块，四个端
新鲜事、匿名树洞、活动报名、闲置、评课、一周 CP、私信、学生认证、积分、社团、运营位、举报与审核。每一块都做到能交给真实学生用的程度，而不是把功能名字凑齐。
判据放在服务端
四个端要长期同源，只有一个办法：客户端不自己推导规则。它问一次「我现在能做什么」，拿回一份能力清单；「没认证所以不能发帖」这类判断一旦下放到客户端，就会在四个端上分叉成四个版本。
跨作用域的资源一律返回「不存在」，和真的不存在长得一模一样——否则光靠报错就能试探出别的学校有什么。
社区能活多久，取决于出事那天
功能决定它能不能开张，治理决定它能不能开一年。所以举报、审核、分级处罚每一步都留痕，删除是软删、可恢复，驳回理由必填并原样回给当事人。
后台那个输入框里写什么，就等于回给一个学生什么。这件事我想了很久，最后决定把它做成硬性要求。