高校科创竞赛（iCAN、互联网+、蓝桥杯、数学建模等）的参赛组织长期有三个低效环节：赛事信息分散在各处通知里，学生很难判断"现在还能不能报名"；组队基本靠熟人，缺少按技能维度找队友的手段，常常"先凑齐人再想做什么"；队伍管理靠微信群，成员、技能需求、指导老师关系散落在聊天记录里，状态没人对得齐。
这个作品把上述场景做成一个可运营的产品：以「赛事 → 技能 → 队伍 → 匹配」为主链，让学生用技能画像找到互补队友，让运营方在同一份数据上做内容与用户治理，而不是再造一个信息公告板。
同类需求并不局限于校园——凡是要把"有需求的个体"和"能补齐短板的团队"撮合到一起、且需要轻量组织管理的场景（社团招新、企业创新大赛报名、开源项目协作招募）都成立，产品结构可直接复用。
面向参赛学生与赛事运营者的微信小程序，共 12 个页面，与配套后台共用一份云数据库。主要模块：
1、赛事大厅：赛事列表与状态自动计算（未开始 / 报名中 / 已结束），按级别、类型、状态多维筛选与下拉刷新；Banner 与置顶位由后台维护。
2、技能画像：微信登录 + 学号/工号绑定；全平台统一的技能字典；完善简介后可一键生成技能熟练度评级（1~5 级），作为后续匹配依据。
3、队伍模块：建队与解散，同时支持团队赛与个人参赛；队长配置招募技能与人数，系统自动算出技能缺口；成员增删与退出，队长与成员权限分离；指导老师以 advisor 挂靠、不占成员名额；准入限制分"无需审核 / 需审核 / 仅邀请"三档。
4、申请与邀请中心：入队申请、队长邀请、系统通知、指导老师邀请四类消息；处理入队时联动成员表、技能缺口重算、进行中赛事、个人队伍列表与匹配池清理。
5、智能匹配池：用户与队伍分别入池，按「技能 + 赛事」双重交集互相推荐，组满或赛事结束后自动出池。
6、AI 能力：接入大模型一键生成赛事简介与含金量解读，输出为固定结构的两段式内容，直接写入并渲染到赛事详情。
演示：小程序为体验版，截图与体验二维码见仓库 README；源码 `gitee.com/baiguanliang/smart-team-build`
我的职责：独立完成需求梳理、数据库结构设计、云函数后端、小程序前端与配套后台的全部开发。
技术栈：微信小程序原生开发 + 微信云开发（CloudBase）；6 个数据库集合、8 个云函数、63 个 action。
后端架构：采用路由型云函数（`event = { action, params }` 统一分发，统一返回 `{ code, data, msg }`），业务错误码与服务器异常（-500）分开，客户端能区分"参数用错了"和"服务出问题了"。
实现亮点与难点：
1、写操作的权限矩阵：原实现只信任客户端传来的队伍/用户 id，存在伪造参数改删他人队伍的风险。改为服务端用 OPENID 反查真实身份，并按「队长 / 管理员 / 成员本人 / 指导老师」四类身份对每个写操作单独判定，修掉了三处真实越权（绕过审核自助入队、非队长移除他人指导老师、创建队伍时伪造成员名单虚增人数）。
2、AI 输出要做到可渲染、可追溯：对模型输出做 prompt 硬约束 + 服务端归一化，固定为"标签：内容"的两段式结构后再写入共享字段渲染；接口只接受赛事 id，名称等参数一律从库内读取，避免"传错参数把内容写进别的赛事且无法回溯来源"。
3、删除的引用检查：文档型数据库没有外键，删除一条技能会在四处留下悬空引用。实现为"扫描四处引用 → 有引用则拦截并回传明细"，不替管理员做级联删除这种破坏性操作。
4、性能：技能引用统计从"每个技能扫四处（约 100 次查询）"优化为"扫用户一次 + 扫队伍一次、内存按技能 id 归并"，2 次查询出全表统计。
5、包体积：主包从逼近微信 2MB 硬性红线降到 93KB（云开发 SDK 拆 719KB 分包、图表库按需注册省 516KB），直接决定了小程序能否正常发布。
评论