X-Financial/document/development/2026-06-30/dev-logs/bugs/multi-task-next-task-blocked-by-preview-ready-timing.md

多 task 串行推进时 task2 无法启动（onPreviewReadyForNextTask 时序缺陷）

日期：2026-06-30 文档路径：document/development/2026-06-30/dev-logs/bugs/multi-task-next-task-blocked-by-preview-ready-timing.md

修复记录

• 11:18：记录 bug 修复：用户在 AI 工作台输入"出差申请 + 招待费报销"等多 task 时，task1（出差申请）保存草稿/提交成功后，task2（招待费报销）完全无法启动，界面停在"申请草稿已保存"。
  • Git 提交检查：git fetch --all --prune 成功；upstream origin/main；HEAD..@{u} 未发现 upstream 新提交；@{u}..HEAD 未发现本地 ahead 提交。工作区改动仅为本次 3 个源文件 + 2 个测试文件（另有一个预先存在的未提交改动 server/rules/finance-rules/公司通信费报销规则.xlsx，与本次无关）。
  • 根因：onPreviewReadyForNextTask 回调在 task1 申请核对表刚生成、用户还没看、还没点保存草稿时就立刻触发 startModelPlannedNextTask，提前把 task2 招待费报销拉起（startAiExpenseDraft 会 push 一条"选择费用报销"用户消息 + 报销 prompt）。两条流程的消息和状态互相打架，用户再在 task1 上点保存草稿时 onApplicationActionCompleted 又试图拉起 task2，但 task2 状态已被前面 onPreviewReadyForNextTask 搞乱，最终表现为"完全无反应"。运行时复现脚本时序铁证：预览生成后立即出现 !!! onPreviewReadyForNextTask 触发(task1预览刚生成,用户还没操作)，与串行推进的正确语义（task1 完成后才推进 task2）冲突。这是早期实现的残留——引入 onApplicationActionCompleted（task1 完成后触发）后，onPreviewReadyForNextTask 职责重叠且时序错误。
  • 修改（前端 web，3 个源文件）：
    • web/src/composables/workbenchAiMode/useWorkbenchAiApplicationPreviewFlow.js：删除 startAiApplicationPreview 预览生成后的 else if (onPreviewReadyForNextTask ...) 提前推进分支（原 L622-L628），并加注释说明 task2 推进统一交给 onApplicationActionCompleted 在 task1 真正完成后触发。executeInlineApplicationPreviewAction 里 L466 的 actionCompletedHandler 回落逻辑保留不动（手动点保存草稿走 actionRouter 不传 options 回调，回落到模块级 startModelPlannedNextTask，这是正确的续跑路径）。
    • web/src/composables/workbenchAiMode/usePersonalWorkbenchAiMode.js：startModelPlannedApplicationPreview 调用 startAiApplicationPreview 时删除 onPreviewReadyForNextTask: startModelPlannedNextTask 一行，只保留 onApplicationActionCompleted: startModelPlannedNextTask（原 L769）。
    • web/src/composables/workbenchAiMode/useWorkbenchAiActionRouter.js：ai_application_confirm_intent（低置信确认按钮）分支删除 onPreviewReadyForNextTask 回调，只保留 onApplicationActionCompleted（原 L99-L104），消除低置信路径的同样时序缺陷。
  • 操作：先写复现脚本 /tmp/repro-timing.mjs（applicationFlow + 两个回调）锁定时序根因——修复前预览生成后立即触发推进回调，修复后无提前触发；再按计划小步改 3 个源文件 + 2 个测试文件；未提交（工作区有预先存在的无关 xlsx 改动，未自动提交）。
  • 验证：宿主机 node v22.22.3 跑 node --test web/tests/workbench-ai-intent-planner-model.test.mjs web/tests/workbench-ai-action-router.test.mjs web/tests/workbench-ai-application-context-submit.test.mjs 通过 27/27（含新增的时序回归用例 workbench application preview does not continue next task until draft is saved or submitted：断言预览生成时 continuedTasks.length === 0、保存草稿后才推进 task2 且走模块级续跑回调、自动续跑时不展示重复的"继续处理"按钮）；npm --prefix web run build 通过（3.97s）；复现脚本 /tmp/repro-timing.mjs 修复后事件序列只剩用户消息、无提前推进；真实 http://localhost:5173/api/v1/steward/plans 与 /api/v1/steward/plans/stream 采样确认该句子仍返回 expense_application + reimbursement 两个 task（后端拆分正确，本次未动后端）。
  • 影响：用户输入框提交"2月20-23日，去上海出差辅助国网仿生产服务器部署，并且报销昨天的上午招待费2000元"等多 task 时，task1 出差申请核对表生成后干净停下等用户操作，用户点保存草稿/直接提交成功后自动进入 task2 招待费报销（预填金额/时间/事由），不再出现两条流程打架导致 task2 完全无反应的问题。不影响后端、单 task 场景、autoSaveDraft 路径（它走 executeInlineApplicationPreviewAction 完成后触发 onApplicationActionCompleted，链路不变）；低置信确认按钮路径也同步修复。