技能介绍

要解决的具体问题

在 monorepo 里，一套代码往往对应构建、测试、集成、部署等多个阶段，把这些阶段塞进同一个 config.yml 之后，很快就会出现重复的配置片段：同一套 orb 版本在多个 job 里各写一遍，不同分支或子项目的参数散落在各处，改一个默认值要翻若干处。CircleCI 官方给出的解法是 Orb——把可复用的命令、job、executor 打包成版本化的包。但 Orb 本身只解决了「片段复用」，并没有解决「流水线怎么按阶段拼起来」这件事，尤其是当流水线的形态取决于上游传入的参数时。

技能如何工作

这个技能把这件事拆成两条线索：

Orb 组合：在流水线里引入已有的 Orb，把多阶段的工作流（构建、测试、部署等）按顺序或条件装配成完整的 pipeline，而不是手工维护一段越来越长的 YAML。
v2 API 驱动：通过 CircleCI v2 的流水线 API 提交配置，流水线结构由程序生成而非纯手写，适合把流水线定义当作代码的一部分来管理。

关键步骤大致是：

用 设置工作流（setup workflow） 先完成环境与前置条件的准备，再进入各业务阶段；
通过 流水线参数（pipeline parameters） 把仓库、分支、目标环境等变量注入流水线；
依据参数动态生成对应的阶段组合，让同一套模板服务于不同的部署诉求；
生成结果直接对接 monorepo 的多阶段部署场景，子项目或子目录的部署不必各自维护一份完整配置。

适用边界与注意点

这套组合依赖 CircleCI v2 配置模型，如果仓库还在用 v1 的 circle.yml 写法，迁移之前需要先理清 job 与 executor 的对应关系。
动态生成的前提是参数在上游就被正确传入，参数缺省或命名不一致会导致流水线阶段出现意外的缺位，建议在设置工作流里先做一次校验。
Orb 的引入会带来一层间接：排查失败时需要同时看生成后的流水线和 Orb 内部定义，不要只看仓库里那份 YAML。
该技能更适合「阶段多、模板化程度高」的 monorepo 项目；阶段很少的单包仓库，直接手写配置反而更直观。