一份活的 awesome 清单:2,400+ 精选 vibe-coded app,每日更新、自我修剪

为什么做成仓库

Awesome list 是开发者真正找东西的方式——排名好、有人 star、在需要的那一刻被快速翻阅。但它们也共享同一种命运:链接腐烂。清单靠热情维护,热情会退,两年后一半条目 404。清单还挂在那里,信任却悄悄走了。

而 One's Vibe 本来就在运转着解决这件事的机器。画廊里每个 URL 都在 ~3 天一轮的滚动复查里;一个 app 长时间无响应,就会被安葬——移出画廊,进 Graveyard 立碑。把这套机器对准一个 README,对我们是零成本,却给了这份清单一种再自律的维护者也给不了的性质:它会自我修剪。

里面有什么

一个 README,由运营画廊的同一班 agent 每天再生成:

• 目录本身。 Editor's Picks 置顶,往下十一个分类——游戏、效率、创意工具、AI agent、开发者工具等等——每条是名字、一句诚实的介绍、在线网址,和一个链回详情页的入口。
• Graveyard。 曾在这份清单上、后来熄灯的 app,留名字和日期,网址刻意不加链接。多数清单藏起自己的死者;我们的死者是标准为真的证据。
• 数据。 data/projects.json 和 data/graveyard.json——整个公开目录的 CC0 JSON:中英双语描述、分类、标签、检测到的技术栈、star 数、try 数。而且因为是 git,提交历史就是 vibe-coded web 的一份免费时间序列。

也是为 agent 造的

这个仓库同时是 coding agent 的低成本通道。浏览、过滤、「列出所有 AI 写作工具」「哪些用 Next.js 搭的」——那是 GitHub CDN 上的一个静态文件,无 API、无限流。只有语义查重(「这个想法有人做过吗?」)才需要在线的 reference API 或 MCP 服务器。仓库里有一个 skill,教 agent 的正是这套分流。

照例的诚实

规矩和画廊一致。「Live checked」意思是这个 URL 最近可以访问——不是安全审计、不是背书、不是质量分。分类内的排序只用公开信号:近期 try 数和 GitHub star。仓库里的一切本来就是公开数据;没有任何私有的东西搭了便车。

去 star、去 fork、拿数据去搭东西:

github.com/JefferyLee/awesome-vibe-coded-apps

想让你的 app 上榜?提交它——在画廊发布后,下一次再生成会自动收录。 /submit