AI时代，软件研发的本质变了吗？
过去两年，软件行业对AI的关注持续升温。软件从业者一方面在追踪各种能力越来越强的工具，另一方面也在借助AI不断提升个人效率。局部看，这种变化已经非常明显；但如果放到企业级的软件研发过程里看，AI带来的整体提效却没有那么显著。
这种反差其实很值得思考。今天大家对AI辅助软件研发已经并不陌生，很多团队都已经在不同程度上使用AI参与日常工作。有人用它辅助开发代码，有人用它辅助测试，有人用它整理文档、分析需求、归纳信息、生成原型。对于个体来说，这种帮助是非常直接的，很多原本要花费不少时间的工作，现在都能更快完成。
但如果把视角从个人工作体验切换到企业级的软件交付过程，情况就没有这么简单了。一个需求从业务提出，到分析、设计、实现、测试、验收，再到最终上线，往往要穿过多个角色、多个系统、多个团队之间的协作链路。站在整个过程回头看，会发现AI虽然显著提升了局部工作的执行效率，却并没有让整体交付过程出现同等幅度的提速。
为什么会这样？如果顺着这个问题继续往下想，会发现软件研发的本质，也许并不是很多人直觉上认为的 coding，而是一个将业务持续转换为软件表达形式的过程。在这个过程中，真正关键的并不是代码生成本身，而是知识如何在不同角色之间被理解、传递、校准，并最终沉淀为可运行、可验证的软件行为。
AI提效，到底体现在哪里
AI 在软件研发中的价值，核心体现在执行层。
当问题已经被定义清楚，目标明确，输入充分，规则和边界也相对完整时，AI 对执行动作的提效非常直接。无论是实现、测试、分析、设计，还是文档和信息处理，只要问题本身足够清楚，AI 的效率优势就会非常明显。
如果借助 Cynefin 框架来理解，这件事会更容易说明。对于 Obvious 的问题，因果关系清晰，处理方式明确，AI 天然非常适合；对于一部分 Complicated 的问题，只要问题能够被拆解、规则能够被说明清楚，AI 同样能提供很强的支持，甚至直接完成交付级产出。
但软件交付并不只由这两类工作组成。真正影响交付效率的很多环节，其实属于 Complex 范畴。它们没有办法在一开始就定义完整，很多理解必须在协作中逐步澄清，很多问题只能在推进过程中不断暴露和修正。也正因为如此，AI 虽然已经大幅优化了执行层动作，但这并不意味着整个软件交付系统会自然按同样幅度提速。
为什么局部提效，没有自然变成整体提效
软件交付从来都不是一条简单的流水线，而是一个跨角色协作、持续校准的过程。
一个业务想法提出之后，通常要经过需求分析、方案判断、实现、验证和验收等多个环节。每往前推进一步，都依赖前一个环节传递过来的理解足够准确。而在这个过程中，真正消耗时间的，往往不是“谁做得慢”，而是“大家对得慢”。
这也是软件研发中最核心、也最容易被低估的成本：知识传递成本。
一个需求从业务意图到最终系统行为，中间通常会经历很多次翻译。业务诉求要被转成需求定义，需求定义要被转成方案判断，方案要被转成实现代码，实现结果又要被转成验证场景，最后再通过验收判断系统是否真正满足业务目标。每一次翻译都可能发生偏差，一旦某个环节理解不准确，后面的工作做得越快，可能只是越快地把偏差传递下去。
团队当然也已经意识到了这条链路本身的低效，所以这些年一直在尝试缩短它，而且有些做法已经相当极致。比如，BA 和 Dev 直接跟业务讨论需求，需求聊清楚后就直接进入代码实现和自动化测试，尽量减少中间环节的传递损耗。这个方向是合理的，本质上是在用更短的链路换更少的理解偏差。
但问题在于，软件交付中的低效并不只来自角色拆分本身。受限于传统软件开发流程的约束，很多沟通、协调、确认、验收相关的工作，依然需要专门的角色来完成。更重要的是，真正复杂的部分，往往出现在系统集成和多方协同中。一个功能如果涉及多个系统、多支团队、多方职责边界，问题就会迅速变复杂。时间上对不齐，目标上对不齐，方案上对不齐，再叠加人员轮换、组织调整、上下文缺失，整个交付过程就会变得非常低效。
很多时候，不是某个人不会做，也不是代码写不出来，而是多方协同没有办法在同一个时间窗口内形成高质量共识。这类问题很难仅靠 AI 的执行能力去解决。因为它们的核心不在于生成代码或自动化测试，而在于如何达成一致、如何拆分责任、如何处理依赖、如何校准方案。这些事情本质上都属于复杂协作问题，而不是单点执行问题。
所以，AI 为什么没有让整体交付同比例提速？因为它主要提升的是局部环节的执行效率，而软件交付真正的系统性瓶颈，很多时候在于跨角色、跨团队、跨系统之间的知识传递和协同对齐。
软件研发的本质，不是coding，而是业务翻译
如果把软件研发理解成“把功能写出来”，那么 AI 确实已经改变了很大一部分工作方式。但如果把软件研发理解得更完整一些，会发现 coding 只是其中的一个环节，而且未必是最难的那个环节。
软件研发真正做的事情，是把业务世界中的目标、规则、限制和例外，持续不断地翻译成软件系统中的结构、流程、状态和行为。代码只是最终承载这些内容的一种表达形式，而不是整个研发活动的本体。
真正困难的地方，往往在 coding 之前，也在 coding 之外：业务目标到底是什么，边界条件如何定义，多系统职责如何划分，方案为什么要这样设计，什么结果才算真正满足业务预期。这些问题如果没有想清楚，coding 再快也没有意义。因为最终产出的，很可能只是一个实现完整、但方向不对的系统行为。
从这个角度看，软件研发的本质并不是简单写代码，而是一个持续的知识转换过程。业务知识需要被抽象，需求需要被澄清，方案需要被校准，实现需要被验证，最终才能变成真正可交付的软件行为。真正决定交付效率和交付质量的，也不是单点动作有多快，而是这整条知识转换链路是否足够顺畅、足够准确。
写在最后
这两年看 AI 辅助软件研发，最大的感受是：它确实显著改变了执行层效率。
但再往深处看，会发现企业级的软件交付并没有因为执行变快就自动变成一条高速通道。因为软件研发从来都不只是写代码，而是在持续地把业务知识转换为软件表达。而这个过程最昂贵的部分，并不是生成代码本身，而是知识在不同角色、不同团队、不同系统之间传递时的损耗。
所以，如果要问 AI 时代软件研发的本质变了吗，我的答案是：变的是执行层，不变的是本质。AI 正在让 coding 越来越便宜，但软件研发中真正昂贵的部分，从来都是知识传递。
注
本文由我与 Codex 协作完成，配图使用 Gemini 生成。