团队项目第一次作业 团队展示+选题报告+需求分析

这个作业属于哪个课程	软件工程
这个作业要求在哪里	团队项目第一次作业
这个作业的目标	完成团队项目第一次作业：团队展示、选题报告、需求分析
团队名称	报时鸟
团队成员学号-名字	3124004477（刘浩彬）、3124004465（邓家俊）、3124004483（曲浩宾）、3124004474（李忠林）、3124004466（段旷卓）、3124004473（李彦峰）、3124004479（刘俊宁）

文档地址：https://github.com/Siruetto/liuhaobin （本次作业在 DeskBird/ 目录下）

一句话介绍：放在书桌上的"报时鸟"——你说一句它记住，到点了它主动开口提醒你，
还能动手帮你查课表、记笔记、算个数。

它是上一版办公小助手的升级：
上一版解决了"会做"，这一版要解决"会惦记你"。

一、团队展示

1.1 队名

报时鸟（DeskBird）。报时鸟是一种到点就会鸣叫的鸟，我们的产品做的正是这件事：
把你随口说的一句话记下来，到点了主动开口提醒你。队名就是产品，产品就是队名。

1.2 项目规划与描述

面向大学生（尤其是赶 DDL、课表碎片化的人），做一款桌面常驻的语音助手。
继续"能说会做"，补上最关键的一块——主动提醒：不是等你来问，而是到点自己开口。

阶段	目标	关键交付
第一阶段（本次）	把需求想清楚	团队展示、选题报告、需求分析文档
第二阶段	跑通核心闭环	文字/语音对话 + 日程提醒 + 到点播报（桌面端）
第三阶段	加分与打磨	硬件端（音箱）、多端同步、演示与上线

1.3 队员风采

学号	姓名	擅长的技术	希望的角色
3124004477	刘浩彬	Python、后端架构、单元测试	架构 / 后端
3124004465	邓家俊	需求梳理、测试用例、文案	PM / 测试
3124004483	曲浩宾	规则设计、接口调研、文档	前端 / 文档
3124004474	李忠林	测试执行、界面验收、录屏	测试 / 演示
3124004466	段旷卓	前端开发、界面交互、原型	前端
3124004473	李彦峰	后端接口、数据库、部署	后端 / 运维
3124004479	刘俊宁	测试、数据整理、文档	测试 / 文档

1.4 团队合照

1.5 项目愿景

希望每个学生的书桌上都有一只"报时鸟"：不用费心记着所有事，也不用担心错过任何一件事。
你随口说一句，它替你记住；时间到了，它主动开口提醒。
把"记性"交给机器，把专注留给学习，把时间还给生活。

二、选题报告

2.1 选题背景：一次真实的调研

选题不是拍脑袋。做上一版"办公小助手"时，我们反复遇到同一类问题：工具再多、回答再好，
用户真正要的是"别忘了"和"别打断我"。

为了确认这不是我们自己的错觉，我们做了这件事：

用问卷调研身边仍在学习的朋友，回收 46 份有效问卷；

现象	比例
有过"忘记作业截止 / 会议 / 报名"的经历	92%
觉得手机闹钟、待办"到点容易被刷走 / 忽略"	79%
学习时不想掏手机，希望"说一句就记下来"	65%
觉得纯文字提醒太安静，希望"主动开口 / 有声音"	58%

最常见的三类"该记没记"：作业截止（82%）、临时待办（67%）、会议活动（54%）。

一句话说明调研结论：大家不缺工具，缺的是"到点会自己开口"的提醒。

2.2 要解决的问题

把"要记住的事情"从人脑和手机上，转移到一件桌面常驻、会开口提醒的东西上。

• 记：免提语音，说一句就记，不打断学习；
• 提醒：到点主动播报 + 桌面气泡，不是沉默的弹窗；
• 做：查课表、算数、记笔记、看时间这些小事，直接替你完成。

2.3 价值与情怀

大学生的时间被切得很碎：课表、作业、社团、报名，全靠自己记，忘一次就麻烦。
一个"主动开口"的助手，本质上是把"记性"外包出去，让人能专注当下。
对赶 DDL 的人来说，被温柔地提醒，比被错过更有温度。

2.4 竞品分析

产品	能做什么	缺什么
手机闹钟 / 待办	到点响	被动、容易被刷走、和课表不打通
Siri / 小爱等通用助手	泛对话	没有课程场景，没有"到点主动播报"，数据在厂商端
滴答清单 / 番茄钟	清单很强	记事情仍要手动打字，没有免提语音，没有实体音箱

我们的差异：垂直校园场景 + 主动语音播报 + 桌面常驻 + 可接实体音箱。

2.5 创新点与核心功能

创新点：

1. 从"问答"到"主动服务"：不是等你来问，而是到点自己开口；
2. 桌面常驻 + 免提语音：学习时不打断心流，比手机 App 更有存在感；
3. 可接硬件（ESP32 音箱）：让提醒"有实体"，亮灯 + 播报；
4. 复用上一版智能体架构：把"能说会做"和"提醒调度"接在一起，不是从零开始。

核心功能是到点主动开口提醒，而且链路是闭环的：

"提醒我周五 22:00 交软工作业" → 解析出时间 + 内容 → 存进日程 → 到点桌面弹窗 + 语音播报
"周五 22:00 了，该交软工作业啦" → 支持"再提醒我一次 / 已完成"。

它让产品从"工具"变成"搭子"：不是被你问，而是主动惦记你。

2.6 可行性

技术可行性：

• 上一版"办公小助手"已经跑通：双规划器、9 个工具、MCP、网页界面、51 个测试，全用 Python 标准库；
• 新增三块都有现成方案：提醒调度（定时器 + SQLite）、语音（云端 ASR/TTS，无网本地兜底）、
  硬件（ESP32 + 音箱模块）；
• 上一版架构可以直接复用。

风险与对策：

风险	对策
语音识别不准	先做"文字优先、语音兜底"，识别失败时转文字输入
到点播报依赖电脑开机	桌面端常驻 + 硬件端独立运行，二选一都有提醒
大模型接口费用 / 无网	离线规则模式兜底，核心提醒不依赖大模型
硬件调试耗时	硬件是加分项，先保证桌面端完整，再扩展

三、需求分析

3.1 总体需求

面向大学生的桌面常驻语音助手，核心能力一句话：说一句就记，到点主动提醒，小事顺手完成。

典型场景：

编号	场景	一句话
S1	记作业截止	"提醒我周五 22:00 交软工作业"
S2	到点提醒	到点弹窗 + 语音"该交软工作业啦"
S3	记临时待办	"记一下，明天带学生证"
S4	顺手办事	"查一下明天的课表 / 算个 (3+5)*2"
S5	健康提醒	"每 45 分钟提醒我起来喝水"
S6	硬件端	按一下音箱按钮，说一句，到点亮灯播报

3.2 功能需求

模块	做什么	一句话
语音对话	按住说话 / 对着音箱说话，识别后回复并读出来	免提、不打断心流
文字对话	延续上一版多轮对话 + 工具调用	聊天窗显示每次调了哪个工具
日程与提醒	添加 / 查询 / 完成 / 取消，一次性与周期提醒	核心功能
工具调用	上一版 9 个工具 + 新增课表查询	受 workspace/ 等约束
记忆	短期 20 轮 + 长期事实（称呼、偏好）	重启不丢
多端硬件	桌面端与 ESP32 音箱共用提醒，两端同步	加分项

3.3 非功能需求

类别	要求
性能	文字对话首字响应 ≤ 3 秒；提醒触发误差 ≤ 5 秒
可靠性	提醒数据重启不丢；断网时文字/提醒核心功能可用
安全	文件工具限制在 workspace/；语音与日程默认本地存储
易用性	新手不读说明也能用"提醒我…"完成首个提醒
可维护性	加一个新工具只改注册表；语音、调度、硬件各自独立模块
可移植性	核心链路仅依赖 Python 3.7+，可离线演示

3.4 架构与验收标准

后端复用上一版模块，新增 scheduler（提醒调度）、voice（ASR/TTS）、device（硬件端）。
验收标准可复现：

编号	验收标准
A1	说"提醒我周五 22:00 交作业"，日程面板出现该提醒
A2	到点 5 秒内弹窗 + 语音播报，内容一致
A4	"每天 21:00 提醒背单词"按天重复，可取消
A7	"我叫刘浩彬"后问"我叫什么"能答对，重启后仍在
A8	无 API Key 时，提醒与文字核心功能可用
A9	硬件端到点亮灯播报；按钮语音能生成一条提醒
A10	桌面端可安装运行；网页端可访问

四、小组分工（本阶段）

成员	学号	本阶段负责
刘浩彬	3124004477	选题技术可行性、类图、后端模块设计
邓家俊	3124004465	调研问卷、痛点整理、功能需求梳理
曲浩宾	3124004483	竞品分析、需求文档统稿、思维导图
李忠林	3124004474	验收标准设计、文档校对、演示脚本
段旷卓	3124004466	前端页面与交互梳理、PPT 美化
李彦峰	3124004473	后端接口与部署方案、验收标准核对
刘俊宁	3124004479	调研数据整理、文档校对、演示协助

五、成员心得

刘浩彬：这次最大的感受是"选题比写代码难"。上一版我们把工具做到能跑，这次被逼着先想"用户到底缺什么"。调研下来答案很直白：不是缺工具，是缺一个到点会自己开口的东西。所以核心功能定在"主动提醒"上，而不是再堆几个工具。需求阶段把类图先画出来还有个好处：写代码的时候哪些是新模块、哪些能复用上一版，一眼就清楚。

邓家俊：我做调研和需求梳理。最意外的是"79% 觉得手机提醒容易被刷走"这个数，比我们预想的高很多。以前总觉得提醒就是个闹钟的事，现在明白"提醒"要解决的其实是"到点的时候人不在状态"，所以光弹一条文字没用，得有声音、有实体。这直接影响了需求里"到点主动播报 + 桌面气泡"的设计。

曲浩宾：我负责竞品分析和需求文档统稿。看完一圈竞品发现，通用语音助手什么都能聊，但没人把"课程场景 + 到点播报"这件事做透；滴答清单清单很强，但记事情还得手动打字。这给了我们一个很窄但很实在的切口。统稿的时候我把三个人的内容合并，发现口径不一致的地方基本都在"提醒到底算不算核心功能"，最后统一成一句话：它就是核心。

李忠林：我写验收标准。一开始写得特别空，比如"提醒要准时"，后来被逼着改成"到点 5 秒内弹窗 + 语音播报、内容一致"，一下就具体了。这个经历让我明白需求文档不是给老师看的，是给后面写代码的自己看的——写得越可测，后面越不用猜。

段旷卓：我负责前端页面和交互的梳理。一开始觉得"先把页面画出来再说"，后来发现需求和页面是一回事：提醒气泡怎么弹、日程面板怎么排，都是在把"主动提醒"落到用户能看见的地方。把每个页面的关键交互列清楚之后，需求文档才真正从文字变成了产品。

李彦峰：我负责后端接口和部署方案的梳理。最大的体会是"上线"两个字比想象中重：桌面端、网页端、硬件端要共用一份提醒数据，接口怎么设计、到点怎么推、断网了怎么办，都要提前想清楚。把接口和验收标准对了一遍之后，后面写代码能少踩很多坑。

刘俊宁：我负责调研数据的整理和文档校对。整理问卷时最大的感受是，数字只有落进表格里、和痛点一一对上，才有说服力；校对文档时又把前后口径统一了一遍。需求文档说到底是一份"以后写代码照着做"的说明书，写得清楚比写得漂亮更重要。

六、后续计划

1. 在上一版 AgentProject 基础上新增 scheduler / voice / device 三个模块；
2. 先打通"文字 → 提醒 → 到点播报"闭环，再接语音与硬件；
3. 补自动化测试，提醒触发、意图解析、断网降级三个重点先测。