---
title: "“日抛软件”：AI时代正在发生的一场认知滑坡"
source: wechat
url: https://mp.weixin.qq.com/s/rWC-oBXzCLZdarnsajbSAA
ingest_date: 2026-07-04
vxc: 49
stars: 4
sha256: ec886132a35ebd21a75a60eae778d71c1a7a9e2d8309d871ea844dd22f3422e4
---

# “日抛软件”：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. 架构推演

在设计阶段评估：

- • 方案在不同负载下的行为

- • 潜在瓶颈位置

- • 系统脆弱点

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

### 2. 复杂性分析

识别系统中的：

- • 高耦合区域

- • 高风险链路

- • 难以演进模块

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

### 3. 架构评审

围绕完整链路：

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

提供：

- • 设计缺陷识别

- • 可执行优化建议

- • 权衡分析

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

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

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

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

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

- • 对系统复杂性缺乏约束

- • 对架构设计缺乏投入

- • 对长期演进缺乏规划

最终结果是：

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

## 六、结语

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

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

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

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

因此问题的关键不在于：

能不能更快生成软件，

而在于：

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