我们如何使用 AI 让 CI 更严格、更可观测，并且更容易跨仓库改进。

在实施与交付两个领域都工作过之后，我意识到在当前的 AI 时代，复杂需求并不一定是最大的问题。

AI 可以帮助我们拆解需求、探索陌生的仓库，并生成实现思路。这让实施步骤变得容易得多。

但实施只是交付的一部分。功能仍需通过真实的工程系统。

它必须适配仓库、CI 规则、评审流程以及交付它的部署路径。

随着实现速度加快，周围的工程系统变得更加重要。真正的挑战在于确保每一次变更都经过测试、按需求评审，并安全合并。

超越被取代的恐惧

人们对 AI 取代开发者的担忧很多。

其中部分担忧是合理的。当日常实现任务可以通过 AI 辅助生成、测试和评审时，入门级机会可能会减少。

这是一项重要挑战，尤其是对那些刚进入软件开发领域的人而言。

但我并不认为这是开发者角色的终结。

我认为这是软件领域最令人兴奋的时期之一。

价值正在发生转移。

编写日常代码的差异化程度正在下降。理解问题、提出正确的问题、验证行为、做出权衡、并对结果负责变得更加重要。

AI 可以生成实现，但它不会自动理解业务背景、隐藏约束、运营风险，以及解决方案是否适合团队。

这就是为什么工作流质量至关重要。

受益最多的开发者未必是让 AI 生成最多代码的人，而是那些能在严谨流程中使用 AI 的人：定义需求、检查证据、测试结果、评估风险，并围绕它改进系统。

对初级开发者而言，路径可能改变，但不会消失。基础知识、调试、沟通、产品理解，以及与 AI 高效协作的能力将变得更加重要。

这种视角转变改变了我们对 CI 的处理方式。我们没有首先问如何让它运行更快，而是问如何让它捕捉更多正确的问题。

真正的工作是强化 CI 工作流

最近，我们在一个 GitLab CI 工作流中承担了多项职责：

  • 当合并请求创建时，将关联的 issue 移至 Status::In Review。
  • 合并后将 issue 移至 Status::Done。
  • 对整个合并请求运行 AI 评审。
  • 当 AI 评审确认存在严重或高危问题时，阻塞流水线。
  • 当合并请求不包含关闭引用时，留下评论。

关键不在于简单地添加更多 CI 作业。

我们使用 AI 检查工作流本身，并提出更好的问题：

  • Status::In Review 是否证明合并请求确实关联了工单？
  • Status::Done 是否仅在真正合并到默认分支后执行？
  • AI 发现是否能在没有具体证据的情况下阻塞合并？
  • 当合并请求缺少关闭引用时会发生什么？
  • 哪些检查属于通用策略，哪些属于特定仓库？

这些问题将 CI 从一组命令转变为质量控制系统。

目标不是让 CI 更复杂，而是让每个决策更明确：自动检查什么、需要什么证据、什么应该阻塞合并。

AI 在流水线中的实际应用

AI 评审不是开发者需要手动运行的独立工具。它是一个在合并请求目标为默认分支时运行的 GitLab CI 作业。

该设置包含四个简单部分：

  1. 在 CI 作业中安装固定版本的 AI CLI。
  2. 一个小型仓库脚本收集合并请求上下文。
  3. AI 返回结构化的 JSON 报告。
  4. 一个独立作业评估该报告并决定流水线是否通过。

该作业使用固定版本的 AI CLI，而非安装最新版本：

ai_review:
  image: node:22-bookworm-slim
  before_script:
    - npm install --global @openai/codex@<pinned-version>
  script:
    - python scripts/ai_review.py review

Enter fullscreen mode Exit fullscreen mode

在此案例中，AI 通过 OpenAI Codex CLI 访问。具体的 CLI 可能不同，但重要的是版本明确，且作业在隔离的 CI 环境中运行。

仓库脚本不会盲目地将整个仓库发送给模型。它仅收集评审所需上下文：

  • 合并请求描述；
  • 关联的关闭 issue 及其需求；
  • 变更的文件和 diff；
  • 变更周围的相关文件内容；
  • 当前提交 SHA 和目标分支。

提示词还定义了 AI 允许得出的结论。例如，需求被标记为 Covered、Partial、Missing 或 Not verifiable。发现必须包含其类别、严重性、受影响路径、证据、影响和建议。

响应在被使用前会根据 JSON schema 进行验证。报告随后保存为 CI 产物并作为合并请求评论发布。这使推理过程可见，并为下一个作业提供稳定输入。

凭证按职责分离：

  • AI 访问令牌允许评审作业调用 AI 工具；
  • GitLab 自动化令牌允许工作流读取合并请求数据并更新评论或标签。

两者均作为掩码的组级 CI 变量管理。评审作业使用 AI 令牌。门控作业无需调用 AI，因此它使用报告产物，并从其环境中移除 AI 令牌。

这种分离有两个好处。它限制了敏感凭证暴露的位置，并防止最终门控执行可能与已评审报告不同的新 AI 请求。

实际流程如下：

Merge request
    -> collect GitLab context
    -> AI review with structured output
    -> report.json artifact and comment
    -> deterministic gate
    -> pass or block the pipeline

Enter fullscreen mode Exit fullscreen mode

因此，AI 用于分析和解释。GitLab CI 负责验证输出、检查提交、更新合并请求并执行最终策略。

打包改进的工作流，而非仓库

共享组件是一个有用的成果，但不是主要改进。主要改进是让 CI 策略明确且可执行。一旦明确，我们就可以打包可复用部分。

改进工作流后，下一个问题很简单：

我们真的需要在每个仓库中手动设置相同的工作流吗？

答案仍然是否定的。

我们没有将改进后的 .gitlab-ci.yml 逻辑复制到每个仓库，而是创建了一个共享的 GitLab CI 组件。

消费仓库只需包含共享模板：

include:
  - project: your-group/ci-components
    ref: v0.1.0
    file: /templates/issue-ai-review.yml

Enter fullscreen mode Exit fullscreen mode

共享组件提供：

  • issue_status_in_review
  • issue_status_done
  • ai_review
  • ai_review_gate

仓库仍保留自己的构建、lint、单元测试、E2E 和部署作业。

这种分离很重要。

Go 仓库不应被迫使用 Python 仓库结构。前端仓库不应继承后端测试命令。

但两个仓库可能仍需要相同的合并请求策略。

可复用部分是质量策略，而非流水线中的每一条命令。

AI 评审需要确定性边界

AI 评审很有用，但 AI 响应不应直接决定合并请求是否可以合并。

AI 评审者生成结构化报告。它评估工单覆盖度、正确性、回归风险、安全性、性能、可维护性等类别。

Critical 和 High 发现随后会独立验证。

最终门控检查确定性条件：

  • 报告是否针对当前提交？
  • 发现是否已独立确认？
  • 严重性是否仍阻塞？
  • 报告生成后是否添加了人工覆盖？

这为我们提供了更好的边界。

AI 适用于对大型合并请求进行推理。

流水线负责执行策略。

这种区分很重要，因为 AI 输出具有概率性，而合并门控应具有可预测性。

使工作流可安全复用

工作流质量不仅来自 AI 步骤。我们还需要使自动化可预测且可安全复用。

缺失的关闭引用变得可见

如果合并请求不包含如 Closes #123 的引用，流水线会自动留下评论说明缺失内容。

该作业也会失败，因此问题在合并前可见。描述更新后，可以重试流水线。

固定共享组件版本

每个仓库使用特定组件版本（如 v0.1.0），而非静默跟随最新变更。

这意味着共享 CI 的更新不会意外改变每个仓库。仓库可在变更经过评审后更新版本。

使用专用机器人进行自动化

工作流需要凭证来更新 issue 标签和评论。这些凭证存储在组级别，属于专用 CI 机器人，而非开发者个人账号。

这将所有权保留给团队，并使人员或职责变更时自动化更容易维护。

保留仓库特定检查

共享组件处理通用合并请求策略。每个仓库仍定义自己的构建、lint、单元测试、E2E 和部署作业。

标签也可以按仓库配置。Go 项目和 TypeScript 项目无需仅因共享相同评审策略而使用相同命令。

结果是共同的质量标准，而非假装每个仓库具有相同结构。

工程领导力发生了什么变化？

AI 改变了瓶颈。

以前，大部分工作是将需求转化为代码，并手动检查 CI 工作流是否捕获了预期策略。

现在，AI 可以减少大部分实现摩擦。

工程领导力角色更侧重于：

  • 定义可复用边界；
  • 决定哪些检查必须保持确定性；
  • 将重复策略转化为自动化；
  • 使 AI 输出可验证；
  • 保留仓库间的灵活性；以及
  • 确保速度不会移除流程中的证据。

工作仍然复杂。

但复杂性可以组织成更小、可复用的系统。

最终要点

复杂需求仍需仔细思考。

AI 不会消除对架构、测试或评审的需求。

但它改变了可行性。

依赖人工检查的评审流程可以转变为自动化的、基于证据的门控。

一旦质量策略明确，重复的 CI 逻辑可以成为版本化的共享组件。

最大的改进不只是更快地编写代码。

而是创建一个让复杂工作更容易协调、验证和复用的系统。

这就是 AI 为工程团队创造最大杠杆的地方。