跳转至

“日抛软件”：AI时代正在发生的一场认知滑坡

Ch01.1147 “日抛软件”：AI时代正在发生的一场认知滑坡

📊 Level ⭐⭐ | 5.3KB | entities/日抛软件ai时代正在发生的一场认知滑坡.md

“日抛软件”：AI时代正在发生的一场认知滑坡

来源: Unknown

发布日期: 2026-04-21

原文链接: https://mp.weixin.qq.com/s/rWC-oBXzCLZdarnsajbSAA

最近，钉钉创始者的“AI 可以代替复杂系统”“生成日抛软件”的言论在技术圈持续发酵。

如果只把它当作一次表达偏差，就低估了问题的严重性。

这不是一次普通的技术争议，而是一次典型的——管理认知与工程现实的断层暴露。

更直接一点说：

不是AI太激进，而是对“软件是什么”的理解出现了偏差。

一、软件不是代码，而是复杂性控制系统

很多人默认一个等式：

AI 能写代码 = 软件可以被快速生产

这个等式的问题在于，它把“软件”降维成了“代码”。

但在工程现实中，软件真正的构成是：

约束 + 状态 + 依赖 + 演化 + 不确定性

代码只是最后一层表达。

真正决定系统成本和难度的是：

  • • 分布式一致性

  • • 业务耦合传播

  • • 需求变更引发的结构重塑

  • • 非功能约束（性能、稳定性、安全）

这也是为什么：

企业软件的大部分成本，发生在“写完之后”。

而“日抛软件”的逻辑，本质是：

忽略这些复杂性，把软件理解为一次性产物。

二、“日抛软件”的本质：把可控复杂性转化为系统性风险

从局部看，“日抛”是一种效率最大化：

  • • 快速生成

  • • 用完即弃

  • • 不做维护

但从系统层面看，它做的是：

把“可治理的复杂性”，转化为“不可治理的风险”

1. 数据不可日抛

企业系统的核心不是功能，而是：

  • • 数据模型

  • • 业务语义

  • • 状态流转

这些要素具有：

不可逆、强依赖、强历史性

你可以重写代码，但无法“重写历史数据”。

当系统被当作“日抛”处理时，数据层会出现：

  • • 语义漂移

  • • 结构碎片化

  • • 口径不一致

最终演化为：

系统级的数据混乱

2. 架构问题不会消失，只会扩散

“日抛”的一个隐含假设是：

不维护 = 没有技术负担

但现实是：

  • • 接口频繁变化 → 上下游成本上升

  • • 系统边界模糊 → 责任难以划分

  • • 重复实现增加 → 复杂度持续叠加

结果是：

局部看似轻量，全局持续失控

3. 运维复杂度不可承受

“日抛软件”隐含一个前提：

系统是孤立的

但真实环境中：

  • • 系统高度耦合

  • • 调用链跨多个服务

  • • 故障具备传播性

当系统不断被“生成和替换”，运维面对的将是：

不可稳定观测、不可稳定复现的问题空间

这意味着：

  • • 问题难以定位

  • • 难以复盘

  • • 难以收敛

三、问题的根源：用人力替代逻辑理解AI

“日抛软件”的底层逻辑，其实并不新：

用AI替代人力，提高产出速度

这是一种典型的工业时代思维：

  • • 关注产量

  • • 忽略结构

  • • 回避复杂性

本质上是：

用“人力替代”的方式理解AI，而不是“认知增强”

这也解释了一个矛盾现象：

  • • 叙事里：AI 可以快速生成复杂系统

  • • 现实中：工程体系并未同步进化

问题不在能力，而在认知模型。

四、AI在软件工程中的正确位置

如果AI只用于生成代码，那么“日抛”是一个自然结果。

但这只是AI在软件工程中最低价值的使用方式。

更合理的方向是：

1. 架构推演

在设计阶段

→ 原文存档

关联