webiny-js

Webiny：企业级无服务器 CMS 与 AI 开发平台

背景：一个让大型组织头疼的内容管理难题

想象一下，一家坐拥数亿用户数据的企业——比如亚马逊、财富500强公司或政府机构——想要构建一套内容管理系统。他们面临的选择往往是：要么花大价钱购买商业 CMS 解决方案（动不动数十万美元/年的 SaaS 订阅），要么自己从零造轮子。面对这个两难困境，Webiny 给出了第三条路：开源、自托管、全功能，且专为 AWS 无服务器架构而生。

Webiny 由 Webiny Ltd. 开发和维护，是一个完全开源的 TypeScript 框架。截至目前，它在 GitHub 上拥有超过 7,900 颗星，被亚马逊、阿联酋航空、财富 500 强公司和多个政府机构在生产环境中使用——这些可不是小打小闹的项目，而是真正扛得住亿级数据量、PB 级资产、千名编辑并发的大型系统。

图1：Webiny Headless CMS 内容模型管理界面

类比解释：给 AWS 装上一颗 CMS 大脑

如果把 AWS Lambda、DynamoDB、S3 这些基础设施比作一座摩天大楼的钢筋水泥，那么 Webiny 就是在上面盖楼装修的完整团队——它把 CMS、页面编辑器、多租户管理、GraphQL API 等所有功能打包成一个 TypeScript 框架，开发者用代码扩展，而不是在后台 UI 里点点点。

更关键的是：它跑在你自己的 AWS 账号里。这意味着数据主权完全在自己手里，不存在 SaaS 平台跑路或涨价的问题。这对于金融、医疗、政府等对数据合规要求极高的行业来说，是致命的吸引力。

核心功能拆解

1. Headless CMS（无头内容管理系统）

Webiny 的核心模块。不同于传统 CMS（如 WordPress）将前端和后端绑定，Webiny 做的是纯 Headless 架构：内容存储在后端，通过 GraphQL API 对外暴露，前端可以随意选择 React、Vue、Next.js、Nuxt 等任意框架来渲染。

具体能力包括：

• 自定义内容模型：通过管理后台 UI 或代码两种方式定义内容结构
• 字段级权限控制：不同角色看不同字段，细致到每个字段的读写权限
• 本地化和版本管理：一条内容可以有多语言版本，支持历史版本回滚
• 草稿-发布工作流：内容必须经过审批才能上线，有完整的审计追踪

2. Website Builder（可视化页面构建器）

基于 Next.js SDK 的拖拽式页面编辑器。运营人员不需要懂代码，直接在可视化界面里拖拽组件排版，发布到自己的前端。开发者则可以通过 React 组件自定义页面元素，灵活度极高。

图2：Webiny Website Builder 可视化编辑界面

3. Multi-Tenancy（多租户）

这是 Webiny 最有技术含量的特性之一。它支持从单次部署中天然隔离数千个租户的数据、用户、资产和权限。租户通过 GraphQL API 编程式创建和管理。这让它特别适合 SaaS 平台商：一份基础设施，服务 N 个客户，大幅降低成本。

4. AI 能力：MCP Server + AI Power-Ups

这是 Webiny 近期最令人兴奋的新方向。2024-2025 年间，Webiny 引入了对 MCP（Model Context Protocol） 的支持，使其可以与 Claude 等 AI 大模型深度集成：

• packages/mcp：独立的 MCP Server 包，通过 npx webiny-mcp serve --skills=./skills 启动，暴露 Webiny 的内容模型和 API 能力给 AI 助手调用
• packages/ai-powerups：AI 增强模块，在 CMS 编辑器中集成 AI 辅助功能，帮助内容编辑者更高效地产出内容

Webiny 的 AGENTS.md 文件（而非 CLAUDE.md）明确表明项目在 AI Agent 方向上的野心——通过 MCP 协议，让 AI Agent 能够自主操作 CMS 内容、查询数据、执行发布工作流。

5. 技术栈亮点

从代码结构来看，Webiny 的技术选型非常扎实：

• Monorepo 架构：119 个 npm 包，采用 Yarn Workspaces 管理，涵盖 app-*（React 应用）、api-*（GraphQL 服务）、cli-*（命令行工具）、handler-*（Lambda 处理器）等不同层次
• 编辑器升级：从老旧的 Slate.js 迁移到 Lexical（Meta 开源的下一代富文本编辑器框架），lexical-editor 系列包完整覆盖编辑器开发需求
• 搜索后端：支持 DynamoDB + Elasticsearch 和 DynamoDB + OpenSearch 双路径，api-opensearch 包提供了更灵活的搜索选项
• Pulumi IaC：通过 packages/pulumi 和 packages/project-aws 实现基础设施即代码，开发者一行命令 webiny deploy 即可在 AWS 上搭建完整 CMS 环境

部署门槛：不是给新手准备的

这是 Webiny 最需要坦诚的地方：它的部署难度相当高。

首先，没有 Dockerfile，意味着你无法简单地 docker run 就跑起来。其次，它依赖完整的 AWS 环境——Lambda、DynamoDB、S3、CloudFront、API Gateway、Elasticsearch（或 OpenSearch）、Cognito……这些服务必须全部在 AWS 账号里预先配置或通过 Pulumi 自动创建。

官方推荐的部署路径是：运行 yarn create webiny-project 初始化项目，然后用 Webiny CLI 的 webiny deploy 命令触发 Pulumi 脚本，在 AWS 上按顺序创建 IAM 角色、VPC、S3 桶、Lambda 函数等资源。这个过程对 AWS 新手来说并不友好，即使有文档，也需要 2-4 小时才能完成首次部署。

不过，一旦部署完成，系统就能自动弹性扩缩容——Lambda 按调用计费，DynamoDB 按需扩展，不需要运维人员持续盯着服务器。这正是"无服务器"架构的魅力所在。

代码质量评估

作为一个拥有 119 个包的大型 monorepo，Webiny 的代码组织值得称道：

• TypeScript 强类型：所有核心包均为 TypeScript，有完整的 tsconfig.build.json 构建配置
• Vitest 测试：使用 Vitest 作为单元测试框架，覆盖率较好（__tests__ 目录遍布各包）
• 自定义 lint 工具：使用了自定义的 oxlint（而非 ESLint 的简单封装）和 oxfmt 格式化工具，体现了项目在工程化上的追求
• Monorepo 工具链：Yarn Workspaces + 自定义构建脚本 + Verdaccio 本地 npm 仓库，形成了完整的开发闭环

整体来看，这是一个工程化程度极高的企业级项目，代码质量对得起它的使用场景。

行业意义与局限

Webiny 的出现填补了开源世界里"企业级自托管 Headless CMS"的空白。传统竞品如 Strapi、Directus 虽然也是开源 CMS，但在多租户、GraphQL 深度集成、AWS 原生部署等方面远不如 Webiny 走得远。而与 Contentful、Contentstack 等商业 SaaS 相比，Webiny 的开源性质和数据主权优势又非常突出。

但它的局限也很明显：AWS 强绑定 + 高部署门槛让它天然不适合中小企业或个人开发者。对于想要快速建站的用户，Next.js + 第三方 SaaS CMS 的组合效率更高。Webiny 的目标用户画像应该是：有 AWS 预算和技术能力、需要高度定制化内容平台的中大型组织。

图3：Webiny 官方 Logo