# 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 表，会比现在提前设计复杂表结构更稳。