💡 项目选题库¶
选一个你愿意做、也做得出来的项目¶
好选题不是功能最多，而是问题清楚
课程项目不需要一开始就追求“大平台”“高并发”或复杂 AI。一个适合你的题目，应该有明确用户、真实问题和一条可以完整演示的业务流程。
例如：学生发布失物信息 → 其他学生提交认领 → 发布者或管理员审核 → 完成归还。这就是一条可以开发、测试和展示的业务闭环。
本页怎么用
先从推荐题目中选择 2～3 个感兴趣的方向，再比较用户是否容易接触、业务是否能讲清、数据是否容易准备，最后确定一个项目。
🎯 选题时先看这 4 点¶
| 有用户 | 有问题 | 有闭环 | 能完成 |
|---|---|---|---|
| 能说清楚系统给谁使用 | 能说明当前做法哪里不方便 | 至少有一条从开始到结束的流程 | 核心版本能在课程周期内开发和测试 |
用一句话描述你的项目：
例如：
面向高校学生和校园失物管理人员，解决失物信息分散、认领过程难以确认的问题，通过信息发布、认领申请、身份核验和归还确认，形成校园失物招领系统。
不要用技术名词代替项目价值
“使用 Spring Boot、Vue、RAG 和大模型”不是选题理由。技术是实现手段，选题首先要回答：谁遇到了什么问题，系统准备怎样帮助他。
🧗 难度怎么选¶
| 难度 | 适合情况 | 建议目标 |
|---|---|---|
| L1 基础 | 第一次独立完成 Web 项目，基础较弱 | 登录、基础管理、一条核心业务闭环 |
| L2 标准 | 已做过简单增删改查，希望完成多角色业务 | 多角色权限、状态流转、统计或审核功能 |
| L3 进阶 | 核心 Web 功能已经熟练 | 在完整业务系统上增加推荐、知识问答等 AI 能力 |
多数同学建议从 L1 或 L2 开始
先完成一个小而完整的系统，再增加特色功能。选题难度不会直接决定成绩，系统是否真实运行、业务是否闭环、本人是否能够解释和验证更重要。
🏫 校园服务类¶
1. 校园失物招领系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 学生、失物发布者、管理员 |
| 解决问题 | 失物信息分散，认领身份难确认，归还结果无法跟踪 |
| 核心闭环 | 发布失物 → 提交认领 → 审核身份 → 确认归还 |
| 必做功能 | 注册登录、失物发布、分类搜索、认领申请、审核、状态更新 |
| 可选功能 | 图片识别、相似失物推荐、消息提醒 |
2. 宿舍报修管理系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 学生、维修人员、宿舍管理员 |
| 解决问题 | 报修依赖口头或群消息，处理进度不透明 |
| 核心闭环 | 学生报修 → 管理员派单 → 维修处理 → 学生确认评价 |
| 必做功能 | 报修提交、图片上传、派单、进度更新、维修记录、评价 |
| 可选功能 | 超时提醒、维修统计、常见故障知识库 |
3. 实验室预约系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 学生、教师、实验室管理员 |
| 解决问题 | 可预约时段不清楚，人工登记容易冲突 |
| 核心闭环 | 管理员发布时段 → 用户预约 → 审核 → 签到或取消 |
| 必做功能 | 实验室管理、时段发布、预约、冲突校验、审核、预约记录 |
| 可选功能 | 二维码签到、违约限制、使用率统计 |
4. 校园活动管理平台 L2¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 学生、活动负责人、学校管理员 |
| 解决问题 | 活动通知分散，报名、签到和反馈缺少统一管理 |
| 核心闭环 | 发布活动 → 学生报名 → 审核 → 现场签到 → 活动评价 |
| 必做功能 | 活动发布、报名、人数限制、审核、签到、评价、统计 |
| 可选功能 | 活动推荐、电子证书、消息提醒 |
5. 学生竞赛管理系统 L2¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 学生、指导教师、竞赛负责人 |
| 解决问题 | 赛事通知、组队、材料和审核记录分散 |
| 核心闭环 | 发布赛事 → 学生组队报名 → 提交材料 → 教师审核 → 查看结果 |
| 必做功能 | 赛事管理、团队管理、报名材料、审核意见、状态跟踪 |
| 可选功能 | 材料完整性检查、竞赛推荐、成果统计 |
🌱 生活服务类¶
6. 健康打卡与习惯管理系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 希望规律运动、作息或学习打卡的个人用户 |
| 解决问题 | 打卡目标分散，难以持续记录和了解自己的完成情况 |
| 核心闭环 | 创建目标 → 每日打卡 → 查看完成记录 → 获得进度反馈 |
| 必做功能 | 用户登录、目标创建、每日打卡、记录查询、完成统计、提醒设置 |
| 可选功能 | 连续打卡排行、健康建议、数据图表分析 |
单角色项目也可以有业务闭环
健康打卡不需要强行加入管理员。重点是“设定目标—记录行为—查看进度—调整计划”的完整过程，而不是角色数量。
7. 志愿服务管理系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 志愿者、活动负责人、管理员 |
| 解决问题 | 志愿活动报名、签到和服务时长统计不方便 |
| 核心闭环 | 发布活动 → 志愿者报名 → 审核 → 签到 → 记录服务时长 |
| 必做功能 | 活动发布、报名审核、签到、时长记录、个人服务记录 |
| 可选功能 | 证书生成、活动推荐、服务排行榜 |
8. 个人记账与预算管理系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 有日常收支管理需求的个人用户 |
| 解决问题 | 收支记录零散，难以了解钱花在了哪里 |
| 核心闭环 | 记录收支 → 分类查看 → 设置预算 → 查看超支提醒 |
| 必做功能 | 收支记录、分类管理、月度统计、预算设置、数据筛选 |
| 可选功能 | 票据识别、消费建议、图表分析 |
单角色项目也可以有业务闭环
个人记账不需要强行加入管理员。重点是“记录—统计—预算—反馈”的完整过程，而不是角色数量。
9. 宠物救助与领养系统 L2¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 救助者、领养申请人、平台管理员 |
| 解决问题 | 救助信息传播困难，领养审核和后续回访缺少记录 |
| 核心闭环 | 发布救助信息 → 提交领养申请 → 审核 → 完成领养 → 回访记录 |
| 必做功能 | 宠物档案、救助发布、领养申请、审核、状态跟踪、回访 |
| 可选功能 | 宠物匹配推荐、健康提醒、地图展示 |
🏢 行业应用类¶
10. 门店预约管理系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 顾客、服务人员、门店管理员 |
| 解决问题 | 电话预约效率低，时间冲突和爽约难管理 |
| 核心闭环 | 发布服务时段 → 顾客预约 → 门店确认 → 到店完成或取消 |
| 必做功能 | 服务项目、时段管理、预约、冲突检查、状态更新、记录查询 |
| 可选功能 | 到期提醒、爽约记录、服务统计 |
11. 社区服务工单系统 L2¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 居民、社区工作人员、处理人员 |
| 解决问题 | 居民问题反馈渠道分散，处理过程难跟踪 |
| 核心闭环 | 居民提交工单 → 社区受理派单 → 工作人员处理 → 居民评价 |
| 必做功能 | 工单提交、分类、派单、进度、处理记录、评价、统计 |
| 可选功能 | 紧急程度识别、相似工单推荐、超时提醒 |
12. 小型商品与库存管理系统 L1¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 店员、仓库管理员、经营者 |
| 解决问题 | 商品库存依赖手工表格，出入库记录容易出错 |
| 核心闭环 | 商品建档 → 入库 → 出库 → 库存更新 → 盘点查询 |
| 必做功能 | 商品管理、分类、入库、出库、库存查询、操作记录 |
| 可选功能 | 库存预警、销售统计、条码识别 |
13. 旅游路线与景点管理系统 L2¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 游客、景点或内容管理员 |
| 解决问题 | 景点信息分散，用户难以根据时间和兴趣安排路线 |
| 核心闭环 | 浏览景点 → 收藏或选择景点 → 生成路线 → 查看行程 |
| 必做功能 | 景点管理、分类搜索、收藏、路线创建、行程查看 |
| 可选功能 | 路线推荐、地图展示、景点智能问答 |
🤖 AI 应用类¶
AI 项目仍然需要完整的普通 Web 业务。不要只做一个输入框调用大模型接口。
14. AI 学习助手 L2¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 某门课程的学习者、教师 |
| 解决问题 | 学习资料分散，学生难以找到针对性的解释和练习 |
| 核心闭环 | 教师维护资料 → 学生提问 → AI 基于资料回答 → 学生反馈结果 |
| 必做功能 | 用户登录、资料管理、问答记录、反馈、基础权限 |
| 可选功能 | RAG 检索、错题分析、个性化练习 |
15. AI 简历优化系统 L2¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 求职学生、就业指导教师 |
| 解决问题 | 学生不知道如何针对岗位描述简历项目经历 |
| 核心闭环 | 填写岗位与简历 → AI 分析 → 生成修改建议 → 用户确认并保存版本 |
| 必做功能 | 简历信息、岗位信息、分析任务、修改建议、版本记录 |
| 可选功能 | 岗位匹配度、模拟面试、敏感信息提醒 |
16. 课程知识库问答系统 L3¶
| 项目 | 内容 |
|---|---|
| 目标用户 | 学生、教师、知识库管理员 |
| 解决问题 | 课程资料较多，学生查找知识点和依据耗时 |
| 核心闭环 | 管理员上传资料 → 系统处理文档 → 学生提问 → 返回答案和来源 → 用户反馈 |
| 必做功能 | 文档管理、知识库、问答记录、答案来源、反馈管理 |
| 可选功能 | RAG、文档分段策略、效果评测、问题推荐 |
AI 功能必须准备降级方案
如果模型服务暂时不可用，普通的资料管理、搜索、记录和反馈仍应能够运行。不要让整个项目只依赖一次外部 API 调用。
🔍 怎样从题目中确定自己的版本¶
同一个题目，不同学生可以做出不同范围。先将功能分为四类：
| 优先级 | 含义 | 示例 |
|---|---|---|
| 必做 | 没有它就无法形成核心闭环 | 宿舍报修中的提交、派单、处理和确认 |
| 应做 | 能让系统更完整 | 查询筛选、状态记录、简单统计 |
| 选做 | 核心版本完成后再增加 | 智能推荐、消息提醒、数据可视化 |
| 本期不做 | 主动排除，避免项目失控 | 在线支付、复杂即时通信、跨校数据共享 |
范围控制的简单规则
基础项目建议控制在 2～3 类用户、4～6 个核心模块、1～2 条主要业务流程。如果一句话无法讲清主流程，通常说明范围还需要缩小。
🤝 使用 AI 辅助选题¶
教师可以在 Trae 中提供“项目选题”Skill 或 Agent，引导你比较题目、控制范围并生成立项书初稿。
可以这样向 AI 提问：
AI 的建议不是调研证据
AI 可以帮你发现问题、比较范围和整理文字，但不能代替真实用户。至少与一名潜在用户交流，或体验 1～2 个同类产品，再确认项目问题是否真实存在。
✅ 选题自查表¶
确定选题前逐项检查：
- 我能用一句话说明系统为谁解决什么问题；
- 我能画出一条从开始到结束的核心业务流程；
- 目标用户是具体人群，不是“所有人”；
- 项目不是只有若干互不关联的增删改查页面；
- 数据、账号和必要的外部服务能够获得；
- 必做功能能在课程周期内完成；
- 已明确哪些功能本期不做；
- 即使去掉 AI 增强功能，基础业务系统仍然可以运行；
- 我愿意持续开发并在答辩中讲清这个项目。
如果有 2 项以上无法确定，先缩小范围或更换题目，再填写项目选题立项书。
🚦 选定题目后的下一步¶
- 从本页选题或提出自己的题目；
- 使用 AI Skill/Agent 比较范围和可行性；
- 完成简单的用户交流或同类产品体验；
- 确定最小业务闭环和本期不做的内容；
- 进入第二篇，完成《项目选题立项书》和《需求分析说明书》。
不选看起来最复杂的题目，选择你真正理解、能够完成、愿意展示的题目。