# Generation Job 状态落库决策

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

## 当前结论

已新增轻量 `generation_jobs` 与 `generation_job_events` 表，但不引入复杂工作流引擎。

原因是当前 MVP 的生成方式仍然以同步请求为主：后端在一次请求中完成主内容保存，再补全封面、绘本插图或语音。用户最关心的是“这个故事现在能不能读、哪些资产可补全”；系统侧则需要有足够的轨迹说明“这次生成做到了哪一步、哪里失败、哪些资产还能重试”。

因此当前采用轻量落库策略：

- `stories` 继续承载用户可见结果和当前状态。
- `generation_jobs` 记录一次生成或资产补全尝试。
- `generation_job_events` 记录关键步骤事件，例如 `request_accepted`、`generation_completed`、`asset_retry_started`、`asset_retry_completed`。

## 现有状态模型

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

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

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

## 什么时候需要落库 job

如果后续进入真实生产化，需要扩展当前 job/event 模型：

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

## 推荐未来扩展

当前已有两层记录，未来可以继续扩展字段和事件颗粒度：

- 在 `generation_job_events` 中补 provider、耗时、成本和错误摘要。
- 对绘本逐页插图、TTS、后处理任务记录更细事件。
- 为前端提供 job 查询接口，用于真正异步生成时轮询进度。

## 面试表达

我没有一上来引入复杂工作流引擎，而是先用轻量 job/event 表把关键执行轨迹落下来。这样既能回答“生成过程是否可追踪”，又不会为了求职版 MVP 牺牲主链路稳定性。