在 Beta 阶段，我们团队的主要目标是完成核心功能的稳定性测试，并重点攻克“三角洲行动（Delta Force）”游戏内物资信息的自动化提取（OCR）这一技术难点。
经过为期 10 天的冲刺（Sprint），我们在原有视频剪辑软件 "DeltaClip" 的基础上进行了关键的功能转向，成功集成了基于计算机视觉的战利品识别功能。本次会议旨在回顾这一阶段的得失，为接下来的发布阶段做准备。
1. 设想和目标 (Vision & Goals)
我们的目标是开发一款能够自动识别游戏录屏中“战利品/物资”信息的工具。在 Alpha 阶段，我们发现市场上竞品（如某大厂推出的高光时刻记录工具）已经占据了通用剪辑的生态。因此，在 Beta 阶段我们Pivot（转型）到了更垂直的领域：利用 OCR 技术提取游戏内的文本信息（如物品名称、属性），辅助玩家进行库存管理或高光回放索引。
Q: 我们达到目标了吗？A:基本达到。我们成功实现了从视频流中截取帧，并识别出关键物资文本的功能。但距离“完美”还有差距。
2. 计划 (Plan)
Q: 原计划的工作是否都在预定时间内完成了？A:
完成项：C++ 截屏模块、Python OCR 识别核心逻辑、基础的数据导出功能。
延期项：实时 UI 覆盖（Overlay）功能。
原因：低估了 C++ 截屏数据传递给 Python 进程时的内存管理复杂度，导致在解决“多线程死锁”和“内存泄漏”问题上花费了额外 3 天时间。
Q: 燃尽图（Burndown Chart）反映了什么？A:(此处建议插入一张 Beta 阶段的燃尽图)从图中可以看出，在 Sprint 的第 4-6 天曲线趋于平缓（由 OCR 模型集成困难导致），而在最后 3 天随着技术难点突破，任务快速闭环。
3. 资源 (Resources)
Q: 我们有足够的资源吗？A:
人力：3人小队。一人负责 C++ 高性能截屏（WGC/DXGI），一人负责 Python/OCR 模型调优（PaddleOCR/ONNX），一人负责前端与业务逻辑。分工明确，但在接口联调时出现了人力瓶颈。
技术：我们使用了 PaddleOCR 和 ONNX Runtime。在 Beta 阶段，我们发现 CPU 推理速度在部分低配机器上无法满足实时性要求（FPS 低于 30），这是 Gamma 阶段需要解决的资源优化问题。
4.变更管理 (Change Management)
Q: 发生了什么意外？我们是如何应对的？A:
意外：游戏更新了 UI 字体和背景透明度，导致原有的 OCR 预处理算法失效，识别率下降至 60%。
应对：紧急召开临时会议，决定引入传统的图像处理（OpenCV 腐蚀与膨胀）对文本区域进行增强，并将识别区域从“全屏”缩小为“特定 Loot Box 区域”，识别率回升至 90% 以上。
5. 设计与实现 (Design & Implementation) —— 聚焦 OCR
这是 Beta 阶段最核心的技术复盘：
5.1 技术栈选择
截屏层：使用 C++ (Windows Graphics Capture / DXGI Desktop Duplication) 确保低延迟抓取。
识别层：Python + PaddleOCR 。
通信层：共享内存（Shared Memory）用于传输图像数据，避免磁盘 I/O 开销。
5.2 遇到的坑与填坑
问题：直接对游戏画面进行 OCR，容易受到背景干扰（如地面纹理被误识别为文字）。
解决：实现了一个“掩膜（Mask）”系统，只提取游戏 UI 中固定的物品栏坐标。
6. 测试与发布 (Test & Release)
Q: 即使在 Beta 阶段，软件也能运行吗？A:是的。我们发布了v0.8.0-beta版本。
Q: 用户反馈如何？A:我们邀请了 5 位资深玩家进行测试。
好评：“终于不用手动记账了，识别很准。”
差评：不支持非16：9，4：3以外的屏幕（这是我们在下一阶段必须优化的重点）。
7. 总结与下一步工作 (Conclusion & Next Steps)
| 成员 | 角色 | Beta 阶段主要贡献 | 自我评分 |
| 成员 A | 核心开发 | C++ 截屏与 Python OCR 的桥接，性能优化 | 9/10 |
| 成员 B | 算法工程师 | 训练/微调 OCR 模型，提升特殊字体识别率 | 9/10 |
| 成员 C | 产品/UI | 设计交互界面，收集用户反馈，测试用例编写 | 9/10 |
)
