一份方案几分钟就能写完，一段代码很快就能生成，一个客服回复几秒就能给出。

但从初稿到交付，中间还要经过核对、修改、审批、测试和执行。判断AI是否提高效率，要沿着这条完整流程往下看。

2026年9月28日，微软等机构研究人员发布《Towards an AI Software Factory for Data Systems》。研究报告了特定应用工作中的效率提升，也披露了系统建设投入。

这提供了一个值得追问的问题：企业使用AI，究竟加速了哪一步，又为这一步付出了多少准备成本？

“3倍效率”，先看分母里算了什么

论文披露，内部工具链Autoperf所支持的团队，在应用工作中达到每工程师小时0.35个代码变更请求（PR）。作者估计，这一产出率约为人工开发的4.7倍、现有智能体编程工具的3倍。团队约43%的时间用于应用工作，另有57%用于基础设施建设和代码库接入。^[1]

这里至少涉及两个问题：应用阶段是否变快，以及把准备工作计入之后，团队总体产出率是多少。

若43%和57%的工时划分与0.35的统计范围一致，可以做一个简化折算：每总工程师小时的PR产出率≈0.35×43%=0.1505。

将其倒数作为平均工时指标，约为每个PR对应6.64个总工程师小时；只看应用工时，则约为2.86小时。

注：第一行产出率来自论文，其余为本文计算。工程师小时是劳动投入，不等于从提交到上线的日历时间。PR也不能直接等同于已上线且产生价值的功能。

这项折算帮助识别分母，但不能据此宣布总体效率只剩某个倍数：人工开发和其他AI工具的比较基线是否包含同样的建设投入，仍需统一。

也不能把57%的建设时间全部认定为浪费。可以复用的接口、评测和数据整理，会服务于后续任务。其成本是否值得，要继续观察复用次数和维护投入。

企业核算时可采用一个更完整的框架：

每项合格交付的劳动投入=直接处理工时+复核返工工时+持续维护工时+分摊的初始建设工时。

若只统计直接处理，就容易把成本转移误认为成本消失。

图1｜将建设与接入投入放回分母。原始比例来自论文；100小时归一化及产出率折算为本文计算。

图3｜论文第6页工时分配句的局部截图。保留英文原文；原文链接见文末来源^[1]。

局部快10倍，整体可能只快22%

可以用一个明确标注假设的情景说明这个问题。

假设完成一项工作原来需要100小时，其中AI能加速的环节占比为p，该环节提速10倍；其他环节耗时不变，暂不考虑新增复核成本、并行处理和质量变化。

新总耗时为：100×（1－p＋p÷10）。

注：本表为数学情景测算，100小时、环节占比和10倍加速均为假设，不是企业调查或微软实验数据。

第一行尤其值得注意：一个环节提速10倍，完整工作的处理速度只提高约22%。原因是原来的80小时仍然存在。

更进一步，若可加速环节只占20%，即使这个环节耗时降到零，全流程速度上限也只有1.25倍。

这意味着企业选场景时，应先了解工时分布。生成初稿很醒目，但如果大部分时间花在核对资料、跨部门等待或返工上，继续加快初稿生成，能够释放的空间就有限。

可以从一批已完成任务中记录五项耗时：资料准备、生成处理、人工复核、等待流转、返工。哪一项占比最高，哪一项又有条件被压缩，才决定下一步投入。

图2｜延伸正文测算，观察局部加速1—20倍时的全流程变化。情景假设，非企业实测。

真实实验说明，“感觉变快”需要实际计时验证

2025年7月，研究机构METR公布一项随机对照实验：16名经验丰富的开源开发者，完成246项自己熟悉项目中的真实任务。任务随机分配为允许或不允许使用AI。结果是，允许使用AI时，完成任务的耗时增加19%；开发者在实验结束后仍估计AI让自己提速20%。

这项实验只反映2025年初的工具和特定开发场景，不能直接作为2026年AI能力的结论。

但它揭示了一个测量问题：主观体验和实际耗时可能存在明显差异。

还要区分“耗时增长”与“产出率下降”。若同类、同质任务的原耗时设为100，增加19%后为119，同等工时下的产出率为：100÷119≈84.0%，即下降约16.0%。

耗时增加19%，不等于产出率下降19%。两者的分母不同。

这个历史结论也需要和后续信息一起读。METR在2026年2月更新中表示，新实验的参与者和任务存在选择效应，多智能体并行也让工时计量变得困难；机构认为AI提效可能已改善，但后续数据对改善幅度的证据很弱。

由此能提出一个实际要求：评估AI时，应同时记录总劳动投入、交付质量和任务难度。只问“用起来是否顺手”，难以判断最终效率。

5172名客服的证据：衡量解决问题，而非生成回复

《Generative AI at Work》的修订版本研究了5172名客服人员。研究发现，引入AI辅助后，以每小时解决的客户问题数量衡量，平均生产率提高15%，且不同经验和技能水平员工的收益存在差异。经验较少、技能较低的员工，在速度和质量上都有改善；最有经验、技能最高者的速度收益较小，质量有小幅下降。

这一指标比“回复生成速度”更接近业务交付：它关注客户问题是否得到解决。

不过，15%的产出率提升仍不能直接解释成15%的工时节约。在工作量和其他条件相同的简化假设下：新耗时÷原耗时=1÷1.15≈87.0%。

即完成相同数量问题所需工时约减少13.0%。这只是对平均产出率的倒数换算，不代表每位员工都能节约同样比例，也不等于可以直接减少同等比例的人员。

客服案例还提醒企业：平均值可能掩盖不同人群的收益。

若要判断工具适合怎样部署，可以按员工经验、问题类型、处理难度分组，分别比较解决率、重复来访率、升级处理率与人工投入。不能把所有人、所有任务都套进一个平均数。

微软研究、METR实验和客服研究，分别衡量PR产出率、任务耗时和问题解决率。它们不能拼成一张通用的“AI提效排行榜”。能够共同支持的判断是：提效必须对应明确的任务、质量标准和投入范围。

把数据接起来，才能知道AI为什么有效

微软论文还报告了一个具体优化案例：针对Fabric数据仓库的一个GPU计算内核，系统在数小时内产生40多个软件变体，最佳方案叠加5项优化，获得2.6倍加速。这是特定内核的结果，不能扩大为整个数据仓库提速2.6倍。

这一案例说明，评价AI方案需要有可比较的目标和测试结果。但该研究没有单独证明数据整合贡献了多少效率，不能把所有收益都归因于数据治理。

对于企业，可以从这一点推导出一套实际的数据设计：把任务、输入、行动和结果用同一任务编号关联。

注：本表为本文提出的实施框架，不是上述研究已经验证的通用方案。

例如，AI从维修记录生成处置建议，若最终维修结果没有关联回原任务，企业只能统计生成了多少条建议，难以判断哪些建议有效。关联之后，才有条件按设备类型、故障类别和数据版本比较结果。

数据整合在这里承担的作用，是让效率变化可解释、失败可追踪、经验可复用。这比单纯增加文档数量更接近业务需要。

政策把“应用验证”写进了高质量数据集建设

国家数据局2026年6月发布的《关于推进行业高质量数据集建设行动的实施方案》，提出到2028年底建设经过应用验证的行业高质量数据集，并强调数据质量验证与模型应用反馈，利用动态交互数据持续提升行业模型能力，同时推进采集、清洗、质检、测评、迭代和审计等全生命周期管理。

这是政策方向，不能据此认定企业已经完成上述能力建设。

结合前述案例，可以形成一个行业判断：数据服务的交付要求会进一步延伸到应用过程。客户需要知道数据是否适配任务、版本更新是否影响结果，以及投入后是否减少了全流程成本。

具体的服务机会可以落在三个环节：

这些是基于材料提出的需求分析，不是已经确认的市场规模或收益预测。

企业采购这类服务时，也应把验收指标落到场景上：交付速度是否改善，复核投入是否下降，质量是否保持，失败是否可以定位，建设成果能否复用。

企业提效，最终要落到合格交付

AI生成速度的提升，给企业带来了新的能力；完整流程的改进，则需要同时处理资料、目标、复核、流转和反馈。

近期微软研究提供了有价值的系统实践，但建设投入必须保留在账本中。METR的历史实验与后续更新提醒我们，测量方法也会受到工具和使用方式变化的影响。客服研究则展示了用业务结果衡量AI的一种路径。

企业真正需要积累的，是一组可以持续比较的证据：相近任务，在相同验收标准下，投入多少总工时，完成多少合格交付，质量如何变化。

当任务、过程和结果能够被关联，企业才有条件回答：AI究竟在哪一步提高了效率，这种改善又能否持续。

来源与口径说明

1. Towards an AI Software Factory for Data Systems，2026-09-28，arXiv v1。引用其特定任务、团队估计与案例，不能视为跨行业随机实验结论。
2. METR：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity，2025-07-10。16名开发者、246项任务，为特定场景随机实验。
3. METR：We are Changing our Developer Productivity Experiment Design，2026-02-24。用于说明后续测量局限，不能沿用旧结果概括当前工具。
4. Generative AI at Work，采用2024-11-06修订版本的5172人、15%口径，不混用早期版本的5179人、14%数据。
5. 国家数据局：关于推进行业高质量数据集建设行动的实施方案，网页发布于2026-06-08，文件落款2026-06-03。

本文的0.1505个PR／总工程师小时、6.64小时／PR、16.0%产出率下降、13.0%工时减少，均为标注条件下的算术换算。100小时和10倍加速表为假设测算。