✨ feat(scheduler): 新增热点自动采集功能并优化发布路径
CI / Lint (ruff) (push) Has been cancelled
CI / Import Check (push) Has been cancelled

- 新增热点自动采集后台线程,支持定时搜索关键词并执行 AI 分析,结果缓存至结构化状态
- 新增热点分析状态管理接口,提供线程安全的 `get_last_analysis` 和 `set_last_analysis` 方法
- 新增热点数据桥接函数 `feed_hotspot_to_engine`,将分析结果注入 TopicEngine 实现热点加权推荐
- 新增热点选题下拉组件,分析完成后自动填充推荐选题,选中后自动写入选题输入框
- 优化 `generate_from_hotspot` 函数,自动获取结构化分析摘要并增强生成上下文
- 新增热点自动采集配置节点,支持通过 `config.json` 管理关键词和采集间隔

♻️ refactor(queue): 实现智能排期引擎并统一发布路径

- 新增智能排期引擎,基于 `AnalyticsService` 的 `time_weights` 自动计算最优发布时段
- 新增 `PublishQueue.suggest_schedule_time` 和 `auto_schedule_item` 方法,支持时段冲突检测和内容分布控制
- 修改 `generate_to_queue` 函数,新增 `auto_schedule` 和 `auto_approve` 参数,支持自动排期和自动审核
- 重构 `_scheduler_loop` 的自动发布分支,改为调用 `generate_to_queue` 通过队列发布,统一发布路径
- 重构 `auto_publish_once` 函数,移除直接发布逻辑,改为生成内容入队并返回队列信息
- 新增队列时段使用情况查询方法 `get_slot_usage`,支持 UI 热力图展示

📝 docs(openspec): 新增内容排期优化和热点探测优化规范文档

- 新增 `smart-schedule-engine` 规范,定义智能排期引擎的功能需求和场景
- 新增 `unified-publish-path` 规范,定义统一发布路径的改造方案
- 新增 `hotspot-analysis-state` 规范,定义热点分析状态存储的线程安全接口
- 新增 `hotspot-auto-collector` 规范,定义定时热点自动采集的任务流程
- 新增 `hotspot-engine-bridge` 规范,定义热点数据注入 TopicEngine 的桥接机制
- 新增 `hotspot-topic-selector` 规范,定义热点选题下拉组件的交互行为
- 更新 `services-queue`、`services-scheduler` 和 `services-hotspot` 规范,反映功能修改和新增参数

🔧 chore(config): 新增热点自动采集默认配置

- 在 `DEFAULT_CONFIG` 中新增 `hotspot_auto_collect` 配置节点,包含 `enabled`、`keywords` 和 `interval_hours` 字段
- 提供默认关键词列表 `["穿搭", "美妆", "好物"]` 和默认采集间隔 4 小时

🐛 fix(llm): 增强 JSON 解析容错能力

- 新增 `_try_fix_truncated_json` 方法,尝试修复被 token 限制截断的 JSON 输出
- 支持多种截断场景的自动补全,包括字符串值、数组和嵌套对象的截断修复
- 提高 LLM 分析热点等返回 JSON 的函数的稳定性

💄 style(ui): 优化队列管理和热点探测界面

- 在队列生成区域新增自动排期复选框,勾选后隐藏手动排期输入框
- 在日历视图旁新增推荐时段 Markdown 面板,展示各时段权重和建议热力图
- 在热点探测 Tab 新增推荐选题下拉组件,分析完成后动态填充选项
- 在热点探测 Tab 新增热点自动采集控制区域,支持启动、停止和配置采集参数
This commit is contained in:
2026-02-28 22:22:27 +08:00
parent 1889e9a222
commit 4d83c0f4a9
34 changed files with 1318 additions and 161 deletions
@@ -0,0 +1,27 @@
## ADDED Requirements
### Requirement: 会话级结构化分析状态存储
系统 SHALL 在 `services/hotspot.py` 中维护一个模块级变量 `_last_analysis: dict | None`,用于保存最近一次热点分析的完整结构化结果。
#### Scenario: 初始状态为空
- **WHEN** 应用启动且尚未执行任何热点分析
- **THEN** `get_last_analysis()` SHALL 返回 `None`
#### Scenario: 分析完成后自动写入
- **WHEN** `analyze_and_suggest` 成功调用 `LLMService.analyze_hotspots()` 并获得结构化 dict
- **THEN** 系统 SHALL 调用 `set_last_analysis(analysis)` 将结果写入 `_last_analysis`
#### Scenario: 并发安全
- **WHEN** 多个线程同时调用 `get_last_analysis()` 和 `set_last_analysis()`
- **THEN** 所有读写操作 SHALL 通过 `_cache_lock`(RLock)互斥,不发生数据竞态
### Requirement: 线程安全的分析状态存取接口
系统 SHALL 提供 `get_last_analysis() -> dict | None` 和 `set_last_analysis(data: dict) -> None` 两个公开函数。
#### Scenario: get_last_analysis 返回深拷贝
- **WHEN** 调用 `get_last_analysis()`
- **THEN** SHALL 返回 `_last_analysis` 的副本(而非引用),防止外部修改影响缓存
#### Scenario: set_last_analysis 合并多关键词结果
- **WHEN** 调用 `set_last_analysis(new_data)` 且 `_last_analysis` 已有数据
- **THEN** SHALL 将 `new_data` 的 `hot_topics` 和 `suggestions` 追加到已有列表并去重,而非完全覆盖
@@ -0,0 +1,31 @@
## ADDED Requirements
### Requirement: 定时热点自动采集任务
系统 SHALL 在 `services/scheduler.py` 中提供 `start_hotspot_collector` / `stop_hotspot_collector` 函数,启动独立的后台线程按固定间隔自动采集热点。
#### Scenario: 启动自动采集
- **WHEN** 调用 `start_hotspot_collector(keywords, interval_hours, mcp_url, model)`
- **THEN** 系统 SHALL 启动一个 daemon 线程,在首次启动后立即执行一轮采集,随后按 `interval_hours` 间隔循环执行
#### Scenario: 单轮采集流程
- **WHEN** 采集线程执行一轮任务
- **THEN** SHALL 遍历 `keywords` 列表,对每个关键词依次调用 `search_hotspots(keyword, "最多点赞", mcp_url)` 获取搜索结果,再调用 `analyze_and_suggest(model, keyword, search_result)` 执行 LLM 分析,分析结果通过 `set_last_analysis()` 合并写入状态缓存
#### Scenario: 停止自动采集
- **WHEN** 调用 `stop_hotspot_collector()`
- **THEN** 系统 SHALL 清除运行标志,等待线程优雅退出
#### Scenario: 防止重复启动
- **WHEN** 自动采集已在运行中再次调用 `start_hotspot_collector`
- **THEN** SHALL 返回警告信息,不启动新线程
### Requirement: 热点自动采集配置
系统 SHALL 支持通过 `config.json` 的 `hotspot_auto_collect` 节点配置自动采集参数。
#### Scenario: 配置节点结构
- **WHEN** 读取 `config.json` 中的 `hotspot_auto_collect`
- **THEN** 该节点 SHALL 包含以下字段:`enabled`(bool,默认 false)、`keywords`(string list,默认 `["穿搭", "美妆", "好物"]`)、`interval_hours`(int,默认 4)
#### Scenario: 配置缺失时使用默认值
- **WHEN** `config.json` 中不存在 `hotspot_auto_collect` 节点
- **THEN** `ConfigManager.get("hotspot_auto_collect")` SHALL 返回默认值 `{"enabled": false, "keywords": ["穿搭", "美妆", "好物"], "interval_hours": 4}`
@@ -0,0 +1,16 @@
## ADDED Requirements
### Requirement: 热点数据注入 TopicEngine
系统 SHALL 提供 `feed_hotspot_to_engine(topic_engine: TopicEngine) -> list[dict]` 函数,将缓存的热点分析结果传入 `TopicEngine.recommend_topics()`。
#### Scenario: 有缓存分析结果时注入并返回推荐
- **WHEN** 调用 `feed_hotspot_to_engine(topic_engine)` 且 `get_last_analysis()` 返回非空 dict
- **THEN** SHALL 调用 `topic_engine.recommend_topics(hotspot_data=data)` 并返回推荐结果列表
#### Scenario: 无缓存分析结果时返回空推荐
- **WHEN** 调用 `feed_hotspot_to_engine(topic_engine)` 且 `get_last_analysis()` 返回 `None`
- **THEN** SHALL 调用 `topic_engine.recommend_topics(hotspot_data=None)` 并返回其结果(仅基于权重数据推荐)
#### Scenario: 函数位于 hotspot 模块避免循环依赖
- **WHEN** `feed_hotspot_to_engine` 被定义
- **THEN** SHALL 位于 `services/hotspot.py` 中,接受 `TopicEngine` 实例作为参数,不在 `topic_engine.py` 中反向引用 hotspot 模块
@@ -0,0 +1,16 @@
## ADDED Requirements
### Requirement: 热点选题下拉组件
系统 SHALL 在热点探测 Tab 中新增一个 `gr.Dropdown` 组件,用于展示 LLM 分析出的推荐选题列表。
#### Scenario: 分析完成后动态填充下拉选项
- **WHEN** `analyze_and_suggest` 执行完成并返回分析结果
- **THEN** 下拉组件 SHALL 通过 `gr.update(choices=...)` 更新为分析结果中 `suggestions` 列表的 `topic` 字段值
#### Scenario: 用户选择下拉项后写入选题输入框
- **WHEN** 用户在下拉组件中选择一条推荐选题
- **THEN** 系统 SHALL 将选中的 `topic` 文本自动填入 `topic_from_hot` Textbox
#### Scenario: 无分析结果时下拉为空
- **WHEN** 尚未执行热点分析或分析结果中无 `suggestions`
- **THEN** 下拉组件 SHALL 显示空选项列表,不影响用户手动输入选题
+13 -2
View File
@@ -1,12 +1,23 @@
## ADDED Requirements
## MODIFIED Requirements
### Requirement: 热点探测函数迁移至独立模块
系统 SHALL 将热点搜索与分析相关函数从 `main.py` 提取至 `services/hotspot.py`,包括:`search_hotspots`、`analyze_and_suggest`、`generate_from_hotspot`、`_set_cache`、`_get_cache`、`_fetch_and_cache`、`_pick_from_cache`、`fetch_proactive_notes`、`on_proactive_note_selected`。
新增对外接口:`get_last_analysis`、`set_last_analysis`、`feed_hotspot_to_engine`。
#### Scenario: 模块导入成功
- **WHEN** `main.py` 执行 `from services.hotspot import search_hotspots, analyze_and_suggest` 等导入
- **THEN** 所有函数可正常调用
#### Scenario: 线程安全缓存随模块迁移
- **WHEN** `_cache_lock`(`threading.RLock`)随函数一起迁移至 `services/hotspot.py`
- **THEN** `_set_cache` / `_get_cache` 的线程安全行为保持不变
- **THEN** `_set_cache` / `_get_cache` / `get_last_analysis` / `set_last_analysis` 的线程安全行为保持不变
#### Scenario: analyze_and_suggest 写入分析状态
- **WHEN** `analyze_and_suggest` 成功获得 LLM 分析结果
- **THEN** SHALL 在渲染 Markdown 之前调用 `set_last_analysis(analysis)` 缓存结构化数据
- **AND** 返回值格式不变(status, summary, keyword)
#### Scenario: generate_from_hotspot 支持增强上下文
- **WHEN** 调用 `generate_from_hotspot` 生成文案
- **THEN** 函数 SHALL 自动从 `get_last_analysis()` 获取结构化摘要,与 `search_result` 拼接后传入 `svc.generate_copy_with_reference()`,总参考文本限制在 3000 字符以内
+17 -1
View File
@@ -1,8 +1,12 @@
## ADDED Requirements
## MODIFIED Requirements
### Requirement: 排期队列操作函数迁移至独立模块
系统 SHALL 将内容排期队列相关函数从 `main.py` 提取至 `services/queue_ops.py`,包括:`generate_to_queue`、`_queue_publish_callback`、`queue_refresh_table`、`queue_refresh_calendar`、`queue_preview_item`、`queue_approve_item`、`queue_reject_item`、`queue_delete_item`、`queue_retry_item`、`queue_publish_now`、`queue_start_processor`、`queue_stop_processor`、`queue_get_status`、`queue_batch_approve`、`queue_generate_and_refresh`。
`generate_to_queue` SHALL 新增 `auto_schedule: bool = False` 和 `auto_approve: bool = False` 参数:
- 当 `auto_schedule=True` 时,SHALL 为每篇生成的内容调用 `PublishQueue.auto_schedule_item()` 自动分配排期时间
- 当 `auto_approve=True` 时,SHALL 在入队后自动将状态从 `draft` 变为 `approved`(或 `scheduled`,如果有排期时间)
#### Scenario: 模块导入成功
- **WHEN** `main.py` 执行 `from services.queue_ops import queue_generate_and_refresh, queue_refresh_table` 等导入
- **THEN** 所有函数可正常调用
@@ -14,3 +18,15 @@
#### Scenario: 队列操作读写 pub_queue 单例
- **WHEN** `queue_ops.py` 中的函数需要访问 `pub_queue` 或 `queue_publisher`
- **THEN** 这些单例 SHALL 通过函数参数传入,不在 `queue_ops.py` 模块顶层初始化
#### Scenario: 自动排期生成
- **WHEN** 调用 `generate_to_queue(auto_schedule=True)` 生成 3 篇内容
- **THEN** 每篇内容入队后 SHALL 调用 `auto_schedule_item()` 分配排期时间,3 篇内容 SHALL 分配到不同时段
#### Scenario: 自动审核生成
- **WHEN** 调用 `generate_to_queue(auto_approve=True)`
- **THEN** 入队项 SHALL 在添加后立即被审核通过,状态变为 `approved` 或 `scheduled`
#### Scenario: queue_generate_and_refresh 传递新参数
- **WHEN** UI 层调用 `queue_generate_and_refresh` 且用户勾选了自动排期
- **THEN** `auto_schedule=True` SHALL 被传递到 `generate_to_queue`
+7 -1
View File
@@ -1,8 +1,10 @@
## ADDED Requirements
## MODIFIED Requirements
### Requirement: 自动调度器函数迁移至独立模块
系统 SHALL 将调度器相关的状态变量和函数从 `main.py` 提取至 `services/scheduler.py`,包括:`_scheduler_next_times`、`_auto_log`(列表)、`_auto_log_append`、`_scheduler_loop`、`start_scheduler`、`stop_scheduler`、`get_auto_log`、`get_scheduler_status`、`_learn_running`、`_learn_scheduler_loop`、`start_learn_scheduler`、`stop_learn_scheduler`。
`_scheduler_loop` 中的自动发布分支 SHALL 改为调用 `generate_to_queue(auto_schedule=True, auto_approve=True)` 生成内容入队,不再调用 `auto_publish_once` 中的 MCP client 直接发布逻辑。
#### Scenario: 调度器启停正常工作
- **WHEN** `start_scheduler(...)` 被调用并传入合法参数
- **THEN** 调度器线程 SHALL 正常启动,`get_scheduler_status()` 返回运行中状态
@@ -14,3 +16,7 @@
#### Scenario: engagement 通过回调写日志
- **WHEN** `services/engagement.py` 中的函数需要写日志时
- **THEN** SHALL 通过 `log_fn` 参数(由 `scheduler.py` 传入 `_auto_log_append`)写入,不直接导入 `scheduler.py`
#### Scenario: 自动发布走队列路径
- **WHEN** `_scheduler_loop` 中 `publish_enabled=True` 且到达发布时间
- **THEN** SHALL 调用 `generate_to_queue(auto_schedule=True, auto_approve=True)` 替代直接发布,日志记录入队结果
@@ -0,0 +1,45 @@
## ADDED Requirements
### Requirement: 最优时段计算
系统 SHALL 基于 `AnalyticsService` 的 `time_weights` 数据计算每个 3 小时段的权重得分,并按得分降序排列为候选时段列表。
#### Scenario: 有分析数据时按权重排序
- **WHEN** `time_weights` 包含至少 1 个时段的权重数据
- **THEN** `suggest_schedule_time()` SHALL 按 `weight` 值降序排列时段,优先返回高权重时段的具体时间
#### Scenario: 无分析数据时使用默认时段
- **WHEN** `time_weights` 为空字典或不存在
- **THEN** 系统 SHALL 使用默认的高流量时段作为候选:08-11 时(权重 70)、12-14 时(权重 60)、18-21 时(权重 85)、21-24 时(权重 75)
### Requirement: 时段冲突检测
系统 SHALL 在分配排期时间前查询已有队列排期,避免同一时段内容拥堵。
#### Scenario: 单时段内容上限控制
- **WHEN** 某个 3 小时时段中已排期的队列项数量达到 `max_per_slot`(默认 2)
- **THEN** 系统 SHALL 跳过该时段,选择下一个权重最高且有空余的时段
#### Scenario: 单日内容上限控制
- **WHEN** 某天的已排期总数达到 `max_per_day`(默认 5)
- **THEN** 系统 SHALL 将内容排期到次日的最优可用时段
#### Scenario: 最远排期范围
- **WHEN** 未来 7 天内所有时段均已满
- **THEN** `suggest_schedule_time()` SHALL 返回 `None`,内容以 approved 状态入队(不带排期时间)
### Requirement: 排期时间精确化
系统 SHALL 在选定的 3 小时段内随机选择一个精确的分钟级时间点,避免所有内容在整点发布。
#### Scenario: 时段内随机时间
- **WHEN** 系统选定 18-21 时段为最优
- **THEN** SHALL 在该时段范围内随机生成精确时间(如 `2026-02-28 19:37:00`),格式为 `%Y-%m-%d %H:%M:%S`
### Requirement: 队列项自动排期
`PublishQueue` SHALL 提供 `auto_schedule_item(item_id, analytics)` 方法,为指定队列项调用排期引擎并更新其 `scheduled_time`。
#### Scenario: 自动排期成功
- **WHEN** 调用 `auto_schedule_item(item_id, analytics)` 且队列项状态为 draft 或 approved
- **THEN** 系统 SHALL 计算最优时间并更新该项的 `scheduled_time` 和状态为 `scheduled`
#### Scenario: 自动排期无可用时段
- **WHEN** 调用 `auto_schedule_item()` 但未来 7 天无可用时段
- **THEN** 系统 SHALL 保持队列项当前状态不变,返回 `False`
@@ -0,0 +1,23 @@
## ADDED Requirements
### Requirement: 调度器发布通过队列执行
`_scheduler_loop` 中的自动发布分支 SHALL 调用 `generate_to_queue(auto_schedule=True, auto_approve=True)` 替代 `auto_publish_once` 中的直接发布逻辑。
#### Scenario: 调度器触发自动发布
- **WHEN** `_scheduler_loop` 的 publish 定时触发且 `publish_enabled=True`
- **THEN** 系统 SHALL 调用 `generate_to_queue` 生成内容入队(带 `auto_schedule=True, auto_approve=True`),不再直接调用 MCP client 发布
#### Scenario: 发布由 QueuePublisher 完成
- **WHEN** 调度器生成的内容入队后
- **THEN** `QueuePublisher._loop()` SHALL 在下一次检查循环中检测到该排期/待发布项并执行实际发布
### Requirement: auto_publish_once 重构为入队操作
`auto_publish_once` SHALL 重构为仅生成内容并加入队列,不再包含直接调用 MCP client publish 的逻辑。
#### Scenario: auto_publish_once 返回入队结果
- **WHEN** 调用 `auto_publish_once`
- **THEN** 函数 SHALL 生成文案和图片、调用 `generate_to_queue` 入队,返回队列项 ID 和排期时间信息
#### Scenario: QueuePublisher 未运行时的提示
- **WHEN** `auto_publish_once` 成功入队但 `QueuePublisher` 未启动
- **THEN** 返回信息中 SHALL 包含提示「内容已入队,请启动队列处理器以自动发布」