zhoujie
1ec520b47e
- 新增智能选题引擎 `TopicEngine`，整合热点数据与历史权重，提供多维度评分和创作角度建议 - 新增内容模板系统 `ContentTemplate`，支持从 JSON 文件加载模板并应用于文案生成 - 新增批量创作功能 `batch_generate_copy`，支持串行生成多篇文案并自动入草稿队列 - 升级文案质量流水线：实现 Prompt 分层架构（基础层 + 风格层 + 人设层）、LLM 自检与改写机制、深度去 AI 化后处理 - 优化图文协同：新增封面图策略选择、SD prompt 与文案语义联动、图文匹配度评估 - 集成数据闭环：在文案生成中自动注入 `AnalyticsService` 权重数据，实现发布 → 数据回收 → 优化创作的完整循环 - 更新 UI 组件：新增选题推荐展示区、批量创作折叠面板、封面图策略选择器和图文匹配度评分展示 ♻️ refactor(llm): 重构 Prompt 架构并增强去 AI 化处理 - 将 `PROMPT_COPYWRITING` 拆分为分层架构（基础层 + 风格层 + 人设层），提高维护性和灵活性 - 增强 `_humanize_content` 方法：新增语气词注入、标点不规范化、段落节奏打散和 emoji 密度控制 - 新增 `_self_check` 和 `_self_check_rewrite` 方法，实现文案 AI 痕迹自检与自动改写 - 新增 `evaluate_image_text_match` 方法，支持文案与 SD prompt 的语义匹配度评估（可选，失败不阻塞） - 新增封面图策略配置 `COVER_STRATEGIES` 和情感基调映射 `EMOTION_SD_MAP` 📝 docs(openspec): 归档内容创作优化提案和详细规格 - 新增 `openspec/changes/archive/2026-02-28-optimize-content-creation/` 目录，包含设计文档、提案、规格说明和任务清单 - 新增 `openspec/specs/` 下的批量创作、文案质量流水线、图文协同、服务内容和智能选题引擎规格文档 - 更新 `openspec/specs/services-content/spec.md`，反映新增的批量创作和智能选题入口函数 🔧 chore(config): 更新服务配置和 UI 集成 - 在 `services/content.py` 中集成权重数据自动注入逻辑，实现数据驱动创作 - 在 `ui/app.py` 中新增选题推荐、批量生成和图文匹配度评估的回调函数 - 在 `ui/tab_create.py` 中新增智能选题推荐区、批量创作面板和图文匹配度评估组件 - 修复 `services/sd_service.py` 中的头像文件路径问题，确保目录存在
5.5 KiB
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 状态。
理由:
- LLM API 通常有 rate limit，串行更稳定
- 复用现有
PublishQueue的完整草稿管理能力（审核、编辑、排期、重试） - 用户可在批量生成后逐篇审核调整
替代方案: 并行调用 + 独立草稿存储。弃选原因——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 内新增折叠面板，降低导航复杂度）