Knowgtzh

GitHub 热门趋势简报（中文版）

从 GitHub Trending 生成通俗易懂的中文简报。优先使用 WebFetch/WebSearch，而非本地爬虫脚本。本 skill 的价值在于趋势解读，而非爬虫维护。

工作流程

1. 确定范围：

   • 默认周期：daily（每日）。
   • 同时支持 weekly（每周）和 monthly（每月）。
   • 默认输出：带日期的 markdown 简报。

2. 获取当前数据：

   • 抓取 https://github.com/trending?since=daily、weekly 或 monthly。
   • 捕获仓库名称、URL、语言、总 stars 数、本周期新增 stars 数，以及简短描述。
   • 如果 GitHub Trending 不可用，使用 WebSearch 寻找可靠的镜像站或 GitHub 搜索作为备选方案，并说明使用了何种备选。

3. 查找历史：

   • 如果当前项目有 trending_reports/ 目录，读取最新的 2-5 份 markdown 报告。
   • 如果用户指定了其他历史目录，使用用户指定的目录。
   • 如果没有历史记录，创建首份简报，并说明暂无对比基准。

4. 对比分析：

   • 识别今日新上榜项目：和最近 2-5 份历史报告对比，找出首次或近期未出现的项目。
   • 识别近期最佳项目：连续上榜、排名维持靠前、或新增 stars 明显加速的项目。
   • 同时参考日榜和周榜：日榜用于发现新变化，周榜用于判断近期最佳表现。
   • 提炼 2-4 个趋势主题，例如 Agent、Token 成本、数据输入层、AI 视频、开发工具、安全等。

5. 撰写简报：

   • 默认输出完整中文 Markdown 简报：标题与元信息、新上榜、近期最佳、趋势解读、完整榜单（日榜）、完整榜单（周榜，如有）。
   • 不要改成"今日值得看"单表格，也不要按涨幅拆成"新星/稳步/稳定"等多档。
   • 表格要紧凑，解释要短，但不要为了短而把项目说扁。通俗解释 应保留项目类型、核心场景、关键差异。
   • 趋势解读要有判断，但不要空泛。每个小节围绕一个明确主题，引用 1-3 个具体项目作为证据。
   • 使用直接清晰的语言。避免使用架构、范式、赋能、杠杆、战略护城河等术语，除非仓库本身使用了这些词且确有必要。
   • 解释每个项目能解决什么问题、服务什么场景，而非复述内部实现细节。
   • 保留必要技术词：LLM、RAG、Agent、API、TTS、Markdown、Token、爬虫等可以直接写，不要强行翻成幼稚比喻。
   • 不要在项目间复制粘贴相似描述。每个解释都要体现项目独特点。
   • 通俗解释必须"翻译"而非"复述"：Trending 页面上的英文描述（如 "Tokenizer-Free TTS for Multilingual Speech Generation"）外行看不懂。仅根据 trending 页面的项目名、语言、描述和通俗解释一栏的英文，把"项目做什么、给谁用、什么场景"用一句中文讲清楚——不要去 WebFetch 仓库 README。直接搬运英文原话或堆功能清单（"多语言/多说话人/多框架"）就是不及格。

6. 保存 markdown 输出（在仓库中工作时）：

   • 默认生成一份简报 → trending_reports/trending_briefing_YYYY-MM-DD.md。
   • 只有当用户明确要求"详细报告""逐个讲解""deep dive"时，才额外生成 trending_reports/trending_detailed_YYYY-MM-DD.md。
   • 除非用户要求，否则不要覆盖已有报告。

7. 【可选】生成 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）
   • 自动检测平台，不要询问用户使用什么操作系统。

简报结构

除非用户另有要求，否则使用以下结构：

markdownCopy code
# 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 问：

1. 一个非技术读者看完能知道"这玩意儿是给谁解决什么问题的"吗？答否 → 重写。
2. 是否在搬运 GitHub README 英文原话？答是 → 重写。
3. 是否在堆功能清单（"多语言/多说话人/多框架"）？答是 → 重写。

仓库解释模板（详细报告用）

当需要在详细报告中单独解释某个仓库时，使用以下格式：

markdownCopy code
**这是什么？** 1-2 句说明项目定位和核心用途。

**简单类比：** 仅在项目确实陌生时使用；不要为了类比而幼稚化。

**它能帮你做什么？**
- 帮你 …
- 让你 …
- 省去 … 的麻烦

**谁真正需要它？**
- 有具体工作或反复遇到的问题的人。