小程序 · 全栈业务系统 · 2026
学生兼职平台
面向在校学生的本地兼职小程序：学生按「离学校近、课余时间、不押金」找工作，运营在后台录入和审核职位。
- 类型
- 自研项目（MVP 验证版）
- 我的角色
- 产品设计 + 全栈开发
- 年份
- 2026
- 技术
- uni-app · NestJS · Prisma · MySQL
要解决的问题
校园兼职信息散在微信群和公告栏里，真假难辨，学生最怕遇到押金骗局。直接做一个双边平台又太重——冷启动没有供给，九成同类项目死在这一步。
我做了什么
- 01
先砍需求，再动手
砍掉蓝领市场、自研聊天和广告位，只保留「浏览 → 收藏 → 打电话」这条最短路径。验证期不建 Redis、队列和限流，单城市规模用不上。
- 02
三端一次打通
uni-app 小程序（学生端）+ Vue3 运营后台 + NestJS 服务端。同一套 API，后台负责录入与审核，小程序负责浏览与联系。
- 03
数据模型按验证指标设计
6 张表：用户、职位、分类、收藏、联系记录、举报。联系记录是验证「浏览 → 联系」转化的核心数据源，看板直接围绕它设计。
- 04
工程化不掉链子
Prisma 迁移、30 项单元测试、ESLint 9、Docker 多阶段构建、GitHub Actions CI、Nginx 反向代理模板，上线前该有的都有。
关键决策
联系方式交换，而不是自研 IM
聊天是成本最高、审核最重的模块。先用「一键拨打 + 联系记录」验证需求，真有用户再考虑加聊天。
企业信息内嵌，不单独建表
验证版由运营录入职位，企业信息跟着职位走。少一张表、少一层关联，后台操作也更快。
金额用「分」存储
涉及薪资的计算一律用整数分，避免浮点误差。这是小决定，但能省掉后面很多对不上账的麻烦。
结果
完整业务闭环跑通：运营注册登录 → 录入职位 → 学生浏览/搜索 → 收藏/举报 → 联系方式交换，前后端与数据三层全通。微信登录代码已完成，填入 AppID 即可启用。
3
端（小程序/后台/服务端）
6
数据表
30
单元测试
11
看板指标
踩过的坑
- MVP 的难点是说「不做」：每砍一个功能，冷启动就快一点。
- 验证指标要在建表时就定下来，否则做完也不知道有没有用。
- 工程化不是上线后才补的，CI 和测试在第一天写最便宜。