[T.13] 团队项目：Alpha 阶段项目展示

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	[T.13] Alpha 阶段项目展示
我在这个课程的目标是	掌握软件工程的核心理论，协作完成软件项目开发
这个作业在哪个具体方面帮助我实现目标	对团队在Alpha阶段的产品成果进行介绍

一、团队成员与分工

成员	分工	个人主页
章宇馨	PM / UI设计 / 测试	https://www.cnblogs.com/Alicexin
刘小莉	UI/UD设计 / 测试	https://www.cnblogs.com/mmxli
程嘉烨	UI实现 / 测试	https://www.cnblogs.com/gugugaga
王宇博	基础设施 / DevOps	https://www.cnblogs.com/sigma2331
吴峥	后端 / 算法 / 测试	https://www.cnblogs.com/yushiwuzheng
曾立宏	后端 / 安全 / 辅助测试	https://www.cnblogs.com/xiany9n

项目管理

代码管理

我们通过Github进行代码管理

• 功能开发在开发人员各自分支完成，通过PR并经审核后才能合并
• 通过GitHub Actions实现从代码提交到生产部署的全自动化流程，涵盖代码规范检查、单元测试拦截、Docker镜像构建与安全扫描

任务与进度管理

我们采用共享文档作为任务管理的工具。在Alpha迭代开始前，PM将得到的全部子任务按角色拆分，填入共享文档中。

• 每个子任务明确指定唯一负责人，截止时间精确到天当日23:59前必须完成

• 通过查看共享文档的填写情况可以得知开发人员在开发过程中遇到的困难和完成任务的情况

• PM每日上午检查进度，识别延期的任务，并在会议中讨论

团队沟通方式

团队以微信作为主要沟通工具，PM在通知群中统一发布任务和重要信息。

每两天举行一次线下团体会议，用于同步项目进度、讨论技术方案和解决阻塞问题。

在Bug修复阶段，PM会视情况组织针对特定成员的小范围会议，对修复任务进行一对一的沟通与跟进。

整体上，由PM统一负责沟通统筹与信息流转，确保信息传递及时、准确，任务执行闭环可控。

团队贡献分分配

我们按照[T.8] 团队项目：团队贡献分分配规则，将个人得分分为基础分40分+奖励分-惩罚分。

成员	分工	贡献分	具体贡献
章宇馨	PM / UI设计 / 测试	55	统筹项目整体进度，对每日运势、广场、情绪日记本UI进行优化，完成了14篇博客，开展了9次会议，发现软件中的若干bug并组织解决，负责推广宣传
刘小莉	UI/UD设计 / 测试	60	完成前端项目架构搭建与PWA配置，确定API接口契约，构建Pinia状态树，实现分享广场、情绪日记本等高保真UI，实现手机号登录页，进行若干bug修复
程嘉烨	UI实现 / 测试	47	完成运势看板、答案之书等核心页面开发，实现ECharts运势轨迹与运势看板、答案之书等交互动效，进行bug修复
王宇博	基础设施 / DevOps	53	搭建阿里云ECS服务器环境，编写CI/CD流水线，实现自动化测试与部署，编写部署维护手册，完成SSL证书申请与HTTPS配置
吴峥	后端 / 算法 / 测试	44	设计数据库并开发20余个Flask后端API，实现用户认证与JWT，编写单元测试，确保了接口正确率
曾立宏	后端 / 安全 / 辅助测试	41	封装AI调用及内容审核，开发运势与答案生成接口，实现分享广场及点赞功能

实际进展

二、典型用户场景

典型用户一：日常解压型

• 身份：大二学生，专业学习压力适中，喜欢研究星座和塔罗
• 产品偏好：喜欢随机、治愈、轻松不费脑的内容
• 使用时间：集中在早晨起床、午休、睡前等碎片化时段
• 主要动机：获得积极心理暗示、娱乐消遣
• 核心需求点：
  • 每天都要有点小期待，不想每次打开都看到重复内容
  • 不要太复杂，打开就能用
  • 不喜欢加载慢、广告多的App

我们的产品如何满足需求？

• 一键即看，零门槛体验：作为WebApp，输入网址即可打开，无需下载安装。
• AI生成，每日保持新鲜感：运势文案由AI根据日期与数据动态生成，拒绝模板化重复。小雅每天打开都会获得不同的解读，满足“每天都有小期待”的心理诉求。
• 无广告纯享，使用无干扰：界面极简，没有任何广告或付费弹窗，小雅纯粹沉浸在这份小小的仪式感中。

典型场景

早晨7点半，闹钟响后，小雅习惯性地点开心运岛网站。在首页通过动态抽签，显示今日运势。

今日运势为小瑾，爱情、事业、财富、健康的状态都很稳定。小雅看到今日宜“简单运动拉伸”，决定在晚上学习结束后去操场跑两圈。运势轨迹整体呈一个上升趋势，每日运势评分都有增加，小雅对今天很有信心。

在忙碌了一天的晚上后，小雅想起来今日宜记录感悟，于是点开“我的”的情绪日记本，选择了今日的心情，并简单写下了今日的收获感悟。她点开心情时间轴，可以看到这几天来的心情变化和简短小日记。

典型用户二：决策纠结型

• 身份：大四学生，面临求职与论文双重压力，经常陷入选择困难
• 产品偏好：希望获得有启发的、可操作的建议，而非玄学预言
• 使用时间：在遇到具体问题或情绪低落时使用
• 主要动机：获得决策参考、缓解焦虑、理清思路
• 核心需求点：
  • 回答不能太空洞，要有启发性和可操作性
  • 想要有历史记录，方便回头看

我们的产品如何满足需求？

• AI哲思响应，提供决策参考：阿杰输入问题后，系统会调用AI生成哲思或治愈性回复，不提供玄幻预言，而是以真诚共情的视角提供参考建议。
• 历史回溯，复盘成长：所有答案都会被完整保存到个人历史记录中。阿杰可以在迷茫时回溯自己过去抽到的问题与回答，感受到自己的成长轨迹。

典型场景

晚上11点，考研复习到中途的阿杰感到疲惫又迷茫。他打开手机，在心运岛进入“答案之书”页面，在输入框中写道：“我到底要不要坚持考研到理想的学校？”

他轻触书籍，屏幕缓缓翻开出一段话：“再坚持一下，答案会慢慢浮现”。他将这个答案存入收藏，决定好好睡一觉，明天再坚持坚持。

答案之书，不帮你做决定，但帮你更好地做决定。

典型用户三：社交互动型

• 身份：大三学生，社交媒体重度用户，热衷于在小红书、朋友圈分享生活
• 产品偏好：喜欢高颜值、可互动、可炫耀的内容
• 使用时间：抽到有趣答案或高颜值卡片时立即使用
• 主要动机：展示自我、获得社交认同、与好友互动
• 核心需求点：
  • 卡片和界面一定要好看，足够精致
  • 希望有人能懂我的分享，能和我互动
  • 社交要轻松，不要像某些app那样打开就感觉压力很大

我们的产品如何满足需求？

• 高颜值精美卡片：卡片视觉设计由专业UI/UX同学把控制作，每一张都是视觉作品。小琳可以将自己喜欢的卡片发布到朋友圈或小红书，轻松展示个性。
• 轻社交广场，无压力互动：产品内设“分享广场”，小琳可以将有共鸣的卡片匿名发布到广场上，无需加好友，即可收获他人在卡片下方的点赞与评论，避免社交负担。
• 纯享清净，贴纸不打扰：没有任何广告、无付费弹窗、无恼人贴纸骚扰，小琳在这里只与美好的卡片和温暖的陌生人为伴。

典型场景

午饭时间，小琳随手在心运岛抽到了今日运势，她觉得这个签文特别应景，当即生成了一张带有精美插画的幸运卡片发布到分享广场，没多久便收到陌生人的点赞。在轻社交的设计理念下，一张卡片也能连接起相同频率的温暖灵魂。

三、杀手级功能

1. AI驱动，千人千面

市面上大多数“答案之书”类产品，本质是一个固定的语料库——你每次摇一摇，系统从几百条预设句子中随机抽取一条。第一次可能觉得有趣，第二次、第三次就开始重复、空洞，最终被遗忘在手机角落。

心运岛的“答案之书”不是这样。它是一本会“记得你”的书。

当你在心运岛输入一个问题，AI并不是随机吐出鸡汤。它会结合：

• 你当下的问题关键词
• 你近期的情绪日记记录
• 你过往的提问历史

同样问“我该不该换工作”，一个连续疲惫了一周的用户会收到：

“你最近太累了。换工作不是现在最急迫的事，也许可以先请一天假，把自己从忙碌里打捞出来。休息好了，答案会更清晰。”

而另一个刚刚在情绪日记里写下“今天拿到了新offer，开心”的用户，则会收到：

“你看，你已经迈出了很棒的一步。新的机会值得认真考虑，不妨列一个清单，把‘想要的’和‘害怕的’都写下来——你比想象中更有判断力。”

2. 历史回溯

很多趣味工具用完即弃，因为用户觉得“没有积累”。心运岛会永久保存你所有的记录。

你可以随时回到“我的”页面，翻看自己三个月前的运势记录、一段时间以来的心情，还可以看到自己提了哪些问题，收获了哪些解答。

心运岛不再是一次性的游戏，而是一本属于你自己的成长日记。

3. 轻社交

许多产品的社交功能很容易走向两个极端：要么太过冷清，发出去的东西无人问津；要么太过吵闹，评论区充斥着攀比、杠精和广告。心运岛的“轻社交”走的是第三条路——低压力、高共鸣、只传递善意。

你可以把抽到的运势卡片或答案卡片发布到广场，不需要加好友。发布时只需要一句话，甚至只发卡片本身。

四、软件发布

心运岛：http://39.106.220.76/

反馈问卷：https://v.wjx.cn/vm/rrlZLpU.aspx#

在正式公开推广前，我们先邀请小范围同学进行测试，将心运岛部署到云服务器，邀请了30名左右目标用户（以在校大学生为主）进行测试。

• 通过微信群发放访问链接
• 鼓励用户日常使用，并在测试群中反馈问题、提出建议
• 团队实时收集Bug、优化体验

通过小范围测试，我们验证了核心流程的稳定性，并根据反馈优化了AI Prompt，修复了前端出现的各种显示问题。

接下来，我们进行了公开推广计划，在小红书上面发布心运岛网站宣传。通过配以精美卡片截图和话题标签：#治愈系App #答案之书 #情绪日记，来吸引更多人使用我们的网站。

在通过用户使用后，我们也收集到了一些bug和可以优化的方向：

1. 抽签后ECharts折线图未实时更新
2. 验证码未增加人机检验
3. 答案之书在没填写问题时，点击书本应该出现提示输入问题的UI

这些问题我们会在Beta阶段进行优化。

五、软件工程质量

代码规范与协作流程

团队制定了统一的Git规范、开发日志、PR流程和提交规范，确保代码风格一致、变更可追溯。

• 分支策略：main 为主分支，dev 为开发分支，功能分支从 dev 拉出，完成后提交PR
• 提交信息格式：<type>(<scope>): <subject>，如 feat(answer): add history backtracking
• 代码审查：每个PR至少由一名非本人成员审阅通过后方可合并
• 每日日志：每位成员在工作群中同步当日进度与计划，便于PM跟踪

CI/CD

已通过GitHub Actions搭建CI流水线，每次代码提交自动运行单元测试和代码风格检查。

API文档

涵盖所有接口的URL、请求参数、响应示例和错误码。文档随代码更新，团队成员可随时查阅，减少前后端沟通成本。

测试

• 后端单元测试：共159个用例，通过率100%；服务层行覆盖率93%，路由层行覆盖率71%
• 压力测试：简单查询接口在200并发下错误率0%，吞吐量达140 req/s；登录接口为当前性能瓶颈，80并发下平均延时5.5秒，系统稳定承载并发上限约80
• 兼容性测试：覆盖macOS / Windows下的Chrome、Safari、Edge、FireFox，所有核心功能（登录、运势查看、答案之书、心情日记、分享）均通过
• Bug修复：前端共发现并修复20个功能性Bug，后端修复4个逻辑与接口问题；剩余2个低优先级问题（PWA主屏添加、ECharts更新）计划在Beta阶段解决

以上测试数据表明，系统核心功能稳定、兼容性良好，主要性能瓶颈已定位，为Beta阶段优化提供了明确方向。

六、团队总结

学到的经验和教训

1. 团队一定要积极沟通，不能闭门造车

Alpha阶段初期，部分成员习惯于各自埋头开发，遇到问题不好意思开口，结果往往是浪费了半天时间才发现自己走错了方向，或者在联调时才发现前后端对接口的理解完全不一致。在之后的Beta开发阶段，我会促进大家同步进度，遇到阻塞问题立即在群里@相关人，前后端接口讨论必须拉通各方一起确认。

2. API文档要写详细

我们早期API文档只有接口名称和字段名，前端同学不得不频繁去翻后端代码或直接问，消耗了大量沟通时间。现在我们的API文档规范会十分规范。每个接口包含URL、Method、请求参数（含类型、必填、示例）、响应结构（含字段说明）、错误码列表、调用示例。文档随代码更新，团队成员随时可查，极大减少了口口相传的信息损耗。

3. 完成任务后不要就觉得可以了，要主动多想还有什么没实现

在测试阶段我们会发现，开发过程中很多已经完成的功能出现了严重问题。这件事让我们意识到：功能能用和功能健壮之间还有很大距离。每个任务完成后，负责人要主动思考：“还有哪些边界情况没处理？还有什么异常场景没覆盖？” 这种多想一步的习惯，能帮我们在后续开发中规避不少Bug。

4. Beta阶段早点开始测试阶段，耗时比想象的久

Alpha阶段，我们把大量测试工作挤压到了最后一周。结果发现，单元测试、集成测试、端到端测试、兼容性测试、压力测试，每一项都比预想的要耗时得多。这次教训让我们深刻认识到：测试不是最后收尾的扫尾工作，而应该贯穿开发全过程。Beta阶段我们会把测试前置，从第一周就开始搭建测试框架、编写测试用例，让测试和开发并行推进。

Beta阶段计划预览

基于Alpha阶段的经验教训和已暴露的瓶颈问题，Beta阶段我们将在以下四个方向重点发力：

性能优化

1. 重点优化运势卡片接口
2. 优化广场卡片列表查询性能
3. 对核心接口进行二次压测，确保200并发下稳定运行

功能完善

1. 新增运势PK功能
2. 新增随机彩蛋机制，特定时间/天气触发特殊回复风格与视觉效果
3. 新增验证码发送前的人机检验，采用滑块验证，防止恶意刷屏
4. 修复Alpha版本遗留的PWA主屏添加问题和ECharts折线图更新Bug

安全加固

1. 强化内容审核机制，扩展敏感词库覆盖范围
2. 完善用户数据脱敏方案，确保情绪日记等敏感信息安全

用户体验

1. 增加连续签到打卡激励机制，提升用户留存
2. 优化移动端适配细节，提升触控交互体验
3. 持续收集用户反馈，定期迭代优化