项目地址：[swil-news.vercel.app](https://swil-news.vercel.app)
我做 Swil News，不是因为这个世界上缺一个新闻网站，也不是因为 AI 不能帮我找新闻。恰恰相反，正是因为现在的 AI 已经很像一个很强的搜索引擎了，我才开始认真想另外一个问题：
如果我每次想看某一类新闻，都只是临时打开一个 AI，对它说一句“帮我总结今天的 AI 新闻”或者“帮我看看今天金融市场发生了什么”，这件事虽然能做，但它并不工程化，也不够长期。
它更像一次性的问答，而不是一个稳定的信息系统。而且人们好像已经很久不关注类似报纸这样的内容了，要么是每天面对自媒体，短视频和碎片化信息的噪音干扰，或许一个相信AI的新闻内容产出平台在这个时代下更值得。
我一直觉得，真正好用的东西，不只是“能做”，而是“可以持续地做，而且每次做出来的结果都比较稳定、比较有组织、比较容易回看”。所以我开始想，能不能把这件事从“每次手动问一次 AI”，变成“先把 AI 的行为规范好，再让它持续产出结构化内容，最后给人一个真正可读的界面”。
Swil News 就是从这个想法里长出来的。
我想解决的，其实不是“搜索”，而是“组织”
现在大家都知道 AI 很强，尤其在搜索、整理、总结这些事情上，它已经非常能打了。你给它一个 prompt，它就能很快给你一份结果。
但问题是，这种方式天然有几个限制。
第一，它很临时。
你今天问一次，明天再问一次，输出风格可能不一样，重点可能不一样，结构也可能不一样。
第二，不够可积累。
这些结果大多数时候只是一次聊天记录，不太适合长期归档、持续回看，也不适合慢慢沉淀成你自己的信息资产。
第三，它对“人”的阅读体验并不好。
AI 可以给你一大段结果，但那不等于它已经是一个适合人类阅读的产品。搜索结果和日报产品，其实是两回事。
所以我真正想做的，不是单纯“让 AI 帮我找新闻”，而是想做一个更工程化一点的流程：
先把 prompt、格式、输出路径、主题分类这些东西提前设计好，再让 AI agent 按这个规则去稳定地产出不同类别的新闻内容，最后把这些内容整理成一个真正能每天打开、每天阅读、每天更新的界面。
为什么不只做 AI 新闻
如果只是从“热门方向”出发，那做 AI 新闻当然很合理。毕竟我本身也关心模型、产品、工具链这些东西。
但我做这个项目的时候，脑子里想的并不只是 AI。
我更真实的状态是：我是一个对世界本身有好奇心的人。我想知道今天全球发生了什么，金融市场有什么变化，AI 和科技又在推什么新东西，科学、加密、供应链、能源、汽车这些方向有没有值得关注的变化。问题是，人的时间和精力其实都很有限，不可能每天自己把所有信息源都刷一遍。
所以我才更觉得，这件事值得被“系统化”。
与其每次想到什么看什么，不如提前把几个我长期关心的主题分出来，让它们各自跑自己的生成流程，然后统一汇总到一个地方。这样我每天只要打开这个站，就能用一个比较舒服、比较稳定的方式，快速看一遍今天值得知道的内容。
这也是为什么 Swil News 不是单一主题项目，而是一个多分类日报系统。
我对这个产品的理解，其实很朴素
说实话，这个 app 的技术复杂度并没有高到哪里去。它不是那种看起来“非常重”的系统，也不是什么改变世界的大产品。
但我自己反而挺喜欢这种项目。
因为它不是为了炫技做出来的，而是真的能进入我的日常使用场景里。
如果我今天想快速看一眼新闻，我会打开它。
如果我今天想看某一个专题，我也可以直接点进去。
如果我想让内容每天自动更新，我可以在自己的电脑上让它跑。
如果我某天临时想手动更新一次，我也能自己触发。
它不一定是那种“影响特别大”的产品，但它是一个可以长期运行、长期迭代、并且真的对我自己有帮助的东西。
对我来说，这种项目反而很有价值。因为它不是一个演示，而是一个活的系统。
技术上，我是怎么把这件事串起来的
Swil News 的思路本质上是一个很简单但我觉得很顺的闭环：
先用预设好的 prompt 和脚本，把不同类别的日报生成出来；
再把这些结果以 Markdown 的形式存到本地；
然后用 Next.js 去做渲染、归档、分类、阅读和展示。
我刻意保留了“文件就是数据”这件事。因为我觉得这类内容并不一定需要一上来就进数据库。日报本身天然适合 Markdown：它可读、可版本管理、可迁移，也方便后续继续加工。对这种项目来说，先把内容资产稳定地落到 NEWS/ 目录里，本身就是一个很重要的设计选择。
整个流程大概是这样的：
不同主题对应不同的生成脚本和 prompt 规范
AI agent 根据这些规则去搜索、筛选、整理、成文
内容输出为结构化的 Markdown 日报
构建时生成索引，方便按日期、主题和关键词去浏览
前端再把这些内容用更适合阅读的方式展示出来
我也做了中英文双语支持，因为我本来就希望这个东西不是只能服务一种语言场景。对我来说，双语不是“为了国际化而国际化”，而是因为这本来就是更自然的使用方式。
在技术栈上，我用了 Next.js 来做渲染和页面组织。一方面它对这种内容型站点很顺，另一方面在 SEO、页面结构和部署体验上也比较成熟。虽然这个项目本身不是一个很复杂的 web app，但把这些基础能力做好，至少能让它更像一个完整产品，而不是一个只在本地凑合看的 demo。
为什么我现在更愿意先做 local-first
这个项目其实还可以继续往更重的方向走，比如完全云端化、把生成和展示全部放到线上、做更复杂的调度和分发，等等。
但我现在反而觉得，local-first 对它来说是一个很合适的阶段性答案。
原因很简单：第一，我能控制成本；第二，我能控制生成过程；第三，我能确保这个系统真的先服务于我自己的日常使用，而不是一开始就为了“上线一个很大的平台”去设计很多其实还不必要的复杂度。
而且这件事本身也和现在很多开发者的真实使用场景很接近。我们都在用 agent coding，也都在消耗各种 plan、token、额度。既然这些能力已经在手上，那我自然会去想：能不能把它们用在一个持续运行、持续产生价值的地方，而不是只停留在零散的实验和一次性的调用上。
Swil News 某种程度上就是我对这个问题的一个回答。
这个项目对我来说，更像一种长期练习
我不觉得每个项目都一定要“特别大”才有意义。很多时候，一个项目的价值，不在于它多复杂，也不在于它多有商业想象力，而在于它是不是能真实运行，能不能持续迭代，能不能真的帮到人。
Swil News 对我来说就是这样一个东西。
它一方面是一个产品思考练习：如何把 AI 的一次性能力，整理成一个稳定、长期、可用的信息产品。
另一方面也是一个工程练习：如何用尽量克制的技术复杂度，把一个看起来不大、但其实有真实使用价值的系统做完整。
我现在并不觉得它已经做完了。它后面还有很多可以继续优化的地方，比如更强的搜索、更稳定的云端运行方式、更好的生成调度、更丰富的阅读体验，甚至可能进一步把它做成一个更完整的“个人信息中枢”。
但至少到现在为止，我已经很满意它完成了一件事：
它把“AI 能帮我找新闻”这件事，往前推了一步，变成了“我真的有一个地方，可以每天去看新闻”。
而对我来说，这一步就已经很值得了。