为什么 AI 最擅长 React/Next.js,却很少看到真正好用的 Next.js 开源项目?

0 阅读5分钟

这是一个很有意思的问题,而且实际上揭示了一个经常被混淆的概念:

“AI 最擅长写 React/Next.js” ≠ “AI 最擅长构建大型 Next.js 项目”。

1. React/Next.js 的训练语料确实最多

GitHub 上拥有数量庞大的 React/Next.js 项目、教程、博客和示例,因此 AI 对组件、Hook、Tailwind、路由、Server Action 等局部开发任务表现非常优秀。

但这并不意味着 AI 学到了企业级应用的整体架构。

2. AI 学到的大多数是“局部代码”

训练数据中大量存在的是:

  • Button.tsx
  • LoginForm.tsx
  • UserTable.tsx
  • useFetch.ts

而不是完整的 ERP、CRM、电商、CMS 等大型系统。

商业项目通常不会开源,因此 AI 能学习的大型工程案例相对有限。

3. Next.js 社区大量都是 Demo 或 Starter

很多高 Star 项目实际上只是:

  • 登录
  • 博客
  • Dashboard
  • Stripe 支付
  • Prisma
  • 基础认证

它们展示的是技术组合,而不是经过多年演进的企业系统。

4. Next.js 本身不是企业框架

Next.js 的定位一直是 React Framework,它主要解决:

  • Routing
  • Rendering
  • Build
  • Image
  • Server Functions

而企业应用真正复杂的是:

  • 权限体系
  • 多租户
  • 插件机制
  • 模块化
  • 工作流
  • 数据权限
  • 审计
  • 消息系统
  • 事务
  • 国际化

因此实际项目通常还需要大量外围技术栈共同完成。

5. React 的最大优点,也是最大挑战

React 高度灵活,可以自由组合:

  • Redux、Zustand、MobX……
  • React Hook Form、TanStack Form……
  • SWR、TanStack Query……
  • Prisma、Drizzle……

这种生态繁荣意味着不存在唯一的最佳实践,也导致 AI 更容易学习到大量不同风格,而不是统一架构。

6. 真正困难的是架构,而不是代码

AI 已经能够快速生成 CRUD 和组件。

真正困难的是:

  • 为什么模块这样拆?
  • 为什么生命周期这样设计?
  • 为什么权限模型采用这种方式?
  • 为什么插件扩展点放在这里?

这些来自长期实践和持续演化,而不是单纯的代码统计。

总结

“AI 擅长 React”更准确地说,应理解为:

AI 非常擅长补全 React/Next.js 代码,但并不意味着它已经学会设计大型 React/Next.js 应用。

训练语料丰富提升的是局部代码生成能力;而成熟企业级项目依赖的是长期架构设计、业务沉淀和持续演进。这也是为什么真正优秀、长期维护的大型 Next.js 开源项目并不多。


如果目标是企业级全栈项目,可以试试 CabloyJS

上面的结论并不是说 React 或 Next.js 不好。它们仍然是非常优秀的工具:当你需要 React 生态、需要快速构建页面,或者项目本身就是一个边界清晰的 Web 应用时,Next.js 可以非常直接。

但如果你的目标从“做出一个应用”变成“长期演进一套企业系统”,那么除了生成组件和接口,还需要一套能回答以下问题的全栈框架:

  • 一个业务能力应该归属到哪里?
  • 后端 DTO、OpenAPI 和前端调用如何避免各写一份?
  • 前端资源变化后,后端侧的元数据或 SSR 消费者如何同步?
  • 多个业务模块、Admin、Web、SSR、SPA 如何在同一个工程中协作?
  • AI 生成的代码如何遵循已有模块、命令和验证路径,而不是在仓库里随意拼接?

这正是 CabloyJS 希望解决的问题。

CabloyJS 是一个 Node.js 全栈框架系统:

  • Vona 提供后端运行时、业务服务、数据与契约能力;
  • Zova 提供前端应用能力;
  • suite/module 为业务域和能力提供稳定的组织边界;
  • contract loop 让后端 OpenAPI 契约生成前端 SDK,也让前端资源和元数据能沿明确的交接路径回到后端侧;
  • CLI-first workflow 将创建、生成、构建和验证变成仓库可发现、可重复执行的工作流。

它的价值不在于让 AI 替你完成架构设计。真正的价值是:当项目已经有明确的模块边界、契约来源、生成路径和验证要求时,AI 不必只依赖临时提示词猜测“应该怎么做”,而可以在同一套全栈规则中参与开发。

当然,这也意味着 CabloyJS 并不是最轻量的选择。它需要学习 Vona、Zova、suite/module 和 contract loop 的模型;对于一次性页面、简单网站或明确只采用 React/Next.js 的项目,保持轻量可能更合适。

但当你需要多模块业务系统,需要前后端长期同步,需要同时处理 Admin、Web、SSR 和 SPA,或者希望 AI 不只会生成局部代码,而能逐渐遵守整个仓库的协作规则时,CabloyJS 值得尝试。

从一个小实验开始

Cabloy Basic 的公开起点是:

npm create cabloy

进入生成的项目后,启动后端:

npm run dev

也可以分别启动 Cabloy Basic 的 Zova Admin 或 Web 前端:

npm run dev:zova:admin
npm run dev:zova:web

然后跟随 Cabloy Fullstack Quick Start Tutorials,从创建一个小模块开始,亲手体验 CRUD、前后端契约共享和全栈工作流如何连接在一起。

如果你正在寻找的不是“另一个组件库”或“另一个 Next.js Starter”,而是一套面向企业级全栈协作的框架,不妨从 Cabloy Fullstack Quickstart 开始试用 CabloyJS。

延伸阅读