PQ .v.Next Beta postmortem

一、团队贡献分排名（仅输出排名）

评分原则参考：

• 《软件团队中的个人贡献如何评价》
• 《再谈软件团队中的个人贡献》
  核心思想：看对团队目标的真实贡献与不可替代性，而不是单纯工作量。

🏆 团队贡献分最终排名

第 1 名：闫秉政

• 持续承担项目主线任务与技术路线决策
• 主导 KG → LLM → Bloom 分类 → 流水线化的完整演进
• 在 Alpha Postmortem 后推动关键改进（LLM 介入、策略重构）
• Daily Scrum 连续记录，承担高不确定性探索任务
  → 对项目成败具有最高不可替代性

---

第 2 名：韩云河

• 负责后端与数据库相关核心实现
• 为整体系统提供稳定的数据与服务基础
• 在 Beta 阶段支撑功能整合与系统落地
  → 对系统可运行性贡献显著

---

第 3 名：荚左龙

• 负责前端 UI 设计与前后端对接
• 保证功能在用户侧可展示、可验证
• 参与代码仓库管理与工程协作
  → 对产品可用性与展示效果贡献明显

---

第 4 名：何绍斌

• Beta 阶段新加入成员
• 参与时间较短，贡献主要集中在后期
  → 因参与周期原因，整体贡献相对有限

---

二、Postmortem 反思

1. Alpha 阶段暴露的主要问题

在 Alpha 阶段 Postmortem 中，团队明确识别出以下问题：

1. 技术路线探索性强但不稳定

   • 知识图谱关系抽取效果较差
   • 大量关系被简化为泛化的 related to，缺乏语义区分度

2. 目标输出与设计目标存在偏差

   • 生成题目不符合布鲁姆认知层级要求
   • 题目质量与分布不可控

3. 人工依赖程度高

   • 实体与关系需人工修正
   • 缺乏自动化、可复用的流程

4. 工程闭环不足

   • 尚未形成完整流水线
   • 结果难以稳定复现与集成

---

2. Alpha Postmortem 后采取的改进措施

（1）引入 LLM 参与关系修正 —— 针对“关系质量差”的直接回应

• 从单纯 NRE 模型，升级为 LLM 参与关系语义校正
• 明显减少关系语义塌缩问题
• 将“不可用的探索结果”转化为“可继续优化的中间结果”

👉 这是对 Alpha 技术问题的直接技术层面修正

---

（2）重构布鲁姆分类生成策略 —— 针对目标偏差问题

• 识别出题目集中在 B1 / B3 / B4 的问题
• 多轮调整 Prompt，引入显式 Bloom 约束
• 在多个文件上测试其普适性，而非单样本验证

👉 从“能生成题目”转向“按教育目标生成题目”

---

（3）工程化与流水线化 —— Alpha 阶段没有做到的关键改进

• 构建完整流程：
  PDF → OCR → KG → LLM → Bloom 分类 → 批量出题
• 将探索性代码整理为可复用流程
• 为后续并入 PQ v.Next 创造条件

👉 标志着项目从实验性探索进入可交付阶段

---

3. 改进是否有效？

结论是：改进是明确且有效的。

• Alpha 阶段的问题并未被回避，而是被拆解并逐项应对
• 技术路线从“单点探索”演进为“多策略协同”
• 输出结果从不可控转向可调、可复用
• Daily Scrum 显示任务目标逐步清晰、风险逐步收敛

团队在 Alpha Postmortem 后，体现了明显的反思—调整—验证的迭代闭环，这正是 Scrum 与课程所期望的核心能力。

---

4. 总结性反思

本项目在 Alpha 阶段更多处于技术可行性探索阶段，而在 Postmortem 之后，团队基于问题导向不断调整技术策略与工程实现方式，使系统逐步具备稳定输出能力。这一过程虽然经历多次试错，但最终形成了可运行、可扩展的完整流程，体现了团队对反思结果的有效落实。