Talk Is Cheap: LLM 使用的运营影响解读

背景

在之前的讨论《我是如何看待 LLM 价值的》中，作者曾对 LLM（大语言模型）的价值创造持观望态度，并主张 LLM 永远不会成为“天才”。本文是这一讨论的延续，作者在此明确表态：目前我们在软件行业中平均使用 LLM 的方式，很可能正在摧毁价值。

这一立场的转变源于作者发现了一家名为 Faros.ai 的软件开发遥测（telemetry）公司。Faros.ai 的产品能够接入 Jira、Github 和 CI/CD 流水线等常见开发工具，直接测量软件开发团队的主要运营指标。今年三月，Faros 发布了一份报告，直接对比了其客户群体中“在软件开发流程中使用 AI 的团队”与“未使用 AI 的团队”之间的交易级数据。

该样本包含 22,000 名开发者和 4,000 个团队，这是作者目前能找到的、最能直接衡量 LLM 在软件开发过程中运营影响的数据。然而，数据结果令人震惊且糟糕。

核心内容

Faros 的报告包含大量细节，但作者重点提炼了三个主要的头条结论，并深入分析了其背后的含义。

1. 开发者层面的生产力有所提升，但幅度有限

数据确实显示，个体开发者的生产力速度有所加快。这印证了作者之前的观点：LLM 确实带来了个体生产力的提升。然而，这种提升并非乐观派 AI 支持者所宣称的“10 倍”增长，而是一个更为 modest（温和/适度）的改进，最好情况下的提升幅度约为 2 倍。

警示信号：

• 部署频率下降 11%：这是一个系统级指标，直接衡量公司向客户交付价值的频率。
• 代码删除比率：作者建议读者自行解读这一指标，暗示其负面含义。

术语辨析： 作者特意区分了“生产力（productivity）”和“吞吐量（throughput）”。作为受《目标》（The Goal）一书影响的运营者，作者认为“吞吐量”应保留给整个系统的总流量，即最终成品流出系统的速度。当开发者完成任务时，功能特性（feature）并未真正交付（shipped）。因此，个体效率的提升并不等同于系统整体的交付效率。

数据局限性说明： 图表中标注的“10% 数据集”意味着只有部分 Faros 客户将遥测产品接入其 CI/CD 流水线。因此，直接的系统级数据实际上基于 2,200 名开发者和 400 个团队的子样本。作者认为该子样本足够大，足以得出关于整体分布中心的结论，尽管读者可能对此持有异议。

2. 整体系统流程在每个环节都变慢了

这是令作者感到震惊且难以用言语形容的部分，被视为对我们使用 LLM 方式的严厉指控。

• 系统吞吐量指标：这些指标直接对应系统吞吐量。从商业角度来看，系统吞吐量是唯一重要的指标，因为产品只有上线（production）才能销售。
• 前置时间激增：如果将功能特性部署到生产环境的前置时间（lead time）增加了近 5 倍，这意味着我们的运营适应性在错误的方向上发生了数量级（order of magnitude）的变化。

3. 质量指标急剧恶化

这一部分没有模糊空间可躲藏。如果这些统计数据能推广到总体人群，想象一下我们对客户产生的集体影响。缺陷在运营管道中传播得越远，对整个系统的成本呈指数级增长。

关于“高绩效组织保护论”的反驳： Faros 构建了统计模型，试图找出组织特征是否预测了更糟糕的结果。一个惊人的观察结果是：

DORA 的《2025 年 AI 辅助软件开发状态报告》得出结论：AI 放大了现有的优势和劣势，强大的工程基础可以抵御 AI 的负面影响。然而，我们的遥测数据（源自数千个团队的工程系统）并不支持这一保护因素。高绩效的工程组织正在经历与其他人相同的下游恶化。

量化影响：我们到底损失了多少价值？

作者重申，只有能兑换成金钱的“成品”（即不产生浪费和返工的低质量系统吞吐量）才真正重要。在软件领域，这意味着交付到生产环境且不破坏系统的功能特性。

基于 Faros 数据（结合附录中的建模，受限于上述 10% 的数据 caveat）， headline results（主要结果）如下：

• 缺陷率增加：使用 LLM 的 Faros 客户，平均每位开发者的缺陷率增加了 50%。
• 系统吞吐量下降：使用 LLM 的 Faros 客户，平均系统吞吐量下降了 71-80%。

关键要点

• 个体效率 vs 组织效能的悖论：存在四条高质量的信息线描述 LLM 对软件产品开发运营的影响（直接生产力研究、Shovelwear 数据、2024-2025 年 DevOps 状态报告、Faros 2026 客户指标）。它们描绘了一幅一致的画面：人们在个体层面体验到 LLM 带来的生产力红利，但在组织层面，这种红利并未显现。
• 价值毁灭而非创造：在最好的情况下，这些影响对成品（完成的功能特性）吞吐量是中性的；在最坏的情况下（由最细致、最直接的数据支持），这些影响正在减缓系统吞吐量，即** actively destroying value（积极摧毁价值）**。
• 质量无“最好情况”：对于质量而言，不存在最好或最坏的情况。数据是不含糊的：我们对 LLM 的使用正在摧毁产品质量，进而摧毁企业价值。
• 反驳“电气化类比”：
  • Azeem Azhar 的观点：Exponential View 的评论员 Azeem Azhar 认为，个体生产力与组织效能之间的二分法是一个部署问题。他类比电网的部署，认为新技术需要时间让组织学习如何正确使用（电力行业花了约 30 年才在总体生产力统计中显现效果）。
  • 作者的反驳：作者认为这一类比是错误的。历史上每次革命性新技术（制造机械、管道、飞机、电力、计算机、互联网等）的普及，都伴随着可靠性的增加趋势。每一项基础技术都从不可靠开始，最终走向极高可靠性。而目前 LLM 的使用并未体现这一趋势，反而导致了可靠性的急剧下降。

意义与影响

这篇文章对当前盲目推崇 AI 辅助开发的行业氛围提出了严峻挑战。其核心意义在于揭示了微观效率提升与宏观系统失效之间的巨大鸿沟。

1. 重新评估 AI 投资回报（ROI）：企业不能仅看开发者编写代码的速度（个体生产力），必须关注从代码提交到生产部署的全链路效率（系统吞吐量）以及上线后的稳定性（质量）。如果部署频率下降 11%、系统吞吐量下降 71-80%、缺陷率上升 50%，那么个体编码速度的提升毫无意义，甚至是一种负资产。
2. 工程基础的重要性被低估：DORA 报告认为强大的工程基础可以保护组织免受 AI 负面影响，但 Faros 的数据直接反驳了这一点。即使是高绩效工程组织，也未能幸免于 LLM 带来的系统性恶化。这表明问题可能不在于组织基础薄弱，而在于 LLM 本身在当前工作流中的整合方式存在根本性缺陷。
3. 对“技术成熟曲线”的反思：Azeem Azhar 等思想家试图用历史技术（如电力）的成熟曲线来安慰业界，认为这只是暂时的阵痛。但作者指出，历史技术的共性是可靠性随时间递增，而当前的 LLM 应用却表现出可靠性的指数级下降。这暗示 LLM 可能并非像电力那样的“基础基础设施”，而是一种需要彻底重构工作流、甚至可能无法通过简单适应来解决的新型风险源。
4. 行动呼吁：软件行业需要停止仅仅关注“Talk”（宣传 LLM 带来的个体速度提升），转而关注“Operational Impact”（运营影响）。如果无法解决部署频率下降、缺陷率上升和系统吞吐量暴跌的问题，LLM 的使用就是在系统地摧毁软件企业的核心价值。