Nx工作区模式Skill：把 monorepo 的目录、边界与缓存一次配置到位
- 它是什么：
nx-workspace-patterns（Nx工作区模式Skill）是一个面向 Nx monorepo 的配置与优化技能，把「新建工作区、划分库边界、加速 CI、接入远程缓存」这些高频但容易出错的动作，沉淀成可直接套用的模板与规则。 - 核心交付物：
nx.json配置模板、项目级project.json模板、ESLint 模块边界约束规则、自定义生成器代码、基于 affected 命令的 CI 流水线、本地/云端缓存方案，以及一组常用命令与最佳实践清单。 - 解决什么痛点：Nx 能力很强但配置项分散在
nx.json、项目配置、ESLint 规则、CI 脚本多处，新手容易「装完不知道下一步做什么」，老项目则容易在库边界上失控、循环依赖堆积、CI 越跑越慢。 - 适合谁：前端架构师、负责工程化的技术负责人、正在把多仓库合并成 monorepo 的团队，以及已经在用 Nx 但想补齐缓存与边界规范的开发者。
- 一句话结论：它不是又一个文档搜索工具，而是把 Nx 的生产级实践「实例化」到你的仓库里，让配置从「凭经验猜」变成「照着模式填」。
1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | Nx工作区模式Skill |
| 技能英文名 | nx-workspace-patterns |
| 技能ID | 13252 |
| 技能定位 | 配置与优化 Nx monorepo 工作区 |
| 触发场景 | 搭建 Nx 工作区、配置项目边界、优化构建缓存、实现受影响命令（affected） |
它到底解决什么问题
Nx 是一个成熟的 monorepo 工具链，但它把复杂度留给了配置者：一个可用的生产级工作区，需要你同时想清楚目录分层、库的类型划分、项目标签体系、依赖约束规则、可缓存的任务范围、CI 中如何只跑受影响的项目、以及缓存放在本地还是远端。这些内容分散在多个文件里，彼此还有依赖关系——比如你在 ESLint 里写了 type:feature 的约束，就必须保证项目 project.json 里的 tags 真的打上了对应的标签，否则规则形同虚设。
这个技能的价值就在于：它把上述配置以「模板 + 规则 + 命令」的形式一次性给全，你只需要按自己的项目名、组织名、技术栈做替换，就能得到一个语义自洽的 Nx 工作区骨架。
一键安装 AI 技能提升开发效率的思路
AI 技能的安装通常遵循同一套逻辑：找到技能 → 安装到你的 AI 助手/客户端 → 用一句自然语言验证是否生效。具体步骤如下：
- 确认安装前提：你使用的 AI 编程助手或技能市场需要支持「技能（Skill）」机制，并已完成账号登录；同时本机应具备 Node.js 运行环境，因为后续 Nx 工作区的初始化与命令执行都依赖它。
- 获取技能：在技能市场或技能列表中搜索技能中文名「Nx工作区模式Skill」或英文名
nx-workspace-patterns，也可直接使用技能ID13252定位。（技能市场的具体入口地址与页面路径以官方说明为准。） - 执行安装：在技能详情页点击安装/启用按钮，或在客户端内通过技能安装入口添加。若你的客户端支持命令行安装方式，请以官方文档给出的命令为准。
- 验证是否生效：安装完成后新开一个会话，直接提问「帮我写一份 Nx 的 nx.json 配置，要求开启 build/test/lint/e2e 缓存并限制并行数为 3」。如果返回的是结构完整、带
targetDefaults与namedInputs的配置，而不是泛泛而谈的建议，说明技能已生效。 - 补充验证边界能力：再追问「
type:ui的库允许依赖哪些类型的库」，若回答能对应到enforce-module-boundaries的depConstraints规则，说明技能已能正确调用其内置模式。
说明：本技能详情中未提供具体的安装命令、下载链接与资费信息，请以官方技能市场页面说明为准，本文不代为编造。
2. 该技能的主要功能和特点
主要功能
- 工作区架构设计：给出
apps/（可部署应用）、libs/（共享库）、tools/（自定义执行器与生成器）三层目录模型，并区分shared与feature两类库的组织方式。 - 库类型规范化：内置 feature、ui、data-access、util、shell 五种库类型的职责定义与命名约定，避免「这个组件该放哪」的反复讨论。
nx.json配置生成：覆盖affected.defaultBase、tasksRunnerOptions的可缓存任务列表与并行数、targetDefaults的任务依赖与输入声明、namedInputs的 default/production/sharedGlobals 分层，以及生成器默认参数。- 项目级
project.json模板：以应用web为例，完整给出 build / serve / test / lint 四个 target 的执行器、输出路径、开发与生产两套 configuration 的差异配置。 - 模块边界强制：提供基于
@nx/enforce-module-boundaries的 ESLint 规则，从type:（架构层级）与scope:（业务域）两个维度约束依赖方向，并开启enforceBuildableLibDependency。 - 自定义生成器示例：给出
feature-lib生成器的完整 TypeScript 实现，包含调用libraryGenerator生成基础库、读取项目配置、批量写入自定义文件、格式化收尾的完整流程。 - CI 加速方案：提供基于 GitHub Actions 的流水线模板，包含
nx-set-shas派生基线 SHA、nx affected分任务执行、按任务调整并行度（如 e2e 并行数为 1）。 - 缓存能力接入：同时给出 Nx Cloud 与自托管 S3 缓存（
@nx-aws-cache/nx-aws-cache）两种配置写法，并支持自定义缓存目录。 - 常用命令与最佳实践：汇总生成库、运行受影响任务、查看依赖图、重置缓存、版本迁移等高频命令，并给出「应该做的 / 不应该做的」清单。
和普通工具比强在哪
| 库类型 | 目的 | 示例 |
|---|---|---|
| feature | 智能组件、业务逻辑 | feature-auth |
| ui | 表示组件 | ui-buttons |
| data-access | API 调用、状态管理 | data-access-users |
| util | 纯函数、辅助工具 | util-formatting |
| shell | 应用程序引导 | shell-web |
差异化之处在于三点。第一，它给的是成套的、可互相引用的配置，而不是孤立的代码片段——边界规则里用到的标签，正好是项目模板里打的标签。第二，它内置了取舍判断，比如「不要过度细化库数量」「不要跳过 affected」「不要创建循环依赖」，这些是踩坑经验而非 API 说明。第三，它覆盖了从开发到 CI 的完整链路，本地缓存与远程缓存、affected 与依赖图是配套出现的。
3. 如何使用该技能？
步骤一：明确你的工作区目标
先用自然语言把现状说清楚，例如：「我们是一个 React + Node 的中型团队，现在有 3 个前端应用和 2 个后端服务，代码分散在多个仓库，想合并成 Nx monorepo，需要有人帮我规划目录和库类型。」
步骤二：让技能输出架构方案
技能会给出 apps/ 与 libs/ 的分层建议，并按 feature / ui / data-access / util / shell 归类。此时你需要确认：业务域（scope）怎么切分，比如按 web、api、shared 三个域划分。
步骤三：生成 nx.json
输入示例：「按 npmScope 为 myorg、默认基线分支为 main、需要缓存 build/lint/test/e2e/build-storybook 的要求，生成一份 nx.json。」
输出说明：你会得到包含 $schema、npmScope、affected、tasksRunnerOptions、targetDefaults、namedInputs、generators 的完整配置。重点检查 namedInputs.production 是否排除了测试与 lint 配置文件——这直接决定缓存命中率。
步骤四：为项目补 project.json 与标签
输入示例：「给 apps/web 生成项目配置，使用 webpack 构建，需要 development 与 production 两套配置，标签设为 type:app 和 scope:web。」
输出说明：得到含 sourceRoot、projectType、tags、targets 的项目配置，build 的 configurations 中生产环境应开启 optimization、outputHashing: all，关闭 sourceMap。
步骤五：启用模块边界规则
输入示例：「帮我写 ESLint 的模块边界规则，要求 util 只能依赖 util，ui 只能依赖 ui 和 util，app 可以依赖除 app 外的所有类型，并按 scope 限制跨域引用。」
输出说明：得到 @nx/enforce-module-boundaries 配置，含 depConstraints 数组与 enforceBuildableLibDependency: true。写好后务必用 nx lint 跑一遍，确认已有代码没有违规。
步骤六：接入 CI 与缓存
输入示例：「给我一份 GitHub Actions 配置，只在 PR 和 main 分支触发，用 nx affected 跑 lint/test/build/e2e，并接入缓存。」
输出说明：流水线中必须包含 fetch-depth: 0 的完整拉取与 nrwl/nx-set-shas 步骤（否则 affected 无法计算基线），随后是 npx nx affected -t lint --parallel=3 等命令。若要远程共享缓存，再追加 Nx Cloud 的访问令牌配置或 S3 缓存桶配置。
步骤七：日常使用与验证
常用命令包括：nx g @nx/react:lib feature-auth --directory=libs/web --tags=type:feature,scope:web 生成新库；nx affected -t test --base=main 只测受影响项目；nx graph 查看依赖图确认无环；nx reset 清理异常缓存；nx migrate latest 配合 nx migrate --run-migrations 完成版本升级。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| Nx工作区模式Skill（nx-workspace-patterns） | AI 技能，把 Nx 生产配置模式实例化 | 架构分层、库类型规范、nx.json/project.json 模板、模块边界规则、自定义生成器、CI 与缓存方案 | 低：安装技能后用自然语言提问，无需通读文档 | 新建 Nx 工作区、治理已有 monorepo、加速 CI | 优势是成套配置开箱即用、有最佳实践取舍；不足是模板需按实际技术栈改写，且依赖使用者能判断配置是否合理 |
| Nx 官方文档与示例仓库 | 权威一手资料 | 完整 API 说明、概念讲解、官方示例 | 中：信息量大，需要自己串联多个章节 | 查证具体配置项含义、跟进新版本能力 | 优势是最准确、更新及时；不足是需要读者自行完成「从概念到可运行配置」的翻译工作 |
| Nx Console（编辑器图形界面插件） | IDE 内的可视化操作面板 | 图形化运行生成器与任务、查看项目列表 | 低：安装编辑器插件即可使用 | 习惯图形化操作、频繁执行生成器的开发者 | 优势是操作直观、降低命令记忆成本；不足是偏向执行而非架构规划，边界与缓存策略仍需人工设计 |
| Turborepo 等其他 monorepo 工具 | 轻量级任务编排与缓存方案 | 任务管道编排、缓存、过滤执行 | 中：需要自行搭建项目约束与生成体系 | 中小型仓库、希望更快上手 monorepo 的团队 | 优势是配置简洁、心智负担小；不足是缺少内建的库类型规范、模块边界强制与生成器生态 |
选择建议：如果你已经在 Nx 生态内或计划使用 Nx 的能力（执行器、生成器、依赖图、模块边界），优先使用本技能快速搭出骨架；如果团队规模很小、只是想给现有仓库加速构建，轻量的任务编排工具可能更合适；而遇到「这个配置项到底什么意思」的疑问时，仍应回到官方文档核对，本技能适合作为落地脚手架而非最终依据。
5. 该技能的典型应用场景与实际体验情况
场景一：从多仓库迁移到 monorepo 的前端架构师
痛点是历史仓库各自为政，合并后「应用代码被 import 进共享库」这类反向依赖极易发生。使用方式是先让技能输出目录分层与库类型规划，再生成模块边界规则并立即接入 lint。实际体验：配置骨架的生成速度很快，一次对话就能拿到 nx.json 与 ESLint 规则的组合；需要注意的是一次性打开全量边界校验会产生大量报错，建议先设为警告、分批整改后再收紧为错误。
场景二：CI 越来越慢的中型团队
痛点是每次 PR 都全量跑测试与构建，流水线时长随仓库增长线性上升。使用方式是让技能给出 affected 流水线与缓存配置，重点落 targetDefaults 的 cache: true 与 namedInputs.production 的排除规则。实际体验：模板中的 fetch-depth: 0 和 nx-set-shas 是很多人容易漏掉的两个细节，技能的模板里已包含，能避免「affected 计算不准」的经典坑；此外 e2e 并行度设为 1 也是经验性建议，照做可减少环境冲突。
场景三：需要统一团队生成规范的工程化负责人
痛点是新人建库时命名、标签、测试配置各不相同。使用方式是让技能生成自定义生成器，把「建库」这个动作标准化。实际体验：生成器代码涉及 @nx/devkit 的 Tree、generateFiles、readProjectConfiguration 等 API，对不熟悉 Nx 插件开发的成员有一定门槛，技能给的是可直接改的完整实现，但需要理解每个参数含义后再落地。
场景四：已用 Nx 但缓存命中率低的开发者
痛点是缓存开了却经常失效。使用方式是让技能检查 namedInputs 与 targetDefaults 的写法，并用 nx reset 排除脏缓存干扰。实际体验：问题往往出在输入集合写得过宽（比如把整个 {projectRoot}/**/* 都算进 production 输入），技能推荐的排除写法能明显改善命中率。整体注意事项：所有模板中的组织名、路径、执行器版本都需替换为你项目的真实值；配置修改后应先用 nx graph 确认依赖无环，再提交。
6. 该技能能为用户带来的价值
效率层面：把原本需要翻阅多个文档章节、反复试错才能拼出的配置，压缩为一到数轮对话。仅「架构分层 + nx.json + 项目配置 + 边界规则 + CI 流水线」这五项，人工从零配置通常需要数小时到一天，而按模板改写通常在几十分钟内即可得到可运行骨架。
门槛层面：库类型划分、标签体系、依赖约束这些「靠资深工程师口口相传」的隐性知识被显式化，新成员不必先踩一遍坑才能理解为什么要这样分层。
质量层面：模块边界规则把架构约束变成可执行的 lint 校验，让架构不会因为交付压力而悄悄腐化；depConstraints 按 type 与 scope 双维度限制，比单纯靠 code review 更可靠。
成本层面：缓存与 affected 命令直接作用于 CI 时长与机器成本，构建时间随仓库规模增长而急剧上升的问题得到缓解；远程缓存进一步让团队内、流水线间的构建结果可复用。
长期价值：技能固化了「一致性使用标签、早期启用缓存、保持库专注、使用生成器、记录边界」这套实践，随着仓库演进，团队仍然能维持清晰的依赖图与可控的维护成本。
7. 常见问题 FAQ
Q1：这个技能怎么安装？安装在什么地方？
A：在支持技能机制的 AI 助手或技能市场中搜索「Nx工作区模式Skill」或 nx-workspace-patterns（技能ID 13252），点击安装/启用即可。具体的市场入口、命令与页面路径以官方说明为准。安装后建议用一句「生成一份带缓存的 nx.json」来验证是否生效。
Q2：技能收费吗？ A：技能本身的资费信息不在本技能详情范围内，请以官方技能市场页面的说明为准。需要注意的是，技能生成的配置中若涉及 Nx Cloud 等第三方服务，其费用政策同样以其官方说明为准。
Q3：它适合谁用？纯新手能用吗？ A：适合前端架构师、工程化负责人、正在做 monorepo 迁移的团队，以及已用 Nx 想补齐缓存与边界的开发者。纯新手也能用，但建议按「先骨架、后边界、再缓存」的顺序推进，并且每改一处配置都跑一次命令验证，避免一次性套用全部模板后难以定位问题。
Q4：它和直接看 Nx 官方文档有什么区别？怎么选？ A：官方文档是权威来源，讲清每个配置项「是什么」；本技能提供的是「怎么组合起来才对」的成套模式，包括目录分层、标签体系、边界规则与 CI 命令的配套关系。实践中推荐组合使用：先用技能快速搭建骨架，遇到具体配置含义与版本差异时查官方文档核对。
Q5：生成器、边界规则这些配置能直接用在生产仓库吗？
A：可以作为起点，但必须改造。模板中的 npmScope、目录路径、执行器名称、缓存桶名称、访问令牌等都是占位值，需要替换为真实信息；边界规则建议先以警告级别运行，清理完历史违规后再升级为错误级别，避免阻塞正常交付。