An 18-hour half-life for mixed launch feeds

混合发布信息流的 18 小时半衰期

Product Hunt, Hacker News, and GitHub do not speak the same language. One is votes in a 24-hour window, one is comments on a Show HN, one is stars on a repo that may have been created last month. I wanted a single public list of what just shipped — not another idea-validation landing page (that is a different product at launchsignal.io).

Product Hunt、Hacker News 和 GitHub 并不使用同一种“语言”。前者是 24 小时窗口内的投票，中间者是 Show HN 上的评论，后者则是可能在一个月前创建的仓库的星标。我想要一个统一的公开列表来展示刚刚发布的内容——而不是另一个用于验证创意的落地页（那是 launchsignal.io 上的另一个产品）。

The ranking bet is boring on purpose: heat = score × exp(−hours / 18) Eighteen hours is a guess. Too short and GitHub never shows up. Too long and yesterday’s PH winner sits on the homepage all week.

排名的逻辑特意设计得很简单：热度 = 分数 × exp(−小时数 / 18)。18 小时是一个估算值。太短的话，GitHub 的内容永远不会出现；太长的话，昨天的 Product Hunt 赢家就会在首页霸榜一周。

Score is source-native: PH’s public feed has no vote count I can trust, so every PH row starts at 12; HN is points + 0.4 × comments; GitHub is 2 × stars + forks. Then the same decay hits all three.

分数是基于来源的：PH 的公开信息流中没有我能信任的投票数，所以每一条 PH 记录的初始分设为 12；HN 的分数是积分 + 0.4 × 评论数；GitHub 的分数是 2 × 星标数 + 分支数。然后，这三者都应用同样的衰减公式。

GitHub Search taught me not to get clever. A long OR query came back 422. The surviving query is short: created recently, plus (ai OR llm OR gpt OR openai OR claude OR gemini). If that source dies, the board still has HN and PH. Recency and heat, nothing else — no classifier.

GitHub 的搜索功能教会我不要耍小聪明。一个很长的 OR 查询返回了 422 错误。最终保留的查询很简单：近期创建，加上 (ai OR llm OR gpt OR openai OR claude OR gemini)。如果其中一个来源失效，看板上依然有 HN 和 PH 的内容。只有时效性和热度，没有其他——没有分类器。

Live list (same payload as JSON): https://launchsignal.ai/feed If you have mixed a vote-based feed with a star-based one, what half-life did you keep?

实时列表（与 JSON 数据负载相同）：https://launchsignal.ai/feed 如果你曾将基于投票的信息流与基于星标的信息流混合在一起，你设置的半衰期是多少？