收益：
- 能够理解 CI/CD 概念、管道剖析（触发器、作业、步骤、运行程序、工件）以及 GitHub Actions 和 GitLab CI 之间的差异，并让人工智能生成具有正确上下文的管道
- 能够检查和保护人工智能生成的管道中的秘密引用、权限和被调用组件的存在
- 能够应用不以纯文本编写机密、授予最低授权以及通过将部署与 CI 分离来控制部署的原则
现代软件的核心是自动化管道，代码通过该管道离开开发人员的计算机，直到安全到达客户。该管道称为 CI/CD。 CI（持续集成）是每次代码变更的自动编译和测试；其目的是在开发人员离开键盘之前捕获错误。 CD（持续交付/部署）是自动准备甚至发布经过测试的代码。 CI/CD 管道是一个按顺序定义这些步骤的配置文件 - 通常以 YAML（一种人类可读的配置文本格式）编写。
手动编写这些 YAML 文件是乏味、冗长且容易出错的；如果压痕滑移一格，整个管道就会断裂。这就是人工智能发挥作用的地方：在正确的背景下，它可以在几秒钟内生成工作草案。但你的工作是理解和验证每个生成的步骤的作用 - 因为这是将你的代码传送到产品的管道。
CI/CD 管道剖析
每个管道都包含几个基本概念。如果不了解这些，你就无法控制 AI 输出：
- 触发器：什么启动管道？通常是推送到分支、拉取请求（合并请求）或计划。
- Job：执行一系列步骤的逻辑单元；例如“测试”、“构建”、“部署”。
- 步骤：作业中的单个命令或操作。
- 运行器：运行作业的虚拟机或容器。
- 工件：一项作业产生并供后续作业使用的输出（例如，编译后的文件）。
- Secret：Pipeline 使用的机密信息，但不应以纯文本形式保留在存储库中。
GitHub Actions 将此定义保留在 .github/workflows/*.yml 文件中；单位是工作流→作业→步骤层次结构。另一方面，GitLab CI 在 .gitlab-ci.yml 文件中使用阶段→作业结构。 AI 知道这两种语法，但你必须明确说出你想要哪一种。
提示：当向 AI 请求管道时，请务必指定：平台（GitHub Actions 或 GitLab CI）、语言/框架（Node、.NET、Python…）、触发器以及是否部署。这四条信息使输出的有用性加倍。
一步一步：使用 AI 设计管道
- 明确目标。就像“在推送到主库时运行测试，构建映像，但仅在抛出标签时进行部署”。
- 制作骨架。向AI询问基本工作流程。
- 阅读并理解步骤。验证每个运行和使用行的作用。
- 检查秘密参考文献。秘密是用 ${{ Secrets.NAME }} 调用的还是嵌入在代码中？
- 在本地/CI 尝试一下。在小型测试存储库上运行它，查看红-绿（失败-通过）行为。
- 逐渐扩大。首先添加 CI（测试），然后构建，最后添加部署。
安全性：管道中的秘密和许可
CI/CD 是秘密泄露最多的地方之一。三大黄金法则：
- 切勿在 YAML 中以纯文本形式编写机密。使用平台的秘密存储库（GitHub Secrets、GitLab CI/CD Variables）并使用 ${{ Secrets.X }} 调用它。
- 最小特权。您给予 Pipeline 的令牌仅具有必要的权限。使用权限缩小范围：GitHub Actions 中的块。
- 不要在日志上按秘密。像 echo $TOKEN 这样的行揭示了日志中的秘密。平台掩盖了，但也要小心。
注意：为了方便起见，AI 有时会在示例管道中放置嵌入值，例如密码：123456 或过于广泛的权限：全部写入。始终解决这个问题：将秘密更改为引用，折叠权限。
对比图
概念
GitHub 操作
亚搏体育appGitLab持续集成
配置文件
.github/工作流程/*.yml
.gitlab-ci.yml
建筑单位
工作流程→作业→步骤
阶段→工作
触发器
十：
规则：/仅：
召唤秘密
${{ 秘密.NAME }}
$NAME（CI/CD 变量）
准备好组件
使用：action@v4
包括：/模板
跑步者
运行：
标签：
三个迷你箱子
案例 1 — 缩短至 6 小时 40 分钟。一个团队希望自动化其手动测试-构建-部署流程，但没有人熟悉 YAML。他们将 YZ 描述为“Node.js 项目、GitHub Actions、npm 测试和 npm 构建推送到主目录，仅在 v* 标记中部署”。 AI制作了40行的工作骨架；团队验证了每一步并在 40 分钟内上线。如果他们用手写的话，那就需要一天的工作。
案例 2 — 身份验证发现安全漏洞。一位工程师要求AI部署工作流程。输出包括权限：write-all——这意味着令牌可以写入存储库、包以及所有内容。工程师注意到了这一点，并通过权限缩小了范围：{contents:read,packages:write}。这消除了被劫持的依赖项替换整个存储库的风险。
案例 3 — 幻觉行为。一个团队运行了 AI 建议的用途：actions/deploy-to-aws@v3 行；没有这样的官方动作，AI 起的名字。管道因“未找到操作”而爆炸。课程：在 Marketplace 中验证使用 use: 调用的每个组件是否确实存在。
四个可复制模板
1）CI基本工作流程：
为 GitHub Actions 编写 CI 工作流程。项目：[语言/框架]。触发器：向主分支推送和拉取请求。步骤：安装依赖项、运行测试、运行 lint。没有 Deploy.Runner ubuntu-latest。不需要秘密。注释 YAML。
2) 部署的 CD 工作流程（安全）：
编写[平台]的部署工作流程。它应该只适用于“v*”标签。目标：[媒体/云]。规则： - 切勿以纯文本形式编写秘密，请使用 ${{ 秘密来调用它们。
3）描述现有的管道：
逐行描述以下[平台]管道：每个作业的作用是什么，以什么顺序运行，它使用什么秘密，以及它的两个最危险的点是什么？最后，提出 3 项改进建议。Pipeline：[YAML CONTENT]
4）加速管道：
以下 CI 管道运行缓慢（持续时间：[X 分钟]）。检查缓存使用情况、并行作业和不必要的步骤。给出 5 条具体的、可操作的加速建议，并写下每条建议的估计影响。管道：[YAML]
弱提示/强提示
弱项：“编写 GitHub Actions 工作流程。”
结果：不清楚是哪种语言、哪种触发、是否有部署； AI 提供了一个通用的 Node 实例，可能不适合您的项目，并且可以对秘密进行硬编码。
强：“编写 GitHub Actions 工作流程。Python 3.12 项目，在拉取请求和主推送中运行 pytest + ruff；无需部署；使用 pip 缓存加速依赖项；不需要任何机密。使用注释导出 YAML。”
区别：第二个提示给出了语言、触发器、范围（无部署）、性能期望和安全约束。输出直接起作用。
常见错误
- 将秘密嵌入到 YAML 中。明文密码/令牌是最常见的 CI 漏洞。
- 过于宽泛的许可。授予所需的最低权限而不是全部写入。
- 依赖于不存在的操作/模板。验证人工智能的用途：市场中的产品线。
- 将 Deploy 与 CI 混淆。测试可以在每次推送时运行，但部署必须受到控制和批准。
- 不使用缓存。每次运行时从头开始安装依赖项会使管道减慢几分钟。
- 直接在主存储库中尝试第一个工作流程。首先在测试存储库上运行它。
综上所述
CI/CD 管道是自动化管道，可将代码安全地移动到产品并使用 YAML 定义。 AI 可以快速生成 GitHub Actions 和 GitLab CI 的工作蓝图 - 但您需要清楚平台、语言、触发器和部署范围。安全性有三个规则：通过引用调用机密、授予最低权限、不在日志中打印机密。您有责任验证每个 use:/include: 组件是否确实存在以及每个步骤的作用。
应用任务
选择一个简单的示例项目（甚至用您的语言编写“hello world”也可以）。让 AI 使用上面的“基本 CI 工作流程”模板生成工作流程。然后：（1）用自己的话写出每一步的作用； (2) 验证没有嵌入任何秘密且权限较窄； (3) 如果可能，在测试槽中运行并观察红绿行为。
清单
- [ ] 我将平台、语言/框架、触发器和部署范围添加到我的提示中。
- [ ] 我了解生成的 YAML 中每个作业和步骤的作用。
- [ ] 没有秘密就是明文；所有 ${{ Secrets.X }} / CI 变量。
- [ ] 我将权限缩小到最小权限。
- [ ] 我验证了所有调用的操作/模板确实存在。
- [ ] 我通过批准/保护控制了部署步骤。