针对基于 Vue CLI 的前端项目，生成一个包含 build、test、deploy 三个阶段的 .gitlab-ci.yml 文件：build 阶段需缓存 node_modules 并依次执行 npm install 与 npm run build；test 阶段运行 npm test；deploy 阶段则通过 rsync 将 dist 目录推送至指定服务器路径。

在 VS Code 中使用 CodeGeeX 插件快速生成一个可直接提交到 GitLab 仓库的 .gitlab-ci.yml 文件。这个任务看起来简单，但手动编写 YAML 很容易遗漏 stages、cache 或 artifacts 等关键结构。更棘手的是，不同语言项目（如 Node.js、Python、Java）的 job 配置差异明显，单靠记忆难免出错。那么，如何高效、准确地完成这项工作呢？

确认插件状态与项目上下文

打开 VS Code，确保左侧活动栏能看到蓝色机器人图标。如果未显示，需要先安装最新版 CodeGeeX 插件并完成登录。

接着在项目根目录新建一个空白文件，命名为 .gitlab-ci.yml —— 此名称必须准确，且必须放在根目录下，否则 GitLab 无法自动识别，这一点务必注意。

在文件的第一行输入提示语：“为一个使用 Vue CLI 构建的前端项目生成 GitLab CI/CD 流水线脚本，包含 build、test、deploy 三个阶段；build 阶段需缓存 node_modules 并执行 npm install 与 npm run build；test 阶段运行 npm test；deploy 阶段将 dist 目录内容同步至 /var/www/myapp。”

触发生成并验证基础结构

选中整段提示文字，右键选择“CodeGeeX → Generate Code”。几秒后，生成的内容就会插入到光标处。

检查生成的内容是否包含 stages: 这一顶层定义，且三个 stage 的名称必须与提示完全一致——大小写和连字符都不能出错。这是基础中的基础。

特别留意 build_job: 下是否有 cache: 区块，且 paths: 的值为 - node_modules/。若缺失此配置，后续构建会重复下载依赖，流水线效率将大幅降低。

适配实际环境参数

方法一：直接修改生成脚本中的镜像与路径

将 image: node:18 更新为 image: node:20.15.0 —— 这是当前 GitLab 共享 runner 最稳定的 LTS 版本。使用更高版本可能导致 npm ci 失败，得不偿失。

把 cp -r dist/* /var/www/myapp 替换为 rsync -a v --delete dist/ user@server:/var/www/myapp/。同时确保在该行上方添加 before_script: 区块，用于 SSH 密钥注入。缺少这一步，rsync 将无法执行。

方法二：通过二次提示精准修正

在刚生成的 YAML 文件末尾另起一行，输入：“把 deploy 阶段改为通过 rsync 推送至 192.168.10.5 的 /var/www/app 目录，使用 deploy_user 用户和 ~/.ssh/id_rsa_deploy 私钥，跳过 host key 检查。”

选中这行提示，按 Ctrl+Enter 触发补全。CodeGeeX 会自动在 deploy job 中插入 before_script 和 script 块，省去手动拼接 SSH 参数的繁琐操作。

本地语法校验与提交前检查

第一步：安装 GitLab CI Linter 扩展（例如“GitLab CI Linter”），启用后右下角会出现“CI Lint”按钮。

第二步：点击该按钮，粘贴当前的 .gitlab-ci.yml 内容，再点击“Validate”。如果返回“Valid configuration”，说明语法本身没有硬伤。但需注意，此校验不检查镜像是否存在或路径权限。所以务必人工确认 deploy_user 对目标目录拥有写入权限，否则 job 会卡在 rsync 步骤，白白浪费一次流水线机会。

第三步：保存文件，在终端执行 git add .gitlab-ci.yml && git commit -m "ci: add GitLab pipeline"，然后推送到远程仓库主分支。至此，整个流程才算真正完成。