最近在认真想 FrontPost。

不是“我又想到了一个看起来很酷的 side project”，也不是“诶我会前端、后端、AI、爬虫、移动端，不如把技能点都缝到一个项目里证明一下我很厉害”。这种东西以前可能会让我短暂兴奋，但现在越来越觉得没什么意思。

我想做的是一个真的有人需要、真的能跑起来、真的能解决痛点的产品。

这句话听起来很像创业鸡汤，但对我来说其实是一个很具体的分界线：我不能再把“做出来”当作终点了。写完代码、部署上线、UI 好看、架构完整，这些都只是产品成立之前的必要条件。真正的问题是：有没有一群人，会因为这个东西少一点痛苦、多一点效率、得到一个原来没有的工作流？

啾啾状态：第一次认真从“我能不能做出来”切到“别人为什么需要它”。

FrontPost 是什么

FrontPost，前沿邮报。

我现在对它的定义是：面向科研和前沿资讯的 AI 原生跨端产品，核心体验是一套持续运行的文献追踪 Agent，加上编辑化的研究界面。

更人话一点说，它不是一个新的论文搜索框。

搜索解决的是“一次性找资料”。但很多真实场景不是这样的。你关注一个领域、一个问题、一个技术路线、一个作者、一个公司或一个产业方向时，真正困难的不是今天搜到几篇论文，而是：

• 新东西每天都在出现，我怎么知道哪些真的重要？
• 预印本、正式发表、引用、反证、撤稿、开源代码、数据集之间的变化怎么串起来？
• 我不想每天打开十个网站刷新，但我也不想错过关键进展。
• AI 总结可以很快，但它到底依据哪篇原文、哪段证据、哪里是模型推断？
• 信息最后应该进入我的工作流，而不是停在某个漂亮页面里。

所以 FrontPost 想做的不是“帮你搜论文”，而是“帮你持续追踪一个领域，并把变化整理成一份可以读、可以查、可以订阅、可以回到证据的前沿邮报”。

公开领域的邮报可以免费订阅，比如 AI 与计算、生命科学、医学健康、气候与能源、材料科学。个人版则可以按关键词、作者、期刊、机构、技术路线去定制。送达方式不应该只有站内消息，而应该有 Web、邮件、RSS、Zotero，甚至之后的 AI 播客。

这个想法让我比较兴奋的地方在于，它不是把 AI 贴到页面角落里当聊天框，而是让 AI 进入一个完整工作流：发现、筛选、追踪、解释、投递、反馈，然后继续校准。

为什么不是自娱自乐

我以前很容易被“工程完整性”吸引。

比如一个项目有好看的前端、有后端 API、有异步任务、有数据库、有 Docker、有 CI/CD、有移动端、有一堆架构图，我就会觉得：哇，好完整，我好棒。

但现在看，这还不够。

一个全栈项目很容易变成自娱自乐。尤其是当开发者本身很喜欢搭系统的时候，更容易在“我能不能把这套东西搭出来”里获得满足感。但用户不关心这个。用户只关心：它帮我省了什么时间？减少了什么不确定性？解决了什么原来绕不过去的麻烦？

所以我想给 FrontPost 设一个很朴素的要求：

如果它失败，也应该失败在真实产品假设上，而不是失败在我做了一个没人要、但我自己觉得技术上很完整的东西。

这也是为什么我不想把它只写成一个技术项目。它当然需要技术，而且技术复杂度不低：学术来源接入、爬虫与 API、去重、任务队列、摘要、引用追踪、对象存储、权限、投递、跨端体验、成本控制、合规边界，全都要考虑。

但技术只是 bridge，不是目的。

我真正想验证的是：在信息过载已经成为常态的情况下，科研和前沿行业的人是不是需要一种比搜索更连续、比 newsletter 更可定制、比普通 AI 摘要更可信的研究信息产品。

第一次以 CEO 的方式做产品

我说“类似 CEO 角色”，不是因为想给自己贴一个很大的 title。

恰恰相反，这个词对我来说意味着不能只躲在自己最熟悉的工程舒适区里。

以前做东西，我最自然的反应是：先把架构想清楚，先把 repo 搭好，先把技术路线跑通。这个当然重要，我也确实喜欢构建好且跑得通的工程。但如果我真的把 FrontPost 当作产品，就不能只问“怎么实现”，还要持续问：

• 这个用户是谁？
• TA 为什么现在需要？
• TA 现在用什么替代方案？
• 我做的东西比替代方案好在哪里？
• 第一版最小闭环是什么？
• 哪些功能只是我觉得酷，实际上会拖慢验证？
• 怎么定价、怎么获客、怎么保留、怎么判断值得继续做？

这部分对我反而是更大的挑战。

因为写代码的时候，问题虽然多，但大多数问题可以被拆解、复现、调试、修掉。产品问题更麻烦。它会逼你面对真实世界：用户不按你想的方式使用，需求不是你脑子里最优雅的抽象，市场不会因为你的架构好看就自动奖励你。

说白了，CEO 不是“更大的程序员”。CEO 要为方向、节奏、取舍和结果负责。

我现在还远远谈不上会，但 FrontPost 可以是第一次认真练习。

全栈的意义

全栈对这件事仍然很重要，只是意义变了。

它不是“我一个人可以从 0 写到 1，所以很酷”。而是当我想验证一个产品闭环时，不会被某一个环节卡死。

我可以自己做前端，把信息层级、阅读体验、订阅入口和移动端适配先跑出来；可以自己做后端，把任务队列、数据模型、用户系统和投递链路先搭起来；可以自己理解 AI 调用和成本；也可以自己判断哪些地方该先糙一点，哪些地方一开始就不能糙。

这种能力的价值不是炫技，而是缩短反馈回路。

FrontPost 的第一阶段不需要一开始就宏大。它可以先从一个很小的闭环开始：

• 选几个公开学术来源。
• 选几个高价值公开领域。
• 每天稳定抓取和筛选新增内容。
• 生成一份可读、可追溯、可订阅的前沿邮报。
• 让真实用户订阅、阅读、反馈。
• 根据反馈决定继续加阅读器、Zotero、播客、个性化追踪还是别的。

这才是我理解的全栈：不是把所有层都写满，而是把从痛点到交付的链路打通。

接下来怎么做

我现在对 FrontPost 的要求大概有三条。

第一，先证明痛点存在。

不能只因为我自己喜欢前沿信息、喜欢论文、喜欢 AI，就默认大家也需要。我要去看真实用户现在怎么追踪信息：他们订了哪些 newsletter、用不用 RSS、有没有 Zotero 工作流、会不会每天刷 arXiv、会不会用 Perplexity / Elicit / Semantic Scholar / ResearchRabbit 这类工具，以及这些工具哪里不够顺手。

第二，先做一个能闭环的版本。

第一版不需要包山包海。它只要能让用户完成一件事：订阅一个领域，然后持续收到一份质量稳定、证据清楚、能回到原文的前沿邮报。如果这个闭环不成立，后面再多功能都是装饰。

第三，审美和可信度不能让位。

FrontPost 处理的是研究信息，不是短视频 feed。它应该友好、轻盈，但不能轻浮；应该现代、AI-native，但不能像一个随便生成的模板站；应该有摘要和播客，但每条结论都要能回到原文。

这也是我为什么很在意它的视觉语言：圆角、纸张感、留白、编辑化层级、证据回链，这些不是单纯的美术问题。它们会影响用户是否愿意相信、阅读和长期使用一个产品。

最后

我不知道 FrontPost 最后能不能做成。

但我现在越来越确定，它至少值得我认真试一次。不是作为一个“我又做了个项目”的作品集条目，而是作为一次真正的产品实践：从需求、设计、工程、数据、AI、增长、商业化，到我自己作为负责人如何做判断。

这件事对我也有点像从工程师视角往产品负责人视角走的一次训练。

以前我会更关心“我能不能把一个复杂系统搭起来”。现在我更想知道：“我能不能做出一个别人真的愿意用、并且用完觉得生活或工作变好了一点的东西。”

如果能，那就太好了。

如果不能，也至少要搞清楚为什么不能。

啾啾状态：有点紧张，但开始干活。

总之，FrontPost 开工。

不是玩具，不是 demo，不是自娱自乐。

要做一个真的解决问题的东西。