本文基于《Bitrise State of Mobile Development 2026 》一文进行解读，一些图表无法直接在公众号查看，想看的可以去看文章的原文。Bitrise是一个专门做移动端CI/CD的平台。
过去两年，关于 AI 写代码的讨论几乎没断过。一边是"AI 让开发效率提升十倍"的欢呼，一边是"AI 生成的代码会搞崩你的 pipeline"的警告。两边都有道理，但都缺一样东西------数据。
Bitrise 作为一个为数千移动开发团队提供 CI/CD pipeline 的平台，手里握着大量真实的构建数据。他们在 Q1 2025 和 Q1 2026 之间，分析了超过 1900 万次匿名构建，出了这份《State of Mobile Development 2026 报告》。核心问题只有一个：AI 写的代码，到底对移动开发 pipeline 做了什么？
结论有点出乎意料。
161 倍：AI 构建的增长有多猛
这是整份报告里最炸裂的数字。一年时间，带 AI 标记的构建量增长了 161 倍。注意，这不是"AI 工具使用率提升 161%"，是 161 倍。
Bitrise 怎么判断一次构建是 AI 产生的？他们用了三个信号：commit message 里有 co-author 行（比如 Co-authored-by: Claude）、已知的 bot 账号触发了构建（比如 webhook-github/cursor[bot]）、或者分支名带有 agent 风格（比如 devin/1777625139-migrate-item-post）。
kotlin
# AI 构建的三种识别方式Co-authored-by: Claude <noreply@anthropic.com>webhook-github/cursor[bot]devin/1777625139-migrate-item-post这就意味这份报告里的数据只可能更多，而不是更少。比如说相当一部分人是从豆包等AI工具中粘贴一段代码，用自己名字提交，那次构建看起来就跟普通 commit 一模一样。以我自身为例，我用AI的时候基本上不会出现上面的几种情况，所以实际的 AI 代码量只会更多。
谁在写这些代码：Claude 一家独大
从工具份额来看，Claude 占了 AI 构建的 67%，无可争议的老大。但有两个细节值得注意。
第一，份额下降不等于使用量下降。整个 AI 构建的 pie 在这一百多倍增长中被做大了，所以 Devin 和 Copilot 虽然份额缩了，但绝对构建量比以前还多。只是 Claude 涨得太猛，把其他人的比例稀释了。
第二，构建份额不等于渗透率。Copilot 在更多 workspace 里出现，但每个 workspace 跑的构建数少，所以它的份额被低估了。换句话说，Copilot 是"用的人多但跑得少"，Claude 是"用的人可能没那么广但跑量大"。
全行业入场：从旅游到保险
一年前，AI 构建在所有行业都接近零。现在，Bitrise 追踪的 17 个行业全部有了 AI 构建的影子。旅游业领先，36% 的 workspace 至少跑过一次 AI 构建；外卖和消费电子紧随其后，各 35%。
排在最后的是保险业，13%。但仔细想想，保险业对代码质量和合规的要求本来就更高，13% 已经不少了。而且这些受监管、重风险的行业没有一个选择观望------它们只是更谨慎，不是不参与。
行业之间的差异已经不再是"用不用 AI"，而是"用多深"。但这个差距，正在快速缩小。
最大的意外：AI 没有搞崩构建
这大概是整份报告里最反直觉的部分。在 AI 写代码大规模进入 pipeline 之前，很多人的预测是：构建失败率会飙升。理由也合理------AI 生成的代码质量不稳定，缺乏上下文理解，容易引入编译错误和逻辑 bug。
但我们从Bitrise提供的数据来看却是另外一回事。
AI 相关构建的失败率是 16.3%，反而比非 AI 构建的 17.4% 还低。构建速度方面，AI 构建平均 10.7 分钟，非 AI 构建 11.8 分钟，AI 构建快了约 9%。P90 慢尾也短，22 分钟 vs 24 分钟。
有人可能觉得这是 AI 构建集中在基础设施更好的团队里导致的偏差。Bitrise 也想到了，所以他们做了第二轮分析：在同一个 workspace 内部对比 AI 和非 AI 构建，结果一样------AI 构建仍然失败率更低，速度快约 5%。
一个重要限定：这个数据是从 CI 阶段开始测量的，也就是代码到达 pipeline 之后的情况。开发者在 push 之前做了什么、agent 在本地跑了几轮，我们看不到。而且对比的是不同构建，不是同一个 pipeline 分别被人触发和 agent 触发。所以部分差距可能来自 AI 构建本身就是不同类型的工作。但结论是明确的：带 AI 标记的构建，没有失败更多。
整体失败率纹丝不动
把视角拉到全局：同一批团队的构建量涨了 20%，但整体失败率从 17.8% 微降到 17.4%。六分之一左右的失败率，跟 AI 进入 pipeline 之前一模一样。
更有意思的是失败的性质在变。在可分类的失败中，"质量检查挡住了 bug"的比例从 21.5% 升到了 25.3%------测试和 lint 在干活。而真正的基础设施故障稳定在 5.6% 左右，没变。
自动化也在跟上节奏。Bitrise 的自动测试重跑功能（用来自动标记 flaky test）使用频率涨了 5 倍。使用 Bitrise Test Reports 的团队，单测试失败率减半，而测试量增长了 78%。这看起来更像是自动化在替人挡问题，而不是人手动在查。
构建时间不升反降：iOS 首次超越 Android
构建量涨了 20%，但构建时间反而降了。iOS 构建从一年前的约 13.7 分钟降到了 12.05 分钟，降幅 12%。Android 降到了 12.98 分钟。两条线在 2025 年年中交叉------iOS 构建第一次比 Android 快了。
原因分两个层面。
硬件层面，Bitrise 的 iOS 机队从 M1 时代全面切换到了 M4。一年前，61% 的 iOS 构建跑在 M1 机器上；现在 M1 只占 4%，M4 从零涨到了 54%。M4 机器的纯粹算力提升直接反映在了构建时间上。甚至同代 M2 机器在一年内也快了 16%。
软件层面，Android 团队也没闲着。Gradle Build Cache 的采用率一年涨了 53%，这让 Android 构建也快了 7%。但 Android 的非 PR 构建失败率从 17.1% 降到了 15.4%，这是所有细分数据里最大的可靠性改善。
一个 Apple 相关的提醒：每次 Xcode 大版本发布后的几周内，构建失败率会暴涨最多 16 个百分点。跟着 Apple 的节奏升级 Xcode 是最痛的迁移期。固定 Xcode 版本，按自己的节奏升级，依然是移动 CI 里最容易拿到的可靠性提升。
真正拉开差距的不是 AI 用多深，而是基础设施
报告里有一个对比让我印象很深：
80.6% 的高构建量团队同时启用了缓存、测试报告和可观测性工具；而低使用量团队只有 6.6% 做到了这一点。
这个差距比 AI 用多用少的差距大得多。Bitrise 的数据显示，至少 45% 的活跃 workspace 在 CI 中跑自动化测试，但只有 34% 开启了测试报告。也就是说，有超过十分之一的团队在跑测试，但根本没在看测试结果。
在现代基础设施（Bitrise 当前一代构建栈）上，P90 排队等待时间下降了 13%，而构建量增长了 17%。但还在用旧基础设施的团队，额外负载直接变成了队列堆积，最长等待时间超过半小时。
这跟 AI 无关。同一套基础设施，好的团队用 M4 机器 + 缓存 + 测试报告 + 可观测性，构建快、失败率低、排队短。差的团队用旧机器、没缓存、不测试不报告，构建慢、失败多、排队长。AI 只是把更多的代码推到了 pipeline 里，但 pipeline 本身的质量，决定了这些代码能不能顺畅地走完。
我的看法
这份报告并不是想告诉你，"AI有多厉害"或者说"AI就是神"，毕竟在过去的一年多甚至2年多的时间里，你已经听过无数次类似的话了。AI已经毫无争议的改变了移动开发，这份报告也不是在讨论"AI 能不能写 Swift、Kotlin 或 Flutter"这类问题，。它的主要价值在于：代码进入研发流水线的速度正在显著提高。
几个让我意外的点：
第一，AI 构建失败率更低。 这可能不是 AI 代码质量更高，而是 AI 更倾向于在有充分上下文的环境中工作（成熟 workspace、完善 pipeline），以及 AI 工具在 push 前可能已经做了本地验证。但不管原因是什么，"AI 代码会让 CI 崩掉"这个预测，在数据上不成立。
第二，基础设施才是分水岭。 报告里 80.6% vs 6.6% 那个对比，比任何 AI 工具的份额对比都更有信息量。如果你团队的构建还在旧机器上跑，没有缓存，测试不报告，先别想着换 AI 工具，先把 pipeline 搞好。AI 不会拯救一个糟糕的 CI，但一个好的 CI 能让 AI 写的代码走得更顺。
第三，自动化在默默干重活。 测试重跑 5 倍增长，单测试失败率减半，测试量增长 78%------这些数字不在聚光灯下，但它们才是 pipeline 没崩的真正原因。人没有变快，自动化变快了。
最后一点感受：这份报告测量的是 CI 阶段。代码在 push 之前发生了什么------AI agent 在本地跑了几轮、人改了几行、测试在本地过了没------这些我们还看不到。AI 对移动开发的影响，可能比这份报告能捕捉到的还要大。但至少在 pipeline 这个切片里，数据说的是：洪水来了，堤坝没塌。不是因为洪水不够猛，是因为堤坝在过去一年里悄悄加固了。