夜雨聆风
软件日抛论 这一个观点在技术圈开始流行。
大意是：AI时代，软件可以随写随抛，用完就换，没必要在乎代码质量。
反正AI能生成，生成不好再重新生成，出了问题推倒重来就是了。
这个观点，听起来很酷。
它也很危险。
先从昨天刚发生的事说起
就在两天前，Claude大面积宕机，有用户收到了别人的对话。
你知道这个事故的技术根因是什么吗？
跨租户隔离失效——现代AI API由负载均衡器、请求路由器、网关、队列、内存缓存、连接池等多层共享组件构成，每一层都持有状态，任何一层出问题都可能把A用户的数据塞给B用户。
这不是AI模型本身的问题。
这是软件架构和工程设计的问题。
是那些在AI背后，撑着整个系统运转的代码，出了裂缝。
AI越强，承载AI的工程底座就越关键。底座裂了，上面再聪明的AI也跑不稳。
"软件日抛论"是怎么来的
这个观点，有它的土壤。
过去一年，AI编程工具的确进步惊人。
一年前AI写几行代码都错漏百出，现在它能编写十万行正确运行的代码，复杂的多日项目已经被大幅自动化。
这是真的。
于是一批人开始得出结论：既然AI能写，那代码好不好无所谓，写坏了就让AI重写，反正成本低。
这个推导，在演示和原型阶段，没有问题。
但在真实的生产系统里，这个逻辑会在某个夜里，以一种非常具体的方式崩掉。
代码不是用完就扔的餐巾纸
有一个词叫"技术债务"。
它不是比喻，是真实的重量。
当你用AI快速生成了一个功能，没有认真设计架构，没有写测试，没有文档，没有考虑边界情况——那段代码就开始积累债务。
一开始没什么感觉。
三个月后，你想在上面加一个新功能，发现改哪里都会动到别的地方。
六个月后，系统开始出现奇怪的bug，没人知道为什么，因为最初写这段代码的人已经离职了，而且那段代码根本没人能看懂。
一年后，你面临两个选择：花三个月重写，或者继续在一栋随时可能倒塌的楼里装修。
德勤预计AI有望推动软件开发生命周期实现30%到35%的生产力提升。但同时他们也指出：技能退化在长期内是一种潜在风险，可能阻碍创新能力与应变能力的培育。
生产力提升了30%，但如果工程质量下降，这30%的提升，可能在后期维护阶段全部吐回去，甚至倒欠。
Linus说了什么，值得认真听
没有人比Linus Torvalds更有资格谈论这件事了。
他花了三十多年，维护着全世界最复杂的开源代码库之一。
Torvalds明确表示，他喜欢使用AI工具，也承认它能提升效率，但反对"99%的代码由AI编写"这类营销性质说法。
他强调，Linux面临的核心难题不只在代码本身，更在协作方式。AI扩大了参与规模，也同步放大了沟通、评审、分发的压力，真正刺痛社区的往往是"社会性瓶颈"，而不是单纯的技术问题。
Torvalds说，维护工作依赖于人而不是代码，作为最高级别的维护者，他的工作不是写代码而是与人合作，他不会用AI来与人合作，并建议其他人也不要这么做。
这句话值得反复想：
AI能写代码，但AI处理不了代码背后那些复杂的人与人之间的协作、判断和责任。
那才是软件工程最核心的东西。
AI生成的代码，有一个隐蔽的问题
当开发者只依赖AI去扫描漏洞时，因为用的工具都一样，结果就是所有人报的问题都长得一模一样，报告堆成山，维护者们根本没时间看有用的，只能忙着把废话过滤掉。
这是AI工具的一个深层问题：它降低了参与的门槛，但同时也在批量生产"相似的东西"。
相似的代码结构，相似的错误模式，相似的解决方案。
当整个行业的代码都开始趋同，当每个人生成的解决方案都差不多，你的竞争优势在哪里？
真正的差异化，从来不在代码生成的速度上。
在架构判断，在业务理解，在对"这个功能值不值得做、怎么做才能长期维护"这类问题的回答能力上。
这些，AI给不了你。
更大的系统，更高的要求
AI将杀死SaaS、软件行业将被颠覆——这些担忧出现过。但来自企业管理层和一线从业者的声音透露出一种新的图景：AI的确在冲击传统软件，但这种冲击并非简单的替代，而是一场深刻的重构。
Gartner预测，到2030年，80%的组织将把大型软件工程团队演变为规模更小的AI增强型团队。
注意那个措辞：AI增强型团队。
不是"被AI替代的团队"，不是"可以不需要工程师的团队"。
是增强型。
更小的团队，做更大的事，用AI来放大每个工程师的能力。
但放大的前提，是那个工程师本身有东西可以被放大。
一个没有扎实工程基础的人，用了AI工具之后，能更快地写出更多糟糕的代码。
一个有扎实工程思维的人，用了AI工具之后，能用更少的精力，设计出更好的系统。
AI是放大镜，放大的是你本来就有的东西。
Claude的宕机，多说一句
这件事里，有一个细节被很多人忽略了。
宕机本身，大家还能接受。AI系统出故障，概率不为零。
但那个"跨租户数据泄漏"的可能性，才是真正让工程师们脊背发凉的。
因为那不是AI模型的问题，那是基础工程设计的问题——是隔离机制、是缓存管理、是连接池的生命周期管理。
这些东西，是最古老、最基础的软件工程问题。
它们存在了几十年，在AI时代依然存在。
只是现在，当数百万用户把越来越多的敏感信息托付给这些系统的时候，这些古老问题的代价，变得前所未有地昂贵。
AI让软件的影响范围更大了，但没有让软件工程的基本问题消失。它让这些问题的代价，变得更大。
普通工程师，该怎么想这件事
不是要你抵制AI工具，不是要你假装AI没有让生产效率提升。
而是要想清楚一件事：
在AI能帮你做的事情越来越多的今天，那些AI做不了的事情，会变得越来越值钱。
AI能帮你写代码，但它不能替你做架构决策。
AI能帮你生成测试用例，但它不能替你理解"为什么这个测试是重要的"。
AI能帮你排查bug，但它不能替你在凌晨三点，对着一个生产环境的事故，做出那个正确的判断。
那个判断，背后是你多年的工程经验，是你真正理解了系统在做什么。
用好AI的人，未来会越来越稀缺。因为大多数人，要么不会用，要么只会用，但不理解它在做什么。
前者，很快会被时代甩下。
后者，最终会被系统崩溃教训。
只有真正理解工程、又能用好AI的人，才会在这场重构里，站在最值钱的那个位置上。
写在最后
软件日抛论，本质上是一种对速度的崇拜。
这种崇拜有它的道理，在一些场景下也是合理的选择。
但当它变成一种普遍的工程哲学——当整个行业都开始觉得代码质量无所谓、工程基础可以绕过去的时候——
我们正在为未来某一天那场大规模的系统崩溃，做精心的准备。
就像我们在昨天的那次宕机里，看到的一个小小的预演。
AI越强，软件工程越重要。这不是矛盾，这是规律。
工具越锋利，越需要稳定的手。
