---
title: "从 AI 写代码到 AI 审代码：开发者外循环加速完整实战"
author: deletexiumu
pubDatetime: 2026-03-25T00:00:00+08:00
featured: false
draft: false
tags:
  - AI 编程
  - 效率
  - 教程
description: "AI 让写代码快了 50%，但 MR 在审查队列躺了三天。本文拆解外循环三大瓶颈——代码审查、CI/CD、组织流程，给出 GitLab AI 审查、CI 优化、流程债务清理的完整实操方案。"
---


## 一个真实的荒诞场景

用 Claude Code 花了 30 分钟写完一个功能模块——以前这至少要半天。提交 MR，心想今天效率真高。

然后这个 MR 在审查队列里躺了 3 天。

Reviewer 终于开始看，面对 AI 生成的 500 行 diff，花了 2 小时逐行审查，提了 8 条意见。修改、再审、又等了 1 天。最终合并时，日历上已经过去 5 天。

这不是个案。Faros AI 2025 年对超过 10,000 名开发者的遥测分析发现：AI 辅助开发后，团队合并的 MR 数量增长 98%，MR 体积增长 154%，审查时间增长 91%——但组织级交付指标持平。

哪怕 AI 让你写代码快了一倍，你的团队交付快了多少？

## 30 秒理解内循环 vs 外循环

DORA 创建者 Nicole Forsgren 在 2026 年 2 月的 Pragmatic Summit 演讲中大意是：**我们在加速本来就快的部分，慢的部分一点没动。**

这句话戳破了很多团队的幻觉。拆开来看：

- **内循环（Inner Loop）**：写代码、调试、本地测试——AI 已经大幅加速
- **外循环（Outer Loop）**：代码审查、CI/CD、安全扫描、流程审批——基本没变

整体交付时间由最慢的环节决定。内循环快了 3 倍，外循环不动，交付速度还是卡在那里。

![内循环 vs 外循环：AI 加速了写代码，但审查、CI、审批基本没变](/blog/ai-outer-loop-acceleration/01-inner-outer-loop.jpg)

一个需要正视的前提：如果团队里有人害怕暴露自己使用 AI 的方式——怕被质疑"是不是全靠 AI 写的"——那所有流程优化数据都会失真。心理安全是一切效率改善的前提。

下面按"先量基线、再打瓶颈"的逻辑，逐个拆解外循环的三个堵点：代码审查、CI/CD、组织流程。

## 实操一：让 AI 审 AI 的代码

![AI 代码审查工作流：拆分代码 → 自审 → AI 自动审查 MR → 人工审查](/blog/ai-outer-loop-acceleration/02-ai-review-workflow.jpg)

代码审查是外循环中最大的瓶颈。一个开发者从每周 1-2 个 MR 变成每天多个 MR，reviewer 的时间没有同比增长——队列就是这么堵起来的。

量化来看：CodeRabbit 2025 年 12 月的一份研究（470 个真实开源 MR 样本，厂商数据仅供参考）发现，AI 协作生成的代码每 MR 问题数约为纯人工的 1.7 倍，逻辑和正确性问题高出 75%。简单说：代码产出越多、质量风险越高，审查压力成倍放大。

### 先把 MR 变小

AI 容易一次生成大 diff，而大 MR 恰恰是审查地狱的根源。业界普遍认可的经验是：MR 越大，审查质量越低、等待时间越长。

几个立刻能做的事：

- **设 diff 预算**：团队约定单个 MR 不超过 400 行变更。超了就拆
- **MR 模板强制写 intent summary**：reviewer 不猜你改了什么，而是先知道你为什么改
- **超阈值自动标红**：后面 Risk Lanes 一节会给出自动打标签的配置
- **进阶**：把一个大功能拆成串联的小 MR（业界称为 Stacked MRs），每个 MR 只做一件事，审查者不需要在脑子里同时装下整个功能。Graphite、git-town 等工具可以辅助管理这种依赖链，详见各工具官方文档

> **管理者行动**：在团队规范中写入 MR 大小上限，而不只是"建议"。没有约束力的建议不会改变行为。

### 方案 A：AI-Codereview-Gitlab（Webhook + 独立服务，推荐）

国内 GitLab 环境下最流行的开源方案（GitHub 1.5k+ stars）。原理：GitLab Webhook 推送事件 → 独立服务接收 → 调用大模型审查 → 结果写回 MR/Commit Note。

核心特点：
- 支持 DeepSeek、OpenAI、ZhipuAI（智谱）、Ollama（本地部署）
- Docker 一键部署，5 分钟搞定
- 自带 Dashboard 可视化审查记录
- 支持钉钉/企业微信/飞书消息推送

**最小可用配置**：

```bash
# 1. 克隆部署
git clone https://github.com/sunmh207/AI-Codereview-Gitlab.git
cd AI-Codereview-Gitlab
cp conf/.env.dist conf/.env
```

编辑 `conf/.env` 关键配置：

```bash
LLM_PROVIDER=deepseek
DEEPSEEK_API_KEY={YOUR_KEY}
DEEPSEEK_API_MODEL=deepseek-chat
SUPPORTED_EXTENSIONS=.java,.py,.go,.ts,.js
GITLAB_ACCESS_TOKEN={YOUR_GITLAB_TOKEN}

# 钉钉/飞书/企业微信推送（按需开启）
DINGTALK_ENABLED=1
DINGTALK_WEBHOOK_URL=https://oapi.dingtalk.com/robot/send?access_token=xxx
```

```bash
# 2. 启动
docker-compose up -d
# API: http://your-server:5001
# Dashboard: http://your-server:5002
```

GitLab Webhook 配置：
1. 项目 → Settings → Webhooks
2. URL: `http://your-server:5001/review/webhook`
3. Trigger: 勾选 Push Events 和 Merge Request Events
4. Secret Token: 你的 GitLab Access Token

**成本说明**：仅大模型 API 费用。费用取决于 MR 数量和模型选择。以 DeepSeek 为例，每次审查约消耗 2000-5000 token，5 人团队每天 10 个 MR 的场景下，月费用通常在几十到百元级别。

### 方案 B：ai-review（GitLab CI 内嵌，轻量）

不想部署独立服务，可以直接在 `.gitlab-ci.yml` 中集成审查 Job：

```yaml
ai-review:
  stage: review
  image: nikitafilonov/ai-review:latest
  rules:
    - if: '$CI_MERGE_REQUEST_IID'
  script:
    - ai-review run
  variables:
    LLM__PROVIDER: "OPENAI"  # 也支持 Claude、Gemini、Ollama
    LLM__META__MODEL: "gpt-4o-mini"
    LLM__HTTP_CLIENT__API_TOKEN: "$OPENAI_API_KEY"
    VCS__PROVIDER: "GITLAB"
    VCS__PIPELINE__PROJECT_ID: "$CI_PROJECT_ID"
    VCS__PIPELINE__MERGE_REQUEST_ID: "$CI_MERGE_REQUEST_IID"
    VCS__HTTP_CLIENT__API_TOKEN: "$CI_JOB_TOKEN"
  allow_failure: true
```

支持 inline（逐行评论）、context（跨文件分析）、summary（总结报告）三种审查模式，以及 Agent 模式——AI 先自主浏览代码库再审查。

### CodeRabbit：SaaS 方案

如果团队预算允许且不想自建，CodeRabbit 是支持 GitLab 的 SaaS 方案，开箱即用。

**最小可用配置**：

1. 在 coderabbit.ai 注册（免费版无需信用卡）
2. 在设置面板添加需要启用的 GitLab 仓库
3. 在仓库根目录创建 `.coderabbit.yaml`：

```yaml
reviews:
  profile: "assertive"
  auto_review:
    enabled: true
    drafts: false
    ignore_title_keywords:
      - "WIP"
      - "DO NOT MERGE"
  path_filters:
    - "!dist/**"
    - "!node_modules/**"
```

提交后，每个新 MR 会自动触发审查，以 MR 评论的形式输出 walkthrough 摘要和逐文件意见。也可以用 CodeRabbit CLI 在 pre-push hook 中前置审查。

**定价**（查询日期 2026-03-24，具体档位和费用以 coderabbit.ai/pricing 官网为准，以下仅供参考）：

| 计划 | 说明 |
|------|------|
| Free | MR 摘要，有速率限制 |
| Pro | 完整审查功能、SAST 集成、Jira/Linear 联动 |
| Enterprise | 自托管、SSO、高级合规 |

只对创建 MR 的开发者收费，不限仓库数量。

### 方案选型建议

| 方案 | 适用场景 | 模型支持 | 部署方式 | 成本 |
|------|---------|---------|---------|------|
| AI-Codereview-Gitlab | 自建 GitLab，想要 Dashboard + IM 推送 | DeepSeek/OpenAI/智谱/Ollama | Docker 独立服务 | 仅模型 API 费用 |
| ai-review | 想在 CI pipeline 内闭环 | OpenAI/Claude/Gemini/Ollama | GitLab CI Job | 仅模型 API 费用 |
| CodeRabbit | 预算充足，想开箱即用 | 内置（含 Claude） | SaaS | 按开发者收费 |
| GitLab Duo | 用 GitLab.com 托管版 | GitLab 内置 | 原生集成 | 按 GitLab Credits 计费（以官网为准） |

### 分层审查策略（Risk Lanes）

不是所有 MR 都需要同等审查强度。把 MR 按风险分级，低风险快速过，高风险严格审——这是在不增加人手的情况下提升审查吞吐量的最直接手段。

| 风险等级 | 判定标准 | 审查策略 |
|----------|----------|----------|
| 低风险 | 文档、样式、.gitignore | AI 审查通过即可合并 |
| 中风险 | API 变更、服务逻辑、依赖更新 | AI 预审 + CODEOWNERS 指定审查者 + 1 人批准 |
| 高风险 | 数据库迁移、支付/认证逻辑、基础设施 | AI 审查 + 2 人交叉验证 + 安全团队 |

用 GitLab CI 自动给 MR 打风险标签：

```yaml
label-risk:
  stage: .pre
  image: alpine:latest
  rules:
    - if: '$CI_MERGE_REQUEST_IID'
  before_script:
    - apk add --no-cache curl jq
  script: |
    # 获取 MR 变更文件列表
    FILES=$(curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
      "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/changes" \
      | jq -r '.changes[].new_path')

    # 判断风险等级
    RISK="medium"
    echo "$FILES" | grep -qE '(migrations/|src/payment/|terraform/|src/auth/)' && RISK="high"
    echo "$FILES" | grep -qvE '(docs/|\.md$|README|\.gitignore|src/styles/)' || RISK="low"

    # 给 MR 打标签
    curl -s --request PUT \
      --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
      "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID" \
      --data "add_labels=risk:$RISK"
```

配合 `CODEOWNERS` 文件定义各目录的审查责任人（GitLab 同样支持，语法与 GitHub 相同）：

```
# CODEOWNERS
*                       @org/core-team
src/frontend/**         @org/frontend-team
src/payment/**          @org/payment-team @org/security-team
migrations/**           @org/dba-team @org/backend-lead
terraform/**            @org/infra-team @org/security-team
docs/**                 @org/docs-team
```

在 GitLab 中配置 Merge Request Approval Rules（Settings → Merge requests → Approval rules）：
- 低风险：0 approvals required
- 中风险：1 approval from CODEOWNERS
- 高风险：2 approvals + 安全团队

> **管理者行动**：授权团队自主决定低风险 MR 的合并权限。不是所有 MR 都需要走同一审批流。

> 数据说明：上文引用的审查效率数据部分来自工具厂商研究（CodeRabbit、Faros AI），适合用来提出假设和参考，不宜单独当行业定论。

## 实操二：CI/CD 从 25 分钟压到 7 分钟

![CI/CD 流水线优化前后对比：25 分钟 → 4 分钟](/blog/ai-outer-loop-acceleration/03-ci-optimization.jpg)

代码审查通过了，CI 又跑了 25 分钟。开发者去喝杯咖啡回来，发现因为一个 flaky test 失败了，重跑。又 25 分钟。

CI 慢不只是浪费时间，它打断了开发者的上下文——等结果回来时，脑子里的工作记忆已经换成别的事了。

### 三板斧：并行 + 缓存 + 分层测试

以下以 Node.js/npm 生态为例演示，原理适用于任何语言栈。

**并行化——把测试分片跑**

```yaml
test:
  stage: test
  image: node:20
  parallel: 5
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/
  before_script:
    - npm ci --cache .npm --prefer-offline
  script:
    - npx vitest --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
```

25 分钟的测试套件分 5 个 shard 并行跑，降到 6 分钟。GitLab 的 `parallel` 关键字自动生成 `$CI_NODE_INDEX` 和 `$CI_NODE_TOTAL` 变量，比手动定义矩阵简洁得多。

**缓存——别每次都全新安装依赖**

```yaml
test:
  stage: test
  image: node:20
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/
    policy: pull-push
  before_script:
    - npm ci --cache .npm --prefer-offline
  script:
    - npm run test:unit
```

GitLab CI 的 `cache` 指令基于 lockfile hash 缓存依赖。`policy: pull-push` 表示 Job 既拉取缓存也更新缓存。注意缓存的是 npm 全局缓存目录（`.npm/`）而非 `node_modules/`——因为 `npm ci` 会先删除 `node_modules` 再重建，缓存它没有意义。`--cache .npm --prefer-offline` 让 npm 优先从本地缓存安装，依赖安装从 3-15 分钟降到几十秒。

**分层测试——不是每次 push 都要跑全套**

| 层级 | 何时触发 | 速度目标 |
|------|----------|----------|
| Pre-commit hooks（lint + format） | 每次 commit 前 | < 10 秒 |
| CI 单元测试 | 每次 push / MR | < 5 分钟 |
| 集成测试 | 合并到 main 前 | < 15 分钟 |
| E2E 测试 | nightly build | 可接受较慢 |

用 GitLab CI 的 `rules` 实现"MR 只跑快速测试，合并到 main 前才跑慢测试"：

```yaml
stages:
  - lint
  - test
  - integration

lint:
  stage: lint
  script:
    - npm run lint
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

unit-test:
  stage: test
  parallel: 5
  script:
    - npm ci
    - npx vitest --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

integration-test:
  stage: integration
  script:
    - npm ci
    - npm run test:integration
    - npm run test:e2e
  rules:
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"'
      when: on_success
```

GitLab CI 的 `rules:changes` 还可以实现条件执行——纯文档变更跳过测试。做法是在测试 job 自身加排除规则（而不是单独建一个 job）：

```yaml
unit-test:
  stage: test
  parallel: 5
  script:
    - npm ci --cache .npm --prefer-offline
    - npx vitest --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "docs/**/*"
        - "*.md"
        - "README*"
      when: never
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

integration-test:
  stage: integration
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run test:integration
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "docs/**/*"
        - "*.md"
        - "README*"
      when: never
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"'
      when: on_success
```

### 把验证前移到内循环

等 CI 告诉你代码有问题，反馈周期太长。把能提前发现的问题移到本地：

1. **Pre-commit hooks**：用 husky + lint-staged（JS/TS）或 pre-commit 框架（Python），在 commit 前自动跑 lint 和 format。只检查 staged 文件，秒级完成
2. **AI 预检**：push 之前在 Claude Code 里跑 `/review`，让 AI 先扫一遍你的 diff。相当于一个不会累的虚拟 reviewer

```bash
# 在 Claude Code 终端中
/review           # 审查当前 git diff
```

目标：MR 提交前就发现大部分低级问题，减少 CI 往返和审查来回。

### 实测数据

两个社区案例的具体优化路径：

**案例一**（来源 markaicode.com）：CI 从 45 分钟 → 3 分钟
- 依赖缓存：15 分钟 → 几秒
- 顺序执行 → 并行 jobs
- Docker 层缓存：30 分钟构建 → 2 分钟
- 条件执行：文档变更不触发完整测试

**案例二**（来源 techbuddies.io）：CI 从 20 分钟 → 9 分钟
- 先测量 2 周 timing 数据，定位瓶颈在依赖安装和顺序测试
- 依赖缓存 + 并行 jobs + 选择性触发
- Flaky test 修复：失败率从 10-15% 降到 3-4%
- 月度 runner 费用降低约 50%

综合多个社区分享的经验，**缓存 + 并行 + 条件执行 + 修复 flaky test 通常能带来 60-80% 的 CI 时间缩减**。

> **管理者行动**：设置 CI p95 时间阈值（如 < 10 分钟），超标即触发优化。不要等开发者抱怨。

技术瓶颈堵住后，剩下的等待时间往往来自跨团队审批和历史流程——这就是下一个要打的仗。

## 实操三：识别和消灭组织流程债务

### 什么是组织流程债务

一句话：那些"以前有意义、现在纯浪费时间"的会议、签批、固定步骤。

Forsgren 在演讲中大意是：AI 半天写完代码，开发者却花更长时间等流程走完。这个落差感比以前强烈得多——以前写代码本身就慢，等待被分摊进了整个过程；现在写代码极快，等待暴露得一览无遗。

### 快速诊断清单（5 分钟自查）

以下信号命中越多，流程债务越重：

- [ ] 每个 MR 必须 2 人审批，不分风险级别
- [ ] 部署需要填工单或走审批系统
- [ ] 每周有超过 3 个"同步会"
- [ ] 发布前要邮件通知 5+ 个人
- [ ] 有人的工作就是"在各系统之间复制粘贴状态"
- [ ] 测试环境需要排队
- [ ] 代码冻结期超过业务实际需要
- [ ] 新人上手要配置的开发环境步骤超过 20 步
- [ ] 跨团队协作需要"先开个会对齐"
- [ ] 有流程文档，但没人记得上次更新是什么时候

### 三步消除法

1. **审计**：记录一周内所有"等待时间"——等审批、等会议、等回复、等环境。不用精确计时，粗略感知就够
2. **分类**：哪些是合规必须（保留），哪些是历史惯性（挑战），哪些是"因为上次出过事所以加的"（评估是否还有意义）
3. **砍掉**：从最容易的开始，每周消灭 1 个。小胜积累信心

> **管理者行动**：每季度做一次"流程审计"，公开宣布砍掉了哪些步骤。让团队看到改变正在发生——这本身就是对心理安全的投资。

## 先量基线，再上工具

前面讲了怎么打通审查、CI 和流程三个瓶颈。但在动手之前，你得先知道瓶颈在哪。盲目上工具是另一种流程债务。

### 为什么"代码行数"和"MR 数"是垃圾指标

Forsgren 在演讲中大意是：100% 的 AI 工具采用率加上 0% 的交付改善，完全可能发生。

Faros AI 的数据也印证了这一点：AI 让 MR 数翻倍，但交付周期没变。更多的 MR 不代表更多的价值——它可能只是意味着更多的审查负担。

代码行数在 AI 时代更加没有意义——AI 可以轻松刷高这个数字，但更多的代码不代表更多的价值。可以把这类表面指标理解为"测量体温来评估运动能力"——有相关性，但完全不是因果关系。

### 应该看什么指标

**DORA 指标**——业界公认的软件交付性能衡量标准，2025 年已从 4 指标升级到 5 指标：

1. 部署频率（Deployment Frequency）
2. 变更前置时间（Lead Time for Changes）
3. 变更失败率（Change Failure Rate）
4. 失败部署恢复时间（Failed Deployment Recovery Time）
5. 返工率（Rework Rate）——新增，追踪推送到生产环境的非计划修复频率

多数团队仍在用传统四指标，但知道官方已升级很重要——返工率填补了一个盲区：团队可能在四个核心指标上表现优秀，但花大量时间清理刚部署的问题。

**Developer Flow**——Forsgren 强调应优先关注开发者被打断的频率。被糟糕流程、慢工具、不必要会议打断的次数越多，效率越低。减少这个数字，速度和质量都会跟着改善。

**MR Queue Time**——MR 从提交到首次审查的等待时间。这是最容易量、最直观的外循环指标，也是本文重点解决的问题。

### 度量工具推荐

**按预算分级**：

- **零成本起步**：**GitLab Value Stream Analytics**（Settings → Analytics → Value stream）——免费版就有基础的 MR 生命周期数据，包括从 Issue 创建到合并部署的各阶段耗时。手动统计每周 MR Queue Time 的中位数也够用
- **轻量级方案**：Grafana + GitLab Data Source 插件，自建 dashboard。可视化 MR 审查响应时间、合并前审查轮次等
- **SaaS 方案**：LinearB 自动计算 DORA 和 Flow Metrics，直接对接 GitHub/GitLab + Jira。Nave 专注看板流程效率可视化，擅长暴露工作项的等待时间

选哪个不重要，重要的是**开始量**。

> **管理者行动**：从 MR Queue Time 开始量，每周团队会上看一次趋势。不需要复杂工具，不需要完美数据，需要的是持续关注。

## 瓶颈已经转移，你准备好了吗

Forsgren 在演讲中大意是：目标是让"正确的做法"同时也是"最容易的做法"。

AI 时代真正稀缺的能力不是写 prompt，而是打通从代码到交付的完整链条——让审查不再排队、CI 不再空转，让那些无人记得为什么存在的流程消失。这些看起来不性感的工作，决定了 AI 加速能不能真正兑现为团队交付速度。

**三步行动，按"先量再改"排序**：

1. **今天**：量一下你团队的 MR Queue Time——从提交到首次审查，平均等了多久？
2. **本周**：给项目试配 AI-Codereview-Gitlab 或 CodeRabbit，让 AI 接手第一轮审查
3. **本月**：用本文的诊断清单做一次流程审计，砍掉 1 个无价值的流程步骤

---

## 附录 A：AI-Codereview-Gitlab 高级配置

更多配置项（Review 风格、日报生成、Dashboard 设置等）请参考仓库 `conf/.env.dist` 文件：
https://github.com/sunmh207/AI-Codereview-Gitlab

## 附录 B：GitLab CI 常用优化技巧

### Docker 层缓存

构建 Docker 镜像时利用层缓存避免重复构建：

```yaml
build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_BUILDKIT: 1
  script:
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build
      --cache-from $CI_REGISTRY_IMAGE:latest
      --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      --tag $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest
```

### 自托管 Runner

GitLab 共享 Runner 排队慢？自建 Runner 是国内团队的常规操作：

```bash
# 在你的服务器上
curl -L --output /usr/local/bin/gitlab-runner \
  https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
chmod +x /usr/local/bin/gitlab-runner
gitlab-runner register \
  --url https://your-gitlab.com \
  --registration-token YOUR_TOKEN \
  --executor docker \
  --docker-image alpine:latest
```

在 `.gitlab-ci.yml` 中指定 Runner：

```yaml
test:
  tags:
    - self-hosted
  script:
    - npm test
```

### Artifacts 配置

测试报告和构建产物的传递：

```yaml
unit-test:
  stage: test
  script:
    - npm ci
    - npm run test:unit -- --reporter=junit --outputFile=report.xml
  artifacts:
    reports:
      junit: report.xml
    paths:
      - coverage/
    expire_in: 7 days
```

## 附录 C：其他包管理器的缓存配置（GitLab CI）

### yarn

```yaml
test:
  image: node:20
  cache:
    key:
      files:
        - yarn.lock
    paths:
      - .yarn/cache/
  script:
    - yarn install --frozen-lockfile
    - yarn test
```

### pnpm

```yaml
test:
  image: node:20
  before_script:
    - corepack enable
    - corepack prepare pnpm@latest --activate
  cache:
    key:
      files:
        - pnpm-lock.yaml
    paths:
      - .pnpm-store/
  script:
    - pnpm install --frozen-lockfile
    - pnpm test
  variables:
    PNPM_HOME: .pnpm-store
```

---

## 参考文档

以下链接均于 2026-03-24 查询确认可访问。

Nicole Forsgren, The Pragmatic Summit 2026.2 演讲要点（宝玉整理）: https://x.com/dotey/status/2035621498707177923

AI-Codereview-Gitlab: https://github.com/sunmh207/AI-Codereview-Gitlab

ai-review: https://github.com/Nikita-Filonov/ai-review

GitLab CI/CD 官方文档: https://docs.gitlab.com/ee/ci/

GitLab CODEOWNERS: https://docs.gitlab.com/ee/user/project/codeowners/

GitLab Merge Request Approvals: https://docs.gitlab.com/ee/user/project/merge_requests/approvals/

GitLab Value Stream Analytics: https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html

CodeRabbit 快速入门文档: https://docs.coderabbit.ai/getting-started/quickstart

CodeRabbit 配置参考: https://docs.coderabbit.ai/reference/configuration

CodeRabbit 定价页面: https://www.coderabbit.ai/pricing

CodeRabbit, State of AI vs Human Code Generation 报告 (2025.12): https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

Faros AI, DORA Report 2025 Key Takeaways: https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025

DORA, Software Delivery Metrics: https://dora.dev/guides/dora-metrics-four-keys/

CD Foundation, The DORA 4 Key Metrics Become 5: https://cd.foundation/blog/2025/10/16/dora-5-metrics/

Aviator, Code Reviews at Scale: https://www.aviator.co/blog/code-reviews-at-scale/

Aviator, A Modern Guide to CODEOWNERS: https://www.aviator.co/blog/a-modern-guide-to-codeowners/

markaicode.com, The 45-Minute Build That Nearly Broke My Team: https://markaicode.com/github-actions-cicd-optimization-slow-to-fast/

techbuddies.io, Case Study CI/CD Pipeline Optimization: https://www.techbuddies.io/2025/12/17/case-study-how-we-optimized-ci-cd-pipelines-in-github-actions-and-gitlab-ci/

博客园 GitLab+GPT 实战: https://www.cnblogs.com/wintersun/p/18471799

N8N+GitLab 自动化评审: https://www.boboidea.com/posts/n8n-gitlab-auto-review/

LinearB 平台: https://linearb.io/

Nave Flow Efficiency: https://getnave.com/flow-efficiency-chart

Grafana GitLab Data Source Plugin: https://grafana.com/grafana/plugins/grafana-gitlab-datasource/
---

## 相关阅读

- [从需求到自动化：Claude Code Skill 工具链完整实战](/posts/claude-code-skill-toolchain/) — 文中提到的 `/review` 命令就是 Claude Code 的 Skill 之一，了解完整工具链
- [我如何使用 Claude Code：先计划，再编码](/posts/claude-code-plan-before-code/) — 内循环效率提升的另一面：AI 辅助开发的工作流方法论
- [25分钟完成5套UI风格：AgentTeam + Git Worktree 并行开发实战](/posts/agent-team-worktree-ui-styles/) — 用 Agent Team 并行开发，进一步压缩内循环时间