几乎所有组织都在琢磨怎么优化流程——市场下行时更是如此。如今 AI 被推到台前,随之而来的却是一堆不切实际的期望:代码生成快了,交付自然就快了?作者 Frederick Van Brabant 重读了两本关于流程与流动的经典著作后,给出了一个冷静的判断:AI 不会让你的流程变快。
这个结论乍听反直觉,但拆开看逻辑很硬。
瓶颈不在写代码这一步
流程的速度由瓶颈决定,这是流水线理论的基本常识。软件开发流程的典型瓶颈是什么?
- 需求从想法到可开发规格的转化(模糊需求堆积)
- 代码写完到可部署的等待(CI 排队、审批链、环境依赖)
- 部署后到用户反馈的回路长度(发布间隔长、观测弱)
- 跨团队依赖与排队(等待另一个服务的 API、等待安全审查)
AI 确实让"写代码"这一步变快了——但这一步往往不是瓶颈。如果你用 AI 把非瓶颈步骤的效率提升了 50%,整体交付速度的提升可能只有 5%,甚至为零。这就是瓶颈法则的冷酷数学。
流程优化的真正杠杆点
两本经典著作(大概率指 Donald Reinertsen 的《Principles of Product Development Flow》和 Gene Kim 等人的《Accelerate》)反复强调几个杠杆:
- 缩短反馈回路——越快知道做对了还是做错了,越快修正方向
- 减少批量大小——小批量流动更快,排队更短
- 管理排队而非管理利用率——人 100% 满负荷时,排队反而爆炸
- 让决策基于经济成本——延迟的成本是多少?排队的经济损失是多少?
这些杠杆指向的是系统结构,不是个体产出速度。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 的投入回报率就是零,甚至为负(因为它增加了下游的排队压力)。
把管道疏通了,再谈加速。