AI 加不了速的,是你的开发流程

2026-05-19 31 预计阅读时间:1 分钟
来源:oschina.net AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:10 分钟

几乎所有组织都在琢磨怎么优化流程——市场下行时更是如此。如今 AI 被推到台前,随之而来的却是一堆不切实际的期望:代码生成快了,交付自然就快了?作者 Frederick Van Brabant 重读了两本关于流程与流动的经典著作后,给出了一个冷静的判断:AI 不会让你的流程变快。

这个结论乍听反直觉,但拆开看逻辑很硬。

瓶颈不在写代码这一步

流程的速度由瓶颈决定,这是流水线理论的基本常识。软件开发流程的典型瓶颈是什么?

  • 需求从想法到可开发规格的转化(模糊需求堆积)
  • 代码写完到可部署的等待(CI 排队、审批链、环境依赖)
  • 部署后到用户反馈的回路长度(发布间隔长、观测弱)
  • 跨团队依赖与排队(等待另一个服务的 API、等待安全审查)

AI 确实让"写代码"这一步变快了——但这一步往往不是瓶颈。如果你用 AI 把非瓶颈步骤的效率提升了 50%,整体交付速度的提升可能只有 5%,甚至为零。这就是瓶颈法则的冷酷数学。

流程优化的真正杠杆点

两本经典著作(大概率指 Donald Reinertsen 的《Principles of Product Development Flow》和 Gene Kim 等人的《Accelerate》)反复强调几个杠杆:

  1. 缩短反馈回路——越快知道做对了还是做错了,越快修正方向
  2. 减少批量大小——小批量流动更快,排队更短
  3. 管理排队而非管理利用率——人 100% 满负荷时,排队反而爆炸
  4. 让决策基于经济成本——延迟的成本是多少?排队的经济损失是多少?

这些杠杆指向的是系统结构,不是个体产出速度。AI 改变的是个体产出速度。

AI 真正能帮的,和它帮不了的

AI 能帮的:

  • 快速生成代码草稿,减少"从零开始"的启动摩擦
  • 自动补全测试、写文档,减少低价值重复劳动
  • 辅助代码审查,发现常见模式问题

AI 帮不了的:

  • 消除跨团队等待(API 还没就绪,AI 不会替对方写)
  • 缩短审批链(合规流程不会因为 AI 而减少步骤)
  • 让模糊需求变清晰(AI 可以提问,但决策权在人)
  • 减少部署环境的依赖冲突(基础设施问题不是生成代码能解决的)

换句话说,AI 是加速器,不是疏通剂。 管道堵了,加速器只会让上游压力更大。

用数据说话:测量你的流动效率

与其争论 AI 能不能提速,不如先测量你的流程到底卡在哪里。下面是一个可以直接跑的脚本,用 Git 日志计算几个关键流动指标:

#!/usr/bin/env bash
# flow_metrics.sh — 从 Git 历史中计算开发流动指标
# 使用前确保你在项目根目录,且有完整的 merge/commit 历史

set -euo pipefail

REPO_DIR="${1:-.}"
cd "$REPO_DIR"

echo "=== 开发流动指标分析 ==="
echo "仓库: $(git remote get-url origin 2>/dev/null || echo '本地仓库')"
echo ""

# 1. 平均合并间隔(发布批量大小的一个侧面)
echo "📊 最近 50 个 merge commit 的平均间隔(小时):"
git log --merges --format="%ct" -50 | \
  awk 'NR>1 { diff = prev - $1; sum += diff; count++ } { prev = $1 } END { if(count>0) printf "%.1f\n", sum/count/3600; else print "无数据" }'

echo ""

# 2. PR 从打开到合并的平均时长(需要 gh CLI)
echo "📊 最近 30 个 PR 的平均存活时长(小时):"
if command -v gh &>/dev/null; then
  gh pr list --state merged --limit 30 --json createdAt,mergedAt --jq '.[] | ((.mergedAt | strptime("%Y-%m-%dT%H:%M:%SZ") | mktime) - (.createdAt | strptime("%Y-%m-%dT%H:%M:%SZ") | mktime)) / 3600' | \
    awk '{ sum += $1; count++ } END { if(count>0) printf "%.1f\n", sum/count; else print "无数据" }'
else
  echo "(需要安装 gh CLI:brew install gh)"
fi

echo ""

# 3. 每周 commit 数分布(看节奏是否均匀)
echo "📊 最近 12 周的 commit 数分布:"
git log --format="%ad" --date=short -500 | \
  awk -F'-' '{ week = $1"-"$2; counts[week]++ } END { for(w in counts) printf "%s: %d commits\n", w, counts[w] }' | \
  sort | tail -12

echo ""
echo "💡 诊断提示:"
echo "  - 合并间隔 > 24h → 发布批量可能太大,考虑更频繁合并"
echo "  - PR 存活 > 48h → 审查排队严重,瓶颈在审查而非编码"
echo "  - commit 分布不均 → 可能有大批量提交习惯,减少批量大小"

运行方式:

chmod +x flow_metrics.sh
./flow_metrics.sh /path/to/your/repo

这个脚本不依赖任何 AI,但它能告诉你真正的瓶颈在哪里。如果 PR 存活时长平均 72 小时,那你的瓶颈是审查流程——AI 让代码生成快 3 倍也解决不了这个问题,反而会让待审查的 PR 堆积得更严重。

一个更直接的改进:缩小发布批量

很多团队的发布批量是"两周一次"甚至"一月一次"。这是流程慢的最大结构性原因之一。下面是一个极简的 CI + 自动发布配置,把发布间隔压缩到每次合并:

# .github/workflows/continuous-release.yml
# 每次合并到 main 自动发布——缩小批量,加速流动

name: Continuous Release
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest --tb=short -q

  release:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Generate version tag
        run: |
          # 用 commit 数作为版本号,简单但有效
          COUNT=$(git rev-list --count HEAD)
          echo "VERSION=0.${COUNT}" >> $GITHUB_ENV
      - uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: v${{ env.VERSION }}
          release_name: Release v${{ env.VERSION }}
          draft: false
          prerelease: false

这个配置没有 AI 参与,但它解决了一个真实的流程瓶颈:发布等待。每次合并即发布,反馈回路从"两周"缩短到"几分钟"。这才是流程优化的正确方向。

别用 AI 填充一个已经堵死的管道

总结几个实操建议:

诊断信号 真实瓶颈 AI 能帮吗 正确动作
PR 堆积、审查慢 审查流程 ❌ 越快生成越多堆积 拆小 PR、配对审查、设定 SLA
发布间隔 > 1 周 发布批量太大 自动化 CI/CD,每次合并发布
需求模糊反复改 需求到规格的转化 ⚠️ AI 可辅助提问,但决策在人 需求澄清会议、验收条件前置
等其他团队 API 跨团队依赖 API 契约先行、mock 解耦
环境配置冲突 基础设施 ⚠️ AI 可辅助排查 容器化、环境标准化

AI 是好工具,但它优化的是局部效率。流程速度是系统问题,需要系统解法。 先测量瓶颈,再决定在哪里投入——如果瓶颈不在编码,AI 的投入回报率就是零,甚至为负(因为它增加了下游的排队压力)。

把管道疏通了,再谈加速。


相关推荐