用 Claude 从千万条社区评论筛选视频

Karpathy 用一个周末做了视频聚合站 HackerTube：让 Claude 从 Hacker News 过去 20 年的 4300 万条评论中，筛出 6454 个被反复推荐的视频，再用一个简洁的网站呈现出来。他认为，这比 YouTube 自己的推荐更好看。

这件事值得看的地方，是怎样把社区长期积累的推荐变成产品，以及 AI 编程把哪些工作压缩了。至于推荐质量是否更高、项目是否容易复制，原文给出的证据还比较有限。

好视频的入口，可以从社区讨论里找

HackerTube 的思路，是把 Hacker News 用户多年留下的推荐重新整理出来。Claude 处理了 20 年、4300 万条评论，最终提炼出 6454 个视频。

这里有一个合理的判断：被一个社区反复推荐的视频，可能比单次点击更能体现内容的长期价值。对于偏技术、科学和深度讨论的读者，这种筛选方式尤其有吸引力。

但「反复推荐」具体怎么算，原文没有交代。是统计同一个视频链接出现的次数，还是让模型判断评论中的推荐意图？有没有排除负面讨论、失效链接和重复视频？这些都会影响结果。

HackerTube 借用了社区的长期筛选，却没有公开足够细节，让读者复现这套筛选过程。

推荐体验的变化，也来自界面的取舍

HackerTube 不需要登录，使用视频中间的一帧作为预览图，替代专门优化过的缩略图，并把使用状态保存在浏览器本地。

这些设计共同降低了浏览时的干扰。中间帧未必最吸引人，但更接近视频实际画面；无需登录，用户打开就能看；状态留在本地，也让产品少了一套账号和服务端同步流程。

不过，本地保存状态通常不能直接提供跨设备同步。原文没有说明 HackerTube 是否提供导出、备份或其他迁移方式。

Karpathy 在 X 上称，它提供了比 YouTube 推荐「明显更好的观看体验」。这是他的使用感受。原文没有给出用户测试、观看满意度或与 YouTube 的对照数据，因此不能把它当成推荐效果已经得到验证。

AI 压缩的是整条交付流程，数据来源仍然关键

据原文描述，Karpathy 使用 Claude 的 Opus 5.5 模型，让 Claude Code 承担了几乎所有工作，从数据分析到服务器配置。他手动完成的事项只有 Google Cloud API key、租用服务器和购买域名。

随后，他又基于 Tristan Hume 整理的 YouTube 频道列表，制作了包含 47000 个视频的 TristanTube，并称它通过 Claude Code 在 3 分钟内一次生成。

两个项目的数据起点不同。HackerTube 要从大量评论里提取推荐；TristanTube 已经有一份人工整理的频道列表。后者说明，当输入足够明确时，AI 可以很快把现成资料包装成可用的浏览入口。

但「3 分钟一次生成」覆盖哪些环节，原文没说清。是否包含数据抓取、上线检查、错误修复，也没有说明。Karpathy 认为，过去需要数周的项目，如今几小时就能完成；这仍是个人经验，不能直接换算成一般团队的交付周期。

我的判断

我认可这种产品路径：先找有价值的数据，再用 AI 降低整理和交付成本。它给程序员的启发，比单纯展示「几分钟写出网站」更具体。

真正难复制的部分，可能是判断什么数据值得整理。Hacker News 的推荐带有社区偏好，这对目标读者可能是优势，也限制了内容覆盖。把同样的方法用于其他人群，未必还有相同效果。

和直接使用 YouTube 相比，这类站点更适合明确想看某一类内容、愿意接受精选范围的用户。原文没有证明它能普遍替代 YouTube，也没有提供成本、维护量和筛选准确率的对照。把它视为一个成功做出的个人产品案例更合适。

能拿来做什么

• 做技术视频导航时，可以先整理已有社区推荐或可信频道列表，优先验证内容是否值得看，再决定是否增加个性化推荐。
• 用 Claude Code 做类似项目时，把数据整理、页面开发和服务器配置列成明确任务，并检查最终数据中的重复项、失效链接和筛选依据。
• 做个人使用的视频工具时，可以参考无需登录、浏览器本地保存状态的方案；如果需要跨设备使用，再补充同步或迁移能力。
• 评估 AI 编程效率时，分别记录首次生成、修复、验证和上线所需时间，避免把一次生成的用时当成完整交付时间。