AI 写代码变快了,交付为什么没跟上?

2026-06-29 20 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:9 分钟

GitLab 2026 AI Accountability Report 提出了一个很扎实的“AI 悖论”:78% 的开发者认为 AI 让自己写代码更快,但软件整体交付速度并没有同步提升。原因不在编辑器里,而在更靠后的环节:测试、评审、合规、可追溯性,以及企业治理对 AI 生成代码提出的新要求。

速度提升卡在了流水线后半段

AI 编程工具最容易改善的是局部动作:补全函数、生成测试草稿、解释错误、改写 API 调用。这些都发生在开发者工作站或 IDE 里,反馈周期很短。

但软件交付不是“代码写完”就结束。一次变更还要经过:

  • 自动化测试是否足够覆盖变更;
  • Code review 是否能判断 AI 生成代码的意图、边界和副作用;
  • 安全扫描、许可证检查、制品签名是否通过;
  • 需求、提交、合并请求、部署记录之间是否可追溯;
  • 线上问题出现时,团队能否解释“这段代码为什么这么写”。

所以报告里的悖论并不矛盾:AI 加快了“编码”,但没有自动加快“交付系统”。如果测试队列排队 40 分钟、评审没人敢点批准、治理团队无法追踪 AI 参与了哪些变更,局部提速会在下游被吃掉。

企业真正要补的是“AI 变更的证据链”

对个人开发者来说,AI 生成代码像是一个更快的助手;对企业来说,它引入了新的审计问题。

一个成熟的软件组织通常需要回答这些问题:

  • 这个 MR 是否使用了 AI 辅助?
  • 哪些文件主要由 AI 生成或改写?
  • 人类评审者检查了哪些风险点?
  • 生成代码是否引入了不合规依赖?
  • 出问题后,能否从需求追到提交、流水线、部署和审批记录?

这就是 GitLab 报告提到的治理和可追溯性挑战。AI 工具越深入交付链路,组织越不能只看“代码行数”和“提交速度”,而要把 AI 参与痕迹纳入工程系统本身。

可以这样实践:给 AI 辅助变更加上轻量治理门禁

下面是一个可改造的 GitLab CI 示例。它不假设某个具体 AI 产品,而是用 MR 标签和模板文件建立一条简单规则:如果合并请求带有 ai-assisted 标签,就要求仓库中存在 docs/ai-change-note.md,用于记录 AI 使用范围、人工验证动作和风险说明。

你可以把它保存为 .gitlab-ci.yml,并按团队实际规则调整标签名和文件路径。

stages:
  - verify
  - test

verify_ai_traceability:
  stage: verify
  image: alpine:3.20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    - |
      echo "MR labels: ${CI_MERGE_REQUEST_LABELS:-}"
      case ",$CI_MERGE_REQUEST_LABELS," in
        *,ai-assisted,*)
          echo "AI-assisted change detected. Checking traceability note..."
          test -f docs/ai-change-note.md || {
            echo "Missing docs/ai-change-note.md"
            echo "Create it and describe AI usage, human review, and validation steps."
            exit 1
          }
          grep -q "Human validation:" docs/ai-change-note.md || {
            echo "docs/ai-change-note.md must include: Human validation:"
            exit 1
          }
          ;;
        *)
          echo "No ai-assisted label found. Skipping AI traceability check."
          ;;
      esac

unit_tests:
  stage: test
  image: python:3.12-slim
  script:
    - python -m pip install -r requirements.txt
    - python -m pytest -q

配套的 docs/ai-change-note.md 可以用一个很短的模板:

# AI Change Note

AI usage:
- Example: generated initial implementation for input validation helper.

Human validation:
- Example: reviewed edge cases for empty input, malformed IDs, and permission checks.
- Example: added or updated unit tests covering changed behavior.

Risk notes:
- Example: no new runtime dependency introduced.
- Example: security-sensitive logic was manually reviewed.

这类门禁不是为了制造流程负担,而是把“AI 是否参与、人工如何验证”从聊天记录里拉回到工程资产里。真正落地时可以更细:只对高风险目录启用,比如鉴权、支付、数据迁移、基础设施配置。

交付指标也要从“写得快”转向“流得动”

如果只统计 AI 工具采纳率,很容易得到乐观结论。更有价值的是观察瓶颈有没有移动。

可以从这些指标开始:

  • MR 从创建到合并的中位时间;
  • 首次 review 等待时间;
  • CI 排队时间和执行时间;
  • 因测试失败返工的次数;
  • 部署频率与变更失败率;
  • AI 辅助 MR 与普通 MR 的缺陷率、回滚率对比。

下面这个简化脚本展示了如何从 GitLab API 拉取最近合并的 MR,并计算从创建到合并的耗时。运行前需要设置 GITLAB_TOKEN,并把 PROJECT_IDGITLAB_HOST 改成你的环境。

import os
import statistics
from datetime import datetime, timezone

import requests

GITLAB_HOST = os.getenv("GITLAB_HOST", "https://gitlab.com")
PROJECT_ID = os.environ["PROJECT_ID"]
TOKEN = os.environ["GITLAB_TOKEN"]

url = f"{GITLAB_HOST}/api/v4/projects/{PROJECT_ID}/merge_requests"
params = {
    "state": "merged",
    "per_page": 50,
    "order_by": "updated_at",
    "sort": "desc",
}
headers = {"PRIVATE-TOKEN": TOKEN}

resp = requests.get(url, params=params, headers=headers, timeout=20)
resp.raise_for_status()

hours = []
for mr in resp.json():
    created = datetime.fromisoformat(mr["created_at"].replace("Z", "+00:00"))
    merged = datetime.fromisoformat(mr["merged_at"].replace("Z", "+00:00"))
    hours.append((merged - created).total_seconds() / 3600)

if not hours:
    print("No merged merge requests found.")
else:
    print(f"MR count: {len(hours)}")
    print(f"Median lead time: {statistics.median(hours):.1f} hours")
    print(f"Average lead time: {statistics.mean(hours):.1f} hours")

安装依赖并运行:

python -m venv .venv
. .venv/bin/activate
python -m pip install requests
export GITLAB_TOKEN="glpat_xxx"
export PROJECT_ID="123456"
export GITLAB_HOST="https://gitlab.com"
python measure_mr_lead_time.py

这段脚本不能直接证明 AI 是否带来收益,但它能帮助团队把讨论从“感觉更快”拉到“交付是否真的变快”。如果再结合 MR 标签,例如 ai-assisted,就可以分别统计 AI 辅助变更和普通变更的交付周期。

采用建议:别只买工具,要改交付系统

AI 编码工具值得用,但不要把它当成单点加速器。更稳妥的落地路径是:

  • 让开发者使用 AI 处理低风险、高重复的编码任务;
  • 给高风险变更增加可追溯说明,而不是禁止 AI;
  • 把测试、review、CI 等待时间纳入同一张交付看板;
  • 用标签、MR 模板、流水线规则记录 AI 参与痕迹;
  • 定期比较 AI 辅助变更的缺陷率、返工率和合并周期。

报告揭示的核心问题不是“AI 没用”,而是“局部生产力没有自动转化为系统吞吐量”。当代码生成速度超过测试、评审和治理能力时,瓶颈只会换个地方出现。真正的收益来自把 AI 放进完整的软件交付链,而不是只放进编辑器。


相关推荐