筛选与归类

筛选规则.

把应用价值放在前面,让每一项热度都有明确含义。

✳

关注“怎么用”,而不只是“发布了什么”。

优先收录 AI 编程、办公自动化、智能体应用、知识库和内容创作中的可复用方法。首页展示本期全部已采集候选,可按场景筛选;文本规则用于分类与排序,不额外隐藏文章。

如何组织应用场景

标题命中场景词比正文权重更高。按 AI 编程、智能体应用、办公自动化、知识与研究、图像与视频、本地部署归类,优先展示带有代码、安装说明、示例、教程或演示线索的内容。来源保留在卡片上,列表不按平台分组。

场景介绍说明该分类的范围,不代表每条内容都覆盖这些用途。标签来自文本规则,可能有误判;没有运行项目或验证作者声称的效果。应用关联较弱的内容也保留在首页。

网页只读已有报告,不记录阅读行为,不设置个人清单。网页每篇生成一份简短概述;分类仍使用文本规则。

𝕏X

传播与增长

点赞 + 6 × 正的每小时点赞增速;增速未知时只用累计点赞,仍需满足点赞门槛

至少 100 赞。未知点赞数不参与筛选。
GGitHub

维护与可复用性

已知 Star 优先;每小时涨星、README/安装/使用/示例线索、最近提交、总 Star 依次排序

README 和示例是线索,未运行代码;提交时间不是项目发布时间。
PProduct Hunt

产品与试用线索

已知当日排名、投票、评论、产品自述试用线索依次排序;未知值不补造

未知指标不当作 0,不用列表位置冒充官方排名。
YHacker News

讨论与实践反馈

已知 Points 优先;Points + 6 × 正的每小时增速,再比较试用反馈线索和评论量

读者反馈仅作线索;抽样评论不代表全部讨论。

如何理解每小时增长

观测增量 ÷ 实际间隔小时数 = 每小时平均增量

例如,两次采集间隔 2 小时,新增 100 星标,显示为 +50 星标 / 小时。对比记录需来自同一来源,间隔至少 15 分钟、最多 24 小时;不足两次时显示“待观察”。

负增长如实展示。数值不等于严格的过去 60 分钟增量,也不是对未来增长的预测。增长排序使用本期同渠道有效样本的位次,再按实践线索排序;至少 3 个样本且正增长才参与,不满足时排后。「增长靠前」表示位次不低于 75%,相同增速使用相同位次。样本量不等、订阅范围有限,位次也不代表全平台热度。

从原文到概述

  1. 01

    采集与去重

    X、Product Hunt、HN 关注最近 24 小时,GitHub 持续观察近期发现的项目。

  2. 02

    独立排序

    采集层按渠道指标选取最多 100 条原文。网页层按应用场景与实践线索重新组织原文。

  3. 03

    应用解读

    每篇生成简短概述,说明工具用途与有依据的方法,不做全文翻译;概述不代表经过独立核验。