按平台风格改写Gemini脚本部署说明提示词

AI自动生成的部署脚本看起来非常方便，但如果直接扔进CI/CD流水线，常常会出问题——不同平台的语法规范各有不同，YAML解析器无法识别模糊指令，环境变量声明方式也千差万别，权限配置少写一个字段就可能无声无息地失败。下面详细拆解四个主流平台的适配关键点，避免直接把通用提示词原样粘贴就草率了事。

适配 GitHub Actions 工作流

第一步，将提示词中“执行部署命令”这类模糊描述，替换为 run 关键字包裹的 shell 代码片段。注意，命令字符串必须用双引号包围，否则换行符或管道符会导致 YAML 解析器直接报错。

第二步，环境变量不应再用自然语言描述如“用 PROD_API_KEY 连接生产环境”，而应放入 env: 代码块中写成键值对。关键提示：PROD_API_KEY 必须提前存储为 GitHub Secrets，绝对不能在 workflow 文件中以明文形式出现。

第三步，在 job 级别添加 permissions: 配置，例如 id-token: write。如果涉及 OIDC 认证的部署（比如推送 AWS ECR），缺少该字段会导致静默失败，排查起来相当麻烦。

适配 GitLab CI 流水线

方法一，将“运行以下步骤”这类描述替换为 script: 关键字。每条命令单独占一行，末尾不要加分号；多行命令必须保持缩进对齐，否则会被视为多个独立的 script 条目。

方法二，将“检查依赖是否安装”等模糊指令改为具体的可执行命令，例如 which curl || apt-get update && apt-get install -y curl。GitLab Runner 的默认镜像非常精简，甚至可能没有预装常见工具。

变量引用必须统一使用全大写格式，例如 $CI_REGISTRY_PASSWORD。写成 ${registry_password} 在 GitLab CI 中无效，踩过这个坑的人不在少数。

适配 AWS CodeBuild 构建流程

将提示词中的“先打包再上传”拆解为 buildspec.yml 的 phases 显式结构：打包逻辑放入 build:→commands:，上传操作放入 post_build:→commands:。CodeBuild 不识别未声明 phase 的命令块，直接写在外部会被忽略。

环境变量必须通过 environment:→variables: 定义，如果值包含空格或特殊字符，请使用单引号包裹。不要在 commands 中使用 export 定义变量，因为这些变量不会在 phase 之间继承——这个问题容易被忽视，但会导致后续阶段无法获取变量值。

适配 Jenkins Pipeline（Groovy 脚本）

① 将“登录镜像仓库”转化为 sh 'docker login -u $REGISTRY_USER -p $REGISTRY_TOKEN $REGISTRY_URL'。Jenkins 不支持原生变量插值，必须使用单引号配合美元符进行拼接。

② 所有 shell 命令必须放在 sh 步骤中，不能直接书写裸命令，否则 Jenkins 会报错 “Expected a step”。

③ 超过三行的部署逻辑，建议封装为 def deployToProd() { ... } 函数。这一步并非强制要求，但如果不封装，后续脚本膨胀后维护成本会急剧增加。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：按平台风格改写Gemini脚本部署说明提示词要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题