目录

一、站立式会议

参会成员：周蔚琳、刘嘉奕、柳钰舒、黄奕、郑聪凌、刘锐清、林彩华、汤文琪、AI 技术员

会议照片：

二、项目燃尽图

燃尽图：

三、昨日至今进展总览

Day6 是 α冲刺的第六天，主线任务是「检索 + 正文读入（上）」——把外部检索引擎和文档正文抽取接进分析流水线，让"目标输入→四段分析"从 mock 走向真实可用。同时，团队集中清理了前期攒下的一批登录态演示残留，并对 Day5 刚交付的 FSRS 复习调度做了一轮功能完整性核查与收尾修复。专职测试今日跑出 4 个问题，分两组归属到不同阶段的验收遗漏。

3.1 检索 + 正文读入（主线任务）

• 检索引擎切换：主引擎从 Tavily 换成博查 AI Search（国内直连），Tavily 降级为备用。降级链设计为「博查 → Tavily → 仅检索词」，任何引擎故障都不卡住主流程，绝不编造假链接。
• 文档读入扩展：readers 服务升到 0.3.0，新增 read_doc.py，支持 PDF / Word / PPT 三种格式的正文与表格提取，不识别的格式安全排除。
• 端到端验证：真实链接 → 存活检查 → 正文读入 → 落库 body_ready=true，全链路跑通。

3.2 FSRS 复习调度收尾（Day5 遗留问题）

• 原因句规范：固定原因句句末去掉多余句号，且只有"还糊"评分才返回原因句，"还熟"不再误返回还糊原因句。
• 还熟也排复习日：修复标"还熟"时 reviewDate 写死为 null 的问题，现在还熟也走 FSRS 调度排复习日，只是不附原因句。
• 前端手动掌握按钮：任务详情页新增「未标记 / 还熟 / 还糊」三个按钮，用户可以手动切换掌握状态。
• 到期复习显示原因句：今日面板的到期复习条目下方，新增显示完整原因句原文。
• 类型修复：Pydantic review_reason 改为 Optional，修复非 again 时返回 None 导致的 500 错误。
• 阶段测试标准恢复：阶段测试通过标准恢复为说明书要求的 2/3（不足一题向上取整）。

3.3 登录态演示残留清理

• **首帧不再闪现"林知"**：顶栏登录刷新先显示中性占位（头像 + "加载中"），/me 返回后再渲染真实身份。
• 登录态不再闪现示例计划：甘特图首帧不再预填原型种子（"掌握 Rust 异步编程"等），登录态下加载中显示"正在加载计划"。
• **修复"提示成功但画面不动"**：接口响应漏拆 { subtask } 包装层导致的改期、打卡、掌握度不即时刷新问题，已统一修复。
• 全站日期切换为真实当天：前端"今天"从硬编码 2026-10-15 切换为真实日期，访客种子按相对偏移平移。
• 甘特图重构 + 归档概念删除：甘特筛选改为"全部并排 + 弹窗选单切换"，删除整套"归档"概念，后端新增自动毕业判定。

3.4 其他修复

• 对话记录按身份持久化：自由对话切页后丢失的问题修复，记录按访客 id / 用户 id 分开存储，先读后写避免空列表覆盖。
• AI 导入防重复：导入学习计划库按钮加进行中锁与禁用态，成功后显示绿色完成卡片，避免连点重复建计划。

3.5 今日测试发现

专职测试今日跑出 4 个问题：

• Day5 阶段核对联动验收遗漏（问题 1、2）：登录态通过 / 跳过层级测试后，天梯仍显示"本层未测"——根因是视图层 tests 数据写死为空对象，服务端核对结果没有路径映射回前端。
• Day2/Day3 额度体系连带问题（问题 3、4）：登录用户额度显示裸"0 次"语义断裂，访客走完分析导入后额度仍为 0——根因是服务端 ai_generate_count 字段无递增逻辑，实际拦截用的是前端内存计数，两套体系互不相通。

四、成员进展

AI 技术员工作情况（单独表格）

五、代码签入与测试结果记录

代码签入记录

提交记录截图：

工作项（Issue）

工作项列表截图：

测试等其他工作结果

2026-10-28 对 web 工程做了一轮功能测试。测试环境：本地 npm run dev（localhost:3000），访客演示模式（未登录，前端回退 mock 数据），Chrome 浏览器，视口 1440×900。发现 4 个问题：

问题1：登录用户完成并通过 L1 层级测试后，天梯上该层仍显示「本层未测」

冲刺归属：Day 5（10-27）FSRS 复习调度。层级综合测试在登录态下的完整链路是「拉取核对项（listChecks）→ 提交核对（submitStageCheck）→ 服务端按知识点回写熟/糊并进入 FSRS 调度」，这正是 Day 5 冲刺计划里「阶段核对联动」交付的内容，服务端这一半是完整可用的；缺的是联动的另一半——「核对结果 → 天梯状态展示」从来没有接上。

复现步骤：以普通用户登录 → 进入「历阶天梯」（或今日看板）→ 把 L1 的所有知识点逐个标记完成，点亮 L1 后出现「开始测试」按钮 → 点击「开始测试」，答题后点击「提交测试」，达到通过线（≥67%）→ 评估面板提示通过 → 关闭弹窗，回到天梯页观察 L1「通关测试」行的状态标签。

预期行为：评估面板提示通过后，天梯上 L1 通关测试行的状态标签应变为「本层已过 XX 分」；后续 L2 及以上层级的解锁判定基于该结果推进，刷新页面后状态保持。

实际行为：评估面板明明显示「✓ 本层已通过，下一层测试已解锁」，天梯上 L1 的通关测试行却仍显示「本层未测」；刷新页面、重新登录都不会变化。对照实验：同样的操作在访客（未登录）模式下做完，状态标签能正常变为「本层已过 XX 分」——同一条业务链路在两种模式下一个正常一个失效。

根因分析：登录态下「层级测试结果」在前端视图层没有数据来源，是典型的对接断层，分三层看。第一层，展示层读的是 plan.tests：LevelTestRow.tsx 通过 levelTestOf(plan, level) 取状态渲染标签，而 derive.ts 的 levelTestOf 从 plan.tests[l] 取值，取不到就回落到 { status: 'untested' }——于是永远显示「本层未测」。第二层，登录态的 tests 永远是空对象：helix.ts 的 toHelixPlan 把 API 计划映射为视图计划时，写死 tests: {}；后端 /api/tasks 返回的 ApiTaskRow 只带 subtasks 与进度，不携带任何层级核对结果，所以无论 reload 多少次 tests 都是空的。第三层，提交链路只写了服务端、没有回写视图：LevelTestModal.tsx 登录态提交走 submitStageCheck，成功后只调 onResult(true)（实现就是 reload）；服务端 stageChecks.ts 其实把该写的都写了——stageChecks.result 置为 passed、逐知识点回写 mastery 与 FSRS 状态、解锁下一层、taskTraces 记录 stagePassed = true——但这些结果没有任何一条路径映射回前端的 tests 结构。连带影响不止状态标签：derive.ts 的 levelUnlocked / firstBlockingTestLevel 同样基于 plan.tests 判定，登录态下恒为 untested，导致 L1 通过后 L2 的通关测试行仍显示「🔒 需先过 L1 测试」，L2 台阶的打卡与进入仍被前端门禁拦截——与服务端已解锁的事实正好相反。

修复建议：把核对结果接进视图数据层，改动集中在映射一处。数据侧，现有接口已经够用——/api/tasks/:id/checks 返回的 ApiCheck 自带 level 与 result，可以在 useAppData 的首次加载与 reload 里对每个计划并行拉取一次 listChecks，把各层 result 映射进 tests[l]；展示侧，toHelixPlan 接收核对结果参数来构造 tests，替换写死的空对象。映射接通后，levelTestOf / levelUnlocked / firstBlockingTestLevel 三个派生函数对登录态自动生效，状态标签与 L2+ 的解锁门禁一并恢复，展示组件不需要再动。

问题2：登录用户点击「跳过测试」后提示「已跳过」，天梯上该层仍显示「本层未测」

冲刺归属：Day 5（10-27）FSRS 复习调度，与问题一同源。跳过测试在登录态下走的也是「submitStageCheck 提交 → 服务端解锁下一层」这条 Day 5 交付的阶段核对链路，服务端同样正常落库；状态不显示依然是「核对结果 → 天梯状态展示」映射缺失所致。

复现步骤：以普通用户登录 → 进入「历阶天梯」→ 把 L1 的所有知识点标记完成点亮层级 → 点击通关测试行上的「跳过测试」按钮 → 观察 toast 提示与 L1 通关测试行的状态标签 → 刷新页面再观察一次。

预期行为：跳过后天梯上 L1 通关测试行的状态标签应变为「本层已跳过」，L2 及以上层级随之解锁，刷新页面后状态保持。

实际行为：toast 正常弹出「已跳过 L1 测试：L2 已解锁」，但 L1 通关测试行仍显示「本层未测」；刷新页面后依旧是「本层未测」，L2 也仍处于锁定状态。

根因分析：与问题一是同一个断层，只是走的是跳过分支。Ladder.tsx 的 skipTest 在登录态下调 listChecks 找到本层核对项后 submitStageCheck 提交，成功即 reload() 并弹「已跳过 L1 测试：L2 已解锁」；服务端 stageChecks.ts 也正常解锁了下一层并记录 stagePassed = true。但正如问题一根因第二层所述，helix.ts 的 tests: {} 写死为空，reload 拉回的数据不携带任何核对结果，levelTestOf 永远回落「untested」——跳过结果同样没有路径映射回 tests[l].status = 'skipped'。需要特别指出的一点：跳过在服务端是以「全对提交」近似的，落库的 result 与真实通过完全一样都是 passed——也就是说，即使按问题一的修复方案把核对结果映射进 tests，跳过也只会显示成「本层已过 100 分」而不是「本层已跳过」，跳过与通过在天梯上仍不可区分。

修复建议：以问题一的数据映射修复为前提，增量工作只剩「跳过语义的落库与映射」。提交侧，跳过时在请求中带上类型标记，服务端把跳过落成独立的 result 值（如 'skipped'）而不是与通过混用 passed，解锁下一层的逻辑保持不变；映射侧，toHelixPlan 构造 tests 时把该值对应写为 status: 'skipped'，天梯标签即可显示「本层已跳过」。

问题3：登录用户的「分析额度」显示「0 次」与访客的「0 / 3」语义断裂，且账号浮层在登录态下仍保留访客页签

冲刺归属：Day 2（10-24）前后端基本搭建。账号浮层与 users 表的 ai_generate_count 额度字段都是 Day 2 交付的内容，两个子问题的缺陷本体都出在 Day 2 复刻期「形似而神不似」：页签结构照搬原型、没有按登录态裁剪；额度字段只做了「有列、有展示」，没有设计递增逻辑与展示语义。

复现步骤：以访客（未登录）状态点击右上角头像，观察访客卡片上的「分析额度」→ 注册/登录一个普通用户 → 再次点击头像，观察「我的账号」卡片上的「分析额度」与浮层顶部的页签行。

预期行为：登录用户的额度展示应与访客同构且语义明确（如「已用 X / 3」或「不限次」），不应出现让人误读为「没额度了」的裸数字；已登录用户的账号浮层不应再呈现「访客 / 登录 / 注册 / 找回密码」这套访客语境页签，更不应能一键把当前会话切换成访客。

实际行为：访客卡片显示「0 / 3」（带进度条，能看出还剩 3 次）；登录用户的卡片只显示「0 次」——既没有总数也没有「已用」说明，看起来就像额度为零、什么都不能用。同时浮层顶部仍完整保留「访客 / 登录 / 注册 / 找回密码」四个页签（均未选中），「访客」页签可点击，点击后卡片切换为「访客空间 · 数据保存在本机浏览器」，并且当前会话会被真实切换成访客账号。

根因分析：先说结论——「普通用户额度为 0」不是扣错了账，而是两套互不相通的额度体系加上语义断裂的展示叠加出来的观感。第一层，展示端：账号浮层的访客卡片把服务端返回的 user.quota.aiGenerateCount 渲染成「X / 3」带进度条，而已登录卡片把同一个字段渲染成「X 次」——这个字段的语义是「已用次数」，访客卡片有总数做上下文所以读得懂，登录卡片只剩裸数字，0 就被读成了「没额度」。第二层，数据端：全服务端没有任何代码递增这个字段（只有建列默认 0、seed 置 1、/api/auth/me 原样返回），所以它永远是 0——展示的数字从一开始就不反映真实用量。第三层，真正的额度拦截在另一套体系上：AI 助手导入计划前的判断读的是原型 seed 的演示用户 seedState.user（内存态 quota.used/total），导入成功后 bumpQuotaUsed 给这个内存计数 +1，刷新页面即清零；且该判断不区分登录态——登录用户同样被这个「访客额度」拦截。也就是说：卡片上显示的是服务端恒为 0 的已用计数，实际生效的是前端内存里清零即重置的原型额度，两者互不相通。

修复建议：两个子问题分开修。额度侧，正解是把额度体系统一到服务端：在服务端扣减/校验（创建并导入计划时校验上限并递增 ai_generate_count），前端删掉 seed 内存拦截，改为依据 /me 返回的 quota 判断；展示端把登录卡片改成与访客卡片同构的「已用 X / 3」加进度条，杜绝「0 次 = 没额度」的误读。页签侧，登录态下隐藏「访客 / 登录 / 注册 / 找回密码」页签行，保留「退出到访客」作为唯一明确的身份切换入口并加二次确认。

问题4：访客与 AI 对话后，「分析额度」仍是 0，走了完整的新建计划分析后同样纹丝不动

冲刺归属：Day 3（10-25）大模型接入，与问题三连带。额度门禁是 Day 3 接入 AI 时挂在「新建计划的分析导入」这一步的，「自由对话不计次」也是接入时的隐式设计。

复现步骤：以访客（未登录）状态进入「AI 助手」→ 在「自由对话」里进行几轮对话 → 点击头像查看访客卡片的「分析额度」→ 再走一次完整的「新建计划 → 七步分析 → 导入学习计划」→ 再次查看额度并刷新页面。

预期行为：AI 调用若计次，额度应实时递增且刷新后保持；若对话设计上不计次，额度文案应明确计次范围，让用户知道「对话不动」是正常表现。真正计次的新建计划分析导入后，额度必须 +1。

实际行为：对话几轮后额度停在 0 不动；即便走完「新建计划 → 分析 → 导入」这条唯一设计了扣额度的路径，访客卡片依然是 0，刷新也不变——无论怎么用，这个数字永远不动。

根因分析：这个问题是问题三「两套互不相通的额度体系」在访客侧的完整表现，分两层。第一层，「对话不计次」是隐式设计而非漏扣：全组件只有一处额度扣减——AiAssistant.tsx 的 bumpQuotaUsed，挂在导入计划成功的 finishImport 回调里；额度门禁也只在新建计划的 start 入口判断；自由对话的收发链路完全不经过任何额度逻辑。也就是说「分析额度」在代码里只覆盖「新建计划的分析导入」，对话、出题都不计次——单看这是原型语义的延续，但界面上「分析额度」四个字没有说明计次范围，用户自然预期对话也扣次。第二层，「计次了也看不到」：即使走了真正扣额度的路径，被 +1 的也只是前端 seed 的内存计数，而访客卡片显示的是服务端 users.ai_generate_count（无任何代码递增，恒为 0）；顶栏的 user 对象只在页面挂载的 /me 和认证回调时更新，分析导入后也没有任何环节重新拉取——所以无论做多少次分析，访客卡片的数字永远停在 0，内存里的真实用量刷新即清零，两边永远不会对上。

修复建议：与问题三的额度统一方案一体实施，这里是「计次范围」与「展示联动」两个增量。计次范围：先定产品口径——「分析额度」只限新建计划分析（原型语义），还是对话/出题一并计次；按口径在服务端统一扣减与递增，前端删掉 seed 内存计数与拦截。展示联动：额度变动后同步刷新——最简单是导入成功等事件后重新拉一次 /me。文案：把「分析额度」改成明确的计次范围（如「新建计划额度」），对话不计次时加一句说明（如「自由对话不消耗额度」），避免「用了不动」再次被当成 bug。

六、程序/模块最新运行效果

今日项目整体运行正常，主要页面均可正常访问与交互。以下是各模块今日最新效果：

6.1 今日面板：任务概览与学习足迹

今日面板展示当天的待办任务、到期复习项和学习足迹统计，左右两栏各自独立滚动，长列表浏览体验流畅。全站日期已对齐真实当天，访客演示种子按相对偏移围绕真实日期排期，每次打开保持新鲜。

6.2 任务详情页：掌握状态三按钮

任务详情页提供「未标记 / 还熟 / 还糊」三个手动掌握状态按钮，点击即时切换掌握标签。标记为"还糊"后，独立 py-fsrs 服务会根据间隔重复算法计算下次复习日期，到期那天今日面板会自动展示原因句提醒复习。

6.3 甘特图：多计划并排展示与拖拽改期

甘特图支持"全部并排"和"单计划聚焦"两种模式切换，登录态下拖拽条形改期松开鼠标后即时生效，无需刷新页面。复习日卡片由 FSRS 服务端计算，不可拖动改期，提示文案明确。

6.4 顶栏与登录态：中性占位，身份清晰

登录用户刷新页面时，顶栏先显示中性占位（灰色头像 + "加载中"），接口返回后渲染真实用户名与头像，不再闪现演示账号"林知"。访客模式下保留演示种子数据，方便产品演示。

6.5 AI 助手：对话与计划分析入口

AI 助手提供自由对话和新建计划分析两大功能，对话记录按身份持久化（访客用浏览器 id，登录用用户 id），切页后不丢失。导入学习计划时按钮有禁用态和完成卡片反馈，避免连点重复建计划。