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

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

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

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

更直接一点说：

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

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

很多人默认一个等式：

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

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

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

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

代码只是最后一层表达。

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

• • 分布式一致性  
• • 业务耦合传播  
• • 需求变更引发的结构重塑  
• • 非功能约束（性能、稳定性、安全）

这也是为什么：

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

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

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

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

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

• • 快速生成  
• • 用完即弃  
• • 不做维护

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

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

1. 数据不可日抛

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

• • 数据模型  
• • 业务语义  
• • 状态流转

这些要素具有：

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

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

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

• • 语义漂移  
• • 结构碎片化  
• • 口径不一致

最终演化为：

系统级的数据混乱

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

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

不维护 = 没有技术负担

但现实是：

• • 接口频繁变化 → 上下游成本上升  
• • 系统边界模糊 → 责任难以划分  
• • 重复实现增加 → 复杂度持续叠加

结果是：

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

3. 运维复杂度不可承受

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

系统是孤立的

但真实环境中：

• • 系统高度耦合  
• • 调用链跨多个服务  
• • 故障具备传播性

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

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

这意味着：

• • 问题难以定位  
• • 难以复盘  
• • 难以收敛

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

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

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

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

• • 关注产量  
• • 忽略结构  
• • 回避复杂性

本质上是：

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

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

• • 叙事里：AI 可以快速生成复杂系统  
• • 现实中：工程体系并未同步进化

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

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

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

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

更合理的方向是：

1. 架构推演

在设计阶段评估：

• • 方案在不同负载下的行为  
• • 潜在瓶颈位置  
• • 系统脆弱点

核心价值：降低设计阶段的决策错误

2. 复杂性分析

识别系统中的：

• • 高耦合区域  
• • 高风险链路  
• • 难以演进模块

核心价值：让复杂性可见、可度量

3. 架构评审

围绕完整链路：

需求 → 设计 → 架构 → 风险 → 优化

提供：

• • 设计缺陷识别  
• • 可执行优化建议  
• • 权衡分析

而不是单纯增加代码产出。

五、为什么这种认知会带来问题

问题不在于“日抛”这个说法本身，而在于它隐含的判断：

软件可以被随意生成和替换

一旦这种认知成为主导，会带来一系列后果：

• • 对系统复杂性缺乏约束  
• • 对架构设计缺乏投入  
• • 对长期演进缺乏规划

最终结果是：

系统逐步失去可演进性，工程能力被持续削弱

六、结语

软件工程从来不是“生产代码”，而是“控制复杂性”。

AI改变的是工具能力，但没有改变基本规律：

复杂性不会消失，只会转移

当复杂性被忽略时，它不会消失，只会以更高成本在未来集中出现。

因此问题的关键不在于：

能不能更快生成软件，

而在于：

能不能持续构建一个可演进的系统