AI 时代的核心问题：工作流质量重于需求复杂度

我们如何借助 AI，让跨仓库的 CI 更严格、更透明，也更容易持续改进。

在同时参与过实现与交付之后，我逐渐认识到：在当前的 AI 时代，复杂需求未必还是最大的问题。

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

但实现只是交付的一部分。功能最终仍然要经过一套真实的工程系统。

它必须适配负责交付的代码仓库、CI 规则、评审流程和部署路径。

随着实现速度越来越快，周边工程系统的重要性也随之提升。真正的挑战，是确保每一次变更都经过测试、依据需求完成评审，并且能够安全合并。

不必再只担心被取代

关于 AI 会取代开发者，很多人都感到担忧。

其中一些担忧是合理的。当常规实现任务可以在 AI 的辅助下生成、测试和评审时，初级岗位的机会可能会变少。

这是一项重要挑战，尤其是对那些正在争取第一份软件开发工作的人来说。

但我并不认为这意味着开发者这一角色将走向终结。

相反，我认为这是从事软件开发最令人兴奋的时期之一。

价值正在发生转移。

编写常规代码越来越难以形成差异化。理解问题、提出正确的问题、验证行为、权衡取舍，以及对结果负责，正在变得更加重要。

AI 可以生成一套实现，但它不会自动理解业务背景、隐藏的约束、运维风险，也不知道这套方案是否适合当前团队。

这正是工作流质量如此重要的原因。

从 AI 中获益最多的开发者，不一定是那些让 AI 生成最多代码的人，而是能够把 AI 纳入严谨流程的人：定义需求、检查证据、测试结果、评估风险，并改进围绕它运行的整个系统。

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

这种视角上的转变，改变了我们改进 CI 的方式。我们一开始并没有问如何让 CI 跑得更快，而是问：如何让它捕获更多真正重要的问题？

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

最近，我们改进了一套承担多项职责的 GitLab CI 工作流：

• 创建 merge request 时，将关联 issue 移至 Status::In Review。

• 合并后，将 issue 移至 Status::Done。

• 对整个 merge request 执行 AI review。

• 当 AI review 确认存在严重或高危问题时，阻止 pipeline 继续执行。

• 当 merge request 中不包含关闭引用时，留下评论。

真正重要的并不是简单地增加更多 CI job。

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

• Status::In Review 能否证明 merge request 确实关联了某个 ticket？

• Status::Done 是否只会在真正合并到默认分支后运行？

• AI 发现的问题，能否在缺少具体证据的情况下阻止合并？

• merge request 缺少关闭引用时，会发生什么？

• 哪些检查属于通用策略，哪些检查只适用于某个仓库？

这些问题让 CI 从一组命令的集合，转变成了一套质量控制系统。

我们的目标不是让 CI 变得更加复杂，而是让每一个决策都更加明确：哪些内容需要自动检查、必须提供哪些证据，以及什么情况应该阻止合并。

AI 在 Pipeline 中究竟如何使用

AI review 并不是一个需要开发者手动运行的独立工具，而是一个 GitLab CI job。当 merge request 的目标是默认分支时，它就会运行。

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

• 在 CI job 中安装锁定版本的 AI CLI。

• 由仓库中的一个小型脚本收集 merge request 上下文。

• AI 返回结构化的 JSON 报告。

• 另一个独立 job 评估报告，并决定 pipeline 是否通过。

这个 job 使用锁定版本的 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

在这个案例中，AI 通过 OpenAI Codex CLI 接入。具体使用哪一种 CLI 可以有所不同，但关键在于版本必须明确，而且 job 要在隔离的 CI 环境中运行。

仓库脚本不会不加区分地把整个仓库发送给模型，而是只收集评审所需的上下文：

• merge request 的描述；

• 关联的待关闭 issue 及其需求；

• 发生变更的文件和 diff；

• 变更位置附近的相关文件内容；

• 当前 commit SHA 和目标分支。

prompt 还会定义 AI 可以得出哪些结论。例如，一项需求会被标记为 Covered、Partial、Missing 或 Not verifiable。每一项发现都必须包含类别、严重程度、受影响的路径、证据、影响和建议。

响应在使用前会根据 JSON schema 进行验证。随后，报告会保存为 CI artifact，并作为评论发布到 merge request 中。这样既能让推理过程清晰可见，也能为下一个 job 提供稳定的输入。

凭据按照职责进行拆分：

• AI access token 允许 review job 调用 AI 工具；

• GitLab automation token 允许工作流读取 merge request 数据，并更新评论或 label。

两者都作为 masked group-level CI variables 进行管理。review job 使用 AI token。gate job 不需要调用 AI，因此它只读取报告 artifact，并从自身环境中移除 AI token。

这种拆分有两个好处。第一，它限制了敏感凭据的暴露范围；第二，它可以防止最终 gate 再次发起 AI 请求，避免新请求的结果与已经评审过的报告不一致。

在实际运行中，整个流程如下：

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

因此，AI 用于分析和解释。GitLab CI 仍然负责验证输出、检查 commit、更新 merge request，并执行最终策略。

封装改进后的工作流，而不是封装仓库

共享组件是一项有价值的成果，但它并不是最主要的改进。真正的改进，是让 CI 策略变得明确且可以强制执行。在此基础上，我们才得以封装其中可复用的部分。

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

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

答案仍然是否定的。

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

使用方仓库只需要引入共享模板：

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

共享组件提供：

• issue_status_in_review

仓库仍然负责维护自己的 build、lint、unit test、E2E 和 deployment job。

这种职责分离非常重要。

不能强迫 Go 仓库采用 Python 仓库的结构。前端仓库也不应该继承后端的测试命令。

但这两类仓库仍然可能需要遵循相同的 merge request 策略。

真正可以复用的是质量策略，而不是 pipeline 中的每一条命令。

AI Review 需要确定性的边界

AI review 很有用，但不应该让 AI 的响应直接决定一个 merge request 能否合并。

AI reviewer 会生成结构化报告，对 ticket 覆盖度、正确性、回归风险、安全性、性能、可维护性以及其他类别进行评估。

随后，Critical 和 High 级别的发现会接受独立验证。

最终 gate 会检查确定性条件：

• 报告是否针对当前 commit？

• 这项发现是否经过独立确认？

• 它的严重程度是否仍然达到阻塞级别？

• 报告生成后，是否添加了人工 override？

这样一来，我们就建立了更合理的边界。

AI 适合对大型 merge request 进行推理。

pipeline 则负责执行策略。

这种区别非常重要，因为 AI 的输出具有概率性，而 merge gate 应该是可预测的。

让工作流能够安全复用

工作流的质量并不只来自 AI 环节。我们还需要确保自动化过程可预测，并且能够安全复用。

让缺失的关闭引用清晰可见

如果 merge request 不包含 Closes #123 这样的引用，pipeline 会自动留下评论，说明缺少什么内容。

这个 job 也会失败，让问题在合并前暴露出来。更新描述后，可以重新运行 pipeline。

锁定共享组件的版本

每个仓库都使用明确的组件版本，例如 v0.1.0，而不是悄悄跟随最新变更。

这意味着共享 CI 的更新不会意外改变所有仓库。仓库可以在评审过相关变更之后，再更新组件版本。

使用专用 Bot 执行自动化

工作流需要凭据来更新 issue label 和评论。这些凭据存储在 group 层级，并归属于专用的 CI bot，而不是某位开发者的个人账号。

这样可以让所有权留在团队内部，也能在人员或职责发生变化时，让自动化流程更容易维护。

将仓库特有的检查保留在本地

共享组件负责通用的 merge request 策略。每个仓库仍然定义自己的 build、lint、unit test、E2E 和 deployment job。

label 也可以针对每个仓库单独配置。Go 项目和 TypeScript 项目不会仅仅因为共享了同一套评审策略，就必须使用相同的命令。

最终，我们获得了一套统一的质量标准，同时也没有假装所有仓库都拥有相同的结构。

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

AI 改变了瓶颈所在。

过去，大量工作都用于把需求转化为代码，并手动检查 CI 工作流是否准确体现了预期策略。

现在，AI 可以显著减少实现过程中的这类摩擦。

工程领导者的职责会更加聚焦于：

• 定义可复用的边界；

• 决定哪些检查必须保持确定性；

• 将重复出现的策略转化为自动化；

• 让 AI 输出可以验证；

• 保留不同仓库之间的灵活性；以及

• 确保速度的提升不会让流程失去证据。

这项工作依然复杂。

但我们可以把这些复杂性组织成规模更小、可复用的系统。

复杂需求仍然需要谨慎思考。

AI 并没有消除对架构、测试或评审的需求。

但它改变了哪些事情在实践中是可行的。

原本依赖人工检查的评审流程，可以转变成一道自动化、以证据为基础的 gate。

一旦质量策略足够明确，那些重复的 CI 逻辑就可以转化为有版本管理的共享组件。

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

而是建立一套系统，让复杂工作更容易协调、验证和复用。

这才是 AI 能够为工程团队创造最大杠杆效应的地方。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。