[T.18] 团队项目：Beta 阶段项目展示

这个作业属于哪个课程	北航2026年春季软件工程
这个作业的要求在哪里	团队项目：Beta 阶段项目展示
我在这个课程的目标是	完成软件开发，感受软件工程流程
这个作业在哪个具体方面帮助我实现目标	完成 Beta 阶段开发展示

一、团队与项目管理

团队：航航日程（微信小程序）
成员：果洪瑞(PM)、刘誉洲(FE-A)、王彦均(FE-B)、任天宇(BE-A)、牛浩宇(BE-B)、温昊谭(AI)

代号	角色	主负责模块	团队贡献分配
PM	果洪瑞	项目管理、集成测试、文档、进度控制	51
FE-A	刘誉洲	用户中心、日程编辑、AI 对话页	47
FE-B	王彦均	日程视图（日/周/月）、地图页	52
BE-A	任天宇	日程核心（课表解析、规则引擎）、部署	54
BE-B	牛浩宇	用户中心、地图、常用地点	49
AI	温昊谭	AI问答、Prompt 工程	47

• 项目管理：使用github进行项目管理，通过 issus 进行分工与进度控制，提交 PR 使问题方便追溯
• 日常沟通：使用微信方便沟通，定期进行例会保证进度同时汇总问题
• 开发分支：main 作为稳定运行版本，dev 作为测试分支，下分 frontend 与 backend 分支用于开发，具体到每个功能与修复再细化
  

二、项目愿景

做一款面向北航在校学生的一站式课表 + 日程 + AI 学习规划小程序：把"看课表"和"做日程规划"合二为一，一键导入北航教务课表，再用 AI 智能助手把复习/会议/DDL 等安排自动生成并回填到日程表，配合校园地图与场馆信息，让学生"早上起床打开一个小程序，今天怎么过一目了然"。

Beta 阶段的愿景延续 Alpha：在已跑通的核心链路上，补全功能、打磨体验。

三、典型用户和场景

3.1 典型用户画像

核心用户：北航在校本科生 / 研究生。 他们的共同特征是：日程密集且多变——除了固定课表，还要应对实验、组会、社团活动、各科 DDL 与社交安排；习惯用手机和微信处理日常事务，希望"打开即用、注册登录时间成本低"；对学校的教务系统、校园地点高度依赖，但现有工具又分散在多个 App 里。

更细分来看，可归纳为三类：

• "规划型"学生：期中/期末前需要系统安排复习节奏，关心"哪天复习哪门、还剩多少时间"
  使用：填入考试安排后使用智慧助手制订相应计划，一键填入日程安排，每天只需要打开看一眼就能快速确认学习计划
• "事务型"学生：日程被会议、组会、活动塞满，关心"今天到底有几件事、会不会撞车"
  使用：每天早晨点开小程序直观看到今天的课程、会议等安排，并根据常用地点规划行程
• "新生 / 换学期"用户：每学期初都要重新录入整学期课表，关心"能不能一键导入、不用手动敲"
  使用：一键导入学期课表，同时根据课表确认教室，加入常用地点

3.2 用户痛点

• 智慧北航只能看到固定课表，无法把课表和个人日程（会议、DDL、社交）放在一起统一规划，"课表归课表、安排归安排"；
• 通用日程 / 日历工具（系统日历、第三方课表 App）导入北航课表困难，往往要手动逐条录入，操作繁琐、易出错；
• 复习规划只能靠自己在脑子里或纸上排，缺少"根据目标自动生成、又能落进日程表"的工具；
• 想查校内地点（食堂、教学楼、场馆）和做日程是割裂的，查完还要再切到地图 App 导航。

学生缺的是一个把"课表 + 日程 + 规划 + 校园信息"打通的一站式入口。

3.3 典型使用场景

场景一：每天早晨的"今日一览"
小航起床后打开小程序，今日视图把课程、组会、社团、DDL 按时间轴铺开，一眼看清今天怎么过，不必在多个 App 之间来回切换。

场景二：考试周的"一键复习规划"
期末前，小航告诉 AI 学习助手"两周内复习完三门课"，并标注已被课程占用的时段；助手据此生成分日复习计划，小李确认后一键回填到日程表，复习安排立刻变成可执行的日程。

场景三：新学期的"一键导入课表"
开学第一周，小航输入学号等信息，小程序直接对接北航教务系统导入整学期课表，自动解析"第 X-Y 节"与上课周次，省去逐条手敲。

场景四：校园里的"查地点顺手导航"
小李想去某场馆或教学楼，在地图页查看校内地点后可顺手发起导航寻路，查询与出行无缝衔接。

3.4 杀手级功能

用户需求	对应功能
不想手动录课表	输入学号密码一键导入北航教务课表，自动解析节次/周次、处理冲突
课表与日程统一看	今日 / 日视图整合课程、会议、DDL、社交安排
复习要有计划且能落地	AI 学习助手按目标生成计划并回填日程
查地点顺便导航	集成校园地图与导航寻路
随时随地、低使用门槛	微信小程序形态，打开即用

整体形成 一键导入课表 → 统一日程视图 → AI 规划并回填 → 地图查看导航 的闭环，精准命中"既要看课表、又要做规划"的一站式需求。

四、项目发布

• 发布努力：在各大群聊打广告推广
• Beta 阶段发布后，已经积累了 20+ 活跃用户，使用功能集中在课表导入上

五、相对于 Alpha 阶段，在软件的质量上有什么提高？

Alpha 阶段的主要遗留问题：前端未适配手机端、智能日程只有基础功能、智能地图数据不全。

5.1. 界面优化：

• UI 适配手机端，避免了屏幕遮挡问题
• 前端 UI 美化与交互打磨：增加日视图、月视图与地图等页面优化
• 主页面优化布局，同时各个小界面重新排版

5.2. 功能完善：

• 智能日程从"基础功能"到"完整可用"：新增反馈功能，可提出建议多次修改日程计划
• 补全智能地图相关数据数据
• 增加常用地点功能，方便一键导航
• 设置AI调用次数上限，避免恶意调用
• 增加修改密码等基础功能

5.3. 重大bug修复：

• 部分功能无法访问服务器
• 智慧地图导航失败
• 登录状态过期卡死

六、相对于 Alpha 阶段，在软件工程的质量上有什么提高？具体进行了哪些改进？

6.1. 从"手工冒烟测试"到"自动化测试套件"

维度	Alpha	Beta
测试方式	冒烟测试 + 边界手测	自动化单元/接口测试/整体测试
用例数	少量手测	26 个测试文件 / 165 个用例
结果	——	163 passed
代码覆盖率	未量化	94%

6.2. 规范开发

• 沿用 Alpha 的分支规范（main 稳定 / dev 测试 / frontend·backend 再细分），合并前代码审核。
• 完成相关功能时保存接口格式，方便对接
• 每次完成小功能开发进行模块测试，保证稳定性

七、在 Beta 阶段学到了什么

1. 测试要趁早、要自动化
   Alpha 把测试堆到最后导致主要功能的完成质量出现明显赶工痕迹；Beta 引入自动化测试后，缺陷在合并前就能被拦截，质量更可控。
2. 规范化接口设计
   Alpha 阶段与 Beta 阶段开始都没有规范化的接口文档，导致实际汇总时花费过多精力
3. 质量靠数据说话
   "覆盖率 94%、165 用例、定位并修复 n 个 Bug"比"我们测过了"更有说服力，同时许多问题是简单的使用无法发现的，一定要有规范化的测试，尤其在实际开发环境中更需要谨慎
4. 开发环境安全
   api与服务器安全这类问题必须用环境变量管理并及时轮换，不能图省事放到代码中
5. 发布是系统工程
   小程序发布需要较长审核周期，同时域名/服务器备案、小程序审核、真机调试都需提前排期，临期容易踩坑被拖慢进度
6. 沟通与对接很重要
   很多问题如果及时沟通都不会发生，尤其是开发前期对功能和接口等开发一定要确定好，否则中途修改伤筋动骨
7. 开发前的文档应该足够完善和规范细致
   开发前很多功能只停留于脑海中，没有实际的标准，必然会导致实际开发难以满足最开始的标准，不能忽视文档的重要性，开发前应该仔细思考自己的想法是否通过文档规范固定了下来，不会出现开发一半需求不明确或功能实现不明朗等情况