| name | knowgtzh |
| description | 从 WebFetch/WebSearch 结果生成简洁、易读的 GitHub Trending 中文简报，与已有的 markdown 历史报告对比，并撰写每日或每周趋势总结。当用户要求分析 GitHub 热门趋势、对比今日与历史趋势、用通俗语言解释热门仓库，或为 Codex、Claude Code 等编码助手创建可重复的 GitHub 趋势报告时使用。 |
GitHub 热门趋势简报（中文版）
从 GitHub Trending 生成通俗易懂的中文简报。优先使用 WebFetch/WebSearch，而非本地爬虫脚本。本 skill 的价值在于趋势解读，而非爬虫维护。
工作流程
-
确定范围：
- 默认周期：
daily（每日）。
- 同时支持
weekly（每周）和 monthly（每月）。
- 默认输出：带日期的 markdown 简报。
-
获取当前数据：
- 抓取
https://github.com/trending?since=daily、weekly 或 monthly。
- 捕获仓库名称、URL、语言、总 stars 数、本周期新增 stars 数，以及简短描述。
- 如果 GitHub Trending 不可用，使用 WebSearch 寻找可靠的镜像站或 GitHub 搜索作为备选方案，并说明使用了何种备选。
-
查找历史：
- 如果当前项目有
trending_reports/ 目录，读取最新的 2-5 份 markdown 报告。
- 如果用户指定了其他历史目录，使用用户指定的目录。
- 如果没有历史记录，创建首份简报，并说明暂无对比基准。
-
对比分析：
- 识别今日新上榜项目：和最近 2-5 份历史报告对比，找出首次或近期未出现的项目。
- 识别近期最佳项目：连续上榜、排名维持靠前、或新增 stars 明显加速的项目。
- 同时参考日榜和周榜：日榜用于发现新变化，周榜用于判断近期最佳表现。
- 提炼 2-4 个趋势主题，例如 Agent、Token 成本、数据输入层、AI 视频、开发工具、安全等。
-
撰写简报：
- 默认输出完整中文 Markdown 简报：标题与元信息、新上榜、近期最佳、趋势解读、完整榜单（日榜）、完整榜单（周榜，如有）。
- 不要改成"今日值得看"单表格，也不要按涨幅拆成"新星/稳步/稳定"等多档。
- 表格要紧凑，解释要短，但不要为了短而把项目说扁。
通俗解释 应保留项目类型、核心场景、关键差异。
- 趋势解读要有判断，但不要空泛。每个小节围绕一个明确主题，引用 1-3 个具体项目作为证据。
- 使用直接清晰的语言。避免使用架构、范式、赋能、杠杆、战略护城河等术语，除非仓库本身使用了这些词且确有必要。
- 解释每个项目能解决什么问题、服务什么场景，而非复述内部实现细节。
- 保留必要技术词：LLM、RAG、Agent、API、TTS、Markdown、Token、爬虫等可以直接写，不要强行翻成幼稚比喻。
- 不要在项目间复制粘贴相似描述。每个解释都要体现项目独特点。
- 通俗解释必须"翻译"而非"复述"：Trending 页面上的英文描述（如 "Tokenizer-Free TTS for Multilingual Speech Generation"）外行看不懂。仅根据 trending 页面的项目名、语言、描述和通俗解释一栏的英文，把"项目做什么、给谁用、什么场景"用一句中文讲清楚——不要去 WebFetch 仓库 README。直接搬运英文原话或堆功能清单（"多语言/多说话人/多框架"）就是不及格。
-
保存 markdown 输出（在仓库中工作时）：
- 默认生成一份简报 →
trending_reports/trending_briefing_YYYY-MM-DD.md。
- 只有当用户明确要求"详细报告""逐个讲解""deep dive"时，才额外生成
trending_reports/trending_detailed_YYYY-MM-DD.md。
- 除非用户要求，否则不要覆盖已有报告。
-
【可选】生成 HTML 报告：
- HTML 是可选功能，默认不生成。仅在用户明确要求"生成 HTML""可视化"时才执行。
- 读取本 skill 目录下的模板文件
reference/briefing-template.html，理解其 CSS 和 DOM 结构。模板采用单页双标签设计，将简报和详细报告合并在同一页面。
- 生成
trending_reports/trending_briefing_YYYY-MM-DD.html，使用与模板完全相同的 CSS 和 DOM 结构。将每个部分填入真实数据：
- Hero 头部：更新标题、日期、周期、来源、对比基准等信息。
- Stats 统计栏：将示例数字替换为实际统计（总项目数、新上榜数、近期最佳数）。
- 简报标签页（"新上榜"表格、"近期最佳"表格、"趋势解读"段落、"完整榜单"表格）。有真实数据后移除 empty-row 占位行。
- 详细标签页（
.detail-list）：对每个首次出现的项目，渲染完整的 .project-card，包含头部（排名、名称+链接、语言标签、stars 数）和正文（what-is-it、.proj-analogy 类比、.proj-helps 帮助列表、.persona 适用人群标签）。对已在历史报告中出现过的项目，渲染较短的 .project-card，降低透明度，添加引用说明而无需重复完整解读。
- 标签切换
<script>：保留模板中的 switchTab() 函数以确保标签切换正常工作。
- HTML 文件必须是自包含的（不依赖外部资源），所有 CSS 保持在
<style> 标签内，所有 JS 保持在 <script> 标签内。
- 写入 HTML 文件后，在默认浏览器中打开：
- macOS：运行
open trending_reports/trending_briefing_YYYY-MM-DD.html
- Linux：运行
xdg-open trending_reports/trending_briefing_YYYY-MM-DD.html
- Windows：运行
start trending_reports/trending_briefing_YYYY-MM-DD.html（cmd）或 Start-Process trending_reports/trending_briefing_YYYY-MM-DD.html（PowerShell）
- 自动检测平台，不要询问用户使用什么操作系统。
简报结构
除非用户另有要求，否则使用以下结构：
# GitHub 热门趋势简报 - YYYY-MM-DD
> 生成日期：YYYY-MM-DD
> 来源：github.com/trending
> 对比基准：<近期报告日期，多个日期用顿号分隔；没有则写"无">
---
## 新上榜
今日日榜有 **N 个全新面孔**，主要集中在 <主题1>、<主题2> 和 <主题3>：
| 排名 | 项目 | 语言 | 今日新增 Stars | 通俗解释 |
|------|------|------|----------------|----------|
---
## 近期最佳
**<最值得关注的项目或主题> 是近期最佳表现：**
| 项目 | 证据 | 为什么值得关注 |
|------|------|----------------|
---
## 趋势解读
**YYYY-MM-DD 主题：<主题1> + <主题2> + <主题3>。**
### 1. **趋势小标题**
用 1-2 段解释第一个趋势。必须引用具体项目、排名、新增 stars 或历史对比数据。
### 2. **趋势小标题**
用 1-2 段解释第二个趋势。必须引用具体项目、排名、新增 stars 或历史对比数据。
### 3. **趋势小标题**
用 1-2 段解释第三个趋势。没有足够证据时可以省略第三节，不要硬凑。
总的来说，用一句话总结今天的 Trending 说明了什么。
---
## 完整榜单 - 日榜
| 排名 | 项目 | 语言 | 总 Stars | 今日新增 |
|------|------|------|----------|----------|
---
## 完整榜单 - 周榜 Top 15
| 排名 | 项目 | 语言 | 总 Stars | 本周新增 |
|------|------|------|----------|----------|
---
通俗解释写作原则（简报表格用，必须遵守）：
- 只根据 trending 页面的信息写。不要去 WebFetch 仓库 README 或主页。Trending 上给的英文描述外行看不懂，要从项目名、语言、描述里推断"它是干嘛的、给谁用"，再用中文重写。直接搬运英文原话 = 不及格。
- 硬约束：30 字以内。一句话讲清，不分点。超长就是没读懂。
- 保留必要技术对象（LLM、Token、Agent、TTS、RAG、OCR、Markdown）— 这些是高密度信息词，外行也能从上下文猜出含义。
- 禁止堆功能清单。"多语言/多说话人/多框架"这种罗列不是通俗解释，缺用户和场景。功能可作为"为什么值得关注"的隐性信息合并写。
- 不强制套"帮你/让你/省去"，但可以说"适合谁在什么场景下用"。
- 不幼稚化。避免用日常生活中的食物/家具类比（如"给 PDF 装个翻译器"）强行降智。
- 推荐句式：
项目类型/定位：典型用户 + 解决的问题。
- ✅ 好例子：
多语言 AI 配音工具：给视频/有声书自动生成自然人声。
- ✅ 好例子：
给 LLM 输入前先压缩日志、工具输出、RAG 片段，省 token。
- ✅ 好例子：
微软的文件转 Markdown 工具，适合把 Office/PDF 喂给 AI。
- ❌ 坏例子：
Tokenizer-Free TTS for Multilingual Speech Generation, Creative Voice Design, and True-to-Life Cloning（直接搬运英文）
- ❌ 坏例子：
多语言 TTS、声音设计和声音克隆模型（堆功能清单）
- ❌ 坏例子：
NVIDIA 开放的世界模型平台，面向机器人、自动驾驶等物理 AI 场景（搬运 GitHub 原话 + 解释模糊）
写完每个通俗解释后自检 3 问：
- 一个非技术读者看完能知道"这玩意儿是给谁解决什么问题的"吗？答否 → 重写。
- 是否在搬运 GitHub README 英文原话？答是 → 重写。
- 是否在堆功能清单（"多语言/多说话人/多框架"）？答是 → 重写。
仓库解释模板（详细报告用）
当需要在详细报告中单独解释某个仓库时，使用以下格式：
**这是什么？** 1-2 句说明项目定位和核心用途。
**简单类比：** 仅在项目确实陌生时使用；不要为了类比而幼稚化。
**它能帮你做什么？**
- 帮你 …
- 让你 …
- 省去 … 的麻烦
**谁真正需要它？**
- 有具体工作或反复遇到的问题的人。
