正在加载，请稍候
麦肯锡 2026 调研里，80% 的人说 AI 提效了，只有 37% 说公司利润受益。京东 JDD、蚂蚁数科、快手三场 2026 年分享，指向同一个新瓶颈：验收与稳定性处置。
真正卡住企业 AI 落地的不是模型能力，是验收。2026 年 9 月连着几场技术大会给出的数据，都指向同一个结论：代码产出翻倍了，交付周期没有同步变短。
这个判断听起来有点反直觉——毕竟工具在肉眼可见地变强。但把几组公开数据摆在一起，落差就很清楚。
麦肯锡 2026 年的一份全球 AI 调研里，80% 的受访者表示 AI 已经提高了自己的工作效率，但只有 37% 认为 AI 对所在企业的息税前利润（EBIT）产生了正向影响。更值得留意的是后半个数字：它和 2025 年相比几乎没有变化。工具在进步，组织层面的收益曲线却是平的。
2026 年 9 月 9 日的京东全球科技探索者大会（JDD）上，京东零售产研团队把这道缝拆成了两半：代码产生之前的需求沟通、方案设计、任务拆分、系统评估和跨部门协调，属于「上工程」；代码产生之后的 Review、测试、发布和运维，属于「下工程」。现场的分享记录里有一句话很直接：编码只是软件工程中的一环，而现在被 AI 加速最明显的，恰恰只有中间这一段。
这就解释了一个很多团队遇到的怪现象：AI 工具用得越来越顺手，代码提交量涨了，但版本上线的时间点没有提前，反而在评审和测试环节堵得更厉害。评审端被堵死的极端样本，站内那篇AI 提交 1721 行 diff 之后审查者直接关掉 PR 记录得很清楚。
同一场分享里有个具体案例：优化直播频道的膨胀券发放机制。按传统流程，这项需求要经过产品设计、技术评估、架构设计、开发测试到上线发布。新流程里，业务需求先被输入系统，平台结合内部业务知识、历史数据和产品经验，生成初步方案、PRD 和接近线上效果的原型，再分析技术影响范围——这次分析识别出约 30 个业务域和上百个系统可能被波及。
真正关键的动作在后面：方案并没有直接交给智能体执行，而是先分发到不同业务域的负责人手上，由人判断系统边界、业务规则和技术方案是否准确，反馈被系统吸收之后，才调度研发、测试、算法和 SRE 智能体去完成开发、验证、发布与监控。人的位置从执行者换成了关键节点上的判断者。
他们把协作方式的这种变化概括为「从人找人，变成上下文找能力」。对技术负责人来说，这意味着一件事：只采购编码工具是拿不到组织级收益的，还要把需求、边界和验收标准变成机器能读的输入。
蚂蚁数字科技在 2026 年 AICon 全球人工智能开发与应用大会上给出的两组数字更硬。他们的核心判断是：AI 编码并没有创造新的软件工程问题，而是以更高的产能，把需求模糊、目标漂移、事实冲突和验证不足这些旧问题集中放大了。这场分享的完整记录里提到，一个智能体可能在一天内完成过去三个月的代码量——原本分散在几个月里的问题，被压进了一周。
他们用一套围绕约束、验证、验收建立的研发闭环（内部称 Harness）在两个项目上做了验证：
值得抄的是这个顺序。存量项目不是先上 AI，而是先把事实源修好——当代码库、文档和测试用例说的不是同一件事时，模型只会照着最像的那一份去猜，产出越多，偏差越大。把评审这一步本身工程化，站内另有一条从提示词走到产线的多智能体路径可以参考。
快手主站技术稳定性团队在 AICon 上海站补上了下游那一半。他们给出的对比是：上游研发吞吐显著提升、需求到代码的转化成本大幅降低，但线上告警、根因定位、止损决策、修复回归和经验沉淀这条链路几乎没有获得同等加速。两边速率长期不对等，线上的问题数量、严重程度和处置时延会同时变差。
他们举的安卓案例很典型。灰度阶段发现安装包体积突然多了 6 MB，排查后发现：一位开发者用 AI 生成了一段混淆配置，里面带了 -dontoptimize，并写进了 consumerProguardFiles。从那个内部 SDK 自己的角度看，这段配置是合理的——它让 SDK 正常运行了。但这个字段会随 AAR 传递到主工程，在构建时与 R8 规则合并，最终关掉了主工程的全局优化，DEX 体积随之膨胀。
这就是缺少全局上下文时的局部最优陷阱：现象消失了，问题并没有被解决。报告里还有一个数字解释了为什么前置拦截不可能兜住所有情况——安卓线上存在超过 100 种厂商 ROM、1000 多个适配机型；对强运营 App 来说，一天内由 A/B 实验、灰度和运营活动带来的变更可能超过 1 万次。没有任何测试矩阵能在离线环境穷举这些组合。
他们的应对是自建一套稳定性数字同事，聚焦排障与止损：在大前端研发中的用户渗透率接近 60%，根因分析结果的完整采纳率稳定在 50% 左右。一个只有系统堆栈的鸿蒙 C++ 崩溃案例中，它靠寄存器、业务日志和源码构建证据链，约 10 分钟定位到内部基础组件触发的释放后使用（UAF）问题，并帮团队找到了止损开关。
50% 这个采纳率值得单独看一眼。它被公开写进分享，说明团队把它当作一期可接受的水平，而不是失败。稳定性场景里，把专家经验沉淀成可持续迭代的技能包、用坏案例驱动系统进化，比追求一次性全自动现实得多。
只看产能会漏掉另一个更大的变化。2026 年 9 月 10 日，Shopify 宣布把全部移动应用从 React Native 迁回 Swift 和 Kotlin 原生开发——这是对 2020 年那笔押注的公开撤回。官方说明写得相当克制：当年全力投入跨平台框架，是因为「同样的功能不必构建两次」；到 2026 年，这个核心假设被大模型改变了。
反转不是拍脑袋。他们先让模型以 Swift 和 Kotlin 重建几个最大应用的核心部分做原型，结果超出预期：智能体可以拿 iOS 版本作参照去实现安卓版本，也能让开发者在主技术栈之外的领域有效产出。迁移路径上他们放弃了逐步过渡，选择绿地重建，理由是原型显示重建速度远快于编码智能体出现之前。第一个被迁移的 Shop 应用，团队用 12 周就从概念验证走到了完全重建并上架。
代价他们也承认：原生开发仍然要为两个平台构建和维护，这项成本没有消失，只是不再像 2020 年那样具有决定性。为了避免被高速生成的低质量代码淹没，他们没有把模型直接指向旧代码库一次性重写，而是自建了一套渐进式工作流管住这个过程——原文的说法是，即便让模型事先收集尽可能多的信息、固化成绩效说明和任务文件，最终拿到的仍然是大量无法维护、无法发布的代码。
对决策者来说，这一节的现实意义在于：当实现成本的结构被改写，2020 年前后做下的一批技术选型都值得重新算一遍账。跨平台框架、自研中间层、胶水代码，它们的性价比都建立在一个正在被修改的成本假设上。
| 研发环节 | 2026 年的实际变化 | 暴露的短板 |
|---|---|---|
| 编码 | 产能成倍提升，单个智能体可独立跑完整项任务 | 产出速度超过评审与测试的承接能力 |
| 需求与方案 | 加速幅度最小 | 需求本身含糊，目标漂移被高产能放大 |
| 代码评审 | 工具侧有增强 | 待审代码量激增，人成为瓶颈 |
| 测试与验收 | 局部提效，标准未同步升级 | 离线矩阵覆盖不全，验收条件写得含糊 |
| 线上排障与止损 | 几乎未加速 | 问题数量与处置时延同时劣化 |
可以看，但不能单独看。它衡量的是产能，而产能提升本身不产生交付价值。可行的做法是把它和评审轮次、缺陷逃逸率、变更前置时间放在一起——如果编码率涨了而后面几项没动，说明瓶颈已经转移到了下游。
需要，但形式不同。小团队先把三件事定死就够：需求必须写出可验证的验收条件、任何 AI 生成的配置类改动必须标注影响范围、每次上线前保留一条可回滚的路径。这三条成本很低，却能拦住大部分跨系统隐患。
因为它优化的是局部可运行性。前面那个混淆配置的例子就是典型：在 SDK 自己的范围内配置完全成立，但它会跨越工程边界传递到主工程，把全局优化关掉。判断标准要从「这段能不能跑」升级到「放进完整链路后是否稳定」。
新项目可以从第一天就把质量门禁内建进流程，成本最低；存量项目要先重建事实源和门禁，再引入智能体协同演进，顺序颠倒会放大偏差。前者的代表是那个 40 多万行的新仓库，后者是缺陷率从 20% 以上降到个位数的那次改造。
不是。Shopify 的选择建立在它自己的应用规模和团队结构上，而且它明确承认双端维护成本依然存在。对多数中小团队，跨平台框架省下的人力仍然是净收益。真正要判断的是：当模型能承担大量重复实现工作时，你省下的那部分人力，还值不值得用性能损失和平台能力受限去换。