背景
IdeaSense AI 让早期创业者完成一个分阶段的 DVF 评估：结构化对话、阶段之间的显式确认、评分，以及生成报告。每次阶段切换都会先确认已采集的内容，再继续往下。
症状
market 到 tech 的确认（POST /api/v1/assessments/market/confirm）在用户看到任何响应前要约 96 秒。这个时长已经足够让人觉得“坏了”，而不是“在思考”。
错误的本能
本能反应是：模型慢，那就换个快的。系统本来就在多个 provider 之间路由——DeepSeek 和 Qwen 为主、OpenAI 兜底——所以换模型很容易。但这恰恰是陷阱：它把一个结构问题当成采购问题，下一个慢步骤马上又会冒出来。
关键路径上到底在跑什么
在返回之前，这次确认还顺带做了一堆用户不需要等的“确认后富化”：DVF 评分、阶段级验证、逐题 QA 摘要、项目描述补全，外加一次下一题改写。用户其实只需要“确认”本身，其余全都莫名其妙地压在了关键路径上。
解法
改动就是把这些富化工作从同步回合里挪走。现在的确认只做一条薄可见路径——校验输入、落库 confirmed assessment、推进 stage、插入下一阶段的首条消息、把 finalize 任务入队、提交——然后在面向用户的判断一就绪就返回。可见路径的目标是个位数秒级。
评分、验证、QA 摘要、描述补全现在都跑在后台任务（stage_finalize_v0）里；下一题改写则干脆不再位于 confirm 路径上。
为什么这不是“模型快慢无所谓”
诚实的版本——因为工程师一眼能识破偷懒的说法：那 96 秒里绝大部分本身就是模型时间，一串富化调用，所以换个快模型确实能砍掉很多。这正是它危险的地方。
重点不在“模型快慢无所谓”，而在“这些富化压根不该出现在用户的关键路径上”。哪怕每个调用都瞬间完成，把这么多工作串进一次确认，仍然是错误的路径设计。把它挪到后台，确认就快——无论底层模型多快多慢。模型选型能优化每一段的耗时，但消除不了“让用户等一堆他根本不需要的结果”这个结构问题。
原则
当一个 AI 产品让人觉得慢，先问“用户到底在等什么”，再问“哪个模型最快”。这类系统里大多数“感觉上的延迟”是路径设计的决定——什么同步跑、什么可以放后台慢慢结算——而不是模型选型的决定。
这和我对待“准确性”的偏好是一根筋：系统不声称自己知道什么是真的，而是把判断保留成可追踪的证据，并对不确定性保持诚实。设计路径，别过度推销模型。