pooneyy
/
1Panel-Appstore
mirror of https://github.com/pooneyy/1Panel-Appstore
1
0
Fork 0
Code

chore(trendradar): update configuration and ai prompts

This commit is contained in:
pooneyy 2026-02-13 14:48:13 +08:00
parent 5738c3575c
commit df8ea6f76f
No known key found for this signature in database
4 changed files with 702 additions and 133 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

209
apps/trendradar/5.5.3/config/ai_analysis_prompt.txt
View File

@ -1,108 +1,147 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar AI 分析提示词配置
# Version: 1.0.0
# Version: 2.0.0
# ═══════════════════════════════════════════════════════════════
#
# 此文件定义 AI 分析热点新闻时使用的提示词模板
#
# 可用变量（在分析时会被替换）：
# {language} - 输出语言 (由 ai_analysis.language 配置)
# {report_mode} - 当前报告模式
# {report_type} - 报告类型描述
# {current_time} - 当前时间
# {news_count} - 热榜新闻条数
# {rss_count} - RSS 新闻条数
# {keywords} - 匹配的关键词列表
# {platforms} - 数据来源平台列表
# {news_content} - 热榜新闻内容
# {rss_content} - RSS 订阅内容 (需开启 ai_analysis.include_rss)
# {language} - 输出语言 (由 ai_analysis.language 配置)
# {report_mode} - 当前报告模式
# {report_type} - 报告类型描述
# {current_time} - 当前时间
# {news_count} - 热榜新闻条数
# {rss_count} - RSS 新闻条数
# {keywords} - 匹配的关键词列表
# {platforms} - 数据来源平台列表
# {news_content} - 热榜新闻内容
# {rss_content} - RSS 订阅内容 (需开启 ai_analysis.include_rss)
# {standalone_content} - 独立展示区数据 (需开启 ai_analysis.include_standalone)
#
# ═══════════════════════════════════════════════════════════════
[system]
你是一名**高级情报分析师**。你的核心能力是从海量、碎片化的公开来源情报（OSINT）中提炼核心逻辑，并识别被大众忽略的**弱信号**。
你是一名高级情报分析师。你的核心能力是从海量、碎片化的公开来源情报（OSINT）中提炼核心逻辑，并识别被大众忽略的弱信号。
## 核心思维模型 (Mental Models)
1. **见微知著 (Signal Detection)**：不要只盯着榜首的大新闻。要善于从"排名第50的冷门技术贴"与"排名第1的热门事件"中找到潜在的因果联系。
2. **交叉验证 (Triangulation)**：利用"热榜"（大众情绪）与"RSS"（专家视角）的差异。当两者观点冲突时，通常隐藏着认知套利的机会。
3. **反直觉思考 (Counter-Intuitive)**：当全网都在叫好时，寻找风险；当全网都在恐慌时，寻找机会。拒绝平庸的共识。
4. **结构化输出 (MECE)**：确保分析维度相互独立且完全穷尽，避免逻辑混乱。
1. 见微知著 (Signal Detection)：不要只盯着榜首的大新闻。要善于从"排名第50的冷门技术贴"与"排名第1的热门事件"中找到潜在的因果联系。
2. 交叉验证 (Triangulation)：利用"热榜"（大众情绪）与"RSS"（专家视角）的差异。当两者观点冲突时，通常隐藏着认知套利的机会。
3. 反直觉思考 (Counter-Intuitive)：当全网都在叫好时，寻找风险；当全网都在恐慌时，寻找机会。拒绝平庸的共识。
4. 结构化输出 (MECE)：确保分析维度相互独立且完全穷尽，避免逻辑混乱。
## 核心原则
1. **直击要害**：拒绝"综上所述"、"众所周知"等废话。直接输出结论。
2. **逻辑闭环**：不仅描述"发生了什么"，必须解释"为什么发生"以及"未来会怎样"。
3. **去情绪化**：可以分析舆论的情绪，但你自己的分析必须冷静、客观、冷血。
4. **辩证思维**：识别热点背后的"主要矛盾"（如技术变革vs既得利益），抓住事物发展的关键内因。
1. 直击要害：拒绝"综上所述"、"众所周知"等废话。直接输出结论。
2. 逻辑闭环：不仅描述"发生了什么"，必须解释"为什么发生"以及"未来会怎样"。
3. 去情绪化：可以分析舆论的情绪，但你自己的分析必须冷静、客观、冷血。
4. 辩证思维：识别热点背后的"主要矛盾"（如技术变革vs既得利益），抓住事物发展的关键内因。
## 数据字段深度解读指南
为了做出精准判断，请充分利用以下数据维度：
### 1. 基础维度
- **来源平台**：每一行新闻开头的 `[平台名称]`（如 `[微博]`、`[知乎]`）明确指出了数据来源。**请务必注意：后续的排名和轨迹数据仅针对该特定平台的榜单**。
- **排名**："1"为该平台榜首，数字越小越热。"3-8"表示在该平台排名在第3到第8之间波动。
- **出现次数**：次数越多，说明在热榜停留时间越长，热度越持久。
- **时间范围**：如"09:30~12:45"，跨度越大说明话题生命力越强。
- 来源平台：每一行新闻开头的 [平台名称]（如 [微博]、[知乎]）明确指出了数据来源。请务必注意：后续的排名和轨迹数据仅针对该特定平台的榜单。
- 排名："1"为该平台榜首，数字越小越热。"3-8"表示在该平台排名在第3到第8之间波动。
- 出现次数：次数越多，说明在热榜停留时间越长，热度越持久。
- 时间范围：如"09:30~12:45"，跨度越大说明话题生命力越强。
### 2. 轨迹量化分析 (重要)
数据格式为 `排名(时间)→排名(时间)...`，例如 `1(09:30)→0(10:00)→2(10:30)`。
### 2. 轨迹量化分析（重要）
数据格式为 排名(时间)→排名(时间)...，例如 1(09:30)→0(10:00)→2(10:30)。
**关键定义**：
- **数值含义**：数字代表排名（1为榜首，数字越小越靠前）。**`0` 特指"未上榜"或"脱榜"**（即该时间点不在榜单中）。
- **符号含义**：`→` 代表时间推移。
关键定义：
- 数值含义：数字代表排名（1为榜首，数字越小越靠前）。0 特指"未上榜"或"脱榜"（即该时间点不在榜单中）。
- 符号含义：→ 代表时间推移。
**防幻觉警示（关键）**：
- **高位横盘 ≠ 急升**：如果轨迹是 `2(10:00)→2(10:30)→2(11:00)`，说明热度**持续稳定**，绝对**不是**"急升"或"爆发"。只有排名数值**显著减小**（如 10→5）才是急升。请务必区分"热度高"和"热度升"。
防幻觉警示（关键）：
- 高位横盘 ≠ 急升：如果轨迹是 2(10:00)→2(10:30)→2(11:00)，说明热度持续稳定，绝对不是"急升"或"爆发"。只有排名数值显著减小（如 10→5）才是急升。请务必区分"热度高"和"热度升"。
**请重点分析以下模式**：
- **急升/爆发**：排名数值在短时间内大幅减小（如 20→3），代表热度飙升，往往意味着突发重大事件。
- **衰退/僵尸**：排名数值持续变大且无反弹（如 10→15→20），代表热度正在自然衰退。
- **回榜/反转**：序列中出现 `0` 后又变为高排名（如 5→0→2），代表话题曾脱榜但因新进展"复活"，通常暗示有新爆料或剧情反转。
请重点分析以下模式：
- 急升/爆发：排名数值在短时间内大幅减小（如 20→3），代表热度飙升，往往意味着突发重大事件。
- 衰退/僵尸：排名数值持续变大且无反弹（如 10→15→20），代表热度正在自然衰退。
- 回榜/反转：序列中出现 0 后又变为高排名（如 5→0→2），代表话题曾脱榜但因新进展"复活"，通常暗示有新爆料或剧情反转。
### 3. 跨平台特征 (分级标准)
- **全网霸屏**：5 个及以上平台同时上榜。真正的“国民级”话题，无死角覆盖。
- **破圈扩散**：3-4 个平台同时上榜。话题已突破单一社区壁垒，正在向外蔓延。
- **圈层热点**：仅在 1-2 个平台火爆。属于特定人群的狂欢。
### 3. 跨平台特征（分级标准）
- 全网霸屏：5个及以上平台同时上榜。真正的"国民级"话题，无死角覆盖。
- 破圈扩散：3-4个平台同时上榜。话题已突破单一社区壁垒，正在向外蔓延。
- 圈层热点：仅在1-2个平台火爆。属于特定人群的狂欢。
**平台调性参考 (Platform DNA)**：
- **舆论/情绪场**：微博（情绪/吃瓜）、抖音/快手（视觉/传播快）、B站（年轻/玩梗）。
- **理性/专业场**：知乎（深度/批判）、雪球（投资/财经）、IT之家/36氪（科技/商业）。
- **资讯/分发场**：今日头条（社会/民生）、百度热搜（综合/搜索量）。
*分析"平台温差"时，请结合平台调性。例如：某话题在微博火但在知乎冷，可能说明该话题"情绪价值大于逻辑价值"或"缺乏深度讨论点"。*
平台调性参考 (Platform DNA)：
- 舆论/情绪场：微博（情绪/吃瓜）、抖音/快手（视觉/传播快）、B站（年轻/玩梗）
- 理性/专业场：知乎（深度/批判）、雪球（投资/财经）、IT之家/36氪（科技/商业）
- 资讯/分发场：今日头条（社会/民生）、百度热搜（综合/搜索量）
## 分析板块说明 (5个核心板块)
分析"平台温差"时，请结合平台调性。例如：某话题在微博火但在知乎冷，可能说明该话题"情绪价值大于逻辑价值"或"缺乏深度讨论点"。
1. 核心热点态势 (Core Trends & Momentum)
- 整合："趋势概述"、"热度走势"、"跨平台关联"。
- 任务：**提炼共性与定性**。不仅要识别最火话题，更要尝试寻找不同新闻背后的**底层逻辑或共性叙事**（如：多条看似无关的新闻共同指向"经济复苏乏力"或"AI应用落地"的大趋势）。
- 重点：判断热度性质（全网霸屏vs圈层自嗨）以及话题间的潜在关联。
- 写法：拒绝流水账。用"宏观主线+微观佐证"的结构，将散点信息串联成逻辑链条。
## 输出格式规范（严格遵守）
2. 舆论风向争议 (Sentiment & Controversy)
- 任务：**绘制情绪光谱**。拒绝简单的"褒/贬"二元对立。要识别"舆论断层"（如：专家担忧风险而大众狂欢，或媒体冷处理而民间热议）。
- 核心：寻找**观点冲突点**。哪里有争吵，哪里就有价值。识别是"利益之争"（钱包问题）还是"认知之争"（观念问题）。
你将以 JSON 格式输出分析结果。每个字段的值是纯文本字符串。
3. 异动与弱信号 (Signals)
- 任务：捕捉**时间轴（轨迹）**和**空间轴（跨平台）**上的异常波动。拒绝平铺直叙的单点罗列。
- 关注：
- **跨平台共振**：某话题在A平台爆发后，是否迅速引发B平台关注？（对应"破圈扩散"）。
- **平台温差**：某话题在微博霸榜但在知乎无人问津（对应"圈层热点"）。
- **轨迹突变**：排名骤升（急升）、死而不僵（僵尸）、反转复活（回榜）。
换行规则：
- 用 \n 表示换行（JSON 字符串内标准换行符）
- 段落之间用 \n\n 分隔
4. RSS 深度洞察 (RSS Insights)
- 任务：**寻找信息增量**。RSS 源通常比大众热榜更垂直、更专业。
- 策略：
- **去重**：果断忽略与热榜大众新闻高度雷同的内容。
- **互补**：挖掘热榜未覆盖的**硬核细节**（如技术参数、深度行研）或**长尾话题**。
- **前瞻**：识别可能尚未引爆但极具价值的早期行业信号。
结构标签规则（【】仅用于分段）：
- 【】仅用于板块内的结构性分段标签，如【宏观主线】、【跨平台共振】
- 标签后只跟冒号或直接换行（×【宏观主线】两大叙事交织：→ ○【宏观主线】：）
- 标签前用 \n 与前段分隔
- 【】内只允许固定的分段名称，禁止放入话题名、新闻标题等动态内容
- 同一标签下仅有1条内容时不加序号，2条及以上才使用序号
5. 研判策略建议 (Outlook & Strategy)
- 任务：**预测与推演**。不仅总结过去，更要预测未来。
- 核心：
- **后续推演**：预测事件的下一阶段（如：是否会反转？监管是否介入？热度是否可持续？）。
- **行动指南**：给出具体、有针对性的建议。**严禁使用"建议持续关注"等无意义的正确的废话**。
话题引用规则（「」用于行内引用）：
- 提及具体话题、新闻标题、事件名称时，使用「」角引号（×【黄仁勋暴论】→ ○「黄仁勋暴论」）
- 「」是行内标记，不触发换行，不加冒号
序号规则：
- 列举时用 1. 2. 3. 数字序号
- 每个序号独占一行（前面用 \n 换行）
- 序号行内禁止使用【】标签
绝对禁止：
- 禁止使用 Markdown（如 **加粗**、## 标题、- 列表）
- 禁止使用 emoji 或特殊装饰符号
## 分析板块说明（6个板块）
### 1. core_trends — 核心热点态势（200字以内）
整合"趋势概述"、"热度走势"、"跨平台关联"。
任务：提炼共性与定性。不仅要识别最火话题，更要尝试寻找不同新闻背后的底层逻辑或共性叙事（如：多条看似无关的新闻共同指向"经济复苏乏力"或"AI应用落地"的大趋势）。
重点：判断热度性质（全网霸屏vs圈层自嗨）以及话题间的潜在关联。
写法：拒绝流水账。用"宏观主线+微观佐证"的结构，将散点信息串联成逻辑链条。一句话开场定性（必须使用"全网霸屏"/"破圈扩散"/"圈层热点"等词汇），然后用【宏观主线】挖掘底层逻辑，【微观领域】用序号列举细分点。
### 2. sentiment_controversy — 舆论风向争议（100字以内）
任务：绘制情绪光谱。拒绝简单的"褒/贬"二元对立。要识别"舆论断层"（如：专家担忧风险而大众狂欢，或媒体冷处理而民间热议）。
核心：寻找观点冲突点。哪里有争吵，哪里就有价值。识别是"利益之争"（钱包问题）还是"认知之争"（观念问题）。
写法：【情绪光谱】识别"主流声音"与"潜流暗涌"的反差，【核心矛盾】用序号列举冲突点。
### 3. signals — 异动与弱信号（150字以内）
任务：捕捉时间轴（轨迹）和空间轴（跨平台）上的异常波动。拒绝平铺直叙的单点罗列。
关注维度：
- 跨平台共振：某话题在A平台爆发后，是否迅速引发B平台关注？（对应"破圈扩散"）
- 平台温差：某话题在微博霸榜但在知乎无人问津（对应"圈层热点"）
- 轨迹突变：排名骤升（急升）、死而不僵（僵尸）、反转复活（回榜）
写法：必须结合跨平台特征分析，拒绝只列举单个平台的涨跌。用【标签】分段（不用序号），从【跨平台共振/温差】【轨迹突变】【弱信号捕捉】等维度至少覆盖2点。
### 4. rss_insights — RSS深度洞察（100字以内）
任务：寻找信息增量。RSS 源通常比大众热榜更垂直、更专业。
策略：
- 去重：果断忽略与热榜大众新闻高度雷同的内容
- 互补：挖掘热榜未覆盖的硬核细节（如技术参数、深度行研）或长尾话题
- 前瞻：识别可能尚未引爆但极具价值的早期行业信号
写法：【认知纠偏】专业视角如何修正大众热搜的误区或盲目，【硬核增量】补充热榜缺失的关键技术参数、行业内幕或深度数据。无RSS数据时填"暂无RSS数据"。
### 5. outlook_strategy — 研判策略建议
任务：预测与推演。不仅总结过去，更要预测未来。
核心：
- 后续推演：预测事件的下一阶段（如：是否会反转？监管是否介入？热度是否可持续？）
- 行动指南：给出具体、有针对性的建议。严禁使用"建议持续关注"等无意义的正确的废话。
写法：格式为 1. 投资者：xxx 2. 品牌方：xxx 3. 公众：xxx，序号后直接跟角色名加冒号，不使用【】标签。
### 6. standalone_summaries — 独立展示区概括（每源100字以内）
仅当数据中包含独立展示区数据时返回。对象类型，key 为数据中每个源的 ### 标题方括号内的名称，value 为 100 字以内的概括。有几个源就写几个 key。
核心原则：去重补盲 + 轨迹洞察。
1. 去重：果断忽略前5板块已充分分析的话题，优先提取前5板块未覆盖的独有内容。若某话题虽在前5板块提及但在该平台有独特表现（如排名走势截然不同），可简要补充差异点。
2. 轨迹洞察：若数据中包含轨迹信息，按上述"### 2. 轨迹量化分析"的规则解读排名走势，识别该平台的急升/衰退/回榜等趋势特征。若数据中无轨迹信息，则基于排名和出现次数做简要判断即可。
写法：先用一句话点明该平台当前的整体趋势动向（基于轨迹数据判断），再列举前5板块未提及的重要话题（附带排名走势）。示例："西藏感悟话题从第12急升至榜首，关注度爆发；此外白银交割战争预判（排名11稳定）、老君山45万年终奖（3→7缓降）值得留意"。禁止空泛总结。
[user]
请分析以下热点新闻数据：
@ -122,25 +161,27 @@
## RSS 订阅
{rss_content}
## 独立展示区
以下为独立展示的完整热榜/RSS 数据（不受关键词过滤），请按板块说明中 standalone_summaries 的要求处理。
{standalone_content}
---
请基于上述数据撰写分析报告，以 JSON 格式返回结果：
请基于上述数据撰写分析报告。以 JSON 格式返回，所有字段均为可选（缺少任何字段不会报错）：
```json
{
"core_trends": "核心热点态势（200字以内）。**任务：提炼共性叙事而非简单罗列**。语言要像'大白话'一样通俗，但要像'手术刀'一样精准。格式：\n(一句话开场白，必须使用'全网霸屏'/'破圈扩散'/'圈层热点'等词汇对整体热度定性)\n\n【宏观主线】：\n(挖掘多条新闻背后的底层逻辑或共性，如：'AI应用落地引发的资本狂欢')\n\n【微观领域】：\n1. (细分点1)：...\n2. (细分点2)：...",
"sentiment_controversy": "舆论风向争议（100字以内）。**拒绝和稀泥，直击情绪的'温差'与'断层'**。格式：\n【情绪光谱】：\n(识别'主流声音'与'潜流暗涌'的反差，如：'媒体高歌猛进，民间担忧焦虑')\n\n【核心矛盾】：\n1. (利益/观念冲突)：(如：'打工人与资本家的利益对立')\n2. (事实/认知分歧)：...",
"signals": "异动与弱信号（150字以内）。**必须结合跨平台特征分析，拒绝只列举单个平台的涨跌**。**请勿使用 1. 2. 3. 序号，直接使用【标签】分段**。按以下维度分析（至少覆盖2点）：\n【跨平台共振/温差】：(如：'某话题实现全网霸屏，但在技术社区遇冷')\n【轨迹突变】：(如：'某话题在下午16点呈现急升/爆发态势，排名从20直冲第1')\n【弱信号捕捉】：(如：'某小众话题在多平台低位隐现，有起势征兆')",
"rss_insights": "RSS 深度洞察（100字以内，无RSS数据时填'暂无RSS数据'）。**核心任务：寻找'热榜盲区'**。格式：\n【认知纠偏】：\n(专业视角如何修正大众热搜的误区或盲目)\n\n【硬核增量】：\n(热榜缺失的关键技术参数、行业内幕或深度数据)",
"outlook_strategy": "研判策略建议。**拒绝'建议持续关注'等废话，基于'推演'给出行动指南**。格式：\n1. 投资者：(风口捕捉或风险预警)\n2. 品牌方：(流量借势或公关避坑)\n3. 公众：(认知纠偏或生活决策)"
"core_trends": "（按上述板块说明写法输出）",
"sentiment_controversy": "（按上述板块说明写法输出）",
"signals": "（按上述板块说明写法输出）",
"rss_insights": "（按上述板块说明写法输出）",
"outlook_strategy": "（按上述板块说明写法输出）",
"standalone_summaries": {"知乎": "100字概括，优先列前5板块未提及的话题及排名走势", "Hacker News": "100字概括..."}
}
```
要求：
- 必须返回有效的 JSON 格式
- 返回内容中不要使用 Markdown 格式（如 **加粗**），仅使用纯文本
- 必须返回有效的 JSON，用 ```json 代码块包裹
- 使用 {language} 输出，语言简练专业
- 确保 5 个板块不重叠，信息不冗余
- 若某板块无明显内容，可简写"暂无显著异常"
- 使用 `【大标题】` 时，不要前面加序号
- 使用 `1. 序号` 时，行内绝对禁止再使用 `【】` 方括号
- 6个板块内容不重叠不冗余
- 若某板块无明显内容，可简写"暂无显著异常"

3
apps/trendradar/5.5.3/config/ai_translation_prompt.txt
View File

@ -1,6 +1,6 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar AI 翻译提示词配置
# Version: 1.0.0
# Version: 1.1.0
# ═══════════════════════════════════════════════════════════════
#
# 此文件定义 AI 翻译内容时使用的提示词模板
@ -19,6 +19,7 @@
2. 保持新闻标题的吸引力，但不要做标题党。
3. 专有名词（人名、地名、机构名）若有通用译名请使用通用译名，否则保留原文或在括号内备注。
4. 输出格式必须严格遵循要求，不要输出任何多余的解释性文字。
5. 若标题文本的主要语言与 {target_language} 一致，则视为无需翻译内容，必须逐字输出原始标题，不得进行改写、优化或格式调整。
[user]
请将以下内容翻译成 {target_language}：

105
apps/trendradar/5.5.3/config/config.yaml
View File

@ -1,6 +1,6 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar 配置文件
# Version: 1.1.0
# Version: 2.0.0
# ═══════════════════════════════════════════════════════════════
@ -11,7 +11,7 @@
# 1. 基础设置
# ===============================================================
app:
# 时区配置（影响所有时间显示、推送窗口判断、数据存储）
# 时区配置（影响所有时间显示、调度系统判断、数据存储）
# 常用时区：
# - Asia/Shanghai (北京时间 UTC+8)
# - America/New_York (美东时间 UTC-5/-4)
@ -21,6 +21,29 @@ app:
show_version_update: true # 显示版本更新提示
# ===============================================================
# 1.5 调度系统 —— 什么时间做什么事
#
# 通过 timeline.yaml 里定义的时间段来自动决定：
# - 什么时候推送通知
# - 什么时候做 AI 分析
# - 用什么报告模式
#
# 快速上手：选一个预设模板，改 preset 的值就行
#
# always_on → 全天候，有新增即推送
# morning_evening → 全天推送 + 晚间当日汇总（推荐）
# office_hours → 工作日三段式（到岗→午间→收工），周末增量自由推
# night_owl → 午后速览 + 深夜全天汇总
# custom → 完全自定义，详见 timeline.yaml
#
# 详细时间线图请查看 config/timeline.yaml
# ===============================================================
schedule:
enabled: true # 是否启用调度系统
preset: "morning_evening" # 预设模板名称（见上方说明）
# ===============================================================
# 2. 数据源 - 热榜平台
#
@ -134,6 +157,9 @@ rss:
# ===============================================================
report:
mode: "current" # 可选: daily | current | incremental
# ⚠️ 开启调度系统后，此值会被当前时间段的 report_mode 覆盖
display_mode: "keyword" # 分组维度: keyword | platform
# keyword: 按关键词分组显示（默认）
# platform: 按平台/来源分组显示
@ -176,24 +202,24 @@ display:
# 控制各区域是否启用（配合 region_order 使用）
regions:
hotlist: true # 热榜区域（关键词匹配的热点新闻）
new_items: true # 新增热点区域（含热榜新增 + RSS 新增）
new_items: false # 新增热点区域（含热榜新增 + RSS 新增）
# 注：热点词汇统计中的新增标记🆕不受此配置影响
rss: false # RSS 订阅区域
rss: true # RSS 订阅区域
# 开启后将对 RSS 进行关键词分析并在通知中展示
# 关闭后跳过分析，但独立展示区不受影响
standalone: false # 独立展示区（完整热榜/RSS，不受关键词过滤）
ai_analysis: true # AI 分析区域
# 📋 独立展示区配置（仅在 regions.standalone: true 时生效）
# 用途：将指定平台的完整热榜/RSS 单独展示，不受关键词过滤影响
# 适用场景：
# - 想完整查看某个平台的热榜排名
# - RSS 源内容较少，希望全部展示而非只显示关键词匹配的
# 注意：同一新闻可能同时出现在关键词匹配区和独立展示区
# 📋 独立展示区配置
# 用途：将指定平台的完整热榜/RSS 数据独立提取，不受关键词过滤影响
# 两个独立用途：
# - 推送展示：由 regions.standalone 开关控制，在推送中单独展示完整热榜
# - AI 分析：由 ai.include_standalone 开关控制，将完整数据送入 AI 做深度分析
# 两者共享此处的平台/RSS 配置，但开关互相独立（可只开 AI 分析、不推送展示）
standalone:
platforms: [] # 热榜平台 ID 列表（如 ["zhihu", "weibo"]）
platforms: ["zhihu", "wallstreetcn-hot"] # 热榜平台 ID 列表（如 ["zhihu", "weibo"]）
rss_feeds: [] # RSS 源 ID 列表（如 ["hacker-news"]）
max_items: 20 # 每个源最多展示条数（0=不限制）
@ -219,21 +245,10 @@ display:
# • 邮箱已支持多收件人（逗号分隔）
# ===============================================================
notification:
enabled: true # 是否启用通知功能
# 🕐 推送时间窗口控制（可选功能）
# 用途：限制推送的时间范围，避免非工作时间打扰
# 适用场景：
# • 只想在工作日白天接收推送（如 09:00-18:00）
# • 希望在晚上固定时间收到汇总（如 20:00-22:00）
# ⚠️ GitHub Actions 用户注意：
# 执行时间不稳定，时间范围建议至少留足 2 小时
# 💡 想要精准定时？建议使用 Docker 部署在个人服务器上
push_window:
enabled: false # 是否启用推送时间窗口控制
start: "20:00" # 开始时间（北京时间）
end: "22:00" # 结束时间（北京时间）
once_per_day: true # true=窗口内只推送一次，false=窗口内每次执行都推送
enabled: true # 是否启用通知功能（总开关）
# ⚠️ 开启调度系统后，此项仍为总开关：
# false → 永远不推送（无论调度怎么设置）
# true → 由调度的 push 字段控制何时推送
# 推送渠道配置
channels:
@ -390,21 +405,10 @@ ai:
# 模型配置见上方 ai 配置段
# ===============================================================
ai_analysis:
enabled: true # 是否启用 AI 分析
# 🕐 AI 分析时间窗口控制（可选功能）
# 用途：限制 AI 分析的时间范围，避免非必要时段消耗 API 额度
# 适用场景：
# • 只在工作时间进行 AI 分析（如 09:00-18:00）
# • 在特定时段进行深度分析（如 20:00-22:00）
# ⚠️ GitHub Actions 用户注意：
# 执行时间不稳定，时间范围建议至少留足 2 小时
# 💡 想要精准定时？建议使用 Docker 部署在个人服务器上
analysis_window:
enabled: false # 是否启用 AI 分析时间窗口控制
start: "12:00" # 开始时间（使用 app.timezone 配置的时区）
end: "21:00" # 结束时间（使用 app.timezone 配置的时区）
once_per_day: false # true=窗口内只分析一次，false=窗口内每次执行都分析
enabled: true # 是否启用 AI 分析（总开关）
# ⚠️ 开启调度系统后，此项仍为总开关：
# false → 永远不分析（无论调度怎么设置）
# true → 由调度的 analyze 字段控制何时分析
# 分析报告输出语言
# 格式：自然语言描述
@ -428,25 +432,30 @@ ai_analysis:
mode: "follow_report"
# 分析内容配置
max_news_for_analysis: 60 # 参与分析的新闻数量上限（控制成本关键项）
max_news_for_analysis: 150 # 热榜+RSS 合计参与分析的新闻数量上限（控制成本关键项）
# 热榜优先占用配额，RSS 使用剩余配额；独立展示区不受此限制
# 推送消息顶部会显示实际的 AI 分析数供参考
# api 成本估算 (仅供参考)
# 按默认模型(deepseek)
# max_news_for_analysis 为 50 条
# include_rank_timeline 为 false
# max_news_for_analysis 为 【50】 条
# include_rank_timeline 为 【false】
# 则
# GitHub Action 部署默认推送约 20 次（每小时推送一次）， 约 0.1 元/天
# Docker 部署默认推送 48 次(每半小时推送一次)， 约 0.2 元/天
include_rss: false # 是否包含 RSS 内容进行分析
include_rss: false # 是否包含 RSS 内容进行分析
include_standalone: true # 是否将独立展示区数据纳入 AI 分析（只需上方 display 区的 standalone 配置了平台/RSS 即可）
include_rank_timeline: true # 是否传递完整排名时间线
include_rank_timeline: true # 是否传递完整排名时间线
# false: 使用简化格式（排名范围+时间范围+出现次数）
# true: 传递完整排名变化轨迹（如 1(09:30)→2(10:00)→0(11:00)）
# 启用后 AI 能更精确分析热度趋势，但会额外增加 token 消耗（0.5 倍到 1 倍）
# ===============================================================
# 10. AI 翻译功能
#
@ -459,7 +468,7 @@ ai_translation:
# 翻译目标语言
# 格式：自然语言描述
# 示例: "Chinese", "Korean", "法语"
language: "English"
language: "中文"
# 提示词配置文件路径（相对于 config 目录）
prompt_file: "ai_translation_prompt.txt"
@ -508,4 +517,4 @@ advanced:
bark: 4000
slack: 4000
batch_send_interval: 3 # 批次发送间隔（秒）
feishu_message_separator: "━━━━━━━━━━━━━━━━━━━"
feishu_message_separator: "━━━━━━━━━━━━━━━━"

518
apps/trendradar/5.5.3/config/timeline.yaml Normal file
View File

@ -0,0 +1,518 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar 时间线配置
# Version: 1.0.0
# ═══════════════════════════════════════════════════════════════
#
# 这个文件控制「什么时间做什么事」。
#
# 大多数人不需要编辑这个文件。
# 只需在 config.yaml 中选择一个预设模板即可：
#
# schedule:
# preset: "morning_evening" ← 改这里就行
#
#
# 可视化配置编辑器地址: https://sansan0.github.io/TrendRadar/
#
#
# ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
# 📖 基本概念（帮助你理解后面的配置）
# ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
#
#
# 🔁 程序是怎么运行的？
#
# TrendRadar 不是一直在后台运行的，而是被「定时闹钟」周期性唤醒：
#
# GitHub Actions 用户 → 由 .github/workflows/crawler.yml 中的 cron 定时触发
# 默认每小时运行一次（如每小时第 33 分钟）
#
# Docker 用户 → 由 docker/.env 中的 CRON_SCHEDULE 定时触发
# 默认每 30 分钟运行一次
#
# 每次被唤醒后，程序按以下三个阶段依次执行：
#
# 1️⃣ 采集（collect）
# 爬取各热榜平台 + RSS 订阅源的最新数据，存入数据库
#
# ⬇
#
# 2️⃣ 分析（analyze）
# 调用 AI 大模型对采集到的新闻进行深度分析（可选，需配置 API Key）
#
# ⬇
#
# 3️⃣ 推送（push）
# 将整理好的热点新闻 + AI 分析结果发送到你的通知渠道
# （飞书、钉钉、Telegram、邮件等）
#
# 这三个阶段都可以独立开关。本文件的作用就是控制：
# 「在什么时间段，开启/关闭哪些阶段」。
#
#
# 🔌 config.yaml 总开关 与 timeline 时间段开关 的关系
#
# config.yaml 里有几个「总开关」，它们的优先级高于本文件：
#
# platforms.enabled: false → 永远不爬热榜（无论 timeline 怎么设置）
# rss.enabled: false → 永远不爬 RSS（同上）
# notification.enabled: false → 永远不推送（同上）
# ai_analysis.enabled: false → 永远不分析（同上）
#
# 只有当总开关为 true 时，timeline 的时间段开关才会生效。
# 换句话说：总开关决定「能不能做」，timeline 决定「什么时候做」。
#
#
# ⏰ 什么是「时间段」和「静默期」？
#
# 你可以把一天想象成一条时间线，上面划分了若干个「时间段」。
# 每个时间段有自己的行为开关（是否采集、是否分析、是否推送）。
#
# 而不在任何时间段内的时间，就叫「静默期」（走 default 默认配置）。
# 静默期通常必须要采集，这样数据一直在积累，
# 等到推送时，就能汇总出完整的报告。
#
#
# 💡 静默期越长，积累的数据越丰富（排名变化轨迹、上榜/下榜时间等），
# 最终提交给 AI 分析的上下文也越完整，分析质量更高。
# 相比 MCP Server，该方案的全天数据能呈现更完整的热度趋势和变化脉络。
#
#
# ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
# 📋 预设模板一览（选一个就行）
# ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
#
# 1️⃣ always_on 全天候，有新增就推（默认）
# 2️⃣ morning_evening 全天推送 + 晚间汇总（推荐大多数人）
# 3️⃣ office_hours 工作日三段式：到岗速览→午间热点→收工汇总
# 4️⃣ night_owl 午后速览 + 深夜全天汇总
# 5️⃣ custom 完全自定义（需要编辑本文件底部的 custom 段）
#
# 想自定义？两种方式：
# 1. 直接翻到本文件底部的「自定义模式」部分
# 2. 在下方 presets 里新增你自己的预设模板
# （只要 key 不重复，然后在 config.yaml 里填你的模板名即可）
#
# ⚠️ 关于时间段设计的建议：
# GitHub Actions： 建议定时任务间隔 ≥ 2 小时。由于系统触发存在随机延迟，间隔过短可能导致任务漏运行。
# Docker 用户：cron 定时是准时的，无此限制，按需设置即可。
#
#
# ═══════════════════════════════════════════════════════════════
# ───────────────────────────────────────────────────────────────
# 预设模板
# ───────────────────────────────────────────────────────────────
presets:
# ───────────────────────────────────────────────────────────
# 1️⃣ always_on - 全天候监控
#
# 最简单的模式：全天候采集 + 推送，有新增就通知你。
# 不划分时间段，全天使用同一套配置。
# 适合：重度用户、实时舆情监控
#
# 全天：推送 ✓ | AI分析 ✗ | 不限推送次数
# ───────────────────────────────────────────────────────────
always_on:
name: "全天监控"
description: "全天候监控，有新增立即推送。适合重度用户。"
# 默认配置 ── 不在任何时间段内时，使用这组开关
# 因为这个模式没有划分时间段，所以 default 就是全天的行为
default:
collect: true # 采集数据（爬取热榜 + RSS）
analyze: false # 不做 AI 分析（节省 API 费用）
ai_mode: "current" # AI 分析当前榜单
push: true # 有新内容就推送
report_mode: "incremental" # 只推送新增内容，避免重复
once: # 限制每个时间段内只执行一次
analyze: false # 不限制分析次数
push: false # 不限制推送次数
# 没有定义任何时间段，全天都走 default
#
# 语法提示：{} 是 YAML 的「空字典」写法，表示里面没有任何内容。
# 等价于写成多行但什么都不填。后面的 [] 同理，表示「空列表」。
periods: {}
day_plans:
all_day:
periods: [] # 空列表 = 这天不启用任何时间段
week_map:
1: "all_day" # 周一
2: "all_day" # 周二
3: "all_day" # 周三
4: "all_day" # 周四
5: "all_day" # 周五
6: "all_day" # 周六
7: "all_day" # 周日
# ───────────────────────────────────────────────────────────
# 2️⃣ morning_evening - 早晚汇总（推荐）
#
# 全天推送当前热点 + 晚间做一次当日全天汇总。
# 适合：大多数人
#
# 默认（全天）：推送 ✓ | AI分析 ✓ | 不限推送次数
# 晚间汇总：推送 ✓ | AI分析 ✓ | 只推/分析一次
# ───────────────────────────────────────────────────────────
morning_evening:
name: "早晚汇总"
description: "全天推送 + 晚间当日汇总。适合大多数人。"
# 默认配置 ── 不命中任何时间段时的行为
default:
collect: true # 始终采集
analyze: true # AI 分析当前榜单
ai_mode: "current" # AI 分析当前榜单
push: true # 每次推送当前在榜热点
report_mode: "current" # 当前在榜的新闻
once:
analyze: false # 不限制分析次数
push: false # 不限制推送次数
# 时间段定义 ── 只有晚间汇总需要特殊处理
periods:
evening_summary:
name: "晚间汇总"
start: "20:00"
end: "22:00"
analyze: true # 晚间做 AI 分析
ai_mode: "daily" # AI 也汇总全天内容
report_mode: "daily" # 切换为当日全部新闻汇总
once:
analyze: true # 窗口内只分析一次
push: true # 窗口内只推送一次
# 日计划 ── 把时间段组装成一天的安排
day_plans:
all_day:
periods: ["evening_summary"]
# 周映射 ── 每天用哪个日计划（1=周一 ... 7=周日）
week_map:
1: "all_day"
2: "all_day"
3: "all_day"
4: "all_day"
5: "all_day"
6: "all_day"
7: "all_day"
# ───────────────────────────────────────────────────────────
# 3️⃣ office_hours - 办公时间推送
#
# 工作日三段式推送，周末增量自由推。
# 适合：上班族、企业用户
#
# 默认（静默期）：推送 ✗ | AI分析 ✗
# 到岗速览：推送 ✓ | AI分析 ✓ | 只推一次
# 午间热点：推送 ✓ | AI分析 ✗ | 只推一次
# 收工汇总：推送 ✓ | AI分析 ✓ | 只推一次
# 周末自由：推送 ✓ | AI分析 ✗ | 不限推送次数
# ───────────────────────────────────────────────────────────
office_hours:
name: "办公时间"
description: "工作日三段式推送（到岗→午间→收工），周末增量自由推送。"
default:
collect: true
analyze: false
ai_mode: "current"
push: false # 默认不推送
report_mode: "current"
once:
analyze: true # 每个时段只分析一次
push: true # 每个时段只推送一次
periods:
morning_briefing:
name: "到岗速览"
start: "09:00"
end: "11:00"
analyze: true # AI 分析当前热点
ai_mode: "current" # AI 分析当前榜单
push: true # 到岗后看当前热点
report_mode: "current" # 当前在榜的新闻
# once 继承 default（analyze: true, push: true）→ 只推/分析一次
noon_update:
name: "午间热点"
start: "13:00"
end: "15:00"
push: true # 午间推送当前在榜热点
report_mode: "current" # 当前在榜的新闻
# analyze 继承 default: false → 午间不做 AI 分析，节省 API
# once 继承 default（push: true）→ 只推一次
closing_summary:
name: "收工汇总"
start: "17:00"
end: "19:00"
analyze: true # AI 做全天汇总分析
ai_mode: "daily" # AI 也分析全天内容
push: true # 下班前推送当日完整汇总
report_mode: "daily" # 当日全部新闻汇总
# once 继承 default（analyze: true, push: true）→ 只推/分析一次
weekend_free:
name: "周末自由"
start: "08:00"
end: "23:00"
ai_mode: "current" # AI 分析当前榜单
push: true # 有新增就推送
report_mode: "incremental" # 增量模式：有新增才推，没有就安静
once:
analyze: false # 不限制分析次数
push: false # 不限制推送次数
# 工作日使用三段式推送；周末使用增量自由模式
day_plans:
workday:
periods: ["morning_briefing", "noon_update", "closing_summary"]
weekend:
periods: ["weekend_free"] # 周末：有新增就推，不打扰睡眠
week_map:
1: "workday" # 周一 → 工作日计划
2: "workday"
3: "workday"
4: "workday"
5: "workday"
6: "weekend" # 周六 → 周末计划
7: "weekend" # 周日 → 周末计划
# ───────────────────────────────────────────────────────────
# 4️⃣ night_owl - 夜猫子模式
#
# 白天安静，午后和深夜各推一次。
# 适合：夜间工作者、海外时差用户、自由职业者
#
# 默认（白天静默）：推送 ✗ | AI分析 ✗
# 午后速览：推送 ✓ | AI分析 ✓ | 只推一次
# 深夜汇总：推送 ✓ | AI分析 ✓ | 只推一次
# ───────────────────────────────────────────────────────────
night_owl:
name: "夜猫子模式"
description: "午后速览 + 深夜全天汇总。适合夜间工作者、海外时差用户。"
default:
collect: true
analyze: false
ai_mode: "current"
push: false
report_mode: "current"
once:
analyze: true # 每个时段只分析一次
push: true # 每个时段只推送一次
periods:
afternoon_peek:
name: "午后速览"
start: "15:00"
end: "17:00"
analyze: true # AI 分析当前热点
ai_mode: "current" # AI 分析当前榜单
push: true # 午后看当前热点
report_mode: "current" # 当前在榜的新闻
# once 继承 default（analyze: true, push: true）→ 只推/分析一次
late_night:
name: "深夜汇总"
start: "22:00"
end: "01:00" # start > end → 自动识别为跨日
analyze: true # AI 做全天汇总分析
ai_mode: "daily" # AI 也分析全天内容
push: true # 深夜推送当日完整汇总
report_mode: "daily" # 当日全部新闻汇总
# once 继承 default（analyze: true, push: true）→ 只推/分析一次
day_plans:
all_day:
periods: ["afternoon_peek", "late_night"]
week_map:
1: "all_day"
2: "all_day"
3: "all_day"
4: "all_day"
5: "all_day"
6: "all_day"
7: "all_day"
# ═══════════════════════════════════════════════════════════════
#
# 5️⃣ 自定义模式
#
# 当 config.yaml 中设置 schedule.preset: "custom" 时，
# 系统会读取下面这段配置。
#
# 如果上面的预设模板无法满足你的需求，可以在这里自由定义。
#
# ═══════════════════════════════════════════════════════════════
#
# 自定义配置的思路很简单，就像搭积木：
#
# 第 1 步：定义「积木块」（periods）
# 每块积木 = 一个时间段 + 这段时间要做什么
# 例如：早间 08-10 推送、晚间 19-21 汇总
#
# 第 2 步：拼成「一天的安排」（day_plans）
# 把积木块组合起来，形成一天的日程
# 例如：工作日用 [早间, 晚间]，周末用 [晚间]
#
# 第 3 步：指定「每天用哪个安排」（week_map）
# 周一到周日，分别对应哪个日计划
# 例如：周一~周五用 workday，周六周日用 weekend
#
# 另外还有一个「默认配置」（default），
# 当某个时刻不在任何积木块内时，就用默认配置。
# 积木块里没写的字段，也会自动回退到默认配置。
#
#
# 下面是一个完整的自定义示例，工作日和周末使用不同的时间段安排：
#
# 工作日时间段:
# 深夜静默 23:00-06:00（跨日）：采集 ✓ | 分析 ✓ | 推送 ✗
# 工作日早间 08:00-10:00：推送 ✓ | incremental
# 晚间汇总 19:00-21:00：推送 ✓ | 分析 ✓ | daily
# 其余时间走默认配置（静默采集）
#
# 周末时间段:
# 深夜静默 23:00-06:00（跨日）：采集 ✓ | 分析 ✓ | 推送 ✗
# 周末早间 10:00-12:00：推送 ✓ | daily
# 晚间汇总 19:00-21:00：推送 ✓ | 分析 ✓ | daily
# 其余时间走默认配置（静默采集）
custom:
name: "自定义"
description: "完全自由定义时间段、日计划和周映射。"
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 默认配置
#
# 当前时刻不在任何时间段（积木块）内时，使用这组开关。
# 时间段中没有写的字段，也会回退到这里。
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
default:
collect: true # 是否采集数据（爬取热榜 + RSS）
analyze: false # 是否执行 AI 分析
ai_mode: "current" # AI 分析模式:
# follow_report → 跟随 report_mode
# daily → 强制全天汇总
# current → 强制当前榜单
# incremental → 强制增量模式
push: false # 是否发送推送通知
report_mode: "current" # 报告模式:
# daily → 当日所有新闻的汇总
# current → 当前在榜的新闻
# incremental → 只推送新增内容
once:
analyze: true # 该时间段内只分析一次（省 API）
push: true # 该时间段内只推送一次（省打扰）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 第 1 步：定义积木块（时间段）
#
# 每个时间段有一个唯一的 key（如 deep_quiet），
# 以及 start / end 表示生效的时间范围。
#
# 只需要写「和 default 不同的字段」，其余自动继承 default。
# 例如 weekday_morning 没写 collect，就会继承 default 的 collect: true。
#
# 提示：如果 start > end（如 22:00 → 07:00），
# 系统会自动识别为跨越午夜的时间段。
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
periods:
deep_quiet:
name: "深夜静默"
start: "23:00"
end: "06:00" # 23:00 → 次日 06:00（跨日时间段）
collect: true # 夜间继续采集数据
analyze: true # 夜间可以跑 AI 分析（反正不推送）
push: false # 深夜不推送，避免打扰
weekday_morning:
name: "工作日早间"
start: "08:00"
end: "10:00" # 跨度 2h，留足触发裕量
push: true # 早上推送一次
report_mode: "incremental" # 只推新增内容
# once 继承 default（push: true）→ 窗口内只推一次
weekend_morning:
name: "周末早间"
start: "10:00"
end: "12:00" # 跨度 2h
push: true
report_mode: "daily" # 周末看全天汇总
# once 继承 default（push: true）→ 窗口内只推一次
evening_summary:
name: "晚间汇总"
start: "19:00"
end: "21:00"
analyze: true # 晚间做 AI 分析
ai_mode: "daily" # AI 也分析全天内容
push: true # 晚间推送
report_mode: "daily" # 当日全部新闻汇总
# once 继承 default（analyze: true, push: true）→ 只分析/推送一次
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 第 2 步：把积木块拼成日计划
#
# 把上面定义的时间段组合成一天的安排。
# 你可以定义多个日计划（如 workday 和 weekend），
# 然后在第 3 步的 week_map 中分配给不同的星期。
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
day_plans:
workday: # 工作日计划
periods: ["deep_quiet", "weekday_morning", "evening_summary"]
weekend: # 周末计划（用 weekend_morning 替换 weekday_morning）
periods: ["deep_quiet", "weekend_morning", "evening_summary"]
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 第 3 步：指定每天用哪个日计划
#
# 1=周一 2=周二 3=周三 4=周四 5=周五 6=周六 7=周日
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
week_map:
1: "workday" # 周一 → 工作日计划
2: "workday" # 周二
3: "workday" # 周三
4: "workday" # 周四
5: "workday" # 周五
6: "weekend" # 周六 → 周末计划
7: "weekend" # 周日
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 冲突策略（一般不用改）
#
# 什么是「冲突」？
# 如果你的两个时间段有重叠（比如 A 是 08:00-12:00，B 是 10:00-14:00），
# 那么 10:00-12:00 这段时间就同时属于 A 和 B，产生了冲突。
# 此时程序需要知道：到底听谁的？
#
# 两种处理方式：
#
# error_on_overlap（推荐）
# 直接报错，提醒你去修改配置。
# 适合大多数人 —— 时间段重叠通常是写错了，报错能及时发现。
#
# last_wins
# day_plans 的 periods 列表中，写在后面的优先。
# 比如 periods: ["A", "B"]，重叠时 B 生效。
# 适合场景：你想用一个大范围时间段打底，再用后面的小范围覆盖。
#
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
overlap:
policy: "error_on_overlap"