pooneyy/1Panel-Appstore
1
0
Fork 0
Code Activity

chore(deps): update wantcat/trendradar docker tag to v6 (#3993)

Browse Source
This commit is contained in:
renovate[bot]
2026-02-13 22:43:36 +08:00
committed by GitHub
parent 32388f3e6e
commit efe7c58caa
7 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

187
apps/trendradar/6.0.0/config/ai_analysis_prompt.txt Normal file
View File

@@ -0,0 +1,187 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar AI 分析提示词配置
# 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)
# {standalone_content} - 独立展示区数据 (需开启 ai_analysis.include_standalone)
#
# ═══════════════════════════════════════════════════════════════
[system]
你是一名高级情报分析师。你的核心能力是从海量、碎片化的公开来源情报（OSINT）中提炼核心逻辑，并识别被大众忽略的弱信号。
## 核心思维模型 (Mental Models)
1. 见微知著 (Signal Detection)：不要只盯着榜首的大新闻。要善于从"排名第50的冷门技术贴"与"排名第1的热门事件"中找到潜在的因果联系。
2. 交叉验证 (Triangulation)：利用"热榜"（大众情绪）与"RSS"（专家视角）的差异。当两者观点冲突时，通常隐藏着认知套利的机会。
3. 反直觉思考 (Counter-Intuitive)：当全网都在叫好时，寻找风险；当全网都在恐慌时，寻找机会。拒绝平庸的共识。
4. 结构化输出 (MECE)：确保分析维度相互独立且完全穷尽，避免逻辑混乱。
## 核心原则
1. 直击要害：拒绝"综上所述"、"众所周知"等废话。直接输出结论。
2. 逻辑闭环：不仅描述"发生了什么"，必须解释"为什么发生"以及"未来会怎样"。
3. 去情绪化：可以分析舆论的情绪，但你自己的分析必须冷静、客观、冷血。
4. 辩证思维：识别热点背后的"主要矛盾"（如技术变革vs既得利益），抓住事物发展的关键内因。
## 数据字段深度解读指南
### 1. 基础维度
- 来源平台：每一行新闻开头的 [平台名称]（如 [微博]、[知乎]）明确指出了数据来源。请务必注意：后续的排名和轨迹数据仅针对该特定平台的榜单。
- 排名："1"为该平台榜首，数字越小越热。"3-8"表示在该平台排名在第3到第8之间波动。
- 出现次数：次数越多，说明在热榜停留时间越长，热度越持久。
- 时间范围：如"09:30~12:45"，跨度越大说明话题生命力越强。
### 2. 轨迹量化分析（重要）
数据格式为 排名(时间)→排名(时间)...，例如 1(09:30)→0(10:00)→2(10:30)。
关键定义：
- 数值含义：数字代表排名（1为榜首，数字越小越靠前）。0 特指"未上榜"或"脱榜"（即该时间点不在榜单中）。
- 符号含义：→ 代表时间推移。
防幻觉警示（关键）：
- 高位横盘 ≠ 急升：如果轨迹是 2(10:00)→2(10:30)→2(11:00)，说明热度持续稳定，绝对不是"急升"或"爆发"。只有排名数值显著减小（如 10→5）才是急升。请务必区分"热度高"和"热度升"。
请重点分析以下模式：
- 急升/爆发：排名数值在短时间内大幅减小（如 20→3），代表热度飙升，往往意味着突发重大事件。
- 衰退/僵尸：排名数值持续变大且无反弹（如 10→15→20），代表热度正在自然衰退。
- 回榜/反转：序列中出现 0 后又变为高排名（如 5→0→2），代表话题曾脱榜但因新进展"复活"，通常暗示有新爆料或剧情反转。
### 3. 跨平台特征（分级标准）
- 全网霸屏：5个及以上平台同时上榜。真正的"国民级"话题，无死角覆盖。
- 破圈扩散：3-4个平台同时上榜。话题已突破单一社区壁垒，正在向外蔓延。
- 圈层热点：仅在1-2个平台火爆。属于特定人群的狂欢。
平台调性参考 (Platform DNA)：
- 舆论/情绪场：微博（情绪/吃瓜）、抖音/快手（视觉/传播快）、B站（年轻/玩梗）
- 理性/专业场：知乎（深度/批判）、雪球（投资/财经）、IT之家/36氪（科技/商业）
- 资讯/分发场：今日头条（社会/民生）、百度热搜（综合/搜索量）
分析"平台温差"时，请结合平台调性。例如：某话题在微博火但在知乎冷，可能说明该话题"情绪价值大于逻辑价值"或"缺乏深度讨论点"。
## 输出格式规范（严格遵守）
你将以 JSON 格式输出分析结果。每个字段的值是纯文本字符串。
换行规则：
- 用 \n 表示换行（JSON 字符串内标准换行符）
- 段落之间用 \n\n 分隔
结构标签规则（【】仅用于分段）：
- 【】仅用于板块内的结构性分段标签，如【宏观主线】、【跨平台共振】
- 标签后只跟冒号或直接换行（×【宏观主线】两大叙事交织：→ ○【宏观主线】：）
- 标签前用 \n 与前段分隔
- 【】内只允许固定的分段名称，禁止放入话题名、新闻标题等动态内容
- 同一标签下仅有1条内容时不加序号，2条及以上才使用序号
话题引用规则（「」用于行内引用）：
- 提及具体话题、新闻标题、事件名称时，使用「」角引号（×【黄仁勋暴论】→ ○「黄仁勋暴论」）
- 「」是行内标记，不触发换行，不加冒号
序号规则：
- 列举时用 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]
请分析以下热点新闻数据：
## 数据概览
- 报告模式：{report_mode} ({report_type})
- 分析时间：{current_time}
- 数据量：{news_count}条热榜 + {rss_count}条RSS
- 来源：{platforms}
## 匹配关键词
{keywords}
## 热榜新闻
{news_content}
## RSS 订阅
{rss_content}
## 独立展示区
以下为独立展示的完整热榜/RSS 数据（不受关键词过滤），请按板块说明中 standalone_summaries 的要求处理。
{standalone_content}
---
请基于上述数据撰写分析报告。以 JSON 格式返回，所有字段均为可选（缺少任何字段不会报错）：
```json
{
"core_trends": "（按上述板块说明写法输出）",
"sentiment_controversy": "（按上述板块说明写法输出）",
"signals": "（按上述板块说明写法输出）",
"rss_insights": "（按上述板块说明写法输出）",
"outlook_strategy": "（按上述板块说明写法输出）",
"standalone_summaries": {"知乎": "100字概括，优先列前5板块未提及的话题及排名走势", "Hacker News": "100字概括..."}
}
```
要求：
- 必须返回有效的 JSON，用 ```json 代码块包裹
- 使用 {language} 输出，语言简练专业
- 6个板块内容不重叠不冗余
- 若某板块无明显内容，可简写"暂无显著异常"

29
apps/trendradar/6.0.0/config/ai_translation_prompt.txt Normal file
View File

@@ -0,0 +1,29 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar AI 翻译提示词配置
# Version: 1.1.0
# ═══════════════════════════════════════════════════════════════
#
# 此文件定义 AI 翻译内容时使用的提示词模板
#
# 可用变量：
# {target_language} - 目标语言
# {content} - 需要翻译的文本内容
#
# ═══════════════════════════════════════════════════════════════
[system]
你是一位精通多语言的专业翻译助手。你的任务是将新闻内容翻译成目标语言，保持新闻的专业性、准确性和简洁性。
要求：
1. 准确传达原文含义，不要遗漏关键信息。
2. 保持新闻标题的吸引力，但不要做标题党。
3. 专有名词（人名、地名、机构名）若有通用译名请使用通用译名，否则保留原文或在括号内备注。
4. 输出格式必须严格遵循要求，不要输出任何多余的解释性文字。
5. 若标题文本的主要语言与 {target_language} 一致，则视为无需翻译内容，必须逐字输出原始标题，不得进行改写、优化或格式调整。
[user]
请将以下内容翻译成 {target_language}：
{content}
请直接输出翻译结果。

520
apps/trendradar/6.0.0/config/config.yaml Normal file
View File

@@ -0,0 +1,520 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar 配置文件
# Version: 2.0.0
# ═══════════════════════════════════════════════════════════════
# 可视化配置编辑器地址: https://sansan0.github.io/TrendRadar/
# ===============================================================
# 1. 基础设置
# ===============================================================
app:
# 时区配置（影响所有时间显示、调度系统判断、数据存储）
# 常用时区：
# - Asia/Shanghai (北京时间 UTC+8)
# - America/New_York (美东时间 UTC-5/-4)
# - Europe/London (伦敦时间 UTC+0/+1)
# 完整时区列表: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
timezone: "Asia/Shanghai"
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. 数据源 - 热榜平台
#
# enabled: 是否启用热榜抓取（总开关）
# sources: 平台列表
# - id: 平台唯一标识（勿修改）
# - name: 显示名称（可自定义，修改后不影响运行）
# 参考: https://github.com/sansan0/TrendRadar/issues/95
# ===============================================================
platforms:
enabled: true # 是否启用热榜平台抓取
sources:
- id: "toutiao"
name: "今日头条"
- id: "baidu"
name: "百度热搜"
- id: "wallstreetcn-hot"
name: "华尔街见闻"
- id: "thepaper"
name: "澎湃新闻"
- id: "bilibili-hot-search"
name: "bilibili 热搜"
- id: "cls-hot"
name: "财联社热门"
- id: "ifeng"
name: "凤凰网"
- id: "tieba"
name: "贴吧"
- id: "weibo"
name: "微博"
- id: "douyin"
name: "抖音"
- id: "zhihu"
name: "知乎"
# ===============================================================
# 3. 数据源 - RSS 订阅
#
# 与热榜数据分开存储，按时间流展示
# 每个源配置：id(唯一标识)、name(显示名称)、url(订阅地址)
# enabled: 可选，默认 true
# max_age_days: 可选，覆盖全局 freshness_filter.max_age_days
# ===============================================================
rss:
enabled: true # 是否启用 RSS 抓取
# 文章新鲜度过滤配置（全局默认值）
# 过滤掉发布时间超过指定天数的旧文章，避免同一篇文章重复出现在推送中
#
# 过滤逻辑：
# - 文章发布时间距当前时间（app.timezone 时区）超过 N 天则不推送
# - 无发布时间的文章会被保留（不过滤）
#
# ⚠️ 过滤时机：在推送阶段过滤
# - 所有文章都会存入数据库（MCP Server 的 AI 查询仍可访问）
# - 只有新鲜的文章会被推送到通知渠道
freshness_filter:
enabled: true # 是否启用新鲜度过滤（默认启用）
max_age_days: 3 # 最大文章年龄（天）
# - 正整数：只推送 N 天内的文章
# - 0：禁用过滤，推送所有文章
# 单个 feed 可配置 max_age_days 覆盖全局设置：
# - 不配置：使用全局 freshness_filter.max_age_days（默认 3 天）
# - 正整数：覆盖全局设置，只推送此天数内的文章
# - 0：禁用此频道的新鲜度过滤，推送所有文章
feeds:
- id: "hacker-news"
name: "Hacker News"
url: "https://hnrss.org/frontpage"
# max_age_days: 1 # 示例：只推送1天内的文章
- id: "ruanyifeng"
name: "阮一峰的网络日志"
url: "http://www.ruanyifeng.com/blog/atom.xml"
# max_age_days: 7 # 示例：推送7天内的文章（更新较慢的博客）
- id: "yahoo-finance"
name: "雅虎财经"
url: "https://finance.yahoo.com/news/rssindex"
enabled: false # 禁用
# 自定义源示例
# - id: "custom-feed"
# name: "自定义源"
# url: "https://example.com/feed.xml"
# enabled: false
# max_age_days: 0 # 示例：禁用过滤，推送所有文章
# ===============================================================
# 4. 报告模式
#
# 🔸 daily（当日汇总模式）
# • 推送时机：按时推送(默认每小时推送一次)
# • 显示内容：当日所有匹配新闻 + 新增新闻区域
# • 适用场景：日报总结、全面了解当日热点趋势
#
# 🔸 current（当前榜单模式）
# • 推送时机：按时推送(默认每小时推送一次)
# • 显示内容：当前榜单匹配新闻 + 新增新闻区域
# • 适用场景：实时热点追踪、了解当前最火的内容
#
# 🔸 incremental（增量监控模式）
# • 推送时机：有新增才推送
# • 显示内容：新出现的匹配频率词新闻
# • 适用场景：避免重复信息干扰
# ===============================================================
report:
mode: "current" # 可选: daily | current | incremental
# ⚠️ 开启调度系统后，此值会被当前时间段的 report_mode 覆盖
display_mode: "keyword" # 分组维度: keyword | platform
# keyword: 按关键词分组显示（默认）
# platform: 按平台/来源分组显示
# 关键词组排序方式（仅 display_mode: keyword 时生效）
# true: 按 frequency_words.txt 中的定义顺序排列
# false: 按匹配到的热点条数排序（条数多的在前）
sort_by_position_first: false
rank_threshold: 5 # 排名高亮阈值
max_news_per_keyword: 0 # 每个关键词最大显示数量（0=不限制）
# ===============================================================
# 5. 推送内容控制
#
# 统一管理推送消息中显示哪些区域及其排列顺序
# ===============================================================
display:
# 📋 区域显示顺序
# 列表从上到下的顺序 = 推送消息中从上到下的显示顺序
# 想调整顺序？直接剪切粘贴整行即可，例如把 ai_analysis 移到最前面：
# region_order:
# - ai_analysis ← 移到第一行，AI 分析就会显示在最顶部
# - new_items
# - hotlist
# - ...
# 注意：区域需同时满足两个条件才会显示：
# 1. 在此列表中
# 2. 下方 regions 中对应开关为 true
region_order:
- new_items # 1️⃣ 新增热点区域
- hotlist # 2️⃣ 热榜区域（关键词匹配）
- rss # 3️⃣ RSS 订阅区域
- standalone # 4️⃣ 独立展示区
- ai_analysis # 5️⃣ AI 分析区域
# 推送区域开关
# 控制各区域是否启用（配合 region_order 使用）
regions:
hotlist: true # 热榜区域（关键词匹配的热点新闻）
new_items: false # 新增热点区域（含热榜新增 + RSS 新增）
# 注：热点词汇统计中的新增标记🆕不受此配置影响
rss: true # RSS 订阅区域
# 开启后将对 RSS 进行关键词分析并在通知中展示
# 关闭后跳过分析，但独立展示区不受影响
standalone: false # 独立展示区（完整热榜/RSS，不受关键词过滤）
ai_analysis: true # AI 分析区域
# 📋 独立展示区配置
# 用途：将指定平台的完整热榜/RSS 数据独立提取，不受关键词过滤影响
# 两个独立用途：
# - 推送展示：由 regions.standalone 开关控制，在推送中单独展示完整热榜
# - AI 分析：由 ai.include_standalone 开关控制，将完整数据送入 AI 做深度分析
# 两者共享此处的平台/RSS 配置，但开关互相独立（可只开 AI 分析、不推送展示）
standalone:
platforms: ["zhihu", "wallstreetcn-hot"] # 热榜平台 ID 列表（如 ["zhihu", "weibo"]）
rss_feeds: [] # RSS 源 ID 列表（如 ["hacker-news"]）
max_items: 20 # 每个源最多展示条数（0=不限制）
# ===============================================================
# 6. 推送通知
#
# ⚠️ 重要安全警告 ⚠️
#
# 🔴 请务必妥善保管好 webhooks，不要公开!!!
# 🔴 如果你以 fork 的方式部署在 GitHub 上，请勿在此填写
# 🔴 而是将 webhooks 填入 GitHub Secrets
# (Settings → Secrets and variables → Actions)
# 🔴 否则：
# - 轻则：手机上收到大量垃圾广告推送
# - 重则：webhook 被滥用造成严重安全隐患
#
# 📌 多账号支持说明
#
# • 使用分号(;)分隔多个账号，如："url1;url2;url3"
# • 需要配对的配置（如 Telegram 的 token 和 chat_id）数量必须一致
# • 每个渠道最多支持 max_accounts_per_channel 个账号
# • 邮箱已支持多收件人（逗号分隔）
# ===============================================================
notification:
enabled: true # 是否启用通知功能（总开关）
# ⚠️ 开启调度系统后，此项仍为总开关：
# false → 永远不推送（无论调度怎么设置）
# true → 由调度的 push 字段控制何时推送
# 推送渠道配置
channels:
feishu:
webhook_url: "" # 飞书机器人 webhook URL
dingtalk:
webhook_url: "" # 钉钉机器人 webhook URL
wework:
webhook_url: "" # 企业微信机器人 webhook URL
msg_type: "markdown" # 消息类型：markdown(群机器人) | text(个人微信应用)
telegram:
bot_token: "" # Telegram Bot Token
chat_id: "" # Telegram Chat ID
email:
from: "" # 发件人邮箱地址
password: "" # 发件人邮箱密码或授权码
to: "" # 收件人邮箱，多个用逗号分隔
smtp_server: "" # SMTP 服务器（可选，留空自动识别）
smtp_port: "" # SMTP 端口（可选，留空自动识别）
ntfy:
server_url: "https://ntfy.sh" # ntfy 服务器地址（可改为自托管）
topic: "" # ntfy 主题名称
token: "" # ntfy 访问令牌（可选，用于私有主题）
bark:
url: "" # Bark 推送 URL（格式：https://api.day.app/your_device_key）
slack:
webhook_url: "" # Slack Incoming Webhook URL
generic_webhook:
webhook_url: "" # 通用 Webhook URL（支持 Discord、Matrix、IFTTT 等）
payload_template: "" # JSON 模板，支持 {title} 和 {content} 占位符
# 示例：{"content": "{content}"}
# 留空则使用默认格式：{"title": "{title}", "content": "{content}"}
# ===============================================================
# 7. 存储配置
# ===============================================================
storage:
# 存储后端选择
# - auto: 自动选择（GitHub Actions 且配置了远程存储 → remote，否则 → local）
# - local: 本地 SQLite + TXT/HTML 文件
# - remote: 远程云存储（S3 兼容协议，支持 R2/OSS/COS 等）
backend: "auto"
# 数据格式选项
formats:
sqlite: true # 主存储（必须启用）
txt: false # 是否生成 TXT 快照
html: true # 是否生成 HTML 报告（⚠️ 邮件推送或者需要看网页版报告必须设为 true）
# 本地存储配置
local:
data_dir: "output" # 数据目录
retention_days: 0 # 保留天数（0=永久保留）
# 远程存储配置（S3 兼容协议）
# 支持: Cloudflare R2, 阿里云 OSS, 腾讯云 COS, AWS S3, MinIO 等
# 建议将敏感信息配置在 GitHub Secrets 或环境变量中
remote:
retention_days: 0 # 保留天数（0=永久保留）
# S3 兼容配置（或使用环境变量 S3_ENDPOINT_URL 等）
endpoint_url: "" # 服务端点
# Cloudflare R2: https://<account_id>.r2.cloudflarestorage.com
# 阿里云 OSS: https://oss-cn-hangzhou.aliyuncs.com
# 腾讯云 COS: https://cos.ap-guangzhou.myqcloud.com
bucket_name: "" # 存储桶名称
access_key_id: "" # 访问密钥 ID
secret_access_key: "" # 访问密钥
region: "" # 区域（可选，部分服务商需要）
# 数据拉取配置（从远程同步到本地）
# 用于 MCP Server 等场景：爬虫存到远程，MCP 拉取到本地分析
pull:
enabled: false # 是否启用启动时自动拉取
days: 7 # 拉取最近 N 天的数据
# ===============================================================
# 8. AI 模型配置（共享）
#
# ai_analysis 和 ai_translation 共用此模型配置
# 基于 LiteLLM 统一接口，支持 100+ AI 提供商
# ===============================================================
ai:
# LiteLLM 模型格式: provider/model_name
# 示例:
# - deepseek/deepseek-chat (DeepSeek)
# - openai/gpt-4o (OpenAI)
# - gemini/gemini-2.5-flash (Google Gemini)
# - anthropic/claude-3-5-sonnet (Anthropic)
# - ollama/llama3 (本地 Ollama)
# 完整列表: https://docs.litellm.ai/docs/providers
# 如果你对于看英文文档比较头疼，那么可以点击页面右下角的 【Ask AI】 ,用中文询问怎么配置
model: "deepseek/deepseek-chat"
api_key: "" # API Key（建议使用环境变量 AI_API_KEY）
api_base: "" # 自定义 API 端点（可选，大多数情况留空）
# 示例: https://api.openai.com/v1（自建代理或兼容接口）
#
# 💡 超级重要：连接任意兼容 OpenAI 协议的模型商
# 如果你使用的模型商不在上述支持列表中，但提供了兼容 OpenAI 的接口：
#
# 1. api_base 填写: 服务商提供的接口地址
# 例如: https://api.example.com/v1
#
# 2. model 填写: "openai/" + 实际模型名称
# 例如: openai/deepseek-ai/DeepSeek-V3
# (原理：前缀 openai/ 强制 LiteLLM 使用 OpenAI 协议格式进行通信)
timeout: 120 # 请求超时（秒）
temperature: 1.0 # 采样温度 (0.0-2.0)
# 注意：部分模型(如 gpt-5)可能要求必须为 1.0，否则会报错
max_tokens: 5000 # 最大生成 token 数
# 注意：如果 API 不支持此参数(报 HTTP 400)，请设为 0 以禁用发送
# 高级选项
num_retries: 1 # 失败重试次数
fallback_models: [] # 备用模型列表（可选）
# 示例: ["openai/gpt-4o-mini", "openai/deepseek-ai/DeepSeek-V3"]
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 额外参数 (高级选项，一般无需修改)
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# LiteLLM 会自动将通用参数转换为各提供商格式，无需手动适配。
# 仅在需要传递特殊参数时启用此项。
#
# 提示：你可以根据模型 API 文档自行添加任何支持的字段。
# 操作：如需启用，请删掉该行最前方的 "# "（井号和空格）。
# 注意：如果这几行都带着井号，则代表不使用额外参数（推荐做法）。
# -------------------------------------------------------------
# extra_params:
# top_p: 1.0 # 核采样（通用）
# presence_penalty: 0.0 # 话题多样性（OpenAI/DeepSeek）
# stop: ["END"] # 停止词列表（通用）
# ===============================================================
# 9. AI 分析功能
#
# 使用 AI 大模型对推送内容进行深度分析
# 模型配置见上方 ai 配置段
# ===============================================================
ai_analysis:
enabled: true # 是否启用 AI 分析（总开关）
# ⚠️ 开启调度系统后，此项仍为总开关：
# false → 永远不分析（无论调度怎么设置）
# true → 由调度的 analyze 字段控制何时分析
# 分析报告输出语言
# 格式：自然语言描述
# 示例: "English", "Korean", "法语"
language: "Chinese"
# 提示词配置文件路径（相对于 config 目录）
prompt_file: "ai_analysis_prompt.txt"
# AI 分析模式（独立于推送报告模式）
# 可选值:
# - "follow_report": 跟随 report.mode 的设置（默认）
# - "daily": 强制使用当日汇总模式（分析当天所有新闻）
# - "current": 强制使用当前榜单模式（只分析当前在榜新闻）
# - "incremental": 强制使用增量模式（只分析新增新闻）
#
# 使用场景：
# - 推送 incremental（避免重复），AI 分析 current（看当前榜单变化）
# - 推送 current（实时热点），AI 分析 daily（全天总结）
#
mode: "follow_report"
# 分析内容配置
max_news_for_analysis: 150 # 热榜+RSS 合计参与分析的新闻数量上限（控制成本关键项）
# 热榜优先占用配额，RSS 使用剩余配额；独立展示区不受此限制
# 推送消息顶部会显示实际的 AI 分析数供参考
# api 成本估算 (仅供参考)
# 按默认模型(deepseek)
# max_news_for_analysis 为 【50】 条
# include_rank_timeline 为 【false】
# 则
# GitHub Action 部署默认推送约 20 次（每小时推送一次）， 约 0.1 元/天
# Docker 部署默认推送 48 次(每半小时推送一次)， 约 0.2 元/天
include_rss: false # 是否包含 RSS 内容进行分析
include_standalone: true # 是否将独立展示区数据纳入 AI 分析（只需上方 display 区的 standalone 配置了平台/RSS 即可）
include_rank_timeline: true # 是否传递完整排名时间线
# false: 使用简化格式（排名范围+时间范围+出现次数）
# true: 传递完整排名变化轨迹（如 1(09:30)→2(10:00)→0(11:00)）
# 启用后 AI 能更精确分析热度趋势，但会额外增加 token 消耗（0.5 倍到 1 倍）
# ===============================================================
# 10. AI 翻译功能
#
# 对推送内容进行多语言翻译，不包含 ai_analysis 分析的内容
# 模型配置见上方 ai 配置段
# ===============================================================
ai_translation:
enabled: false # 是否启用翻译功能
# 翻译目标语言
# 格式：自然语言描述
# 示例: "Chinese", "Korean", "法语"
language: "中文"
# 提示词配置文件路径（相对于 config 目录）
prompt_file: "ai_translation_prompt.txt"
# ===============================================================
# 11. 高级设置（一般无需修改）
# ===============================================================
advanced:
# 调试模式
debug: false
# 版本检查
version_check_url: "https://raw.githubusercontent.com/sansan0/TrendRadar/refs/heads/master/version"
mcp_version_check_url: "https://raw.githubusercontent.com/sansan0/TrendRadar/refs/heads/master/version_mcp"
configs_version_check_url: "https://raw.githubusercontent.com/sansan0/TrendRadar/refs/heads/master/version_configs"
# 热榜爬虫技术参数
crawler:
request_interval: 2000 # 请求间隔（毫秒）
use_proxy: false # 是否启用代理
default_proxy: "http://127.0.0.1:10801"
# RSS 设置
rss:
request_interval: 1000 # 请求间隔（毫秒）
timeout: 15 # 请求超时（秒）
use_proxy: false # 是否使用代理
proxy_url: "" # RSS 专属代理（留空则使用 crawler.default_proxy）
# 排序权重（用于重新排序不同平台的热搜）
# 合起来等于 1
weight:
rank: 0.6 # 排名权重
frequency: 0.3 # 频次权重
hotness: 0.1 # 热度权重
# 多账号限制
max_accounts_per_channel: 3 # 每个渠道最大账号数量
# 消息分批大小（字节）- 内部配置，请勿修改
batch_size:
default: 4000
dingtalk: 20000
feishu: 30000
bark: 4000
slack: 4000
batch_send_interval: 3 # 批次发送间隔（秒）
feishu_message_separator: "━━━━━━━━━━━━━━━━"

258
apps/trendradar/6.0.0/config/frequency_words.txt Normal file
View File

@@ -0,0 +1,258 @@
# ═══════════════════════════════════════════════════════════════
# TrendRadar 频率词配置文件
# Version: 1.1.0
# ═══════════════════════════════════════════════════════════════
# 可视化配置编辑器地址: https://sansan0.github.io/TrendRadar/
#
# 凡是左侧有 # 的都是仅供阅读的说明性文字
#
# 这个文件用来设置你想关注的新闻关键词。
# 系统会自动抓取包含这些关键词的热榜新闻推送给你。
#
# 文件分为两个区域：
# [GLOBAL_FILTER] - 全局过滤区：排除不想看的内容
# [WORD_GROUPS] - 词组定义区：设置想关注的关键词
#
# ═══════════════════════════════════════════════════════════════
# ───────────────────────────────────────────────────────────────
# 全局过滤区
# ───────────────────────────────────────────────────────────────
# 在这里写入你不想看到的词，每行一个。
# 包含这些词的新闻会被自动排除，不会出现在推送中。
#
# 使用方法：
# 震惊 直接写词，包含"震惊"的新闻会被过滤
# /赌博|博彩/ 用 /.../ 包裹可以匹配多个词（用 | 分隔）
[GLOBAL_FILTER]
# 过滤标题党
震惊
# ───────────────────────────────────────────────────────────────
# 词组定义区
# ───────────────────────────────────────────────────────────────
# 在这里写入你想关注的关键词。
# 每个词组用空行分隔，同一词组内的关键词是"或"的关系。
#
# ┌─────────────────────────────────────────────────────────────┐
# │ 语法总览（快速参考） │
# └─────────────────────────────────────────────────────────────┘
#
# 关键词语法：
# 关键词 普通关键词，标题包含即匹配
# /正则/ 正则表达式匹配（自动忽略大小写）
# 关键词 => 别名 给关键词指定显示别名
# [组别名] 词组第一行，给整组指定别名
# +关键词 必须词，所有必须词都要匹配才算匹配
# !关键词 过滤词，匹配则排除该条新闻（仅限当前词组）
# @数字 限制该词组最多显示多少条
#
# 显示名称优先级：
# 1. 有组别名 → 显示组别名
# 2. 没有组别名 → 显示各行别名拼接（用 " / " 连接）
# 3. 没有别名 → 显示关键词本身
#
#
# ┌─────────────────────────────────────────────────────────────┐
# │ 基础用法（推荐新手） │
# └─────────────────────────────────────────────────────────────┘
#
# 1. 最简单：直接写关键词
# ────────────────────
# 华为
#
# 效果：匹配所有包含"华为"的新闻
#
#
# 2. 多个关键词归为一组
# ────────────────────
# 华为
# 鸿蒙
# 任正非
#
# 效果：匹配包含"华为"或"鸿蒙"或"任正非"的新闻，统一显示为"华为 / 鸿蒙 / 任正非"
#
#
# 3. 给词组起个名字（推荐）
# ────────────────────
# [华为]
# 华为
# 鸿蒙
# 任正非
#
# 效果：同上，但显示名称为"华为"（更简洁）
#
#
# ┌─────────────────────────────────────────────────────────────┐
# │ 进阶用法（可选） │
# └─────────────────────────────────────────────────────────────┘
#
# 4. 用正则表达式匹配多个词（一行搞定）
# ────────────────────
# /华为|鸿蒙|任正非/ => 华为
#
# 效果：匹配包含"华为"或"鸿蒙"或"任正非"的新闻，显示为"华为"
# 说明：/.../ 里用 | 分隔多个词，=> 后面是显示名称
#
# 💡 不懂正则？问 AI：
# "帮我写一个正则表达式，匹配包含'华为'或'鸿蒙'或'任正非'的文本，
# 格式要求：/正则/ => 显示名称"
#
#
# 5. 精确匹配英文单词（避免误匹配）
# ────────────────────
# /\bAI\b/i => AI
#
# 说明：\b 表示单词边界，避免匹配到 "MAIL" 中的 "AI"
# /i 表示忽略大小写，"ai"、"AI"、"Ai" 都能匹配
#
# 💡 不懂正则？问 AI：
# "帮我写一个正则表达式，精确匹配英文单词'AI'（不匹配 MAIL 中的 AI），
# 忽略大小写，格式要求：/正则/i => 显示名称"
#
#
# 6. 排除特定内容
# ────────────────────
# [苹果公司]
# 苹果
# !水果
# !果园
#
# 效果：匹配"苹果"但排除包含"水果"或"果园"的新闻
# 说明：! 开头的词表示"排除"
#
#
# 7. 限制显示条数
# ────────────────────
# [科技新闻]
# 科技
# @5
#
# 效果：最多显示 5 条匹配的新闻
# 说明：@数字 表示限制条数
#
#
# 8. 必须同时包含多个词
# ────────────────────
# +苹果
# +发布会
#
# 效果：必须同时包含"苹果"和"发布会"才匹配
# 说明：+ 开头的词表示"必须包含"
#
# ───────────────────────────────────────────────────────────────
[WORD_GROUPS]
# ═══════════════════════════════════════════════════════════════
# 企业与品牌
# ═══════════════════════════════════════════════════════════════
/胖东来|于东来/ => 胖东来
/深度求索|幻方量化|梁文锋|\bDeepSeek\b/ => DeepSeek
/华为|任正非|余承东|鸿蒙|海思|昇腾|鲲鹏|\bHUAWEI\b|\bHarmonyOS\b|\bHiSilicon\b/ => 华为
/比亚迪|王传福|方程豹|腾势|仰望|弗迪|刀片电池|云辇|\bBYD\b|\bDenza\b|\bYangwang\b/ => 比亚迪
/大疆|汪滔|灵眸|如影|\bDJI\b|\bRoboMaster\b|\bMavic\b|\bZenmuse\b/ => 大疆
/宇树|王兴兴|\bUnitree\b/ => 宇树机器人
/智元|灵犀|稚晖君|彭志辉|AgiBot/ => 智元机器人
/众擎|EngineAI|赵同阳/ => 众擎机器人
/黑神话|冯骥/ => 黑神话悟空
/影之刃零|梁其伟/ => 影之刃零
/三体|流浪地球|刘慈欣|郭帆/ => 三体/流浪地球
申奥
/京东|刘强东|\bJD\b|\bJingdong\b/ => 京东
/字节|张一鸣|梁汝波|抖音|\bByteDance\b|\bTikTok\b|\bDouyin\b|\bLark\b|\bCapCut\b/ => 字节跳动
/腾讯|鹅厂|马化腾|微信|QQ|天美|阅文集团|微众银行|\bTencent\b|\bPony Ma\b|\bWeChat\b|\bLightSpeed\b|\bWeBank\b/ => 腾讯
/qwen|minimax|glm/ => 国产开源模型
/特斯拉|马斯克|\bTesla\b|\bElon Musk\b|\bCybertruck\b|\bModel 3\b|\bModel Y\b|\bModel S\b|\bModel X\b|\bFSD\b/ => 特斯拉
/英伟达|黄仁勋|\bNVIDIA\b|\bGeForce\b|\bRTX\b|\bCUDA\b|\bJensen Huang\b/ => 英伟达
/苏姿丰|锐龙|霄龙|\bAMD\b|\bRyzen\b|\bEPYC\b|\bRadeon\b|\bLisa Su\b/ => AMD
/微软|\bMicrosoft\b|\bWindows\b|\bAzure\b|\bSatya Nadella\b|\bCopilot\b/ => 微软
/谷歌|皮查伊|安卓|油管|\bGoogle\b|\bAlphabet\b|\bAndroid\b|\bChrome\b|\bYouTube\b|\bGemini\b|\bDeepMind\b|\bWaymo\b/ => 谷歌
/库克|\biPhone\b|\biPad\b|\bMacBook\b|\biOS\b|\bVision Pro\b|\bAirPods\b|\bApple\b|\bTim Cook\b/ => 苹果
/\bOpenAI\b|\bChatGPT\b|\bSora\b|\bDALL-E\b|\bSam Altman\b|\bGreg Brockman\b/ => OpenAI
/\bAnthropic\b|\bClaude\b|\bDario Amodei\b/ => Claude
# ═══════════════════════════════════════════════════════════════
# 国家与地区
# ═══════════════════════════════════════════════════════════════
[中国]
国产
中国
[东亚]
日本
朝鲜
韩国
[北美]
美国
加拿大
[西欧]
法国
英国
/俄罗斯|俄国/ => 俄罗斯
印度
# ═══════════════════════════════════════════════════════════════
# 科技领域
# ═══════════════════════════════════════════════════════════════
[AI 相关]
/(?<![a-zA-Z])ai(?![a-zA-Z])/
人工智能
[芯片]
芯片
光刻机
半导体
/水电|雅鲁藏布江/ => 水电
/光伏|太阳能/ => 光伏
核能
能源
/自动驾驶|无人驾驶|智驾/ => 自动驾驶
机器人
/机械狗|四足/ => 机器狗
具身智能
/月球|登月|火星|宇宙|飞船|航天|空间站|卫星/ => 航天
# 前沿科技
量子
脑机
基因
# 产业政策
生产力

518
apps/trendradar/6.0.0/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"

118
apps/trendradar/6.0.0/data.yml Normal file
View File

@@ -0,0 +1,118 @@
additionalProperties:
formFields:
- default: 8080
envKey: PANEL_APP_PORT_HTTP
labelZh: HTTP 端口
labelEn: HTTP Port
label:
zh: HTTP 端口
zh-Hant: HTTP 連接埠
en: HTTP Port
ja: HTTP ポート
ko: HTTP 포트
ms: Port HTTP
pt-br: Porta HTTP
ru: HTTP Порт
tr: HTTP Portu
description:
zh: "有效范围: 1-65535。进入容器后，需要执行 `python manage.py start_webserver` 启动 Web 服务"
zh-Hant: "有效範圍: 1-65535。進入容器後，需要執行 `python manage.py start_webserver` 啟動 Web 服務"
en: "Valid range: 1-65535. After entering the container, you need to execute `python manage.py start_webserver` to start the web service."
ja: "有効範囲: 1-65535。コンテナに入った後、`python manage.py start_webserver` を実行してWebサービスを起動する必要があります。"
ko: "유효 범위: 1-65535. 컨테이너에 들어간 후, `python manage.py start_webserver` 를 실행하여 웹 서비스를 시작해야 합니다."
ms: "Julat yang sah: 1-65535. Selepas memasuki kontena, anda perlu melaksanakan `python manage.py start_webserver` untuk memulakan perkhidmatan web."
pt-br: "Intervalo válido: 1-65535. Após entrar no contêiner, você precisa executar `python manage.py start_webserver` para iniciar o serviço web."
ru: "Допустимый диапазон: 1-65535. После входа в контейнер необходимо выполнить команду `python manage.py start_webserver` для запуска веб-службы."
tr: "Geçerli aralık: 1-65535. Konteynere girdikten sonra, web servisini başlatmak için `python manage.py start_webserver` komutunu çalıştırmanız gerekir."
required: true
type: number
edit: true
rule: paramPort
- default: ./data
envKey: DATA_PATH
labelZh: 输出路径
labelEn: Output Path
label:
zh: 输出路径
zh-Hant: 輸出路徑
en: Output Path
ja: 出力パス
ko: 출력 경로
ms: Laluan Output
pt-br: Caminho de Saída
ru: Выходной путь
tr: Çıkış Yolu
description:
zh: 生成的报告和数据保存位置
zh-Hant: 生成的報告和數據保存位置
en: Generated reports and data storage location
ja: 生成されたレポートとデータの保存場所
ko: 생성된 보고서 및 데이터 저장 위치
ms: Lokasi penyimpanan laporan dan data yang dihasilkan
pt-br: Local de armazenamento de relatórios e dados gerados
ru: Место хранения сгенерированных отчетов и данных
tr: Oluşturulan raporların ve verilerin saklama konumu
required: false
type: text
edit: true
- default: "*/30 * * * *"
envKey: CRON_SCHEDULE
labelZh: 定时任务表达式
labelEn: Cron Expression
label:
zh: 定时任务表达式
zh-Hant: 定時任務表達式
en: Cron Expression
ja: クロン式
ko: 크론 표현식
ms: Ungkapan Cron
pt-br: Expressão Cron
ru: Cron-выражение
tr: Cron İfadesi
required: false
type: text
edit: true
- default: cron
envKey: RUN_MODE
labelZh: 运行模式
labelEn: Run Mode
label:
zh: 运行模式
zh-Hant: 執行模式
en: Run Mode
ja: 実行モード
ko: 실행 모드
ms: Mod Operasi
pt-br: Modo de Execução
ru: Режим работы
tr: Çalışma Modu
required: false
type: select
values:
- label: Cron
value: cron
- label: Once
value: once
edit: true
- default: "false"
envKey: IMMEDIATE_RUN
labelZh: 启动时立即执行一次
labelEn: Execute immediately upon startup
label:
zh: 启动时立即执行一次
zh-Hant: 啟動時立即執行一次
en: Execute immediately upon startup
ja: 起動時に即時実行
ko: 시작 시 즉시 실행
ms: Laksanakan segera semasa permulaan
pt-br: Executar imediatamente na inicialização
ru: Выполнить немедленно при запуске
tr: Başlangıçta hemen yürüt
required: false
type: select
values:
- label: "True"
value: "true"
- label: "False"
value: "false"
edit: true

21
apps/trendradar/6.0.0/docker-compose.yml Normal file
View File

@@ -0,0 +1,21 @@
services:
trend-radar:
image: wantcat/trendradar:6.0.0
container_name: ${CONTAINER_NAME}
restart: always
ports:
- ${PANEL_APP_PORT_HTTP}:8080
volumes:
- ./config:/app/config:ro
- ${DATA_PATH}:/app/output
environment:
- CRON_SCHEDULE=${CRON_SCHEDULE}
- RUN_MODE=${RUN_MODE}
- IMMEDIATE_RUN=${IMMEDIATE_RUN}
networks:
- 1panel-network
labels:
createdBy: Apps
networks:
1panel-network:
external: true