AI 让开发更快，但工作去哪了？

梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

AI 已经让我的部分工作明显变快了。

在研究密集型的设计工作中，我可以从发现会议、用户测试和利益相关者对话中获取转录稿，利用 AI 帮助整理内容、提取反复出现的主题，并将信息组织成有用的东西。我可以利用同样的材料构建演示文稿或建议的基础，而不必每次都从空白页开始。原本需要数天的研究综合或演示，有时一天甚至更短时间就能完成。

我仍然需要阅读输出、质疑它、决定什么重要，并确保它讲述的故事有研究支撑。这个责任并没有消失。改变的是我在翻阅转录稿、整理笔记和格式化幻灯片上花费的时间——在我真正理解所学内容之前。

那段时间让我有更多时间停留在问题上。我可以探索另一个方向，而不是满足于第一个合理的答案；寻找我学到的东西中的空白；或者为另一轮用户测试腾出空间——当截止日期紧张时，这一轮测试可能本来会被削减。对我来说，这是有意义的生产力提升，因为节省下来的行政工作时间可以重新投入到思考、迭代和提出更好的建议中。

我也通过设计团队对编码原型的实验，看到了 AI 辅助加速的更复杂版本。对我们来说，这些原型不仅仅是展示体验应该是什么样子和如何运作。我们一直在探索开发是否可以重用原型代码的一部分作为生产的起点，而不是从头重建设计。

这种方法源于我们试图解决的一个问题。传统的设计交接会在设计和最终构建之间产生细微差异——间距偏移、响应式行为与预期不同，或者交互细节在过程中被简化。这些变化中的任何一个可能看起来很小，但它们加在一起就会形成设计债务。编码原型的部分吸引力在于有机会减少这种传话游戏。如果更多的原始设计意图能随工件一起传递，开发就不必稍后重新构建那么多决策。

这取决于我们选择如何使用编码原型。其他团队可能只将 AI 生成的原型用于探索或验证，并不期望代码本身进入生产环境。

对我们来说，复杂性出现在我们试图在实践中实现这种交接时。这段经历让我更少思考 AI 是否让特定团队更快，更多思考整个系统中的工作发生了什么变化。

1、AI 已经让我的部分工作明显变快了

我们已经知道 AI 可以让某些工作更快。我现在觉得更有用的是理解我们正在创造什么样的速度，以及围绕这些工作的努力发生了什么变化。有时工作消失了，有时它缩小了、改变了形状、转移到其他人那里，或者只是稍后才出现。

有时收益很直接，因为 AI 完全移除了部分工作。例如在研究综合中，我仍然需要解释我所看到的并决定什么重要，但我花在手动整理转录稿、分组笔记和组织原始材料上的时间少得多。任务更快了，因为部分行政工作实际上被减少了。

其他收益更难计算，因为工作并没有消失。我们开始在自己的原型到生产工作流中看到这一点。设计师创建了编码原型供开发重用，但团队并不总是有足够的技术深度来持续评估底层结构。当主要关注点仍然是体验的外观和行为时，一些问题很容易被忽视。组件结构、代码组织或响应式行为的问题可能比预期走得更远。

等到开发接手原型时，表面上看起来几乎完成的东西可能仍然很难用作起点。我们的页面已经增长到数千行代码、不清晰的组件边界，有时实现甚至不匹配设计意图。例如，一个响应式体验最终可能更像独立的自适应布局。在试图减少视觉交接差距的过程中，我们有时创造了一个不同的问题：架构交接差距。然后开发必须解释、分离、重构或重建这些工作，使其适合生产环境。设计确实更快了，但其中一些工作只是转移到了下游。

AI 也在改变工作本身的形状。我们不再手动创建每一部分，而是花更多时间指导工具、检查它产生的内容、纠正它误解的地方，并决定结果是否可靠到可以继续。创建可能花的时间更少，但审查和判断成为了工作的更大一部分。

Annie Vella 和 Kelly Blincoe 2026 年的一项纵向研究发现了专业软件工程师中的类似转变。参与者报告在许多开发任务上花费的时间减少，尤其是编写代码，而更多工作转向了指导、评估和纠正 AI 输出。研究人员将此描述为"监督性工程工作"——我一直称之为"看管"。他们的研究基于专业实践中的自我报告变化而非直接时间测量，但它为一种容易被忽视的模式提供了有用的语言描述——当我们只计算某样东西被创建得有多快时。

然后工作被推到足够远的地方，以至于其成本开始增长。小原型中的捷径可能很容易清理。在相同的结构上再构建几个功能，清理就会变得更困难，因为产品的其他部分现在依赖于它。最初节省时间的东西最终可能需要跨多个组件的重构、额外测试，或重新思考你已经构建的工作。

2、这就是速度开始变得昂贵的地方

这就是为什么我一直回到同一个问题。

工作去哪了？

局部加速可能意味着几种非常不同的结果，一旦你考虑系统的其余部分，它们的价值并不相同。

3、局部速度取决于周围的系统

让我觉得更有趣的是，同样的模式也出现在我的团队之外。

DORA 2025 年关于 AI 辅助软件开发的研究发现，AI 倾向于放大其周围的系统。强大的工作流可以让这种速度更有价值，而薄弱的工作流则可能将其转化为更多的下游摩擦。同样的研究发现，较高的 AI 采用率与改善的软件交付吞吐量相关，同时也增加了交付不稳定性。他们将其解释为团队适应速度的速度快于周围系统安全支持它的速度。

这个区别对我很重要：局部生产力和系统生产力不是同一回事。设计师可以更快地移动，开发者可以更快地生成代码，产品团队可以更快地向利益相关者展示工作概念。这些收益是有用的，但它们没有告诉我们从想法到生产的完整路径是否缩短了、稍后是否出现了更多返工，或者有多少时间转移到了验证上。周围的流程决定了更多输出是否能成为可靠的进展。

4、"足够好"到底意味着什么？

最近与同事的一次对话进一步推动了这个问题。想法是开发应该愿意接受更混乱的代码，如果 UI 看起来正确的话，将其推进，然后在问题出现时被动修复。

我理解这种直觉从何而来。如果 AI 使迭代和清理足够便宜，那么团队应该停止打磨每一个工件，就好像它需要永远存在一样，这是有道理的。对于早期探索，这可能有意义。仅用于测试想法的原型不需要与期望代码进入生产的原型相同的严格性。标准应该匹配我们打算用工件做什么。

让我困惑的是当这种思维成为默认标准时。

点击式审查可以告诉我们一个流程在表面上是否有效。它可以发现损坏的按钮、明显的布局问题或不符合预期的状态。它无法可靠地发现体验下面的问题——包括糟糕的组件结构、重复的逻辑、数据问题、访问控制错误、在代码库其他地方引入的回归，或者随着更多工作建立在其上而变得更难更改的基础。

我们已经开始看到其中一些成本出现。快速生成的代码后来对开发者和 AI 工具来说都变得更难使用。代码变得越大越乱，每次我们要求工具进行更改时，它需要处理的上下文就越多。原本快速生成的东西后来变得更慢、更昂贵来理清。

我们的回应并不是停止使用 AI 构建。我们已经开始更早地重构，添加 Markdown 指导和更清晰的护栏，并对组件结构和响应式行为更加慎重。实验仍在进行中，但 AI 周围的环境可以决定这种速度是否能在下游保持。

这就是我认为"足够好"需要一个更有用定义的地方。

原型代码不需要达到生产就绪状态，但它应该是生产有用的。

对于我所说的这种交接，这意味着代码应该结构足够好，开发可以从中提取，而不需要先理清整个东西。组件边界应该清晰。可重用的部分应该真正可重用。响应式行为应该匹配设计意图。原型不需要完全镜像生产代码库，但它应该足够接近，以保持我们通过代码构建所获得的部分速度。

严格程度也应该取决于原型预期对下游产生多大影响。我接受在可能下周就丢弃的探索性屏幕上使用更松散的代码。当结构、行为或组件打算进入生产时，我对同样的松散程度就不那么放心了——尤其是未来的工作将建立在其上时。

DORA 2025 年的研究直接谈到了这种紧张关系。报告考虑了这样一种想法：更快的 AI 辅助交付可能使不稳定性更容易被接受，因为团队可以简单地更快地修复问题。他们的发现不支持这一假设。即使吞吐量提高了，不稳定性仍然对产品性能和倦怠产生显著的负面影响。

这很重要，因为通过接受较低严格性来快速行动并不是免费的。

重要的部分是知道你在做哪一个。

5、我们实际上在衡量什么？

一旦团队开始谈论 AI 生产力，对话可能很快变得肤浅。有人说一个团队快了两倍或产出多了三倍，这个数字就成了故事。

在我重复这样的说法之前，我想知道是什么让它成为可能。团队是减少了努力、改变了流程、放宽了标准，还是将部分工作转移到了其他人身上？

METR 2026 年关于开发者生产力研究的更新显示，一旦工作流本身改变，这种测量可能变得多么不可靠。他们早期的研究发现有经验的开源开发者在使用 2025 年初的 AI 工具时更慢了，但随着开发者改变了他们会在没有 AI 的情况下执行哪些任务，有时在代理运行时做其他事情，他们的新研究变得难以解释。METR 现在认为开发者可能从更新的工具中获益更多，但表示其当前实验无法可靠地衡量这种收益有多大。对我来说有用的部分是提醒："当工作围绕工具改变时，'更快'变得更难衡量。"

这些问题很重要，因为"更快"可能只描述了流程中很小的一部分。设计师可能用一半的时间制作原型。开发者可能更快地生成代码。产品经理可能用一个下午而不是几天将研究转化为草拟的需求文档。这些都可能是真正的改进，但我更关心的是从原始想法到客户手中有用的东西花了多长时间。如果总时间没有缩短，或者质量下降到足以在以后产生更多返工，那么局部加速就需要更多背景信息。

对于领导者来说，这意味着对数字代表什么更加具体。工作流的哪个部分变快了？从想法到生产的总时间缩短了吗？质量保持了吗？下一个团队收到的东西更容易处理了吗？这些问题告诉我们的远比一个人产出的乘数多得多。

还有一个更基本的问题我认为被忽视了：

答案可能是 AI 移除了大量的手动工作。也可能是团队改变了流程、绕过了瓶颈，或者接受了不同的权衡。这些是不同的故事，它们应该导致不同的决定。

要了解 AI 是否在改善产品开发，我们需要衡量的不仅仅是使用工具的人的速度。我们需要看看他们的工作开始之前发生了什么、交接之后发生了什么，以及整个系统是否在更好地将想法转化为可靠的产品。

6、目标不是放慢 AI 的速度

我不想回到手动整理每份转录稿、从头重建每份演示文稿，或者限制编码原型——因为围绕它们的工作流仍然不完善。这些收益是真实的，这些工具能创造的速度和灵活性太有价值了，不能忽视。

现在的工作是确保系统的其他部分能够跟上。如果 AI 帮助产品开发的某个部分移动得更快，交接可能需要演变，标准可能需要变得更清晰，团队可能需要更好的方式来审查、验证和重用 AI 产生的内容。

错误将是把更快的创建视为终点线。一天内构建的原型、几分钟内生成的代码，或者一下午综合的研究，都可能是有意义的收益。重要的是这种速度是否帮助团队更快地做出更好的决策，使下一阶段更容易，并在不花费返工时间的情况下向客户提供有用的东西。

当有人说 AI 让团队更快了，我想知道什么变快了、其余工作发生了什么、以及客户是否更快地获得了价值。

原文链接: AI Is Making Product Development Faster. But Where Did the Work Go?

汇智网翻译整理，转载请标明出处