AWS PACE 团队为何将其全栈脚手架构建为 Nx 插件
即便让编程 Agent 负责生成前端、API 和基础设施代码，我们也希望结果可预测。AWS PACE 团队（原型开发与 AI 客户工程组）在客户项目中遇到了这个痛点，于是他们将整套配置封装成了一个 Nx 插件。
接下来我们看看它是如何工作的，以及为什么随着 Agent 能够编写这类自动化代码，底层的 Nx Devkit 变得愈发重要，顺便聊聊如果你想自建插件该从哪入手。
面向 AWS 的 Nx 插件
本周，AWS 发布了 Nx Plugin for AWS v1.0，Jack Stevenson 在 AWS 开源博客上介绍了其工作原理。这里不再复述全部细节，建议直接阅读那篇博文，或者查看我的实操演示：
简单来说，你可以通过以下命令创建一个全新的 AWS + Nx 工作区：
pnpm create @aws/nx-workspace my-project（当然也可以用 npm）
然后参考插件文档 来探索其各项能力，文档有详细讲解，甚至包含一个通过构建完整应用来演示的 Dungeon Adventure 教程。你也可以直接让 Agent 阅读文档并动手操作。
为什么要这样做
PACE 团队的工作是为客户探索难题，而他们的切入点就是做原型。
我们隶属于 PACE，即 AWS 的原型开发与 AI 客户工程团队，每天都要在开发速度与生产就绪度之间做平衡。我们跟客户一起解决那些尚无明确答案的问题，或者实现那些技术上风险较高、从未有人构建过的想法。
因此，他们需要一种能快速推进、且不绑定特定语言的化工具。
在 AWS 上开发通常意味着基础设施即代码、后端服务、前端，往往还在同一个项目里涉及多种语言。我们需要一个构建系统，它对所选语言保持中立，并且能管理由许多可变部分组成的项目。我们的团队最终选择了 Nx，并已经用它来专门处理这类场景多年 [……]
目标是在产品落地前拥有一个可运行的原型，这个原型已经内置了构建模块，可以直接拿过去集成到正式产品中。在确定采用 Nx 插件之前，团队探索过多种方案，例如使用模板或基于库的方法。
Nx 生成器最终成为了最合适的选择。不同于要 fork 的模板或要依赖的库，生成器直接将代码写入你的工作区。从生成那一刻起，这些代码就归你所有，后续使用也不需要任何与插件相关的依赖。当生成器没有预见到某些变更需求时，你可以像平常一样直接编辑代码。对于那些因模板导致生成的代码落后的场景，Nx 的迁移功能能让我们后续发布的改进同步应用到早期搭建的工作区中。[……] 每个生成器都被刻意设计为自包含的 [……] 并封装成更高层的构建块：你可以用一条命令组装完整组件，无论你是手动操作还是借助 AI 助手。
生成器是确定性的。智能体决定运行哪些生成器以及如何连接它们。当结果需要针对特定用例进行调整时，智能体可以像处理工作区中的其他代码一样编辑生成的代码。
Nx Devkit 作为可扩展 API
AWS 团队构建的一切都基于 Nx Devkit，这也是 Nx 官方插件使用的同一套 API。它涵盖自定义安装包（如 create @aws/nx-workspace）、用于搭建和修改代码的生成器、执行器，以及告知 Nx 新工具和语言的项目图插件。
过去基于 Devkit 进行开发需要花费大量时间。你必须学习生成器 API，以及插件如何推断项目和任务，因此自定义自动化只有能为团队节省大量工作才值得投入。编码智能体恰好擅长这类工具代码，因此现在你可以将其中很大一部分工作委派给它们。
一些示例：
- 本地工作区生成器 - 让智能体指向现有库，提取出一个能按相同结构搭建新库的生成器。我在一个关于工作区生成器的视频中演示过这一点。
- 自定义 Lint 规则 - 对于公共 ESLint 插件未涵盖的团队规范，可以将其作为自定义工作区 ESLint 规则保存在工作区内。
- 语言支持 - 项目图插件会读取工具链的配置文件，把它们转换为 Nx 的项目、任务和依赖。Add Language Support to Nx 指南以 Python 和 uv 为例做了完整演示，还提供了一个可以直接交给你的 agent 使用的提示词。
有了语言支持，Nx 也能管理 JavaScript 之外的技术栈。社区开发的 @monodon/rust 插件把 Rust 接入了任务图，我曾用它在同一个 monorepo 里结合 Rust 和 TanStack。社区的 @nxlv/python 插件则为基于 Poetry 的 Python 项目提供了同样的能力。我们（Nx 核心团队）提供的 .NET、Maven 和 Gradle 插件也都构建在相同的 Devkit 基础之上。
构建你自己的插件
如果你的组织有自己的新项目启动方式（标准认证库、内部部署配置、指定使用的框架），那大概率也适合做成类似 AWS 插件这样的形态。Extending Nx 板块中的这些指南是不错的起点：
- 创建组织专属插件，集中管理你的生成器
- 本地生成器，适合只有一个 workspace 需要的自动化任务
- 创建安装包，实现你自己的
create-*命令，就像@aws/nx-workspace那样 - 发布你的插件，在多个仓库间共享
AWS 还提供了用他们的 ts#nx-plugin 生成器构建插件的文档，可以通过 MCP server 把你的生成器暴露给 AI 助手。