dreamweaver/docs/technical/generation-job-state.md

Generation Job 状态落库决策

这份文档用于回答一个关键技术债问题：DreamWeaver 是否需要为每次 AI 生成单独建立 generation_jobs 表。

当前结论

短期不新增 generation_jobs 表，继续把求职版状态落在 stories 主记录上。

原因是当前 MVP 的生成方式仍然以同步请求为主：后端在一次请求中完成主内容保存，再补全封面、绘本插图或语音。用户最关心的是“这个故事现在能不能读、哪些资产可补全”，而不是一个独立 job 的生命周期。

现有状态模型

当前 stories 表已承载演示所需状态：

• generation_status: 主流程状态，例如 narrative_ready、assets_generating、completed、degraded_completed、failed
• image_status: 封面或绘本插图状态
• audio_status: 语音状态
• last_error: 最近一次资产失败原因

这些字段足够支撑前端展示、smoke 检查、失败降级和资产重试。

什么时候需要落库 job

如果后续进入真实生产化，需要重新评估 generation_jobs：

• 生成流程改成真正异步，前端需要轮询 job 进度。
• 单个故事会产生多次生成尝试，需要审计每次 provider 调用。
• 需要展示更细颗粒度步骤，例如 prompt 构建、文本生成、封面生成、每页插图、TTS。
• 需要按 provider、成本、延迟和失败原因做运营分析。
• 需要断点续跑，避免 Worker 重启后丢失中间状态。

推荐未来结构

未来可以新增两层记录：

• generation_jobs: 一次用户发起的生成任务，记录输入、状态、耗时、错误和关联 story。
• generation_job_events: 任务事件流，记录每一步开始、成功、失败、provider、耗时和错误摘要。

这会把“用户可见结果”和“系统执行过程”分开，但目前还不是求职版的最高优先级。

面试表达

我现在没有急着加 job 表，是因为 MVP 首要目标是让故事结果稳定可读，并让资产失败可恢复。等生成链路变成真正异步、需要审计和运营指标时，再把执行过程拆到 job/event 表，会比现在提前设计复杂表结构更稳。