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

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

项目与团队亮点

一、团队成员与分工

成员	分工	个人主页
章宇馨	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镜像构建与安全扫描

任务与进度管理

我们采用GitHub Issues，每个任务对应一个Issue，进度透明可追溯。

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

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

团队沟通方式

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

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

在Bug修复阶段，PM对修复任务进行一对一的沟通与跟进。

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

二、典型用户场景

典型用户一：日常解压型

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

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

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

典型场景

早晨7点半，闹钟响后，小雅习惯性地点开心运岛网站。因为经常访问，小雅将心运岛增加到了主屏幕，可以直接点开。

在首页通过动态抽签，显示今日运势。这几天临近端午节了，运势看板显示的是端午节限定节日卡片。

今日运势为守静，爱情、事业、财富、健康的状态都很稳定。小雅看到今日宜“早睡养神”，决定今天晚上学习结束之后早点睡觉。

这几天的运势起伏较大，小雅决心放平心态，以一个平稳的心情面对生活。

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

典型用户二：决策纠结型

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

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

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

典型场景

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

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

阿杰将考研遇到的烦恼写入树洞中，投入树洞后真有一种把烦恼丢出去的感觉，心里的负担减轻了。

凌晨1点阿杰失眠了，再次向答案之书提问，页面触发彩蛋。

在特殊的天气或者节气也会触发相应的彩蛋。

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

典型用户三：社交互动型

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

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

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

典型场景

午饭时间，小琳随手在心运岛抽到了今日运势，她觉得这个签文特别应景，当即生成了一张带有精美插画的幸运卡片发布到分享广场，没多久便收到陌生人的点赞。

无需添加好友，即可实现评论功能。评论在轻社交的设计理念下，一张卡片也能连接起相同频率的温暖灵魂。

小琳将今日运势和答案之书生成的精美卡片都下载下来，收藏记录。

还可以与好友PK运势，点击运势挑战，就会生成PK专属链接，好友点击链接登录即可实现PK。链接仅当日有效。

在心运岛的使用中，小琳逐步达成了许多成就，解锁了许多好看的徽章。

她选择了其中三个进行佩戴，在分享广场里大家都能看到她获得的徽章。

三、杀手级功能

1. AI驱动，千人千面

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

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

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

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

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

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

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

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

2. 历史回溯

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

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

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

3. 轻社交

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

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

四、软件发布

心运岛：https://xinyundao.top

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

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

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

指标	数值
注册用户总数	234 人
核心功能渗透率	136 人使用过任一核心功能，占注册用户的 58.1%
运势渗透率	134 人（57.3%），运势记录总数 242 条
答案之书渗透率	83 人（35.5%），提问总数 246 条
广场发帖用户	11 人（4.7%），卡片总数 30 张，评论 17 条，点赞 37 次
情绪日记用户	10 人（4.3%），日记总数 27 条
运势PK发起用户	6 人，完成 PK 7 次
获得徽章用户	9 人
近7日活跃	运势 17 次、问答 10 次、广场发帖 10 次

实际日活跃用户数约48人，未达到预期。但以下数据说明产品对用户确实产生了价值：

• 次月留存率（对 5 月注册用户）：约 31%，高于行业平均值 20%。
• 核心功能渗透率：58.1% 的注册用户使用了至少一项核心功能，说明产品定位清晰、用户愿意尝试。
• 人均提问次数：83 位提问用户共提问 246 次，人均约 3.0 次，表明答案之书有较强粘性。
• 近一周广场升温：近 7 日发帖 10 张，占历史总量 1/3，说明社交功能开始被用户接受。

五、软件工程质量

代码规范与协作流程

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

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

CI/CD

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

API文档

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

测试

• 后端单元测试：共 372 个用例，100% 通过，源码覆盖率达 83%，覆盖认证、运势、答案、广场、评论、徽章、日记等全部核心模块。
• 前端功能测试：覆盖登录/注册、运势看板、答案之书、广场、我的、设置、PWA、响应式、安全等 9 大模块，累计 70+ 测试点，全部通过。
• Bug 修复：Beta 阶段发现 9 个主要 Bug（勋章遮挡、广场换行、收藏刷新、生日选择器、头像 413、PK 401 等），全部修复并完成回归测试。
• 后端压力测试：150 并发下成功率 100%，200 并发时成功率仍达 99.8%（仅 2 次读超时），性能稳定。
• 前端压力测试：小文件（193KB JS）在 200 并发下吞吐量 129 req/s，传输速率 639 KB/s，响应延迟低；大文件（1.5MB 图片）受带宽限制传输较慢，但不影响核心功能。
• 兼容性测试：覆盖 macOS / Windows 11 / Android 系统，Chrome / Safari / Firefox / Edge / 百度浏览器及 PWA 安装模式，所有核心功能均通过验证。

项目与团队总结

一、项目管理

项目管理方式

• Alpha阶段任务管理使用共享Excel文档，人工更新进度。
• Beta阶段面迁移至 GitHub Issues，每个任务对应一个Issue
• 直观展示待办、进行中、已完成任务，管理者无需逐一核对表格，快速掌握项目整体节奏。

分工协作

• PM（章宇馨）负责整体计划、需求优先级、测试组织、推广活动。
• 前端组（程嘉烨、刘小莉、吴峥）负责UI实现、交互逻辑、PWA配置。
• 后端组（曾立宏）负责API开发、AI调用、内容审核、数据库。
• DevOps（王宇博）负责CI/CD、服务器部署、压测优化。

改进

Alpha阶段在前后端对接上问题较大，信息不对称、联调耗时久。Beta阶段要求成员及时更新API文档，并在组会中简要汇报自己使用的重要接口，降低了前后端沟通成本。

Alpha阶段测试工作集中在最后一周，导致后期压力大。Beta阶段从冲刺第一周开始并行编写单元测试和集成测试，避免积压。

沟通和对接

• 组会：每两天一次，每次约半小时，同步昨日完成、今日计划、阻塞问题。
• 会议纪要：PM记录在博客，包含决议、待办事项、责任人。
• 代码与文档：API变更通过Github和会议同步，PR描述中注明接口改动。

团队贡献分分配

Beta阶段

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

成员	分工	贡献分	具体贡献
章宇馨	PM / UI设计 / 测试	49	统筹项目整体进度，完成了12篇博客，开展了9次会议，发现软件中的若干bug并组织解决，负责推广宣传
刘小莉	UI/UD设计 / 测试	46	设计10组徽章样式及多套UI（设置页、卡片模板），完成PWA引导、默认图像显示和页面美化。
程嘉烨	UI实现 / 测试	55	实现分享广场分享、运势看板节日限定卡片、彩蛋动画（夜晚/雨天/节气）及曲线图等多处Bug修复。
王宇博	基础设施 / DevOps	55	配置HTTPS、滑块验证码、优化服务器缓存与移动端适配，完成HTTP到HTTPS强制跳转。
吴峥	前端 / 测试	50	完成今日树洞、注册信息收集、生日组件重建、运势PK前端流程及徽章系统前端实现。
曾立宏	后端 / 安全 / 辅助测试	45	实现AI个性化Prompt、彩蛋后端逻辑、内容审核扩展及徽章系统，完成后端压力测试，实现分享广场评论功能

总贡献分

成员	贡献分
章宇馨	52
刘小莉	53
程嘉烨	51
王宇博	54
吴峥	47
曾立宏	43

实际进展

二、用户场景

项目开发前的目标与预期场景

心运岛是一款面向年轻群体的轻量级心灵慰藉工具，融合了每日运势看板、智能答案之书、情绪日记与轻社交分享四大模块。产品以WebApp形式发布，通过PWA技术，用户可以将其添加到手机主屏幕，获得接近原生App的启动和交互体验。

日常解压型

大二学生小雅每天起床后，都会点开手机上的心运岛应用。打开后首页直接显示今日运势看板，爱情 4 星、事业 3 星，还标注了宜主动交流、忌拖延。她觉得运势很合心意，便点击生成卡片，选了喜欢的紫色渐变样式保存下来，接着配上 “今天也要加油鸭” 分享到朋友圈。整个过程不到一分钟，既收获了积极的心理暗示，也满足了分享欲。

决策纠结型

大四正在找工作的阿杰，面对一份offer拿不定主意，他打开心运岛进入 “答案之书” 页面，认真输入问题 “我应该接受这个 offer 吗？”，随后摇晃手机，屏幕随即给出回答。他点击保存答案，系统自动将内容存入历史记录，又翻看了昨天抽到的暖心签文，瞬间备受鼓励，不再焦虑纠结，打算第二天梳理好offer的利弊再做决定。

社交互动型

小琳在心运岛抽到了运势上上签的卡片，兴致满满地点击和朋友 PK。室友只抽到上签，系统立刻显示 “你赢了！” 并生成对比卡片，两人看着结果开怀大笑。小琳还把对比卡片发到宿舍群，和大家分享这份乐趣，不仅增添了朋友间的互动趣味，也让产品实现了社交传播。

情绪复盘与自我成长

小鹿使用心运岛两周后，进入个人中心的情绪日记页面，查看过去 14 天的心情图谱，绿色代表心情好、黄色一般、红色低落。通过图谱她清晰发现，自己每逢周一运势都是红色，意识到存在周一焦虑的情况。系统还根据她的记录给出趣味推荐语，小雅觉得十分贴切，从此开始主动记录心情，心运岛也从单纯的娱乐工具，变成了帮助她实现自我认知的成长帮手。

项目发布

运势看板

每日运势

• 用户进入运势看板页面后，系统自动展示当日的运势信息，包含爱情、事业、健康、财富多个维度的评分以及宜/忌建议。
• 支持查看一周的运势记录

限时视觉风格的运势卡片

• 在特定节日（如春节、中秋节），后台可配置限定主题的卡片样式
• 活动期间，所有用户生成的运势卡片均使用限定主题
• 活动结束后，新生成的卡片恢复默认样式，但已生成的卡片不受影响

答案之书

随机答案抽取

• 用户可在输入框中输入心中的疑问，然后点击“开启”按钮，系统返回一句随机生成的哲理或治愈性回复。
• 每条回复字数在 20-150 字之间，且经过内容审核 API 检测，无敏感词、色情、暴力等违规内容。

历史答案回溯

• 用户在个人中心可以查看自己过往抽取的所有答案记录。

• 点击某条记录可展开详情，完整显示问题和答案。

彩蛋机制

• 在特定时间（凌晨、下雨天）或节气（如立春、冬至）时，答案之书的回复风格或视觉主题会发生变化（如飘落花瓣、雨滴、星星闪烁）。

• 彩蛋触发条件由后端根据服务器时间或天气 API判断

分享广场

运势卡片生成

• 用户可点击生成卡片按钮，将当前运势结果转化为一张精美的图片卡片，保存到本地相册。

分享广场

• 用户可将自己的运势卡片或答案卡片发布到广场
• 发布后不可编辑但可删除，删除后广场中该卡片消失。

点赞与评论

• 用户可对广场中的任意卡片进行匿名评论和点赞。每张卡片下方显示评论图标和点赞图标，点击后展开评论输入框或执行点赞。
• 点赞实时更新计数，同一用户对同一卡片只能点赞一次

运势PK

• 用户 A 点击“发起 PK”按钮，，生成一个分享链接。用户 B 打开链接后授权。对比页面展示双方运势值及胜负结果，并可生成对比卡片分享。
• 生成的 PK 链接有效期为 24 小时

今日树洞

• 用户将烦恼写入今日树洞，烦恼就被丢弃了，今日树洞返回治愈性话语。

我的

历史运势记录

• 用户可查看自己过往所有运势记录，支持按月份折叠展示，点击某一天可展开当日完整运势详情。

情绪日记本

• 用户可在日历视图中选择某一天，记录当日心情表情

收藏功能

• 用户可在运势详情页或答案历史页点击按钮收藏内容。

徽章收集

• 用户在使用软件的过程中，会达成各种成就，解锁不同徽章不同等级的徽章。
• 可以选择三个徽章进行佩戴，在分享广场页面可以看见。

PWA

• 可以将Webapp添加到主屏幕，方便每日查看。

心运岛：https://xinyundao.top

用户反馈

已满足全部典型场景。

用户整体满意较高且愿意继续使用心运岛。

三、用户日活

我们采用两种方式进行主要推广。一是同学之间互相邀请新用户。二是小红书进行宣传。

实际日活跃用户数约48人，未达到预期。但以下数据说明产品对用户确实产生了价值：

• 次月留存率（对 5 月注册用户）：约 31%，高于行业平均值 20%。
• 核心功能渗透率：58.1% 的注册用户使用了至少一项核心功能，说明产品定位清晰、用户愿意尝试。
• 人均提问次数：83 位提问用户共提问 246 次，人均约 3.0 次，表明答案之书有较强粘性。
• 近一周广场升温：近 7 日发帖 10 张，占历史总量 1/3，说明社交功能开始被用户接受。

以下是用户对功能改进上进行的反馈

四、特色功能

AI 个性化回复 + 趣味彩蛋机制

主流答案之书、运势类应用普遍使用固定语料库，回答内容重复、同质化严重；部分搭载大模型的同类产品，也仅实现通用 AI 问答，未针对用户做定制化适配，回复内容宽泛生硬。

心运岛突破传统模式，整合用户生日、星座、历史提问数据构建专属用户画像，依托精细化提示词工程生成千人千面的个性化回复

结合实时天气、当日时段触发专属视觉与内容彩蛋，在基础问答之外增添趣味与仪式感，强化产品与用户的情感联结。

竞品未实现该功能的原因

• 该功能需要对接第三方天气 API、开发时段判断逻辑、设计配套前端动画与交互效果，额外增加前后端开发、联调、测试工作量
• 多数竞品以快速上线、降低研发成本为目标，优先保障基础功能，不愿投入资源打磨个性化、彩蛋这类非刚需细节。

团队实现该功能的核心优势

• 团队成员具备 AI 应用开发实战经验，熟练掌握 Prompt 工程，能够精准调教大模型输出风格与内容
• 前端团队独立完成彩蛋动画、交互视觉设计，保障展示效果；后端负责接口对接、数据逻辑与异常处理
• 团队坚持打造有温度、重体验的产品理念，主动分配人力与时间打磨细节功能，不片面追求开发速度。

全记录历史回溯

市面上多数同类趣味工具属于 “一次性使用” 产品，使用后无内容留存，用户无法回顾过往数据，使用粘性偏低。

心运岛支持永久保存用户所有提问、运势、问答记录，用户可在个人中心随时查阅往期内容，回溯不同阶段的心情与疑问，让工具从临时娱乐转变为专属个人的线上成长日记。该功能赋予产品长期使用价值，打破同类产品用完即弃的短板，有效提升用户留存率，让产品具备持续使用的意义。

竞品未实现该功能的原因

• 永久数据留存需要持续的数据库存储资源、数据归档与备份方案，增加服务器运维与资源成本
• 需要开发完整的记录存储、分类展示、时间回溯、历史检索逻辑，增加前后端开发与测试工作量
• 多数竞品将产品定位为轻量化即时趣味工具，仅追求单次使用体验，忽视用户长期留存与情感沉淀，不愿投入成本搭建长期数据体系。

团队实现该功能的核心优势

• 后端团队具备完善的数据存储与运维能力，合理设计数据库表结构，实现用户数据分类存储、永久留存与安全备份，保障数据不丢失
• 前端团队优化历史记录页面展示逻辑，按时间维度规整呈现内容，回溯查看直观流畅，用户体验极佳
• 团队深度洞察用户需求，跳出工具类产品只做单次交互的固有思维，以长期用户留存为核心，主动投入资源搭建数据回溯体系，打造产品长期价值。

低压力轻社交

目前行业内社交类功能两极分化严重：纯广场模式人气低迷、互动冷清；强社交模式则容易出现攀比、争执、广告骚扰等问题。

心运岛打造差异化轻社交广场，主打低压力、纯善意、高共鸣的社交氛围。用户可直接分享运势卡片、问答卡片，支持极简发布形式，无需添加好友、无需复杂编辑，仅分享内容本身，营造轻松纯粹的互动环境。规避传统社交的负面问题，以内容分享为核心，弱化社交压力，契合产品休闲、治愈的整体定位。

竞品未实现该功能的原因

• 多数同类产品要么舍弃社交功能，只做纯工具属性；要么照搬传统社交模式，依赖好友关系、评论互动提升流量
• 轻社交模式无法快速带来流量与热度，短期收益低，多数竞品优先选择高流量、高互动的传统社交方案，忽视用户的轻量化社交需求。

团队实现该功能的核心优势

• 团队精准洞察行业社交痛点与用户心理，摒弃同质化社交模式，明确治愈、休闲的产品社交定位，精准切入低压力社交空白赛道
• 产品团队坚持用户体验优先，不盲目追求社交热度与流量数据，聚焦纯净、善意的社交氛围打造，形成独特的产品社交调性。

五、软件工程质量

文档与代码规范

• 代码规范：定义了ESLint和Flake8配置，提交前自动检查。
• 注释覆盖率：核心函数注释率约70%，复杂逻辑（彩蛋触发、PK算法）有详细注释。
• 新人指导：README.md包含环境配置（Node.js 18+、Python 3.10）、依赖安装、运行命令、测试方法。

代码维护

• 每个PR必须经过审查，强制保持代码风格一致。
• 采用TypeScript和Flask-RESTX，降低理解成本。
• 历史版本通过Git管理，有完整的提交记录。

单元测试与覆盖率

模块	测试用例数	覆盖率
认证/验证码	68	91%
用户资料	52	88%
运势/答案生成	71	79%
分享广场/评论	64	85%
徽章/日记	57	76%
运势PK	60	82%
总计	372	83%

未覆盖的主要是外部服务调用（LLM API、内容审核API）的异常分支，因为难以在单元测试中模拟。

CI/CD 工具

使用 GitHub Actions 实现了：

• 代码检查（ESLint + Flake8）
• Docker镜像构建并推送到阿里云容器镜像服务
• 自动部署

自动化流水线确保每次提交都经过质量检验，减少人工错误，加快迭代速度。

学到的经验和教训

测试用例要尽早开始写，Alpha阶段在前后端对接上问题较大，信息不对称、联调耗时久。Beta阶段要求成员及时更新API文档，并在组会中简要汇报自己使用的重要接口，降低了前后端沟通成本，后期Bug显著减少。

我们应该尽早开始推广，Beta阶段推广时间较短，效果有限。正式发布前应提前一个月布局社交媒体、建立用户社群。