HN.watch：为每条 Hacker News 帖子生成讲解视频
文章摘要
HN.watch 的页面很简单：它同步 Hacker News 首页，每条帖子旁边多了一个「video」链接，点一下就能看一段为这篇文章生成的短讲解视频，标题写着「The Hacker News front page, with a short video explainer for every story」。页面署名「by Scrimba Explain」。发布者 Per（mrborgen）是在线编程教育平台 Scrimba（YC S20）的创始人，他在 Show HN 自述中详细介绍了背后的技术和想法，这条帖子拿到 220 多分。
HTML 视频，而非像素视频。 Scrimba 过去十年一直用一种基于 HTML 的「视频」格式教人写代码：画面其实是网页元素加上语音旁白，而不是逐帧渲染的像素。现在他们把 LLM 接进了这套格式，让人可以为任何主题生成讲解视频，产品叫「Scrimba Explain」。HN.watch 就是为 HN 做的演示：把文章换成讲解视频，第一次有人点击时现场生成，之后的人直接复用缓存。作者承认，用 HTML 而不用扩散模型在视觉上有明显短板，但有三个好处：
- 速度快：从点击到开始播放只要几秒；
- 成本低：每个视频约 0.04 美元（不含部分视频用到的图片生成，那部分成本会迅速上涨）；
- 易编辑：快和便宜也意味着用 AI 辅助修改同样又快又便宜。
从「几美元几分钟」到「几美分几秒」。 他们的假设是，当视频制作的成本降到这个量级，就会出现一批新用途。他们已经看到的有：为每个 Pull Request 生成讲解视频（他们内部就这样做）；给内外部文档的每一页配视频；通过 Chrome 扩展在约 4 秒内把一篇复杂文章变成视频；课程作者在正式录制前快速打草稿；还有很多人用来做给孩子的故事、婚礼请柬、生日祝福等私人内容。
自研技术栈。 整个系统建立在 Scrimba CTO Sindre Aarsæther 创造的开源语言 Imba 之上，它编译成 JavaScript，能与 npm 和 Node 生态完全互通。他们还自研了同步引擎 OP 和面向 agent 的上下文管理系统 Q。作者原本担心这些东西都不在 LLM 的训练数据里（Imba 的资料也很少），会让 AI 写代码时吃力，结果却发现 LLM 很擅长这套技术栈。他推测原因是这套栈非常紧凑：在 OP 里，一个声明就同时定义了存储、同步、权限、UI 以及 AI 能看到什么，没有前端、API、数据库和 JSON 之间的来回转换让模型出错。他自嘲说，别人用 React、Express、Supabase、LangChain，他们全部从零自己造，「确实有点 NIH 综合症」。模型方面用了 Gemini、GPT 系列、Inworld、ElevenLabs 等。
使用入口。 除了 HN.watch，Scrimba Explain 还提供网页界面、MCP（可加到编码 agent 里）、ChatGPT 插件和 Chrome 扩展。作者在帖子末尾预判，HN 用户偏爱文字，这次发布大概会遭到不少反对；他也承认这类工具不适合所有人，但如今很多人，尤其是年轻一代，更喜欢视频。
HN 评论精华
正如作者预料，评论区明显分成两派。很有代表性的是 fishtoaster 的说法：我讨厌这东西的一切，因为我远比视频更喜欢文字，尤其讨厌 AI 生成的视频；同时我也承认，很多人偏爱视频，对他们来说这会很有价值，而且技术上很酷，单个视频的成本低得惊人。
支持者：降低探索的门槛。 ahmedfromtunis 劝作者别理会唱反调的人：他时间有限，平时只按兴趣或投票数挑文章，容易错过冷门好文，两分钟的视频能帮他判断值不值得深读。xp84 认为它的用处在于把晦涩的标题变成一段「为什么值得关心」的说明，很多文章是写给已经懂行的人看的，不懂其中几个术语的人往往直接划过。Vaslo 说对于懂技术但不在一线的人很有帮助。chimneychanga 说自己常因为文章太技术或眼睛太累而跳过，但他更希望只有音频，因为 AI 生成的配图往往和内容对不上。newtypecola 认为它更适合作为阅读的入口，而不是替代。simbas 是教学设计师，表示要借鉴这个思路。
反对者：TLDR 的 TLDR。 1970-01-01 打比方说，就像一本还不错的书拍成电影，电影火了又有人在 YouTube 上概括电影剧情，「这是 TLDR 的 TLDR，去读原文吧」。redhed 补充，很多 HN 帖子本身就是对复杂话题的文字概括，再概括一遍意义不大，用在教科书章节之类信息密集的材料上更合适。jonplackett 的反对最坚决：他看讲解视频是为了讲解者的个性和见解，比如 MKBHD 的观点；如果视频只是把能读到的东西念一遍，只是多了一层遮挡。他认为这恰恰是 AI 最不该做的事，看视频而不动脑会让人自以为学到了东西，实际效果更差，「会让人变笨」。nxc18 说看了几个视频，确认比「脑腐」内容还糟。alansaber 说他喜欢视频是因为它能打破常规，看几千个千篇一律的视频比读 LLM 文章还令人沮丧。
对质量的具体评价。 dd8601fn 认真看了十来个，认为它确实能完成「我没时间啃 45 分钟论文或 20 页长文，给我个摘要」的任务，挑选评论的那一页也是个好设计；主要问题是格式明显套了严格模板，语音也一样，看多了很快就重复乏味。dverlaeckt80 也说单调的 AI 声音很快让人厌倦。作者回应，很多用户都在要求更细腻的声音选择，目前可以在提示里指定「澳大利亚英语女声」，将来希望能描述成「风趣的爷爷」或「投入的新闻主播」。totallygeeky 点开示例「罗马帝国为何衰亡」，看到的问题和其他同类产品一样：可视化部分要么胡乱拼凑，要么和讲述内容矛盾，他认为这类系统不理解任何东西，也没有空间推理能力，不会推荐给学习者。taneq 反驳说，五年前它们只能勉强组织通顺的句子，现在已经能生成 20 分钟、不刻意找破绽就看不出是 AI 的科普视频了。spoon404 拿一篇《连线》人物特写做测试，摘要没有事实错误，但删掉了原文有趣的部分和文风，把一些带引号的主观说法当成事实陈述，还硬加了一个关于子弹的冷笑话，他认为这类文章最能同时暴露系统的长处和短处。customguy 指出作者自己的宣传视频里有一句「压缩机有三个主要器官」，说这种没人认真推敲的内容在视频和文字里都让他难受。
音频和播客形式更受欢迎。 多人表示比起视频更想要音频。abalashov 说自己痛恨视频和 LLM 摘要，但他大量时间在开车或骑车，只能听不能读，这时候它确实有用。xp84 希望有一个每天几次的前十条播客。kristopolous 提议做「HN 十分钟」：首页每条 20 秒，每天一期播客，用 ffmpeg 去掉画面、发成 RSS 就行。TomGarden 说他让 Opus 给自己做了个手机应用，用 TTS 朗读 HN 前 20 条和每条的前 5 条评论，他认为摘要反而是最差的部分，纯朗读更好。
技术与商业问题。 george_max 建议每帖只生成一次而不是每次点击都生成，作者说本来就是这样缓存的。OutOfHere 问那么多网站屏蔽爬虫，怎么可靠读取网页？作者说他们用 Firecrawl，仍有一些页面读不到，这时就用 Algolia API 获取 HN 评论，转而做一期「HN 对这篇文章的反应」。OutOfHere 认为评论可能严重歪曲原文，建议让用户上传原文 PDF。wewewedxfgdf 质疑为讲解网页（它们实际上不算视频）专门造一门编程语言是过度设计。TZubiri 说自己也不喜欢，但这更像是创业公司核心技术的演示，不应当成「读 HN 的方式」来评判；他觉得这东西就是「ffmpeg 加一次 LLM 调用」的小脚本，不过当年人们也这么说过 Dropbox，而且时机晚了两年，需要转型。作者在回复中透露，目标是把一分钟视频的成本降到 1 美分、提交到播放只延迟 1 秒，为此需要极便宜极快的模型，所以不用 Opus 这类昂贵模型；他还在评论里招聘奥斯陆的开发者。
同类尝试。 scosman 说这类 AI 讲解视频正在流行，他五月份尝试时模型还不够好，而 Opus 5.5 似乎是转折点；他开源了一个框架 videowright，支持让动画对齐旁白、用 ElevenLabs 生成配音或给真人配音转写打时间戳、重排场景、导出 MP4。他建议作者让 Opus 来设计风格和参考画面，再让小模型拼装。vbernat 说他用 Claude 把自己一篇带交互图的博客做成了视频，Claude 为此专门写了个录制工具，仍花了好几个小时，他愿意付钱提速，但希望保留对文字的控制，不要摘要。
玩笑与吐槽。 harvey9 提醒大家别在 HN.watch 里点开这条帖子本身的视频，「比在 Google 里搜 Google 还危险」，nonethewiser 却说那一集恰恰是讲得最清楚的。nonethewiser 还预言下一步是每个评论串都变成 10 秒自动播放视频，jameshart 接话「而且没法关掉」。eleventen 说现在他想把评论也做成视频看，作者表示视频结尾通常有一段评论内容，也许会单独做一个「评论视频」。russellbeattie 提出一个延伸观点：如果 HN 在每个评论页顶部放一段 AI 摘要，很多只看标题就发言的讨论可能会改善；xp84 不同意，他认为摘要会漏掉原文已经回应过的反驳，大家反而会提出一堆缺乏洞见的质疑，好像作者没想到一样。