夜雨聆风最近看 AI Coding 相关工具时，我发现一个很适合拆的项目：21st.dev。
Y Combinator 的公开页面里能看到，21st.dev 服务超过 200 万开发者，并有约 37 万月活跃用户。它的 Magic MCP 也已经出现在 GitHub 和 AI Coding 工具生态里。
这不是一个单纯“组件很多”的网站。
它更像是在做一件事：把前端组件、设计规则和可复用 UI 经验，变成 AI Coding 工具可以直接调用的上下文。
AI 能很快写出页面，但不等于能稳定写出好页面。21st.dev 值得拆的地方，是它卡住了“能用”和“像产品”之间的那段差距。
一、先看公开信息
先把公开资料里能看到的几个信号放在一起。
这些数字和入口说明一件事：AI Coding 的前端问题，已经不是“有没有人想生成页面”。
真正的问题是：生成出来之后，页面能不能像一个完整产品，而不是像一堆临时拼起来的区块。
二、这个需求为什么真实存在
我们用 Cursor、Claude Code、Codex 或其他 AI Coding 工具做页面时，经常会遇到一个很现实的问题。
AI 写功能很快。
让它做一个登录页、设置页、仪表盘、价格页、表格筛选、上传弹窗，它都能很快给出第一版。
但第一版经常只是“能跑”。
真正花时间的，是后面的细节：
按钮间距不统一，卡片层级不清楚，移动端断行奇怪，表单状态不完整，空状态没有设计，图标风格混乱，页面看起来像模板拼贴。
这也是很多 AI 生成产品最容易暴露的问题：功能速度上来了，但设计一致性和产品质感没有一起上来。
AI Coding 让“写页面”变快，但没有自动解决“什么样的页面更适合这个产品”。这中间需要组件、规范、样式和业务场景的上下文。
三、21st.dev 到底怎么解决
如果只把 21st.dev 看成组件站，会低估它的价值。
组件站本身并不新。过去我们也有很多 UI 库、模板站、代码片段站。
21st.dev 更有意思的地方，是它正在把这些组件资产接到 AI Coding 工作流里。
第一步，沉淀可复用组件。
组件不是只有视觉样式，还包含布局、交互状态、响应式处理和常见业务场景。
第二步，让开发者直接安装和改造。
对独立开发者来说，复制一段漂亮代码不够，最好能快速落到自己的项目结构、技术栈和页面风格里。
第三步，用 Magic MCP 接入编辑器。
这一步很关键。用户不一定愿意在组件站和编辑器之间来回切换。更顺的方式，是在 Cursor、Claude Code、Cline 这类工具里直接让 Agent 调用组件、理解组件，再生成页面。
第四步，在项目里继续微调。
真正的产品页面不可能一次生成就完美。组件和 AI 只是起点，后面还要结合业务字段、权限状态、空状态、加载状态、错误状态继续调整。
所以 21st.dev 的核心不是“我有很多组件”。
而是：我把组件变成 AI 可以拿来工作的上下文。
四、它未来可能怎么收费
这类工具的收入逻辑，不一定只靠卖组件。
组件本身容易被复制，真正更有价值的是三层东西。
第一层，质量更高的模板和组件包。
比如 SaaS 仪表盘、开发者工具后台、AI 聊天工作台、定价页、数据表格、用户设置页、账单页、文件管理页。这些都是独立产品高频需要的页面。
第二层，团队级设计系统。
当一个团队希望 AI 生成的页面都符合自己的品牌、组件规范和交互规则时，就需要更稳定的私有组件库和使用边界。
第三层，AI Coding 工作流入口。
如果 Agent 能直接调用组件、读取设计规则、按业务场景生成页面，那么收费点就从“下载一个模板”变成“持续提升团队开发效率”。
这也是它和传统模板站最大的差别。
传统模板站卖的是素材。AI Coding 时代，更值钱的可能是让 Agent 可靠复用素材的方法。
五、它的增长逻辑在哪里
21st.dev 的增长逻辑，有几个很值得我们看。
第一，开源和社区天然适合开发者工具。
开发者工具很难只靠广告解释清楚。能看代码、能试用、能复制、能二次改造，比营销话术更重要。
第二，组件本身有传播性。
一个好看的登录页、图表卡片、命令面板、上传组件，很容易被开发者收藏、转发、二次使用。
第三，MCP 把它从网站变成工作流入口。
这一步对增长很重要。因为 AI Coding 用户每天都在编辑器里工作，如果工具能进入编辑器，就比“等用户想起来访问网站”更接近日常使用场景。
第四，它踩中了 Vibe Coding 的真实痛点。
现在很多人已经能用 AI 做出原型，但要把原型变成更像产品的界面，仍然需要大量调试。谁能降低这部分成本，谁就能占住一个高频入口。
六、我们能学什么
如果我们想做 AI 副业产品，21st.dev 这个案例至少有 4 个可迁移点。
第一，不要只做结果，要做可复用资产。
如果我们只帮用户生成一次页面，很容易变成一次性工具。
如果我们沉淀的是某个领域的模板、组件、流程和规则，就有机会变成长期资产。
第二，优先选一个垂直场景。
不要一上来做“所有网站都能用的组件库”。
可以先做更窄的方向：独立 App 官网、SaaS 后台、AI 工具落地页、跨境电商商品页、内容创作者资料页、本地服务预约页。
场景越具体，组件越容易做深，也越容易让 AI 理解上下文。
第三，接入用户已经在用的工具。
很多 AI 产品失败，不是能力不行，而是让用户多开一个平台、多维护一套流程。
如果能接进 Cursor、Claude Code、Codex、Cline、浏览器插件或现有后台，使用阻力会小很多。
第四，把“审美经验”变成规则。
比如按钮尺寸、表单布局、移动端断行、空状态、加载状态、错误提示、信息层级，这些看起来像设计细节，其实都可以产品化。
AI 越会写代码，这些可复用规则越有价值。
七、风险和门槛也很明显
当然，这类产品也不是随便堆组件就能做起来。
第一，组件质量必须够高。
开发者对代码质量、依赖、可维护性、样式污染和响应式适配都很敏感。不好改的组件，再好看也很难长期用。
第二，同质化很快。
如果大家都用同一套组件、同一种渐变、同一种布局，页面会越来越像。工具必须持续提供更细分、更贴近业务的组件。
第三，版权和来源要清楚。
组件社区越大，越要处理授权、归属、复用边界和原创性问题。
第四，企业客户会要求适配自己的系统。
真正进入团队工作流后，问题会从“给我一个漂亮组件”变成“能不能符合我们的品牌、权限、数据结构和代码规范”。这对产品和交付能力要求更高。
越靠近 AI Coding 的真实工作流，机会越大；但越靠近真实项目，组件质量、维护和适配压力也越大。
最后总结
21st.dev 这个案例，最值得我们带走的不是“组件库还有机会”。
而是 AI Coding 进入下一阶段后，开发者需要的不只是会写代码的 Agent，还需要一套可以被 Agent 调用的产品经验。
组件、模板、设计规范、业务流程、行业页面模式，这些东西以前可能只是设计师和前端工程师脑子里的经验。
现在，它们可以被做成工具、文档、组件库、MCP、插件和自动化工作流。
对我们来说，这就是一个很现实的启发：
不要只问“AI 能帮我生成什么”，也要问“我能把哪些重复经验，做成 AI 可以反复调用的资产”。
AI副业增长笔记
记录 AI 副业、独立开发和产品增长
从想法、开发、上架，到数据、优化、反馈
