软件研发的第三种范式:不是让 AI 写更多代码,而是让工作长出

——从传统软件研发、AI驱动研发，到AI原生能力研发

引言：一个值得思考的场景

假设你是一名普通的企业员工。

今天，你需要完成一份复杂的供应商分析报告。

你打开企业 AI 平台，把需求告诉 AI。

AI 给出了第一版结果，但你觉得不对，于是继续补充要求、修改分析口径、调整数据结构。

AI 重新分析，你又发现一些问题，再次纠正。

如此反复。

三个小时过去了。

经过十几轮甚至几十轮沟通，你终于得到了一份满意的报告。

到这里，事情并没有什么特别。无非是一个人使用 AI，提高了工作效率。

但接下来发生了一件有意思的事。

你对 AI 说：

“请回顾我们过去三个小时的沟通过程，分析其中的探索、试错和修正，提炼真正有效的方法，把它整理成一个以后可以反复使用的 Skill。”

AI 开始回顾整个工作过程，整理任务目标、输入要求、有效步骤、判断规则、异常处理方法和输出标准，形成一份可复用的 Skill 草稿。

经过测试与修正，一个新的 Skill 诞生了。

下次遇到类似任务，你不需要再从头探索，而是直接调用这个 Skill。

你的同事也可以使用它。

如果越来越多的人使用，企业还可以继续完善它，形成不同版本，甚至将它开发成一个稳定的软件工具。

仔细想想，这个过程有什么不同？

你最初并没有提出一个软件开发需求。

没有立项，没有产品经理，没有安排程序员，也没有计划开发一个新系统。

你只是想完成今天的工作。

但在完成工作的过程中，你不仅获得了工作成果，还沉淀了一项可以长期复用的数字能力。

更重要的是，这种能力还有机会被共享、组合、迭代，甚至逐步演化成真正的软件。

这让我开始重新思考一个问题：

AI 时代的软件研发，是否正在出现第三种范式？

一、第一代：传统软件研发——人开发软件，工具执行自动化

先澄清一个容易产生误解的概念。

传统软件研发，并不意味着没有自动化。

恰恰相反，经过几十年的发展，软件工程早已拥有相当成熟的自动化体系。

从编译、构建、部署，到自动化测试、CI/CD、DevOps，再到代码生成器、脚本和各种研发工具，自动化几乎贯穿软件研发的全部过程。

一家成熟的互联网公司，其研发自动化水平可能非常高。

但这些自动化有一个共同特征：

自动化的规则和执行逻辑，基本上是人设计和编写的。

例如，一个自动化测试脚本可以执行几千次、几万次测试。

但测什么、如何测、如何判断结果，通常需要人来定义。

一个 CI/CD 流水线可以自动完成构建、测试和部署，但流水线本身的逻辑，也是工程师设计和维护的。

传统研发的典型流程是：

需求调研及管理 → 用户评审（必要时包含交互原型）→ 研发与技术方案评审 → 编码开发 → 测试 → 发布 → 运行维护。

在这个过程中，人类工程师承担大量认知工作：

• 理解业务需求，并把模糊需求转化为明确的问题；
• 设计业务流程、数据结构和系统架构；
• 编写代码与自动化脚本；
• 判断异常、处理复杂问题；
• 协调各个环节，最终完成软件交付。

因此，传统软件研发的核心特征，不是“人工操作多”，而是：

人负责理解、设计和创造，工具按照人的设计执行。

即使自动化程度很高，软件研发仍然主要依靠人的认知能力和工程能力来推进。

二、第二代：AI 驱动研发——AI 深度参与软件生产全过程

大模型和 AI Coding 工具的出现，正在改变上述分工。

与传统自动化不同，AI 开始直接参与过去由人承担的认知工作。

例如，今天的软件研发已经可以形成这样一条新的工作链：

AI 记录需求沟通 → AI 整理和分析需求 → AI 辅助业务建模 → AI 生成高保真原型 → Spec 确认和评审 → AI Coding → AI 辅助验证与测试 → 发布。

这里的变化绝不是简单的代码自动补全。

AI 已经可以深入参与软件研发的多个环节。

在需求阶段，AI 可以记录业务访谈、分析需求、发现矛盾、整理业务规则，辅助建立业务对象及其关系模型。

在设计阶段，AI 可以快速生成高保真原型，让过去需要大量文字沟通的需求，变成能够直接讨论和修改的界面。

在开发阶段，AI Coding 可以根据经过确认的原型、Spec 和工程上下文，生成大量代码，辅助完成重构、调试和技术方案实现。

在测试阶段，AI 可以辅助生成测试用例、分析代码变更、识别潜在风险和定位错误。

这是一种真正的人机协同研发。

人不再需要亲自编写每一行代码、每一份文档、每一个自动化脚本。

AI 可以承担大量具体的智力劳动。

当然，人在其中依然不可或缺。

业务目标需要人确认，复杂架构需要人判断，安全边界需要人把控，最终交付质量需要有人负责。

但随着模型能力和工程工具不断成熟，人与 AI 的具体分工也会持续变化。

我倾向于把这个阶段称为：

AI 驱动研发（AI-Driven Software Development）。

它与传统软件研发的最大区别，是 AI 已经从工具的执行者，逐步成为研发过程中的智能参与者。

然而，如果仔细观察，你会发现：

第二代虽然极大改变了软件研发的过程，却没有从根本上改变软件需求的产生方式。

业务提出需求。

研发团队理解需求。

人与 AI 协同开发软件。

最后交付给业务使用。

软件仍然是核心交付物。

AI 主要改变的是软件如何被生产出来。

这与第三代存在一个非常关键的区别。

三、第三代：AI 原生能力研发——工作本身成为能力生产过程

现在回到文章开头的例子。

一个员工花了三个小时，通过与 AI 的持续沟通，完成了一项真实工作。

期间经历了多次探索、失败、纠正和调整。

最终，他获得了两个结果。

第一个结果：工作已经完成，价值已经产生。

这是即时收益。

第二个结果：工作方法被提炼出来，形成了可以复用的 Skill。

这是长期收益。

这里发生了一个非常重要的变化：

不再是为了完成工作而先开发软件，而是在完成工作的过程中，逐步形成可以复用的数字能力。

过去，我们通常把业务工作和软件研发看成两个相对独立的过程。

业务人员负责使用软件完成工作。

研发人员负责开发软件。

现在，企业员工在使用 AI 完成日常工作的过程中，就有可能同时参与数字能力的创造。

业务人员不一定需要掌握编程。

他可能只是不断向 AI 表达自己的想法、判断结果、提出修改意见。

但这些持续的人机交互，实际上包含了大量有价值的信息：

什么是目标？

什么样的结果才算正确？

哪些方法有效？

哪些尝试失败了？

遇到例外情况如何处理？

如何判断结果是否达到要求？

这些信息原本分散在一个人的工作经验和探索过程中。

现在，它们有机会被 AI 提炼、结构化，并形成可执行的能力。

我认为，这就是第三代范式的起点。

真实工作产生价值，工作过程沉淀经验，经验进一步转化为可复用的数字能力。

这里的核心不再只是“如何开发软件”，而是：

如何让企业员工在完成工作的同时，持续创造和积累组织的数字能力。

四、一个重要概念：能力蒸馏——从工作经验到 Skill

在机器学习领域，有一个概念叫“知识蒸馏”。

它通常指通过教师模型的知识或行为训练学生模型，实现能力的迁移。

这里可以借用“蒸馏”的思想，但需要注意，两者并不完全相同。

我们讨论的并不是必须重新训练一个大模型，而是：

通过 AI 分析和提炼人的工作过程，将部分隐性经验转化成明确、可复用、可执行的能力。

不妨称之为：

能力蒸馏（Capability Distillation）。

例如，一位经验丰富的采购人员，可能非常擅长供应商报价分析。

他知道如何统一价格口径，如何识别异常报价，如何考虑交期、账期与质量风险。

但是这些经验，可能一直停留在他的头脑中。

如果通过与 AI 的长期协同工作，把其中有效的判断方法、操作步骤和例外处理规则整理出来，就有机会形成一个“供应商报价分析 Skill”。

这个 Skill 不一定只是一段提示词。

它还可以包含：

• 任务目标与适用范围；
• 所需的数据和输入条件；
• 标准操作步骤与判断规则；
• 可调用的工具、脚本和数据接口；
• 异常情况及处理方法；
• 输出格式、质量标准和测试样例。

经过测试确认后，它就可以成为一项可复用的能力。

当然，真实工作记录并不等于有效经验。

三个小时的沟通中，可能有错误信息、无效尝试，甚至一些偶然成功的结果。

因此，能力蒸馏不能只是把聊天记录做一次总结。

必须区分成功方法与失败路径，明确适用边界，经过验证后才能形成稳定的 Skill。

这一点非常重要。

Skill 的价值不在于把工作过程记录下来，而在于把其中真正有效的能力提炼出来。

而且 Skill 也应该像软件一样拥有版本。

Skill v1.0、v1.1、v2.0……

随着实际使用、反馈和修正，能力本身可以持续迭代。

一个人的经验，就这样有机会逐步变成多人共享的组织能力。

五、从 Skill 到软件：软件可能不再完全从需求开始

如果 Skill 只能帮助个人提高工作效率，那么它仍然只是一种个人生产力工具。

真正有意思的是下一步。

当越来越多员工在企业 AI 平台上使用 Skill，企业会逐渐积累一批可复用的能力。

这些 Skill 的使用情况，本身还可能提供新的需求线索。

例如：

某个 Skill 每个月被调用数百次。

很多员工都在使用。

任务输入相对稳定，处理步骤高度重复，结果也容易验证。

但它每次运行都需要调用大模型，消耗 Token，并且执行时间较长。

这时，一个新的问题出现了：

是否值得把这项能力进一步固化为一个软件工具？

如果采用传统方式，企业可能需要先调研需求、证明业务价值，再进行软件开发。

但现在，这个 Skill 本身已经经历了大量真实使用。

哪些人需要它、解决什么问题、使用频率如何、哪些地方容易出错，都有机会通过授权的使用数据和业务反馈得到验证。

于是，它就具备了进一步软件化的基础。

当然，不是所有 Skill 都应该开发成软件。

对于低频、变化多、探索性强的任务，继续由 AI 动态执行可能更合适。

对于高频、规则稳定、执行成本高的任务，则可以考虑固化为程序、服务或专用工具。

对于跨多个步骤、需要调用不同系统的任务，可以把多个 Skill 组织成 Workflow 或 Agent。

对于涉及多个部门、多个角色的复杂业务，还可以把不同能力组合起来，再通过工程化形成更完整的业务应用。

但这里必须强调：

复杂软件不是把多个 Skill 简单串联起来。

真正的企业级软件，还需要统一业务模型、数据结构、权限管理、事务一致性、异常处理、系统架构及持续维护。

Skill 可以成为能力来源和需求发现入口，却不能自动替代成熟的软件工程。

这意味着，第三代并没有否定第二代。

恰恰相反，当某项能力需要被工程化为稳定的软件时，可以重新进入第二代的 AI 驱动研发流程：

Prototype → Spec → AI Coding → 测试 → 发布。

于是，两种机制开始连接。

一边是人在日常工作中持续创造新能力。

另一边是企业根据这些能力的价值、成熟度和使用情况，决定哪些应该复用、哪些应该组合、哪些值得进一步软件化。

传统软件研发主要从需求出发，形成软件。

AI 原生研发则增加了另一条路径：

从真实工作出发，先形成可复用能力，再根据需要逐步演化为软件。

六、从项目交付到持续进化：企业数字能力的生长飞轮

如果把上述过程连接起来，就会形成一个新的循环。

真实工作 → 人机协同 → 经验提炼 → Skill 形成 → 共享复用 → 需求洞察 → Agent 或软件化 → 业务反馈 → 能力迭代。

它与传统软件研发有一个非常明显的区别。

传统研发通常围绕一个项目开展。

项目有明确的需求范围、开发周期和交付节点。

软件上线之后，再通过新需求和版本升级持续演进。

但第三代可以增加一种更连续的能力生长机制。

因为人的日常工作并不会停止。

今天有人探索出一个新方法。

明天有人把它改进成 Skill。

后天有人发现它可以与另一个 Skill 组合。

再后来，一批高频 Skill 被工程化成稳定工具。

某些工具又逐步成为大型业务应用的一部分。

在这个过程中，企业的数字能力不再完全依赖一个个正式立项的软件项目。

它可以从日常工作中不断产生新的能力，再通过筛选、复用、组合和工程化逐步成长。

这种过程，很容易让人联想到生物进化。

新的能力不断产生，经过实际工作检验，有价值的得到保留和改进，低价值的逐渐退出。

不同能力相互组合，还可能形成原来没有预料到的新用途。

但这不是说 AI 可以不受控制地自我演化。

企业需要通过测试、评测、人工审核、版本管理和运行反馈，确保能力的可靠性与安全性。

它更像是一个有治理、有选择、有反馈的数字能力进化系统。

从这个角度看，企业 AI 平台有机会形成一个长期运转的能力生长飞轮。

七、企业 AI 平台：第三代范式不可缺少的基础设施

前两代研发的核心生产组织，主要是产品、研发、测试、运维等专业团队。

第三代则有一个非常大的变化：

企业员工在使用 AI 完成工作的同时，也有机会成为数字能力的创造者。

这意味着，参与能力生产的人群，从专业研发团队扩展到更多业务岗位。

但要实现这一点，仅仅采购一个大模型账号，或者给员工部署一个 AI 聊天工具，是远远不够的。

真正的企业 AI 平台，需要承担几项重要职责。

第一，统一 AI 工作入口。

员工可以通过网页聊天、桌面 APP、企业 IM、IDE 等方式使用 AI。

不一定所有人都使用相同的客户端，但底层最好能够按照企业规则统一管理模型、身份、权限和服务。

第二，支持工作过程的能力提炼。

对于获得授权的 AI 工作会话，平台能够保留必要的任务上下文、交互过程及结果反馈。

在员工主动触发或经授权的情况下，辅助分析工作过程，将有效经验提炼成 Skill 草稿。

第三，形成企业 Skill 能力资产库。

对 Skill 进行分类、版本管理、评测、审批、发布、共享、权限控制和生命周期管理。

个人 Skill 可以自用。

经过验证和授权后，可以发布为团队 Skill。

成熟的能力还可以升级为企业级共享 Skill。

第四，支持能力组合与软件化。

平台能够帮助员工调用已有 Skill，组合复杂任务，并辅助识别适合形成 Agent、工作流或独立软件的能力。

第五，建立完整的管理与安全体系。

这部分尤其重要。

企业 AI 平台需要管理模型路由、Token 配额、调用成本、数据权限、敏感信息脱敏、操作审计以及外部工具访问。

与普通聊天应用相比，这些能力不再是可有可无的附加功能，而是企业级平台的基本要求。

特别是工作过程的记录与分析，必须有明确的数据边界。

不能简单地把所有员工的聊天记录、工作文件和个人信息无差别地纳入所谓的“能力蒸馏”。

哪些数据可以采集、哪些可以用于知识提炼、哪些 Skill 可以共享、哪些动作需要人工批准，都必须有清晰规则。

否则，能力积累越多，安全和管理风险也可能越大。

第三代研发降低的是能力创造的门槛，并没有降低组织治理的重要性。相反，它可能对数字化基础设施提出更高要求。

八、重新理解三代研发：真正变化的是什么？

现在，我们可以把三代研发放在一起重新审视。

第一代：传统软件研发

核心是人主导软件生产。

人理解需求、设计方案、编写代码和自动化工具，最终交付软件系统。

成熟的软件工程方法和自动化体系保障复杂软件的稳定交付。

第二代：AI 驱动研发

核心是 AI 深度参与软件生产。

AI 进入需求分析、业务设计、原型、编码、测试与交付全过程，大量承担原本需要人完成的认知工作。

软件研发的效率、方式以及人与工具之间的分工发生明显变化。

但业务需求仍然主要通过明确的沟通、分析和评审进入研发体系。

第三代：AI 原生能力研发

核心是工作本身成为数字能力的来源。

员工直接通过 AI 完成真实工作，在获得即时收益的同时，将有效经验提炼为可复用的 Skill。

Skill 不断被共享、组合、验证和迭代。

部分高频、有价值的能力进一步演化为 Agent、工作流或软件系统。

由此，组织获得了一条不完全依赖传统软件需求立项的数字能力生产路径。

这里需要说明，所谓“三代”是一种便于分析的范式划分，并不意味着严格的历史年代交替。

今天的企业完全可能同时存在三种模式。

传统软件工程仍然不可替代，AI 驱动研发还会不断发展，AI 原生能力研发则为企业增加了一条新的能力生产路径。

第三代不是替代前两代，而是把软件研发纳入一个更大的组织能力生长体系。

九、一个更深层的判断：企业数字化可能从“建设系统”走向“生长能力”

过去，我们衡量企业数字化建设，常常关注：

上线了多少套系统？

交付了多少个项目？

完成了多少项功能？

这些指标当然重要。

但如果 AI 原生能力研发真正成熟，未来可能还需要关注另一组指标：

企业员工通过 AI 完成了多少实际工作？

有哪些有价值的经验被沉淀下来？

有多少 Skill 真正被反复使用？

个人经验有多少转化为了组织共享能力？

从实际工作中发现了多少值得软件化的新需求？

这些能力究竟为企业创造了多少经营价值？

这可能改变我们看待企业数字化的方式。

过去，企业数字化能力主要通过软件采购、系统建设、集成实施和持续开发逐步积累。

未来，企业还可能通过员工与 AI 的日常协同工作，持续生产和积累一部分数字能力。

从买软件、建软件，到在工作中持续生长软件与能力。

这是一个值得认真研究的方向。

它还意味着，企业 AI 平台的价值不只是节省员工时间。

更大的潜在价值，是帮助企业把分散在不同岗位、不同人员身上的部分经验与方法，逐步转化为可复用、可维护、可持续改进的组织资产。

当然，这条路并不容易。

并不是所有人的经验都正确，也不是所有任务都能被 Skill 化，更不是所有 Skill 都有长期价值。

真正的挑战，在于如何识别有效能力，如何建立质量标准，如何进行权限与安全治理，以及如何让能力真正被组织持续使用。

这也是为什么 AI 原生能力研发不仅仅是技术问题，更是组织管理和数字化治理问题。

十、结语：不是 AI 替人开发软件，而是工作开始生长软件

回顾三代研发，可以看到一条有意思的演变路径。

第一代：人开发软件，让软件帮助人完成工作。

第二代：人与 AI 协同开发软件，让软件更快、更高效地被创造出来。

第三代：人与 AI 协同完成工作，让工作过程本身持续创造新的数字能力。

第一代的关键资产是软件代码、工程方法和系统。

第二代在这些基础上，引入 AI 的理解、推理和生成能力，重塑软件生产过程。

第三代则进一步把数字能力生产的起点，从专业研发活动延伸到了企业日常工作。

一个人可能只是为了完成今天的任务，却在过程中探索出了明天还可以使用的方法。

这种方法被提炼成 Skill。

Skill 被其他人复用、改进和组合。

一部分能力逐渐成熟，最终成为稳定的软件工具，甚至复杂业务系统的一部分。

它的独特之处，在于工作成果与能力资产可以在同一个过程中产生。

今天完成工作，今天就有收益；今天沉淀能力，明天还可以持续受益。

如果把企业的真实工作看作源源不断的输入，把 Skill、Agent 和软件看作不断生长的数字能力，那么一个新的问题便浮现出来：

未来企业数字化建设的重点，会不会从“我们还需要开发什么软件”，逐步扩展为：

“我们每天都在完成大量工作，如何让这些工作不仅产生当下的业务价值，还能持续沉淀成整个组织的数字能力？”

我认为，这正是 AI 原生数字化值得探索的方向。

它不是简单地让 AI 写更多代码。

而是让数字能力从真实工作中生长出来，再反过来帮助人更好地工作。

当工作与能力形成持续反馈、相互促进的循环时，企业数字化就有机会从以项目交付为主的建设方式，逐步形成持续积累、复用和进化的组织能力。

这或许才是 AI 给企业软件研发带来的更深层变化。