[T.19] 团队项目：Beta 阶段项目总结

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[T.19] 团队项目：Beta 阶段项目总结 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	学习并实践现代软件工程的完整开发流程，提升全栈开发与团队协作能力
这个作业在哪个具体方面帮助我实现目标	本次作业通过 Beta 阶段的事后复盘 (Postmortem)，帮助团队深刻反思执行与计划的差异，沉淀宝贵的工程经验

本文是哈基米南北绿队在启元知微 Beta 阶段结束后的 Postmortem 总结。会议核心问题是：如果可以重新来过，我们会在哪些方面做得更好？

一、设想和目标

1. 我们的软件要解决什么问题？

启元知微要解决的是北航计算机类课程复习中“资料分散、问答不可核对、做题和复盘割裂、讨论缺少沉淀”的问题。

典型用户是正在备考的本科生。他希望在一个平台中完成：

• 围绕课程资料提问；
• 查看有来源的回答；
• 做题与模拟考试；
• 自动收集错题；
• 根据错题专项复练；
• 在论坛和同学讨论；
• 使用图床等工具辅助文档写作。

这个目标在 Alpha 后已经比较清晰。Beta 阶段的重点不是推翻目标，而是补齐 Alpha 暴露出的 5 类痛点：RAG 无溯源、错题复练断链、缺少埋点、论坛治理不足、移动端体验不完善。

2. 我们达到目标了吗？

总体上达到了 Beta 阶段目标。

原计划 #beta-01 至 #beta-15 共 15 个 Issue，覆盖引用溯源、错题复练、AI 深度解析、管理员后台、行为统计、限流、移动端适配、数据库备份和自动化测试。到发布前，核心功能已经完成并通过联调；6 月 7 日例会时 #beta-01 至 #beta-14 已关闭，仅剩 #beta-15 单元测试收尾。

功能目标完成情况：

目标	完成情况
RAG 引用溯源	已完成，支持引用角标与悬浮卡片
资料库扩充	已完成，重点扩充操作系统、编译原理等课程
错题复练	已完成，支持筛选与一键复练
AI 深度解析	已完成，支持题目解析流式输出
论坛治理	已完成，支持下架、删除、禁言
行为统计	已完成核心统计视图
移动端与暗色主题	已完成主要页面适配
数据库备份与部署	已完成发布前整理

用户目标方面，Beta 展示阶段统计视图显示累计用户 87、活跃用户 65，说明产品已经被部分真实用户使用。但长期 DAU、留存和功能使用深度仍需要更长周期的数据验证。

3. 软件工程质量是否提高？

相比 Alpha，软件工程质量有明显提高。

可量化事实：

指标	当前值
前端页面视图	24
前端 Vue 组件	30
后端 Alembic 迁移脚本	15
GitHub Actions 工作流	6
Backend + RAG 测试函数	22

质量提升点：

• 需求管理从“功能列表”变成了可追踪 Issue；
• 数据库变更通过 Alembic 管理；
• RAG 与 Backend 的调用关系通过协议文档约束；
• 高成本接口引入限流；
• 管理员统计和健康检查提升了可观测性；
• 发布前进行了黑盒回归，并修复 3 个明确缺陷。

不足也很明显：前端自动化测试仍然偏少，跨服务集成测试还不够系统，部分测试结果仍依赖人工验收截图。

4. 用户量和用户接受程度

从注册数和活跃用户看，启元知微已经达到了课程项目阶段的可展示目标。用户对知识问答、题库和图床工具接受度较高；对引用溯源和错题复练的反馈最积极，因为它们直接对应考试周痛点。

不过，用户数据仍有局限：

• 样本主要来自同学圈层，代表性有限；
• 统计周期较短，不能证明长期留存；
• 需要继续区分“打开过”和“真正完成学习任务”的用户。

经验教训：下一阶段要更早设计埋点口径，不能等到发布后才想统计哪些数据。

二、计划

1. 是否有充足时间做计划？

有。Beta 开始时团队专门完成了计划书，明确了 Alpha 痛点、功能规格、技术规格、WBS、Issue 分配和三周时间安排。

真正的问题不是没有计划时间，而是部分计划对联调成本估计偏乐观。例如 RAG 引用协议涉及检索元数据、SSE 首帧、Prompt 约束、前端流式 token 拼接，任何一环出问题都会影响整体体验。

2. 如何解决计划阶段的不同意见？

团队主要通过例会和飞书共享文档对齐。PM 先将需求拆成 P0/P1，再让各模块负责人判断技术风险和依赖关系。

冲突最多的是“做更多功能”还是“把核心链路做稳”。最终团队选择围绕 Alpha 痛点收敛，不再扩张太多新模块。

3. 原计划工作是否都做完？

核心计划已经完成。未完全充分的是自动化测试深度和长期数据分析。我们完成了基础单元测试与回归测试，但前端 E2E、压力测试报告和埋点长期看板仍需要后续补强。

4. 有没有事后看来价值不大的工作？

有一些页面细节讨论过早，例如部分按钮位置、卡片视觉样式，在后续交互变化后又被推翻。Beta 之后我们更认同：复杂模块应先确定状态机和接口，再打磨视觉细节。

5. 是否每项任务都有清楚交付件？

比 Alpha 好很多。#beta-01 至 #beta-15 大多有明确交付件，例如 API、迁移脚本、前端页面、测试用例、部署文档等。但仍有一些体验优化类任务交付件偏模糊，容易变成“差不多好了”。

6. 项目是否按计划进行？

整体按计划进行，但过程有波动：

• 5 月 23 日实际剩余任务数高于计划，说明第一周开发略慢；
• 5 月 30 日进度追平；
• 6 月 7 日联调收尾，进度反而略超前。

意外主要来自跨模块联调：引用卡片 token 边界、错题 Session TTL、禁言状态刷新等问题，都是单模块开发时不容易暴露的。

7. 缓冲区是否有作用？

有。6 月 8 日至 6 月 13 日的回归测试和发布材料时间非常关键。没有这段缓冲，3 个发布前 Bug 很可能会带入 Beta 演示。

8. 如果重来，计划会怎么改？

• 每个跨模块功能提前定义状态机和错误码；
• P0 功能必须配套至少一个自动化测试；
• 前端移动端适配提前到第二周，而不是联调末期；
• 埋点口径在功能上线前确定，避免后补数据解释。

三、资源

1. 资源是否足够？

总体足够，但分布不均。后端和 RAG 的任务密度较高，尤其是引用协议、AI 解析、错题复练和论坛治理都需要后端参与。前端在联调后期承担大量移动端和暗色主题修复，压力也集中。

2. 时间估计精度如何？

纯后端 CRUD 类任务估计较准；涉及 AI、SSE、跨端浮层和状态同步的任务估计偏低。原因是这些任务的难点不在“写接口”，而在“各种异常组合”。

3. 测试资源是否足够？

发布前黑盒测试有效发现了问题，但自动化测试资源不足。当前 Backend + RAG 测试函数共 22 个，对核心逻辑有帮助，但还不能覆盖完整产品链路。

4. 哪些事可以更高效分配？

移动端样式和截图材料可以更早由前端与 PM 合作完成；测试用例也不应全部等功能完成后再补，而应由开发者在实现时同步补充。

经验教训：资源不是人头数量，而是关键任务是否有足够连续时间。Beta 后期碎片化联调会显著降低效率。

四、变更管理

1. 变更消息是否及时同步？

大多数变更通过例会、飞书文档和 GitHub Issue 同步。Beta 阶段比 Alpha 更好的一点是：重要变更会落到 Issue 或文档中，而不是只停留在聊天记录。

2. 如何决定推迟和必须实现？

判断标准主要有三条：

1. 是否直接对应 Alpha 阶段用户痛点；
2. 是否影响核心复习闭环；
3. 是否阻塞 Beta 发布出口条件。

因此，引用溯源、错题复练、论坛治理、移动端适配被保留为必须实现；部分扩展课程资料、复杂运营分析和更完整的 E2E 测试被放入后续优化。

3. 出口条件是否清晰？

比 Alpha 清晰。Beta 出口条件包括：核心 Issue 完成、CI 通过、场景测试通过、P0/P1 Bug 修复、健康检查可用、发布说明完整。

不足是性能指标仍不够硬，例如“多少并发下 P95 延迟多少”还没有形成统一发布门槛。

4. 是否有应急计划？

有一些基础预案：

• RAG 服务异常时返回明确错误提示；
• 高成本 AI 接口通过限流保护；
• 数据库有备份脚本；
• 发布环境通过 Docker Compose 管理；
• 后端健康检查可辅助巡检。

但还缺少更完整的灰度发布和回滚演练记录。

五、设计与实现

1. 设计工作何时由谁完成？

Beta 设计由 PM 牵头，各模块负责人参与。RAG 引用协议由 RAG 与后端负责人主导，错题复练由题库后端和前端共同设计，论坛治理由论坛后端与前端共同完成。

这种分工基本合适，因为跨模块功能需要最了解上下游的人一起定协议。

2. 是否遇到模棱两可？

遇到了。最典型的是引用溯源：

• 引用元数据由 RAG 还是 Backend 分配？
• SSE 首帧如何发送？
• <cite id="x"/> 如果横跨 token 边界怎么办？
• 引用卡片在移动端如何定位？

解决方式是先固定最小协议：RAG 保留 metadata，Backend/前端共享 cite_id 结构，前端进行流式 buffer 拼接和渲染拦截。

3. 是否使用单元测试、UML 或工具辅助？

使用了 pytest、OpenAPI、GitHub Actions、Alembic、Docker Compose 等工具。UML 没有作为主要设计工具，更多依赖架构图、接口文档和 Issue 描述。

这些工具有效，但自动化测试仍需加强。当前更像“核心点有测试”，还没有做到“关键用户路径有完整自动化回归”。

4. 什么功能 Bug 最多？

跨模块链路 Bug 最多，尤其是错题复练和引用溯源。

原因：

• 错题复练涉及题库、用户状态、Session TTL、答题提交、错题回收；
• 引用溯源涉及 RAG 检索、LLM 输出格式、SSE 流、前端 Markdown 渲染和移动端浮层；
• 论坛禁言涉及权限、token 刷新和发帖入口。

发布前发现的 3 个重要 Bug 均属于跨模块或跨端问题。

5. Code Review 如何进行？

主要通过 PR、提交记录和模块负责人互相检查。Beta 阶段 Review 比 Alpha 更有目标，重点看接口契约、数据库迁移、权限边界和异常处理。

不足是 Review 标准仍不够统一。下一阶段需要更明确的 checklist，例如：是否有迁移脚本、是否有权限校验、是否有错误提示、是否补测试、是否更新文档。

六、测试与发布

1. 是否有测试计划？

有。测试覆盖单元测试、接口测试、场景测试、兼容性测试、回归测试和发布测试。Beta 最重视场景测试，因为产品的价值来自完整学习闭环，而不是单个接口可用。

2. 是否进行了正式验收测试？

进行了。发布前团队围绕知识问答、错题复练、AI 深度解析、论坛治理、移动端适配、管理员统计视图进行黑盒回归。

3. 是否有测试工具？

有，但还不够：

• Backend/RAG 使用 pytest；
• Frontend 使用 TypeScript 构建检查；
• GitHub Actions 执行 CI；
• OpenAPI 用于接口检查；
• 手工测试用于场景验收。

下一阶段至少应引入一类自动化 E2E 测试，例如 Playwright，覆盖登录、提问、错题复练、发帖这几条关键路径。

4. 如何跟踪性能？

Beta 阶段主要通过健康检查、管理员统计视图、限流和手工压测观察。普通查询接口在 200 并发下错误率为 0%，吞吐量约 130-150 req/s；AI 链路的瓶颈更多来自外部模型服务和网络，不宜用普通 API QPS 直接类比。

5. 发布中发现哪些意外？

主要意外是移动端引用卡片和错题 Session 过期问题。它们在桌面开发环境中不明显，但在真实用户路径中会出现。

经验教训：发布测试必须包含真实设备和过期/异常状态，而不仅是“正常路径演示”。

七、团队角色、管理与合作

团队角色基本符合成员能力：PM 负责规划与部署，后端成员按用户、问答/RAG、题库、论坛等模块分工，前端成员按页面与交互分工。

成员之间有较多互相帮助：

• 我们感谢袁子轩组织 Beta 计划、测试和发布材料，让团队后期没有失控。
• 我们感谢罗浩宇补齐统计、限流和用户侧能力，让系统更可观测、更安全。
• 我们感谢李昊霖处理 AI 深度解析和论坛管理，让学习链路与治理链路都更完整。
• 我们感谢李昊宸完成 RAG 引用协议和知识库扩充，让问答从“能回答”变成“可核对”。
• 我们感谢赵志勇打通错题复练，让题库模块从“资料浏览”变成“训练闭环”。
• 我们感谢王赫解决引用卡片、移动端和暗色主题问题，让复杂交互真正可用。
• 我们感谢刘诗怡完成管理员面板、统计视图和题库前端优化，让 Beta 功能能被用户看见并使用。

当出现合作问题时，团队主要通过例会重新对齐优先级。如果问题影响发布，优先按 P0/P1 缺陷处理；如果只是体验增强，则进入后续优化。

八、总体评价

1. CMM/CMMI 档次判断

团队目前大致处于 CMMI 2 级到 3 级之间：已经有基本项目管理、Issue 跟踪、CI/CD、测试和文档，但流程标准化和量化管理仍不够稳定。

2. 团队阶段判断

团队从 Alpha 的“磨合阶段”进入 Beta 的“规范阶段”。大家开始用 Issue、协议、迁移、测试和发布条件说话，而不是只靠临时沟通推进。

3. 相比前一个里程碑的改进

• 功能从可演示变成更贴近真实学习闭环；
• 引用溯源提升了 AI 问答可信度；
• 错题复练提升了题库价值；
• 论坛治理让社区功能可持续运行；
• 统计视图和健康检查提升了可观测性；
• 发布前缺陷修复流程更明确。

4. 最需要改进的一方面

最需要改进的是自动化测试与数据度量。

当前我们能通过人工测试保证 Beta 演示质量，但如果项目继续迭代，必须有更系统的自动化回归和用户行为数据，否则越到后期越容易“改一个地方坏另一个地方”。

九、对照敏捷原则

做得较好的原则：

1. 频繁交付可工作的软件：Beta 三周内按周推进，功能逐步联调，而不是最后一次性合并。
2. 业务人员和开发者合作：PM、前端、后端、RAG 在引用溯源和错题复练上持续对齐。
3. 响应变化高于遵循计划：Alpha 反馈中的真实痛点被转化为 Beta 核心任务。
4. 可工作的软件是首要度量：最终验收以场景能否跑通、用户能否完成复习任务为主。

做得还不够的原则：

• 可持续开发节奏仍需改进，后期联调压力偏集中；
• 自动化测试不足，影响快速迭代信心；
• 用户反馈循环还不够长期。

十、下一阶段改进计划

1. 代码管理：建立 PR checklist，要求权限、迁移、错误处理、测试和文档同步检查。
2. 架构质量：继续降低 Backend 与 RAG 协议漂移风险，增加契约测试。
3. 测试工具：引入 Playwright，至少覆盖登录、问答、错题复练、论坛发帖四条路径。
4. 项目管理：为体验优化任务定义更明确的验收截图或验收条件。
5. 用户数据：补充引用点击、AI 解析使用、错题复练完成率等指标。
6. 文档质量：维护部署手册、接口变更记录和故障处理手册。
7. 团队协作：提前暴露跨模块风险，不把联调问题集中到发布前。
8. 软件工程理解：少做几个“看起来炫”的功能，也要把测试、架构、可观测性做扎实。

十一、结语

Beta 阶段让我们更深地理解了“软件 = 程序 + 软件工程”。功能能跑只是第一步，真正让产品可持续的是清晰需求、稳定协议、可追踪任务、可复现部署、可验证测试和真实用户反馈。

如果重新来过，我们会更早写测试，更早定埋点，更早做移动端验收，也更早把跨模块协议写清楚。但也正因为这些弯路，启元知微在 Beta 阶段确实从一个课程 Demo 长成了更接近真实产品的样子。