＂不写文档＂和＂日抛型软件＂:一种危险的行业误导

最近，叮叮无招提出了两个观点：“不要写文档” 和 “日抛型软件”。乍一听，这些说法似乎迎合了 AI 时代”快速迭代”的趋势，但如果稍微深入思考就会发现，这种言论不仅站不住脚，而且正在对软件行业形成一种极具误导性的价值导向，甚至可能带来长期的系统性伤害。

一、”不写文档”是在透支行业的未来

文档不是负担，而是软件工程最后的底线。这里的”文档”，从来不只是程序员写给程序员的开发文档，而是一切用于表达系统边界、约束与决策的外显信息。

说”不要写文档”的人，往往混淆了两个概念：过度文档化和必要的文档。确实，没有人喜欢写那些写完就被束之高阁、与代码脱节的冗长文档。但这并不意味着文档本身没有价值，更不意味着可以放弃文档。

当一个团队开始放弃文档，本质上是在放弃未来。

文档的本质，不是”写给谁看”，而是让系统具备可理解性与可延续性。

文档的核心价值是什么？

• 知识传承：代码可以重写，人一定会离开，但文档是团队知识的唯一沉淀。没有文档，任何一个人员流动，都会让系统”失忆”，项目被迫反复从零开始。

• 协作基础：软件工程从来不是单人游戏。API 文档、架构说明、接口规范，甚至包括产品说明、业务规则，这些本质上都是协作的契约。如果连契约都不存在，所谓”高效开发”，只不过是在放大混乱。

• 维护成本：AI 可以生成代码，但无法替代上下文。而”文档”，本质上就是上下文的外化。半年后，当连原作者都说不清当初的设计意图时，没有文档，维护成本不会线性上升，而是失控式增长。

• 责任追溯：系统一旦出问题，文档就是唯一可以回溯决策链条的依据。没有文档，本质上等于没有责任边界。

你可以不写文档，但你无法逃避由此带来的混乱、重复劳动和系统性风险。

二、”日抛型软件”的致命缺陷

但如果把”日抛型软件”这个概念本身拆开来看，会发现它其实存在一个根本性的自相矛盾：

既然是”软件”，就意味着可以复用、可以演进、可以被他人理解；而一旦”用完即弃”，这些属性就全部消失了。

换句话说，当一个系统真正变成”日抛”时，它也就不再具备软件的核心特征，而更接近一次性的脚本，而不是一个可以被称为”软件”的系统。

如果一个概念在成立的那一刻就否定了自身，那么问题就不只是”是否可行”，而是它是否还在讨论同一类事物。

“日抛型软件”——代码为特定目的生成，用完即销毁。这个概念听起来很”AI 原生”，但它忽略了一个最基本的事实：软件的价值来自积累，而不是消耗。

为什么”日抛型”站不住脚？

• 软件不是消耗品：优秀的软件，从来都是长期演进的结果。

• 信任需要时间：“日抛型”的逻辑是：只对当下负责，不对未来负责。

• 安全无法保障：安全依赖长期治理，而不是一次生成。

• 生态无法形成：“日抛型软件”最大的问题不是不好用，而是没有明天。

三、这种言论为什么危险？

问题不在于观点本身，而在于它来自有影响力的人。

当像叮叮无招这样具有行业影响力的人公开表达”不要写文档””日抛型软件”时，这些观点很容易被简化、被放大、被误用。

四、结语：别让短视毁掉行业

我们需要的，不是更快地写出可以被丢弃的代码，

也不是更多”形式上的文档”，

而是更高效地构建可以被理解、被维护、被延续的软件系统。

否则，所谓的”AI 提效”，最终只会变成一场用速度掩盖混乱的幻觉。