为什么越来越多的软件被“用完即弃”？

在很长一段时间里，软件在企业中的地位几乎没有被质疑过。

一套系统一旦上线，就意味着长期运行。ERP、CRM、MES、PLM 等核心系统，往往以五年甚至十年为周期来规划。开发和实施成本高昂，但只要使用时间足够长，这种投入就被视为合理。

软件因此被默认为一种需要“摊薄成本”的长期资产。

但近两三年，一种与这一逻辑明显不一致的现象正在频繁出现，越来越多的软件，并未被设计为长期存在。

有人为一次活动搭一个应用，用完即弃；业务部门为应急需求快速做一套系统，任务结束后整体重写；AI 生成的工具版本被高频替换，而不是持续维护。

这些做法在传统软件观念中显得不够严肃，却正在成为大量企业的真实选择。

这些变化指向一个正在加速、却仍被低估的趋势：软件正在从“耐用品”走向“快消品”。它不再默认长期存在，而是围绕具体任务被快速生产、快速消耗。

推动这一转向的，是软件生产成本、组织方式与商业模式的同步变化。

01

从反直觉现象看起：

软件为什么开始“用完即弃”

如果回到十年前，许多今天已司空见惯的做法几乎难以成立。

a16z 创始人曾分享过一个案例：有人用零代码工具为朋友的生日聚会开发了一个专属 App，用于展示信息和扫码签到，聚会结束后即删除；还有一位母亲开发了 News for Dinner，只服务于一个家庭，用来筛选适合晚餐讨论的新闻话题。

这类应用规模极小、生命周期极短，但真实存在。

在企业端，同样的现象正在大量出现。

业务部门为了应对一次促销活动、一个旺季周期、一条临时产线或一次监管检查，快速搭建内部系统。任务完成后，这些系统被直接弃用，或在下一个周期整体重构，而不是进入长期维护状态。

如果沿用传统软件逻辑，这种行为看起来并不“经济”。

但前提已经发生改变。零代码平台、AI 代码生成和云资源按需计费，使软件开发的时间成本和资金成本同时下降。当开发一个系统的成本，从“数十万、数月”下降到“几百元、几天”，大量原本不值得被系统化的需求开始浮出水面。

这一变化可以用“杰文斯悖论”来理解。当资源利用效率显著提升时，总消耗量往往不降反升。AI 让代码生产极其廉价，并不会减少软件开发，反而推动软件进入更多原本无法覆盖的场景。

结果是，软件数量快速膨胀，而单个软件的生命周期却在不断缩短，逐步呈现出快消品的特征。

02

四个正在同时发生的结构性变化

“软件消费品化”已经在多个层面落地，同时发生在生产方式、组织结构、开发工具和商业模式之中。

第一，软件正在从系统形态转向任务形态。

在多智能体平台中，软件不再以长期运行的系统存在，而是以完成一次任务的能力出现。

蚂蚁百宝箱 Tbox、360 智能体工厂的实践表明，用户输入目标后，平台会自动拆解任务、调度不同智能体协同完成。交付物往往是一份报告、一条视频或一次执行结果，而不是一个需要持续维护的应用。

制造业中的实践更具说服力。

美的在洗衣机工厂部署的智能体体系，覆盖质检、排产、混线生产等多个环节。多个智能体以秒级响应完成原本需要人工小时级处理的任务，完成后即进入下一次调用。

这里的软件，本质上是被反复消耗的生产要素，而非固定资产。

第二，业务部门开始主导系统搭建。

低代码和无代码平台的普及，正在改变企业内部的软件权力结构。

Gartner 与 IBM 的研究均指出，2025 年前后，约 70% 的新应用将通过低代码或无代码方式完成。国内平台如简道云、轻流，已支撑百万级企业用户。

在实践中，这类系统多强调“阶段可用”而非“长期完美”。零售企业用无代码平台快速搭建库存系统以应对阶段性波动，制造企业为特定产线配置临时管理工具，促销或旺季结束后直接下线重构。这些系统并未被视为长期资产，而是一次性投入后的自然退出。

第三，AI 开发工具正在改变维护与重写的成本对比。

在 AI 辅助开发环境中，越来越多团队发现，整体重写往往比持续维护更划算。某互联网公司引入 AI 开发工具后，将原本约 90 天的开发周期压缩至 30 天，多个内部系统在一年内经历多次整体替换。这是成本结构变化后的理性选择。

第四，结果付费正在为短生命周期软件提供商业合理性。

按功能或席位收费，建立在长期使用前提之上。

当软件本身可能只服务一个阶段，企业更愿意为可量化的业务结果付费。AI 客服按销售提升分成、工业设备按产出计费，本质上都是在为“完成一次任务”买单。这种模式，天然匹配一次性软件的存在方式。

03

To B 软件行业正在承受的四重冲击

当软件形态发生变化，行业沿用多年的运行逻辑与价值共识开始整体松动。这种变化同时作用于产品判断、研发组织、商业模式和客户关系，对整个 To B 软件行业形成系统性冲击。

首先，传统“好产品”的判断标准正在失效。

过去，To B 软件的优劣往往围绕架构是否优雅、系统是否具备长期可扩展性、代码是否易于维护展开。这套标准建立在软件需要长期运行、不断叠加功能的前提之上。

但在大量以任务为导向、生命周期有限的应用场景中，评价重心正在发生迁移。企业更关注的是交付速度是否足够快、结果是否可以被量化验证，以及在需求变化或业务策略调整时，弃用和重建的成本是否足够低。

稳定性和完美架构不再是前置条件，而是在部分场景下才被重新考虑的因素。

其次，研发模式从系统建设转向能力制造。

在传统模式下，研发团队的核心任务是围绕一个统一系统持续演进，强调代码复用、版本兼容和长期维护。

而在软件消费品化的趋势下，研发工作的重心逐步前移到组件、模板、工作流以及智能体协作规则的设计上。代码未必追求长期沉淀，但能力必须可以被快速组合、快速复制，并在不同任务中反复调用。研发更像是在搭建一条高效率的生产线，而不是守护一个不断膨胀的系统。

再次，软件的定价逻辑开始发生结构性变化。

按年订阅、按账号收费的模式，建立在软件长期使用和客户高度锁定的前提之上。当软件被频繁重写、阶段性使用时，这种定价方式的合理性自然下降。

越来越多的厂商开始尝试按结果付费、按任务计费或按调用量计费，使成本与业务价值形成更直接的对应关系。这一变化正在削弱传统 SaaS 对 ARR 的高度依赖，也迫使厂商重新思考增长、续费与客户价值的衡量方式。

最后，客户关系从长期绑定走向项目制协作。

在新的软件形态下，厂商在更多场景中扮演的是高效执行者和能力提供者，而非长期系统伙伴。合作关系围绕明确目标展开，项目完成即阶段性结束。

这并不必然意味着客户黏性下降，但它要求厂商通过效率、结果和专业度持续赢得下一次合作，而不是依赖系统迁移成本形成事实上的锁定。

04

边界与代价：

哪些软件不应被消费品化

需要强调的是，消费品化并非普适答案。它解决的是效率与覆盖面问题，而非所有软件形态下的最优解。

适合这一模式的，通常是个人微需求、部门级临时项目、探索性验证，以及流程相对清晰、结果可以被快速检验的任务型场景。在这些领域中，软件的价值更多体现在是否及时完成任务，而非是否长期存在。

不适合的边界同样清晰。

核心业务系统、安全与合规系统、金融交易、医疗、航空航天等高可靠领域，仍然必须坚持长期可维护的软件逻辑。这些系统直接关联组织运行、安全责任或生命财产风险，一旦失效，代价远高于开发和维护成本。

在此类场景中，稳定性、可解释性、可追责性以及对极端情况的覆盖能力，始终高于交付速度和灵活性。

需要警惕的是，如果在不具备条件的领域盲目推动消费品化，可能带来新的隐性成本。

频繁重写会累积技术债务，短生命周期系统可能削弱组织对关键流程的理解，过度依赖即时生成工具，也可能在合规和安全层面留下难以追溯的风险。这些代价在短期内不易显现，却会在系统规模扩大后集中暴露。

因此，未来的软件行业很可能呈现出更加清晰的分化格局：一端是强调速度、低成本和结果导向的快消品软件，用于支撑高频、变化快的业务需求；另一端则是强调质量、稳定性和长期价值的精品系统，用于承载组织最核心、最不可替代的能力。

企业真正需要的，并不是在两者之间二选一，而是具备区分和匹配不同软件形态的能力。

05

结语

软件的消费品化，并非厂商策略选择，它是 AI 时代生产效率提升后的必然结果。当代码生成成本趋近于零，软件数量必然爆发，生命周期必然缩短。

这既带来风险，也释放创造力。

数字垃圾和技术债务的隐患真实存在，但更多人得以低成本构建工具、验证想法，同样不可逆转。

而真正重要的，不是简单赞美或抵制这一趋势，是建立判断力，判断哪些软件应该快，哪些必须慢；哪些可以用完即弃，哪些值得长期投入。

这种分层能力，将决定企业与软件厂商在新周期中的位置。

本文来自微信公众号“牛透社”（ID：Neuters），作者：Alex，编辑：燕子，36氪经授权发布。