Hacker News thread 转 Markdown 喂给 Claude 做研究 (2026)
Hacker News thread 转 Markdown 喂给 Claude 做研究 (2026)
Hacker News 是开放 web 上信号最高的技术讨论 forum。系统设计或运行时怪癖的 400 评论 thread 常包含比单一博客或 doc 页更多有用智慧。问题:怎么把那 thread 喂给 Claude 或 ChatGPT 让它们能真正推理。
本文是工作流。
为什么 HN thread 研究合成比几乎其他东西都强
我跨 Reddit、X、LinkedIn、HN 做过多次同样研究问题。HN 在技术合成一致赢,因为:
- 信号密度更高:评论平均 3-5 个实质句子,不是 1 行反应
- 引用主张:经验 commenter 链接 paper、RFC、源代码
- 自我修正:错主张在小时内被回击,不是几天
- karma 信号:投票数大致反映技术内容的有用程度
- 比 LinkedIn 促销内容少,比 Reddit casual chatter 少
「资深工程师社区对 X 怎么想?」— HN 是经典首选。
标准 fetcher 看到什么
HN thread 页 (news.ycombinator.com/item?id=...) 有服务器渲染 shell + 首 ~30 评论内联,其余随滚动加载。ChatGPT browse 和 Claude WebFetch 拿到:
- 提交标题、URL、点数
- 顶层评论 (~10-30)
- 其余的
[more]链接
50 评论以下的 thread 这没问题。200+ 评论 thread — 实质在更深 branch — 几乎没用。你拿到讨论可见的 15%。
干净 HN Markdown 长什么样
经过 HN 感知提取器:
# 如果你的构建系统就几百行代码会怎样?
**来源**: https://news.ycombinator.com/item?id=12345678
**提交者**: user42 · **点数**: 489 · **评论**: 312
**发布**: 2026-05-15
## OP 评论
我用 Go 建了一个小构建系统大约共 600 行。和 Bazel/Buck 的不同点是...
## 顶部 thread
- **bcantrill** (84 分): "这是对的方向。Bazel 的复杂度是大多数项目为没用功能交的税..."
- **user123** (42 分): "反驳:Bazel 远程缓存是重点。小本地构建工具没法复制那..."
- **bcantrill** (28 分): "公平,但你可以在简单 core 上叠加缓存。Buck 团队用 [paper 链接] 试过..."
- **another_user** (35 分): "另值得注意:简单方法在 ~500 targets 失效。低于那它显然更好。"
- **drnewman** (61 分): "你的 benchmark 对 Bazel 冷启动比较但 Bazel 实际生产成本是增量重建..."
[完整 thread 继续]
## [dead] 和 [flagged] 标记保留
300 评论 thread 约 25-30k tokens。作者 karma 轨迹、parent-child 关系、dead/flagged 状态全保留。Claude 读了产生根植于特定高 karma 评论的合成。
工作流
三条路:
路径 1:Web2MD HN 提取器 (交互式)
Chrome 打开 HN thread。点 Web2MD。HN 专用提取器:
- 在后台打 HN Firebase API 拿完整评论树
- 保留嵌套最多 5 层,缩进正确
- 抓作者 handle、点数、发布时间戳
- 标记 [dead], [flagged], [downvoted] 评论
- 格式化为可贴 Claude 或存档的干净 Markdown
端到端:每 thread 约 6 秒含 HN API roundtrip。
路径 2:HN Firebase API + 30 行脚本
要批量抽取的开发者:
import requests, json
def hn_to_markdown(item_id):
def fetch(id):
return requests.get(f"https://hacker-news.firebaseio.com/v0/item/{id}.json").json()
def render_comment(c, depth=0):
if not c or c.get("dead") or c.get("deleted"):
marker = "[dead]" if c.get("dead") else "[deleted]"
return f"{' '*depth}- {marker}\n"
indent = " " * depth
author = c.get("by", "unknown")
text = (c.get("text", "")).replace("\n", f"\n{indent} ")
md = f"{indent}- **{author}**: {text}\n"
for kid_id in c.get("kids", []):
md += render_comment(fetch(kid_id), depth + 1)
return md
root = fetch(item_id)
md = f"# {root['title']}\n\n**URL**: {root.get('url', 'self post')}\n"
md += f"**点数**: {root.get('score', 0)} · **By**: {root.get('by')}\n\n"
for kid_id in root.get("kids", []):
md += render_comment(fetch(kid_id))
return md
30 行处理完整树。速率限制在 ~10k 请求触发但典型使用远低于那。
路径 3:批量 HN 研究语料库
# 通过 algolia 搜索找 HN thread
threads = requests.get("https://hn.algolia.com/api/v1/search?query=your+topic&tags=story").json()
thread_ids = [hit["objectID"] for hit in threads["hits"][:30]]
corpus = "\n\n---\n\n".join(hn_to_markdown(tid) for tid in thread_ids)
# 现在贴 corpus 到 Claude
一个话题 30 个 thread 自动。合并语料库典型 ~500k-1M tokens 实质讨论。
真实研究 session
我要理解「2026 年早期阶段 startup 单体 vs 微服务共识是什么?」
- 用 HN Algolia 搜索过去 18 个月相关 thread
- 选 18 个实质 thread (每个 100+ 评论)
- Web2MD 队列 + 批量导出:含 skim 读约 25 分钟
- 合并语料库:~340k tokens
- 贴 Claude Opus 4.7,prompt:「这是 18 个 startup 单体 vs 微服务 HN thread。每边最被点赞的 5 个论点是什么,HN 哪里实际同意 vs 分歧?引用特定评论作者和 thread。」
输出:8 页带特定引用 (user42 在 thread X argue...) 和识别共识区 vs 分歧区的合成。总耗时:~70 分钟。手动版要一整周阅读。
HN 不适合什么
诚实说限制:
- 最近突发新闻:HN 首页天天换。持续事件快照很快变陈。
- 非技术话题:HN 评论质量在核心能力外 (tech, startups, programming language design) 变化很大。消费产品讨论 Reddit 更好。
- 原创研究数据:HN 评论引用一手来源;它们本身不是一手来源。重要主张跟随引用链接。
- 偏见意识:HN 偏男性、美国海岸、基础设施工程。"共识" 反映那个 demographic。
与其他工作流搭配
HN 内容配合得好的:
- Reddit 到 Claude:Reddit 装消费视角,HN 装工程视角
- Wikipedia 转 Markdown:Wikipedia 装已确立知识,HN 装当前从业者意见
- 填 Claude 1M 上下文:HN API 让建 200 thread 语料库变成 30 分钟工作
- LinkedIn 帖子:HN argumentative 文化补充 LinkedIn 促销文化
相关阅读
- 为什么 Claude 读不了 Reddit
- Reddit 到 Claude 1M 上下文:研究管道
- LinkedIn 帖子转 Markdown 给 AI 摘要
- Claude 1M 上下文窗口填法
- HackerNews 转 Markdown — 支持站点页
安装
免费 3 次/天。Pro $9/月解锁无限 + 队列 + 批量导出 + 打 Firebase API 拿完整评论树的专用 HN 提取器。