## Context

当前 autobot 的内容创作流程是单篇串行模式：用户手动输入主题 → LLM 生成文案 → SD 生成图片 → 手动发布/导出。系统已有 `analytics_service.py` 的权重学习和 `hotspot.py` 的热点探测，但两者与创作环节是割裂的——权重数据仅在自动发布时被动使用，热点分析需要用户手动操作后再回到创作 Tab。

核心代码分布：
- `services/llm_service.py`（964 行）：所有 Prompt 模板和 LLM 调用逻辑
- `services/content.py`（210 行）：创作入口函数（generate_copy、generate_images、export、publish）
- `services/analytics_service.py`（666 行）：数据采集 + 权重计算
- `services/hotspot.py`（191 行）：热点搜索 + 分析
- `services/publish_queue.py`（630 行）：SQLite 发布队列，已支持草稿/排期/重试
- `ui/tab_create.py`（183 行）：创作 Tab UI

## Goals / Non-Goals

**Goals:**
- 让选题从"人工拍脑袋"变成"数据推荐 + 人工确认"
- 降低文案 AI 痕迹，提高过检率
- 支持批量创作，一次操作产出多篇内容直接进入草稿队列
- 打通数据闭环：历史表现 → 权重 → 创作 Prompt → 新内容
- SD prompt 与文案内容语义对齐，提升图文一致性

**Non-Goals:**
- 不涉及视频内容生成（仅图文笔记）
- 不改变 MCP 发布协议和 SD 生成核心逻辑
- 不引入新的外部依赖（仅内部模块重组）
- 不改变现有单篇创作的 UI 交互模式（新增批量面板，不替换现有面板）

## Decisions

### Decision 1: 智能选题引擎作为独立模块

**选择**: 新建 `services/topic_engine.py`，不在 `hotspot.py` 或 `analytics_service.py` 中扩展。

**理由**: 选题引擎需要同时聚合热点数据和权重数据，放在任何一方都会造成单向依赖和职责膨胀。独立模块清晰地表达了"整合者"角色。

**替代方案**: 在 `analytics_service.py` 中添加 `recommend_topics()` 方法。弃选原因——`AnalyticsService` 职责已重（采集 + 权重 + 报告），再加选题推荐会让该类过于庞大。

### Decision 2: Prompt 分层而非模板替换

**选择**: 将 `PROMPT_COPYWRITING` 拆为 base + style + persona 三层拼接，而非为每种风格维护完整 Prompt 模板。

**理由**: 当前的完整 Prompt 已有 60+ 行，如果每种风格复制一份，维护成本极高且容易不一致。分层后，基础规则只维护一处，风格层仅包含差异化指导。

**替代方案**: 使用 Jinja2 模板引擎渲染。弃选原因——引入新依赖、过度工程化，字符串拼接足够简单可控。

### Decision 3: 自检用同一 LLM 实例，共享 fallback 机制

**选择**: 文案自检和改写复用 `LLMService._chat()`，共享模型降级和 JSON 回退逻辑。

**理由**: 复用现有的健壮性机制（fallback models、json_mode 回退、超时处理），无需重复实现。自检 Prompt 作为独立方法 `_self_check(content)` 封装即可。

**替代方案**: 使用独立的轻量模型做自检。弃选原因——增加配置复杂度，且当前 fallback 机制已可自动降级。

### Decision 4: 批量创作串行执行 + 队列入草稿

**选择**: `batch_generate()` 串行调用 `generate_copy()`（非并行），结果自动入 `PublishQueue` 的 `draft` 状态。

**理由**: 
1. LLM API 通常有 rate limit，串行更稳定
2. 复用现有 `PublishQueue` 的完整草稿管理能力（审核、编辑、排期、重试）
3. 用户可在批量生成后逐篇审核调整

**替代方案**: 并行调用 + 独立草稿存储。弃选原因——rate limit 风险大，维护两套草稿系统增加复杂度。

### Decision 5: 图文语义联动通过 Prompt 工程实现

**选择**: 在生成文案时把 SD prompt 生成的上下文增强——将文案正文的关键场景词注入 SD prompt 生成指令中，不使用独立的语义匹配模型。

**理由**: 当前 LLM 已具备理解文案并生成对应 SD prompt 的能力，只需优化 Prompt 指令使其更关注文案中的具体场景描述。额外的语义匹配评估作为可选功能，通过 LLM 二次调用实现。

### Decision 6: 封面图策略通过 SD 参数预设实现

**选择**: 在现有 `quality_mode` 机制旁新增 `cover_strategy` 参数，映射为不同的 SD prompt 后缀和尺寸参数，复用 `sd_service.py` 的预设体系。

**理由**: 与现有的"快速/标准/精细"模式选择机制一致，用户理解成本低。

## Risks / Trade-offs

- **[LLM 调用量增加]** → 自检机制每篇多 1 次 LLM 调用，批量创作 N 篇则为 2N 次。缓解：自检设超时上限（10s），失败不阻塞；批量限制 ≤ 10 篇。
- **[Prompt 分层维护成本]** → 风格层 Prompt 需要针对每种风格单独调优。缓解：初期只提供 3 种核心风格层，其余退回基础层。
- **[选题推荐质量依赖数据量]** → 新账号/新赛道初期权重数据不足，推荐质量有限。缓解：无权重时退回纯热点推荐，给出"数据不足"提示。
- **[图文匹配度评估增加延迟]** → 额外 LLM 调用。缓解：评估完全可选，默认关闭，不阻塞创作流程。

## Open Questions

- 风格层 Prompt 的具体数量和优先级——初期先做哪几种风格？（建议："好物种草""日常分享""攻略教程"三种最高频风格）
- 批量创作的 UI 交互方式——独立 Tab 还是在现有创作 Tab 内新增折叠面板？（建议：同 Tab 内新增折叠面板，降低导航复杂度）