作者：古德白

来源：Silicon Mind科技播客

封面：AI生成（可灵）

“所有软件正在变成日抛品，软件时代已彻底终结。”

2026年4月，钉钉创始人兼CEO陈航（无招）在《中国企业家》商界木兰年会上抛出这一断言。此后不到一个月，百度董事长李彦宏也在Create2026大会上提出“未来的软件可能是一次性的”。一时间，“日抛型软件”成为行业热搜。

作为软件工程出身的从业者，亲历了从瀑布到敏捷、从单体到微服务、从云端到边缘的每一次范式跃迁。坦率地说，当我和身边的资深工程师们讨论这一概念时，得到的回应惊人地一致——这不是在预言未来，而是对软件工程最根本常识的缺乏敬畏。

有些东西，如鲠在喉，今天我想认真地解剖这个“日抛”概念：它到底在说什么？它的逻辑漏洞在哪里？它所忽视的，恰恰是AI时代软件工程最珍贵的东西——而这些东西，恰恰是Harness Engineering正在试图回答的命题。

“软件日抛”：一个华丽而危险的比喻

无招的核心比喻来自隐形眼镜：“过去配眼镜要到店里定制，现在大家都用日抛隐形眼镜，用完就扔，明天换新的。软件也一样，按需生成、用完即弃。”

在他的构想中，企业不再需要长期维护的ERP、CRM系统，只需将数据和需求交给AI——系统即时生成，使用完毕即抛弃。他甚至列举了钉钉内部的三条“铁律”：全员禁止手写文档，开会不准做笔记，讨论只准用白板。表面上看，这是AI对文档撰写、会议纪要等重复性劳动的替代，但背后包含着一个更深层的预设：AI可以生成一切，也就可以抹去一切。

这个故事的传播力毋庸置疑。许多企业管理者听完后热血沸腾：“再也不用花几百万买软件了，一句话就行。”

但细究之下，这个比喻从起点就偷换了概念。

四个“一捅就破”的逻辑破绽

破绽一：拿ERP当靶子，恰恰选错了例子

日抛论者最津津乐道的案例就是“ERP可以被AI瞬间生成”。但ERP这类核心业务系统承载的，从来就不只是UI界面那一层。

一家制造企业的MES与ERP组合，背后是几十年沉淀的行业know-how：BOM怎么拆、排产怎么走、成本怎么归集、财务怎么结账、监管怎么报送。这些东西之所以稳定，恰恰因为绑定的业务模式短期内不会翻天覆地式的变化。数据一致性是ERP的生命线：底层逻辑每天变一次，财务报表就要作废一次。合规审计要求每个系统变更都必须留痕、审批、测试——审计日志无法容忍“AI随手生成、立即上线”。挑ERP做“日抛”的代言，相当于拿人体的骨骼说“每周换一根没问题”——这显然混淆了“皮”与“骨”。

破绽二：企业根本拿不到核心代码

无招的原话是：“把系统界面和代码库交给AI，立即重写，不再需要传统开发周期。”

这话的物理前提根本不存在。SAP、Oracle、用友、金蝶这类企业级软件的核心代码是厂商的绝对机密，客户能操作的只有外层配置和二次开发接口。让企业“把代码库交给AI重写”，卡点不在技术能力，而在商业与法律的边界——没有任何商业软件厂商会把自己的知识产权拱手让人。

软件最重要的不是界面， 是业务逻辑， 是设计思想

破绽三：从隐形眼镜到ERP的类比，偷换了最关键的维度

日抛隐形眼镜能够实现“日抛”，因为它的功能极其单一且不涉及数据积累。但企业软件的价值恰恰在于它承载了长期经营的核心资产。

有篇文章犀利地指出这一点：“日抛隐形眼镜是消耗品，不是心脏支架。能日抛的是部门聚餐报名表、会议纪要整理脚本。不能日抛的是财务ERP、客户CRM、工厂MES。”

一个更本质的追问是：那些AI生成的统计工具，数据从哪来？数据不会凭空产生。“能日抛的只是逻辑层和界面层，永远不能日抛的是数据层和权限层。”AI能帮你统计“华东区销售数据”的前提，是这些数据已经完整、准确地存在于某个系统里——而那个“某个系统”，恰恰是“不日抛”的基础设施。

破绽四：不谈成本谈日抛，是核心漏洞的体现

“不谈成本谈日抛，耍流氓。”——这句技术圈里的直白吐槽，恰恰击中了概念的核心漏洞。

“日抛”听起来省了维护成本，但每次“生成”都有Token成本，“抛弃”意味着之前积累的业务逻辑全部流失，下次生成时要从零开始。在之前分析AI编程时我就强调过一个观点：成本管理决定了一个企业能在能力边界上跑多远。日抛模式在边际成本上非但没有优势，反而因频繁的“推倒重来”而产生大量的重复投入。

当一套系统需要承载财务结算、合规审计、长期数据积累这些“不日抛”的功能时，AI生成的轻量工具根本无法胜任。

软件的价值不是“写出来”，而是“活下来”

软件工程的基石不是“生成代码的能力”，而是“让代码长期稳定运行的能力”。这句话值得所有被日抛论冲昏头脑的管理者默念三遍。

真正昂贵的是复杂度成本，而不是创建成本

AI极大降低了软件的“创建成本”——从几周压缩到几小时。但企业数字化进程中真正承受的是“复杂度成本”：系统间的集成、数据治理、权限分级、合规审计、业务连续性保障。这些隐性负担无法被“日抛”消除，反而会因工具的泛滥而加剧。当一个企业为了一个“日抛”需求生成一个临时工具时，它并没有解决数据孤岛的问题——它只是在生产新的孤岛。

工业级软件的本质是“笨重”的

Linux维护了三十多年，MySQL迭代了二十多年，Java、Python这些改变世界的软件——没有一个是“日抛”的。真正的工业级软件都很“笨重”，因为稳定，比性感重要。

“日抛”消灭的是什么？

“日抛逻辑”推崇的是“快，越快越好”。于是整个行业会开始厌恶“长期主义”。软件行业真正伟大的东西，恰恰建立在“长期维护”之上。没有稳定迭代的积累，再强大的AI也只是在沙滩上不断重画图案，潮水一来，一切归零。

如果“日抛”意味着“积累、传播、共享都会消失”，那将是软件行业最彻底的倒退。所有的创新都是站在前人肩膀上的结果——推倒一切、从零开始，不是革新，是革命，而革命往往意味着巨大的浪费与混乱。

“日抛论”背后，钉钉的真实焦虑

理解了这些逻辑破绽，一个更本质的问题浮出水面：无招为什么要说这些？

答案并不复杂。

钉钉做了十一年，烧了阿里至少500亿，至今未盈利。在企业IT总支出中，钉钉、企业微信、飞书三者加起来占比不到5%。企业真正花钱的是ERP、CRM、MES——协同办公永远只是锦上添花，不是核心基础设施。向上做PaaS、做行业解决方案、做ERP，钉钉屡战屡败。向下被企业微信靠微信生态死死压制。横向的互联网公司和创新型企业，几乎全被飞书抢走。

面对AI这个风口，无招需要讲一个足够大的、让阿里继续投钱、让客户暂时忘记“钉钉就是打卡工具”印象的故事。

他不是在预言未来，他是在续命。

理解了这一点，你就会明白为什么日抛论只聚焦于“软件”本身，却从来避而不谈：承载企业核心数据和核心流程的底座怎么办？数据安全怎么保证？合规审计怎么追溯？责任链如何建立？问题的答案，钉钉给不出——因为协同平台的基因决定它很难给出答案。

真正的未来：Harness Engineering，而非“软件日抛”

如果我们否定“日抛”这一极端概念，那么AI时代软件工程的正确方向是什么？

答案是Harness Engineering——驭缰工程。它不是什么概念炒作，而是当前AI工程领域正在发生的范式跃迁。

Harness直译为“马具”，和AI的类比极其恰当：Agent是马，Harness是马具。马的动力是天然的，但马具不提供动力，它管方向、管节奏、管在极速状态下不翻车。更工程化的定义是：Harness是包裹在AI模型周围的基础设施，专门用于管理长期任务，负责提供预设上下文、工具调用的标准化处理、生命周期管理、规划调度、子Agent管理。

Harness架构的核心公式是：Agent = Model + Harness。模型是大脑，Harness是大脑之外的一切：系统提示词、工具调度、上下文管理、权限控制、错误恢复、反馈闭环。你不会把CPU直接交给用户，你交付的是操作系统。在Agent架构层面，这个类比同样成立。

Harness之所以与“日抛论”形成鲜明对照，在于它的设计哲学完全相反：

日抛论预设软件是一次性的，用完即弃，不强调维护与积累；Harness则恰好相反，它设计的目标是让AI Agent在企业级环境中实现稳定、可控、可审计、可追溯的长期运行，解决越权操作、逻辑混乱、无法审计等生产级问题。

这绝非巧合。Harness概念的兴起，正是行业对“裸模型”局限性深刻反思的结果。单纯依赖基座模型面临无记忆、不能执行代码、知识过时等局限；而模型能力的瓶颈往往在模型之外（即Harness），优化Harness可以显著提升Agent性能，满足企业级应用对可靠性、可控性的更高要求。

不破不立：AI时代，软件工程何为

在结束了以上“破”的部分之后，我想做一些建设性的思考：AI时代的软件工程，到底应该往哪个方向演进？

第一，从“代码生产者”到“流程驾驭者”。AI可以写代码，但它不会判断一个业务规则是MECE的，不会判断一段代码是否符合合规框架，不会判断一个架构设计是否能够承受三年的业务增长。这些判断力，才是人类工程师不可替代的价值所在。正如Harness Engineering的定义所示，未来工程师的核心能力将是设计、构建和维护Harness——即让AI Agent稳定运行的基础设施。

第二，从“单体工程”到“混合智能系统设计”。AI时代的软件将不再是单一模型统治一切的状态，而是多个异构模型协同工作、由Harness统一调度的复合系统。这也意味着软件工程的价值重心从“实现功能”向“设计系统集成与治理”转移。

第三，拥抱变化但不放弃基石。“日抛”与“长期维护”不是非此即彼的二选一。AI降低了软件的创建成本，这意味着企业可以更快地试错、更灵活地调整。但这绝不意味着应该抛弃软件工程的基本原则——架构设计、代码审查、测试覆盖、监控运维。这些原则在任何时代都是软件质量的生命线，AI不能替代它们，AI也正在通过学习这些最佳实践来变得更可靠。

结语：警惕被金句掩盖的真实问题

“软件日抛”是一个传播力极强但根基脆弱的概念。它在传播中获得了生命力，恰恰因为它戳中了企业管理者对软件成本和复杂度的高度焦虑。

但对软件工程师而言，这个概念的每一个环节都经不起推敲。软件的真正价值不在于被“生成”，而在于被“维护”。一个无法长期稳定运行的系统，无论生成得多快，都无法成为企业数字化的核心驱动力。

AI时代的到来不是软件工程的终结，而是它的升级和重塑。从提示词工程到上下文工程，再到当前的Harness Engineering，AI工程实践正沿着一条清晰的脉络深化演进。这个演进的核心逻辑，恰恰是让AI从不可控、不可靠的“裸模型”，变成稳定、可控、可审计的企业级生产力。

而“软件日抛”恰恰站在这个逻辑的反面——它不是让AI走向系统化和工程化，而是让软件退回最原始的、碎片化的临时脚本状态。这既不是AI的前沿，更不是软件工程的未来。

金句可以收割流量，但真正的变革永远来自扎实的工程实践。钉钉的困境不是技术预言能够解决的，中国软件产业的升级也不是一句“日抛”就能概括的。我们真正需要的，是既拥抱AI的强大生成能力，又坚守软件工程最核心的价值理念——“让代码稳定、可靠、长期地服务于业务需求”，在这个基础上构建更适合AI时代的Harness工程体系。

那才是值得我们全力以赴的方向。

关于作者：一个长期关注AI的技术人

一个不站队的观察者