diff --git a/apps/trendradar/5.5.3/config/ai_analysis_prompt.txt b/apps/trendradar/5.5.3/config/ai_analysis_prompt.txt index 6ca73a996..aeffe04b3 100644 --- a/apps/trendradar/5.5.3/config/ai_analysis_prompt.txt +++ b/apps/trendradar/5.5.3/config/ai_analysis_prompt.txt @@ -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. 序号` 时，行内绝对禁止再使用 `【】` 方括号 \ No newline at end of file +- 6个板块内容不重叠不冗余 +- 若某板块无明显内容，可简写"暂无显著异常" \ No newline at end of file diff --git a/apps/trendradar/5.5.3/config/ai_translation_prompt.txt b/apps/trendradar/5.5.3/config/ai_translation_prompt.txt index d5a4e12da..db7ee1ba0 100644 --- a/apps/trendradar/5.5.3/config/ai_translation_prompt.txt +++ b/apps/trendradar/5.5.3/config/ai_translation_prompt.txt @@ -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}： diff --git a/apps/trendradar/5.5.3/config/config.yaml b/apps/trendradar/5.5.3/config/config.yaml index 75ba5b13c..30c108fc9 100644 --- a/apps/trendradar/5.5.3/config/config.yaml +++ b/apps/trendradar/5.5.3/config/config.yaml @@ -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: "━━━━━━━━━━━━━━━━━━━" \ No newline at end of file + feishu_message_separator: "━━━━━━━━━━━━━━━━" \ No newline at end of file diff --git a/apps/trendradar/5.5.3/config/timeline.yaml b/apps/trendradar/5.5.3/config/timeline.yaml new file mode 100644 index 000000000..f1d55b1ab --- /dev/null +++ b/apps/trendradar/5.5.3/config/timeline.yaml @@ -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" \ No newline at end of file