韩国开发者1人单挑30家科技媒体，RSS聚合玩出新高度

每天早上打开15个标签页刷科技新闻，开发者김민수（Kim Minsu）算过账：平均47分钟，一年就是286小时。这相当于一个程序员整整7周的工作时间，全耗在信息筛选上。

他没买付费工具，没等大公司出手，直接写了个平台自己用。三个月后，한눈IT（Hanun IT，意为"IT一目了然"）上线，现在每天自动抓取30+信源，把英文内容实时翻译成韩语，还能根据用户偏好推送。

一个人做聚合，技术债怎么还

김민수在技术博客里公开了架构细节。最扎眼的不是用了什么前沿框架，而是缓存策略的层层嵌套——像俄罗斯套娃，每一层都为了解决特定场景的延迟问题。

文章页用增量静态再生（ISR），300秒重新验证一次；API路由带s-maxage=300和stale-while-revalidate=600头。用户点进来，大概率读到的是CDN缓存，数据库连面都不用露。

但真正的性能杀招在数据层。详情页原本串行查Supabase，改成Promise.allSettled并行后，加载时间砍掉40%。客户端再用TanStack Query做5分钟新鲜度+30分钟垃圾回收的缓存，页面切换几乎看不到转圈。

有个细节很产品经理思维：他用React.cache()做了请求级去重。generateMetadata和页面组件共享同一份数据，避免重复查库——这是很多全栈开发者容易漏掉的坑。

RSS没死，只是换了活法

한눈IT的核心依赖是RSS，这个被唱衰十几年的协议。김민수的用法很务实：不追求实时，接受5-15分钟的延迟，换取可控的服务器成本。

30+信源涵盖TechCrunch、The Verge、Ars Technica等国际媒体，也有韩国本土的IT조선、블로터。英文内容走Naver Papago API自动翻译，视频源直接接YouTube Data API，和文字混排。

产品形态上，他做了两个反直觉的设计。一是强制摘要：每篇文章AI压缩到3-5句话，用户先扫再决定要不要读全文。二是情绪切换：读累了可以切视频 tab，同一主题的视频和文章并列，不用跳去YouTube被推荐算法绑架。

社交功能很克制：评论、点赞、周刊订阅。没有关注体系，没有算法推荐流。김민수的解释很直接："我是给自己做的，不需要抖音那套。"

个人项目 vs 平台逻辑

한눈IT的上线时间很有意思：2024年初，正是Perplexity、Arc Search等AI搜索工具密集发布的时候。这些产品的解法是用大模型直接生成答案，跳过信息源；김민수走了另一条路——不消灭信源，而是优化接触信源的方式。

这有点像Spotify和Bandcamp的区别。前者用算法替你决定听什么，后者让你自己逛，但把唱片店的动线设计得更舒服。

技术实现上，한눈IT的栈很" boring "：Next.js 14 App Router、Supabase、Vercel、TanStack Query。没有向量数据库，没有RAG，摘要用的还是传统NLP而非GPT-4。김민수的考量很实际：个人项目，推理成本能省则省。

但有个设计透露了野心。他做了完整的OpenGraph元数据生成，分享文章到Twitter/Threads时，卡片带摘要、来源图标、阅读时长。这是平台级产品的标配，个人工具很少做到这个程度。

开发者工具的"自私"哲学

한눈IT的GitHub仓库没开源，但技术博客写得极细。김민수的解释是："代码耦合了我的Supabase schema和API密钥，清理出来比重写还麻烦。但思路可以抄，架构图随便用。"

这种"自私开发"（selfish development）正在变成一种趋势。开发者不再追求做下一个独角兽，而是先解决自己的痛点，顺手开放给同温层的人用。产品形态轻盈，功能聚焦，不做用户增长，靠口碑在特定圈子里扩散。

한눈IT的注册用户数김민수没公开，但他在评论区回复过：周刊订阅"比预想的多"，主要是韩国本土的初创公司CTO和独立开发者。这些人每天的时间同样被切割成15分钟的碎片，需要一个"科技新闻的Inbox Zero"。

现在的问题是：当AI搜索能直接回答"这周AI领域发生了什么"，RSS聚合还有存在价值吗？김민수在博客里的原话是：「我不相信任何给我答案却不给我看来源的工具。」

你会为了可控的信息摄入体验，放弃算法推荐的"猜你喜欢"吗？