耍起最队｜StudyDay Alpha 冲刺 Day 3

目录

一、站立式会议

实际时间： 2026.10.26 20:00
地点／方式： 腾旭会议
实际参会成员： 黄思哲 柯镇海 范敬翔 郑宇澄 黄思杨 胡加乘

当天会议照片：

实际讨论与结论：

今天的会议主要围绕昨天联调中暴露的问题展开：登录态失效后的统一处理是否落地、任务接口与课程数据的字段是否对齐、AI 流式返回的中间状态是否区分清楚。各成员汇报了昨天会议后的工作进展，确认首轮冒烟测试发现的问题已全部归入 Issue，并把剩余工作拆成了 Day 3 可以验收的最小任务。

二、项目燃尽图

本日燃尽图：

本次计划基线： 45；实际剩余：40.5；统一单位： 任务包。

范围或估算变化说明： 无

本包初始计划参考来自56项日任务包，本次采用的单位与基线以统一燃尽数据为准。图中实际值只使用已提供记录，未来点和缺失点留空；不将理想线或每日4小时容量当作实际剩余。更换口径时提供新基线和原因，统一更新各篇，不与旧单位直接拼接。

三、今日进展总览

当日计划主线（目标）： 任务到专注、AI回答保存到确认笔记的最小流程。

材料支持的本阶段进展：

Day3承接Day2的认证、课程、任务与会话基础，开始准备任务到专注和回答转笔记两条流程。前端截图可见倒计时、提前结束、状态核查和历史空态，但明确标注模拟接口与刷新重置，只证明页面及交互。后端新增专注start/active/finish/history（03161443）、笔记/预览（2162bafe），修正版本保存时间（70dece52）。当前还有明确阻塞：后端SendMessage返回JSON完整ChatMessage，前端按SSE读取并等待saved，双方契约尚未对齐。因此材料支持分端代码与模拟演示成果，不能写成真实MySQL、模型或专注结算已验收；Day4先对齐接口，再检查实际保存、刷新与重复请求。 补充工作项材料：本阶段可核对7个唯一Task（含明确归属本日的跨图条目），图示状态均为“已解决”；只作为任务管理记录，不代替运行验收。

实际验收或测试结论：

可核实后端专注与笔记预览相关提交、测试文件/入口及前端模拟专注界面。两张前端图没有已结束的真实专注记录，不能据此认定刷新恢复、单RUNNING、一次结算或笔记事务已在目标库通过；后端“验证通过”卡片也不提供具体测试范围。真实模型回答、笔记确认后刷新读取及跨账号隔离仍需实际运行结果。本次补做的简单检查应另列执行日期与版本，不倒填为Day3当日测试。真实AI接口存在明确协议差异：backend/internal/handler/chat.go的SendMessage返回JSON完整ChatMessage，而frontend/src/api/chat.js按responseType:sse读取，前端不会把普通JSON当作saved事件。这是当前代码可定位的联调阻塞，不能仅凭双方各有接口认定全链路通过。 后端Go已在2026-10-29补测：五个业务包9个顶层用例通过、0失败；本日主题“专注与笔记创建”对应3个通过。为当前main的本地/Mock测试，不倒填为历史当日或真实联调结果。

代码/配置截图与真实运行/测试结果分别填写。共同模块可由多位成员引用同一证据ID；不要求每个人重复上传同一张截图，非编码工作可用文档、用例或测试结果证明。

本日代码与展示材料

前端模拟界面展示：

证据ID：D3-FEBASE-RUN-01；版本：归档Day3，未核对构建哈希；环境：前端本机模拟/测试；结果：模拟/内存展示，不证明真实API、MySQL持久化或用户隔离。

证据ID：D3-FEBASE-RUN-02；版本：归档Day3，未核对构建哈希；环境：前端本机模拟/测试；结果：模拟/内存展示，不证明真实API、MySQL持久化或用户隔离。

后端提交与代码差异：

证据ID：D3-BEBASE-CODE-01；版本：归档Day3，未核对构建哈希；环境：CodeArts仓库页面；结果：代码与协作记录；累计差异不是当天工作量，平台验证标记不代替业务测试结果。

证据ID：D3-BEBASE-CODE-02；版本：归档Day3，未核对构建哈希；环境：CodeArts仓库页面；结果：代码与协作记录；累计差异不是当天工作量，平台验证标记不代替业务测试结果。

仓库版本与新增代码核验

仓库入口；前端阶段 frontend-d3 / f839ba7ce57f2722127f6edf6dd5221ac7c696fb；后端阶段合并 58c673fa04ed3798e35e5a953343e3c061eb97c9。链接是仓库入口，请按SHA查询，未猜测精确提交网页地址。

本阶段后端新增：专注开始/active恢复/结束/历史API；1-120分钟、本人TODO任务、标题/类型快照；单RUNNING生成列唯一键、重复结束返回首次结果；笔记/标签/预览API；来源成功回答校验；笔记+初始版本同事务。

后端新增提交：

• 0316144375ad147b3cbc6eddf418cb397f41f876 — feat(backend): add focus start, active, finish and history APIs
• 2162bafebcc648d5e7598c839364424ad862caa5 — feat(backend): add notes, tags and note preview APIs
• 70dece527c56c7611d38e9017ecdf0dc7668afee — fix(backend): set note version saved time explicitly

源码定位：backend/internal/service/focus/service.go、backend/internal/db/focus/focus.go、backend/internal/service/note/service.go、backend/internal/handler/focus.go、backend/internal/handler/note.go、backend/deploy/sql/init.sql。前端以对应阶段标签为准；图片按用户归档使用，不能以界面样式反推构建版本。

当前联调问题： backend/internal/handler/chat.go返回JSON完整消息，而frontend/src/api/chat.js要求SSE。模拟/HTTP夹具检查没有消除该差异，需统一协议后验收真实问答及转笔记。任务创建、专注开始也不能笼统记为所有写接口均已有请求级去重。

简单测试展示（本次补充复核）

以下仅展示与本日主题相关的一个短检查，导入仓库实际业务函数。5段均为2026-10-29对main 5e328697的补充复核，不是各阶段旧提交的当日运行；完整脚本和日志见资料包测试/。

test('D3 checkpoint: focus remaining uses server anchor and is never negative', () => {
  const active = { plannedEndAt: '2026-10-29T10:25:00+08:00' };
  const serverMs = Date.parse('2026-10-29T10:00:00+08:00');
  assert.equal(remainingSeconds(active, serverMs, 10000), 1490);
  assert.equal(remainingSeconds(active, serverMs, 2000000), 0);
  assert.equal(remainingSeconds(null, serverMs), null);
});

本次新增检查5/5通过，选跑已有前端检查55/55通过；限本机业务函数、契约与模拟层，不证明真实Go服务、MySQL、模型和云端联调。后端Go现已补测9个顶层用例，结果见下节。

后端Go简单补测

本次实际使用 Go1.26.10 / windows-amd64，对main 5e328697及新增JWT测试进行补充复核。5个业务包、9个顶层测试通过，0失败，退出码0。 本日按主题展示“专注与笔记创建”：TestStartFocus、TestFinishFocus、TestCreateNote，共3个顶层用例通过。

检查内容：默认25分钟、自定时长、无效任务/时长及已有RUNNING分支；提前/到时结算、未到时拒绝正常结束、重复结束返回已存结果；笔记标题规范、初始版本、成功回答摘录、外来来源/标签拒绝。测试方式：Service + Mock DAO/事务。

下面为已执行用例的核心断言节选，省略测试函数、夹具及部分分支；来源：backend/internal/service/focus/service_test.go。

focus, err := svc.Start(context.Background(), 7, 5, tc.minutes)

if tc.wantCode == 0 {
    assert.NoError(t, err)
    assert.Equal(t, uint64(55), focus.ID)
    assert.Equal(t, tc.wantPlan, focus.PlannedSeconds)
    assert.Equal(t, "写随笔", focus.TaskTitleSnapshot)
    assert.Equal(t, model.FocusRunning, focus.Status)
} // 其余断言及失败分支省略，完整代码见对应测试文件

复现命令（在仓库backend目录，先按附带说明加入补充JWT测试）：

go test -mod=readonly '-gcflags=all=-l -N' -p=2 -parallel=1 -count=1 -timeout=90s -json -run '^(TestHashAndVerifyPassword|TestVerifyPasswordRejectsMalformedHash|TestSupplementaryJWT|TestCreateTask|TestStartFocus|TestFinishFocus|TestCreateNote|TestCreateNoteIsIdempotentPerSource|TestOverviewToday)$' ./internal/service/auth ./internal/service/task ./internal/service/focus ./internal/service/note ./internal/service/stats

完整结果：测试/Go/selected-go-tests.jsonl、测试/Go/Go_简单复核说明.md。这些是2026-10-29本次补测，D1—D5仅为展示主题分组，并非对旧阶段提交逐日重跑。DAO已Mock；真实MySQL约束/并发、HTTP联调、真实模型、JSON/SSE适配及华为云未在本次验证，已有联调问题继续保留。

四、成员进展

工作项看板记录

本阶段可核对7个唯一Task，图示状态为“已解决”。

证据ID：D3-ISSUE；版本：用户新增Issue截图；环境：CodeArts Task列表；结果：按可见ID、处理人和阶段登记，不推断未展示的正文或工作项深链。

五、明日计划（Day 4）

先共同对齐问答JSON/SSE及保存确认契约，再用真实模型与数据库复测成功、失败、重试和转笔记；未对齐前不宣称AI端到端打通。Day4在同一候选版本上检查课程到学习任务、专注恢复/历史及AI成功回答到正式笔记两条流程。优先补真实API、JWT、MySQL和模型运行证据，对未具备环境的项目保留未执行；修复登录限制、重复确认和必要页面阻塞，不扩展长期记忆或完整编辑器。

六、AI技术员工作情况

场景一：后端AI程序员——解释JSON与SSE不一致的具体断点

遇到的问题： 当前后端SendMessage返回JSON完整ChatMessage，前端chat.js却按SSE读取并等待保存确认。即使服务返回文字，界面也未必承认已保存，不能据双方各有接口宣布AI链路打通。

向AI提问的具体示例： “这是Gin的SendMessage和前端responseType为sse的调用。为什么HTTP 200仍不能进入转笔记？我们先交Alpha最小链路，请比较统一为JSON完整返回和真正实现SSE两种方案，给出保存确认、失败、重试的验收点，不直接替我们改代码。”

AI给出的答复： 普通JSON不产生SSE的saved事件，应先共同选择一种契约。最小JSON方案需同步解析结果和保存状态；若选SSE，则真实发送约定事件并在持久化成功后确认。不能把收到文字或delta当保存成功，响应丢失先查原请求，再决定重试。

成员如何采用并验证： 胡加乘与黄思哲可逐项核对响应结构，范敬翔协助确认持久化边界；再同赵子龙冻结样例。对齐后用真实模型和测试库检查成功、保存失败、断响应与同请求恢复，随后检查笔记和初始版本同事务；未改前保留阻塞状态。

对效率的具体帮助： 把问题定位到响应协议与保存状态，可避免三人分别修改弹窗、超时或数据库却始终绕不开真正断点。

场景二：前端AI界面助理——让专注恢复和转笔记保持原操作意图

遇到的问题： 杨伟烨要接专注开始和结束，赵子龙要接确认笔记，黄思扬要传课程参数。刷新、返回和重试一旦各自重建状态，就可能重复开始或重复保存。

向AI提问的具体示例： “用户从TODO开始专注后刷新，随后结束响应丢失；另一个用户编辑转笔记预览后取消。请分别列前端应该读什么、不能发什么，说明服务端计时和任务完成边界；课程跳转也必须复用原任务表单。”

AI给出的答复： 刷新只查询当前专注并恢复原ID，不能再次调用开始；结算依据服务端时间与状态，不能靠浏览器倒计时宣告正常结束。结束不自动完成任务。笔记取消不发创建，确认中防重复，失败保留原内容与请求意图；课程只预填同一STUDY表单，LIFE不能带课程。

成员如何采用并验证： 三人可先画状态转移表，再用夹具检查请求次数与参数；切真实接口后比较刷新前后的focusId、首次结算秒数及笔记数量。区分正常到时与提前结束，历史记录应保留开始时的必要快照，再单独检查真实数据库中的恢复结果。

对效率的具体帮助： 先规定“刷新只读、重试查原结果”，可减少页面互相跳转时重复造记录，也能让前后端围绕同一ID排查。