针对流水线参数混乱的问题，核心解决思路是“职责分离”。参数应该根据其生命周期和变更频率存放在不同的位置。
以下是为你制定的指导规则，将参数划分为四个层级：
🏗 移动端流水线参数分层治理架构
1. 仓库内置配置 (In-Repo Config)
原则： 凡是代码运行依赖的、且与特定构建过程无关的配置，必须随代码走。
-
适用内容：
-
构建脚本：
Podfile、Cartfile、package.json。 -
工程定义：
project.pbxproj、Entitlements、Info.plist。 -
版本声明：
.xcode-version（指定 Xcode 版本）、.ruby-version。 -
静态配置： 埋点 Schema 定义、多语言静态文件。
-
优点： 保证了代码在任何机器上回溯构建时，结果是一致的。
2. 应用运行时配置 (App Runtime Config)
原则： 影响 App 运行逻辑、但在编译后仍可动态调整的开关。
-
适用内容：
-
环境切换：
project_prerelease(预发开关)、网关地址。 -
调试工具：
jrdebug、debugEnable、日志等级。 -
功能降级： 某些业务 Feature 的开关。
-
管理方式： 放入 DebugMenu 或 配置中心 (Apollo/Switch)。
-
流水线职责： 流水线仅通过一个
BuildType决定是否将这些调试工具打包进去，而不决定它们的具体开关状态。
3. 原子默认参数 (Atomic Task Config)
原则： 属于流水线插件（原子）内部的逻辑，对 90% 的用户透明，仅在特殊情况下开放修改。
-
适用内容：
-
工具版本：
cocoaPodsVersion、nodeVersion。 -
性能优化： 是否开启增量编译、是否上传符号表。
-
质量扫描：
analyzePackageResource的阈值、Lint 的级别。 -
管理方式： 在流水线平台定义为“高级选项”或“隐藏参数”，提供默认值，仅限管理员或特定需求时修改。
4. 流水线输入参数 (Pipeline Manual Params)
原则： 仅保留必须由人工决策或描述本次构建意图的动态参数。
- 适用内容：
- 构建目标：
scheme、branch/tag、repos(组件版本组)。 - 构建场景：
buildType(Debug/Release/Coverage)。 - 分发渠道：
channel(AppStore/TestFlight/Enterprise)。 - 关联属性：
devErps(触发人)、planNo(如果不符合命名规范需手动填时)。
📊 参数放置决策矩阵
| 参数类型 | 放置位置 | 修改频率 | 谁来管理 | 典型例子 |
|---|---|---|---|---|
| 强依赖配置 | 仓库 (Git) | 极低 | 开发人员 | Xcode Version, Podfile |
| 原子逻辑 | 流水线原子 | 低 | 架构/运维 | Cocoapods Version, SkipLint |
| 运行业务 | DebugMenu/配置中心 | 中 | 产品/测试 | PreReleaseMode, GatewayURL |
| 构建意图 | 流水线启动页 | 高 | 开发人员 | Branch, BuildType, Repos |
💡 治理建议（避坑指南）
- 消除冗余的布尔值：
不要设置isSimulator、isArm64、isTF这种互斥参数。统一用一个destination(Simulator/Device) 和buildType(Debug/Release) 自动推导。 - 推行“配置即代码” (CaC)：
对于复杂的repos参数组，建议支持在仓库根目录放一个build.json。流水线启动时读取该文件作为默认值，而不是让用户在网页上填几十个输入框。 - 原子参数隐身化：
比如analyzePackageResource，如果它执行很快，就不应该作为一个参数出现在启动页面，而是作为流水线的内置强制步骤，只有失败时才弹出通知。 - 环境上下文自动获取：
planNo(集成单号) 应该通过git_branch_name配合正则表达式自动提取，只有正则匹配失败时，才展示输入框让用户补全。
您目前的流水线平台支持参数间的联动吗？（例如选了 Release 自动隐藏预发开关）我可以根据此功能给您具体的 UI 布局建议。