耍起最队｜StudyDay Alpha冲刺总结——从页面原型到阶段交付

本轮冲刺开始前，StudyDay已经有需求文档、设计说明和页面原型。本轮开发把课表、学习/生活任务、专注、AI问答与确认笔记接入同一套工程，并形成了可以用于阶段展示的页面、接口、运行材料和使用说明。

Alpha阶段的重点是把最常用的操作接起来：从课程进入学习安排，记录一次专注；再把问答中有价值的内容整理为自己确认保存的笔记。围绕这些操作，我们经历了工程准备、分组开发、接口对齐、问题修复和交付整理，也看到了后续仍需补充的功能与验证工作。

目录

一、预期计划与实际进展

1. Alpha阶段原本计划完成什么

本轮按七天、八人安排工作，每人每天一个主要交付，先保证基础功能和两条演示流程，再用后半程处理联调、测试及展示。完整需求继续作为后续开发基线。

本轮沿用Vue 3＋Vite前端、Go＋Gin＋GORM后端和MySQL。后端按Handler、Service、DAO组织：请求解析、业务规则和数据访问分别维护，外部AI通过客户端适配接入业务服务。

2. 七天如何推进

图1：七天开发与交付路线：原计划重点和实际阶段成果。

Day为开发材料中的相对阶段。本篇按阶段代码与交付材料回顾，不将后续补测写成历史当天执行。

3. 原计划与最终交付对照

两条演示流程与本轮工程材料已经形成，完整产品能力仍按上述范围逐步开发。

二、阶段成果展示

下面先按操作顺序看页面，再说明背后的规则。运行图来自仓库docs/alpha/assets/的Alpha综合演示归档，不按截图张数计算工作量，也不将其称为Day6/Day7独立新增页面。

图2：Alpha两条核心演示流程。

1. 流程A：从课程安排进入任务与专注

第一步：在课表中查看课程。

课程信息集中展示后，用户可以进入课程详情，查看当前课程并进入学习任务创建入口。这让课程安排和待办事项有了可操作的连接。

图3：Alpha综合运行：周课表与课程安排。

图4：Alpha综合运行：课程详情及学习任务入口。

第二步：创建任务，并体现学习/生活差异。

学习任务可以选择本人课程，也允许不关联课程；生活任务不关联课程。分类会影响表单字段、请求参数、服务端校验与列表筛选。现有运行图展示学习任务带入课程的结果；生活任务带课程的非法输入已在后端选定单测中检查。

图5：Alpha综合运行：学习任务表单带入课程。

第三步：开始专注，结束后查看历史。

本轮从待办任务发起专注，一项任务可以积累多条专注记录。一次专注结束后，任务是否完成仍由用户另行确认。记录保留执行时的信息，便于之后回看本次任务与时长。

图6：Alpha综合运行：提前结束专注，显示29秒及历史记录。

这张运行图中，专注编号2从17:24:23到17:24:52，结算为29秒，页面同时提示任务需要另行手动完成。它展示了提前结束后的界面结果；一次结算、时间边界等规则另由测试核对。

2. 流程B：从AI问答到自己的学习笔记

第一步：提问，并等待回答保存确认。

聊天界面区分生成状态和保存状态。用户看到完整文字以后，仍需要收到保存确认，才开放转笔记入口。这样可以让后续笔记引用到已有的回答来源。

图7：Alpha综合运行：AI问答与回答保存确认。

第二步：预览和整理，保留用户的决定。

进入转笔记后，标题和正文可以先修改。预览是草稿，用户可以取消；确认才进入正式创建流程。AI给出内容后，最终保留什么由用户决定。

图8：Alpha综合运行：可编辑的转笔记预览草稿。

第三步：确认后查看正式笔记。

正式笔记显示正文、内容版本1和来源摘录，便于复习时了解内容来自哪次回答。本轮先完成创建、列表与详情，后续再逐步增加编辑和版本管理页面。

图9：Alpha综合运行：正式笔记详情、版本1及来源摘录。

3. 如何查看和复现本轮成果

演示材料采用本地Compose及Chrome 390×844视口。运行时按仓库说明配置测试环境，模型密钥保留在后端。本文不公开演示口令或访问令牌。

三、开发过程与问题复盘

1. 从“各模块有代码”走到“接口能够对接”

本轮比较有代表性的工作集中在接口约定上：页面使用的请求格式、后端读取的字段、AI返回方式和分页信息，都需要在同一流程中核对。

D6的6ea98815对应契约对齐，693688e6对应配置挂载，c68d9b84对应回归脚本。MR !13、!14可核对胡加乘提交、柯镇海审核合并的过程。

图10：D6合并请求：契约修复及容器配置交接。

这些修复也给下一轮留下了具体做法：公共接口修改时，同时更新样例、调用方与测试。参数能够被某一层接受以后，还要继续检查业务含义、保存结果及页面反馈。

2. 任务、分支与材料怎样衔接

团队按业务对接：课表前后端、任务/专注前后端、AI/笔记前后端分别协作；公共路由、请求和错误反馈由公共工程维护。模块之间的接口变化通过字段对照和问题清单同步。

仓库采用功能/修复分支及MR协作，提交信息按约定描述变更。涉及公共请求、统一响应或配置的改动，需要通知相关模块。发生冲突时，先确认共同基线和文件职责，再对照业务规则处理，合入后重跑相关检查。

图11：D7工作项列表：阶段任务管理记录。

D7截图可见8条工作项均处于“已解决”状态。工作项、提交、测试和演示材料各自记录不同侧面：列表状态用于核对任务管理，功能是否达到预期还需结合代码与结果判断。总结中的个人职责沿用团队分工，具体代码作者以Git/MR记录为准。

3. 测试为本轮交付提供了什么

后端补测涵盖学习/生活任务限制、专注开始与结算、SSE事件、AI生成/保存失败、笔记来源及重复确认等规则。前端检查包括等待saved后才能转笔记、读取失败重试及恢复已有专注等状态处理。

D6/D7原博客中的12项Go是当时的补测结果，后续测试随笔又补了6个不同用例，当前汇总为18项。历史D5截图中的92项对应旧前端版本与成员记录，本篇55项是0.5.2选跑范围，分别保留。

Mock和本机夹具帮助快速核对规则，真实数据库、模型供应商、代理和云主机仍需相应环境中的记录。我们没有将本轮通过数换成覆盖率、并发承载量或完整安全结论。

4. 用燃尽图回看计划偏差

图12：截至Day7的项目燃尽图，代码与材料回溯估算口径。

这张图续接前五天的统计口径：原计划按7天、8人形成56个任务包，灰线为理想剩余，橙线为代码与交付材料回溯估算。Day0—Day7估算余额依次为56、50、45、40.5、33、27、19、8。

后两天补齐接口和交接材料后，前面部分未闭合的工作才能补计，曲线因此继续下降。它提示我们：分组开发之后，需要为跨模块联调和材料整理留出明确时间。

Day7的8个折算值包含原计划中未充分核验或未闭合的部分，不能按8个缺陷理解。Alpha核心流程已阶段交付；真实库并发、模型/云端及完整独立验证等后续工作仍保留。该图是粗粒度回溯估算，实际逐日工时未据此推定。

四、成员分工、协作与收获

1. 八人的职责及协作关系

本轮后端由胡加乘统筹，前端由杨伟烨统筹，柯镇海负责项目协调与集成。范敬翔、黄思哲分别围绕数据/任务专注和AI会话协作；赵子龙、黄思杨分别维护AI笔记和公共前端/课表；郑宇澄整理测试与质量记录。

一个典型协作点是转笔记：AI后端提供成功回答和来源规则，笔记服务处理正式创建与初始版本，前端区分保存、预览与确认，测试再检查来源、重复确认和失败状态。相关职责需要在同一操作流程中对齐。

2. Alpha阶段工作量比例

以下比例由项目负责人提供，作为本轮综合工作量分配，合计100%。开发、联调、测试、文档与组织工作均属于团队贡献，不按提交次数或燃尽图估算分自动换算。

图13：Alpha阶段成员工作量比例，项目负责人提供，合计100%。

3. 各成员的收获与心得

下列心得按岗位和本轮过程整理，供成员核对后作为个人总结使用。

4. 团队协作中需要继续改进的地方

接口要早点共同验证。 字段表和样例能够帮助并行开发，但还需要选一条实际请求，检查发送、接收、业务处理和页面状态。下一轮将公共接口变更纳入对应测试。

把“完成”写得更具体。 “页面完成”“接口完成”很难说明交付程度。后续工作项会明确数据来源、前置条件、操作步骤、预期结果和验证环境。

公共部分减少多人同时修改。 请求封装、路由、认证和公共配置影响范围较大。维护者先同步变更意图，业务模块再按同一约定接入，有助于减少合并冲突和重复实现。

过程材料随开发保存。 版本、工作项、请求结果和运行图在产生时记录，收尾就更容易找到对应关系。下一轮将把记录要求写入任务验收点。

五、AI技术员在整个冲刺中的表现

1. AI在哪些环节提供帮助

本轮围绕AI程序员、前端助理、测试助理和项目记录助理设计辅助工作。已有七天AI问答场景稿提供了可复用的提问方式；其中属于情境示例的部分不作为真实聊天逐字记录。能够在本次协作中核对的代码检查、补测、结果分析和文档整理，分别保留了实际材料。

2. 三个具体场景

场景一：AI协助定位问答保存状态的断点。

可复用的提问方式是：“前端按SSE等待saved，后端返回JSON，为什么已经看到回答却不能转笔记？请沿请求、服务保存和页面状态检查。”对照代码后，问题可以定位到返回协议与保存确认，而不必先改动整套聊天页面。D6随后形成契约修复及对应测试，最终结论以实际提交和用例为依据。

场景二：AI协助整理任务与专注的边界。

将“学习可选课程、生活不能带课程”“提前结束按实际时长”“结束专注不自动完成任务”等规则交给AI，能够快速列出需要检查的输入和状态。成员需要继续核对需求，避免接受不符合本轮规则的建议。本轮选定测试已经覆盖生活带课程、已完成任务开始专注、重复结束等场景。

场景三：AI协助执行测试并整理结果。

测试随笔整理阶段，AI助理依据已有代码和报告，先汇总同版本12项Go与55项前端选跑结果，再补跑6个不同Go用例，保留JSON/TAP日志。汇总时区分成员回归记录、Mock逻辑和真实环境验证，减少重复查找测试名、命令与统计结果的工作。

3. 对贡献的评价与下一阶段用法

AI在代码阅读、边界枚举、重复整理和日志分析上提供了帮助，团队可以把更多精力放在业务规则、接口选择和实际操作上。本轮没有记录可审计的节省工时，因此不填写“效率提升百分比”。

同时，AI不了解全部现场条件。建议生成的代码和用例仍需评审，模拟数据、手册预期和实际运行结果也需要区分。模型调用费用、密钥和个人学习资料应由团队控制。

下一阶段计划这样使用AI：

1. 每次公共接口修改，要求AI同时列出调用方、受影响状态和建议回归项，供维护者核对。
2. 把已确认缺陷的复现步骤交给AI生成用例初稿，人工核对后执行并入库。
3. 为真实模型保留少量成功/失败检查，其余重复逻辑优先使用可控依赖，控制费用。
4. 用AI整理“规则—代码—测试—运行材料”的对应关系，缺少结果时明确保留空项。
5. 记录采用了哪些建议、怎样验证及是否返工，逐步形成实际可评价的AI使用经验。

六、下一阶段展望与答辩材料

1. 先稳定现有流程，再扩展功能

上述为后续迭代顺序，具体日期和容量在下一轮计划确认，避免在尚未稳定时继续扩大并行范围。

2. 答辩PPT与项目入口

答辩PPT及项目材料入口：StudyDay代码仓库

本次统一使用代码仓库作为答辩材料入口。展示顺序建议为：本轮目标与计划对照 → 两条运行流程 → 代表性问题和修复 → 测试与燃尽图 → 成员协作和工作量 → 后续安排。

七、阶段回顾

本轮已经把课表、任务、专注和问答笔记组织成可用于Alpha展示的一套工程。过程中值得保留的做法，是把有分歧的业务规则写成测试，把接口变化落实到调用与响应，再把版本、运行材料和使用说明一起交接。

下一阶段将优先补真实环境验证、稳定性和恢复，再逐步完善管理页面、统计、提醒及记忆能力。七天留下的代码、用例和过程材料，会继续作为后续迭代的基础。

资料索引

• 作业要求。
• 已发布的前五天随笔：Day1、Day2、Day3、Day4、Day5。本篇同时依据后续补全的七天开发记录及源码整理。
• 代码、答辩材料与阶段文档入口。
• 仓库内：docs/alpha/演示手册.md、docs/alpha/阶段交付说明.md及docs/alpha/assets/。
• 本篇配套材料：成员工作量数据、测试结果索引、版本及图片来源清单。