最近刷自媒体，经常能看到这样的演示：半天做出一个游戏，一天做出一个 App，然后宣布"程序员要失业了"。
看着确实挺厉害。但其实，我更想看第二期：
- 如果客户改需求了，这个项目还能接着改吗？
- 如果有Bug，怎么修复呢？
第一版能跑起来，当然值得鼓励、高兴。可用户不会停在演示视频里，他们会提新需求、遇到 Bug，也会问你：我花了钱，这东西能一直用下去吗？
AI 确实改变了很多事情，想想我最近的工作：几乎 95% 的时间，我都是对着 AI 编程工具描述任务，它就像一个不辞辛劳的员工，说什么做什么，甚至还会在合适的时机问你接下来该怎么办，我找不到这么听话能干的员工了（不知道我的老板是不是这么想我的）。
它省下的时间实实在在。只是用得越多，我越觉得，代码生成之后的那些工作，才更考验一个开发者。
这让我想起编程界二十年前的一个承诺：只要把系统模型建好，代码就能自动生成。为什么二十年过去了，我们还在讨论同一个问题 ------ "写代码被替代"？
当时，UML 和模型驱动架构（Model Driven Architecture，MDA）着实让人们眼前一亮：为系统建好模型，就能自动生成代码。
当然，UML 是建模语言，MDA 是基于模型转换的开发思路，两者并不是一回事。（不知道各位用没用过一些 UML 建模工具，完成建模后，可以直接导出 Java/C++ 代码骨架。）
法国敏捷运动的先驱之一 Claude Aubry，以及法国 UML 专家 Pascal Roques，走的是不同的路线，追求的却是同一件事：驾驭软件的复杂性。Claude Aubry 靠改变工作方式，Pascal Roques 靠严谨的建模。
二十年过去了，我们还在写代码。
如今，同样的危机又来了，只是主角换成了人工智能。
法国哲学家 Éric Sadin 是欧洲对技术社会影响批判最尖锐的思想家之一。他在近作《Le Désert de nous-mêmes》（2025）中，批评了 AI 带来的"认知剥夺"。
这让我想起软件行业的一次次危机，以及危机后对基本功的重新重视。
这个基本功就是 ------ 架构！
假设，我是说假设：如果我们不再生产代码，这门手艺最根本的价值是什么？支撑它的人和价值观，又会怎样？
软件行业有个由来已久的习惯：在危机中往前走。
我从业以来遇到的 React、Flutter、Compose、Kotlin，无一不是冲击，对于习惯旧技术的人来说，每次技术更替都可能带来危机感。
危机往往来得不声不响，我们一点点偏离方向，逐渐无法交付真正有价值的东西，工作也失去了意义。每一次，都要等到整个行业有所醒悟，才能重新关注真正要紧的事。
我相信，我们又站在了新一轮循环的边缘。
只不过这一次，危机不是来源于流程太多、每天开会太多、领导官僚作风太重，而是代码来得太容易。
展望未来之前，我们先回顾历史。软件工程的历史里，有不少这样的时刻：整个行业忘了自己究竟在做什么，后来又找回了方向。
我们忘了"为什么"
AI 让写代码的成本几乎为零。但如果缺少架构、设计和工程功底，我们只是在更快地制造技术债。
20 世纪 90 年代，软件开发主要沿用工业工程的思路：V 模型、瀑布模型，还有在写下第一行代码前几个月就已经冻结的需求规格。
结果呢，用统计数据说话吧。
Standish Group 的 1994 年 CHAOS 报告将调查中的项目分为三类：16.2% 按时、按预算并实现最初约定的全部功能；52.7% 虽然完成并投入运行，却存在超支、延期和功能缩水；31.1% 在开发过程中被取消。约 84% 没有达到报告的成功标准，但不能把它们都算成彻底失败，也不能直接当成整个行业的失败率。
我当然没有经历过那个时代，那个时候我才几岁，还不懂什么是软件。不过，凭我 10 多年的工作经验，能按要求顺利交付的项目，感觉也就 20% 左右。当然，这只是我的个人印象，不是标准的统计结果。
而且我发现国内写程序这个行当有个特点，如果到期交付不了，就疯狂加班，虽然肯定交付不了，但是至少有态度，瞧瞧，"至少有态度"，有时候感觉这工作好像唯心主义一样！
问题不在技术上。
我们忘了为什么要开发软件：为了服务用户，而用户的需求会变。或者说，领导的想法随时在变！
同一个十年里，有几位工程师各自摸索出了截然不同的开发方式。
Kent Beck 正在系统化地整理极限编程（Extreme Programming，XP），它或许是其中最大胆的一种。XP 提出的远不止另一套流程，它质疑的是整个行业的基本假设。当大家相信"计划越充分，风险越小"时，XP 给出的答案是短迭代、持续反馈、系统地开展结对编程，尤其是先写测试，再写代码。随着 XP 兴起的测试驱动开发（TDD），把开发顺序倒了过来：先表达意图，再编写刚好能满足它的实现。
与此同时，Ken Schwaber 和 Jeff Sutherland 正在完善 Scrum，另一些人则借鉴丰田的经验，探索精益软件开发。
2001 年 2 月，一群人聚集在美国犹他州 Snowbird 的一间滑雪旅馆里，其中有 Kent Beck、Martin Fowler、Robert C. Martin 和 Ward Cunningham。他们写下了《敏捷宣言》：四项价值观、十二条原则，一页纸就能容纳。四项价值观都在说明如何取舍：
- 个体和互动，高于流程和工具
- 可工作的软件，高于详尽的文档
- 客户合作，高于合同谈判
- 响应变化，高于遵循计划
宣言的力量就在这"分寸"上。
它没有说"不要文档"或"不要计划"，
而是说，当你必须取舍时，优先考虑人、实际成果、合作关系和适应变化。这不是全盘否定，而是明确轻重缓急。敏捷从来无意成为一套方法论。它是在提醒我们：别脱离现实。
我们忘了"怎么做"
敏捷被广泛采用。
但行业又一次学会了形式，却没学到多少实质。
企业拥抱 Scrum、冲刺、每日站会和贴满墙的便利贴，仪式一样不缺。可代码本身并没有变好。交付确实更频繁了，只是交付平庸代码的频率也更高了。
我不知道各位在高负荷（疯狂加班）下，是否有时间去思考代码的质量。
我在高负荷的情况下，会走很多看起来像工作的形式流程：早上起来，晚点到公司，到公司开完早会唠嗑，喝咖啡，混时间，然后中午就吃饭了，午休，睡到一点半，唠嗑。两点半开始工作 + 唠嗑，6 点吃饭，混一个小时时间，7 点继续加班，好，晚上 7 点，开始来精神了，此时，才开始工作！
到最后，XP 的技术实践反而被我们忘了。为了推广敏捷，那些最难受、最需要自律的做法成了牺牲品。
结对编程？"太贵了，两个人守着一台电脑。
"TDD？"太慢了，我们还有功能要交付。
"持续重构？"行，以后再说。"
企业想要流程上的敏捷，却不愿付出让敏捷真正成为可能的技术努力。
2009 年，Robert C. Martin、Sandro Mancuso 等人倡导的《软件匠艺宣言》（Software Craftsmanship Manifesto）回应了这个问题，为敏捷补上了一层要求：软件不仅要能工作，还要做得好。与此同时，Robert C. Martin 在 2008 年出版的《代码整洁之道》（Clean Code）成了重要的参考书。它的基本观点是：读代码比写代码更重要。代码通常会被反复阅读，阅读次数远多于修改次数。把代码写清楚，单从成本上看也是必要的。
软件匠艺重新强调了 XP 从一开始就确立的东西：TDD、重构和结对编程不是可有可无的选项，而是基本功。为了开发速度抛弃它们，就像坐在树枝上，却把脚下的树枝锯断。
我们忘了"构建什么"
与此同时，另一个问题也一直存在：代码可以很整洁，交付可以很规律，流程也可以很敏捷，但造出来的系统仍然可能杂乱无章。单体系统里，所有东西都互相依赖；只加一个简单的业务功能，就得改动十五个彼此无关的模块。
Eric Evans 的领域驱动设计（Domain-Driven Design，DDD）、Robert C. Martin 的整洁架构（Clean Architecture），以及 Alistair Cockburn 的六边形架构（Hexagonal Architecture），都在回应这类结构问题。这些思路的发展时间相互交叠，并不是等软件匠艺兴起之后才出现的。
它们的侧重点不同：DDD 强调理解和建模业务领域，整洁架构与六边形架构则强调隔离业务逻辑和外部技术细节。它们共同提醒我们，软件的复杂性不能只靠技术实现来处理。如果不有意识地为业务领域建模，划清限界上下文、建立通用语言、把核心业务与基础设施分开，你做的就只是堆功能，还谈不上构建系统。
一句话，你写的东西，有人能看懂吗？
你知道自己在为谁、为什么写功能吗？
你了解你的业务或者需求吗？
意义的流失
回头看这三十年，会发现一个反复出现的现象：每个时期，行业都把"生产"与"构建"混为一谈。生产代码、生产交付物、生产功能。每一次，都需要一场运动来提醒我们，构建软件首先需要理解、建模，以及认真对待手头的工作。
敏捷让我们重新记起工作的目的，XP 和软件匠艺让我们重新重视技术纪律，DDD 和整洁架构则让我们重新关注结构。
那么，现在呢？
AI 登场
此时希望读者们心中响起乔峰的背景音乐。
AI 确实改善了开发者的日常工作。无论是开发开源框架，还是在公司工作，我都受益于它的智能补全、样板代码生成、快速探索解决方案和辅助调试。在许多任务上，它带来的效率提升无可否认。
但当生产代码几乎不花钱时，我们很容易只想着多生成一些，而不是把软件做好。
大语言模型（LLM）可以在很短的时间里生成上千行代码。可如果限界上下文没划清、职责混乱、要实现的业务价值也不明确，那你得到的只是更快生成的糟糕代码。技术债也跟着以光速积累。
这和二十年前 MDA 的承诺一样，只是更有说服力了，而这恰恰让它更危险。
模型驱动架构的问题摆在明面上：一些 UML 生成器产出的代码僵硬又冗长，问题很容易被看出来。AI 生成的代码却看起来没什么问题。它能编译，能通过常规场景的检验，也像是开发者自己写出来的。那些"凑合能用"的不足被掩盖了，比显而易见的失败更难应对。
危机，不在技术上
我担心的下一场软件危机，不只是"AI 写的代码有 bug"。即使模型继续进步，生成代码在语法和功能上越来越正确，但下面的问题仍然存在：
缺少设计意图的代码拼不成系统，只会堆在一起。
如果你还记得我开头的那个问题：AI 做的游戏，客户改需求了，这个项目还能接着改吗？读到这里，应该就能明白我为什么想看"第二期"了。
改第二版时，我们得弄清原来的代码为什么这样写，新需求会影响哪些地方，以及改完以后，原有功能还能不能正常工作。这些都要回到前面说的业务理解、代码质量和架构上。
如果做出一个能运行的 Demo，就足以证明 AI 可以替代软件开发，那打开 Android Studio，选个模板，不也能创建一个可以运行的 App Demo 吗？
没有清晰的架构，多次生成的代码就容易各行其是。没有共享的领域模型，AI 可能随着提示词的变化，引入彼此不一致的抽象。缺少对代码整洁度的要求，可读性也容易越来越差。而代码被阅读的次数，远远多于被编写的次数。
可测试性、可维护性和整体一致性，这些让软件经得起时间考验的性质，不能指望 AI 自动保证。如果给它的上下文和验收标准只覆盖局部，它就容易只顾眼前的函数或任务。即使 AI 能参与跨模块规划，全局仍然需要我们把关。
想到刚入行的学生，我更担心的是：如果开发者在掌握设计、架构和工程基本功之前，就先学会了用 AI 写代码，谁还能看出系统正在偏离方向？
下一份宣言
历史总在重演。软件行业经历过的几次危机，都推动人们重新审视自己的价值观，有时也催生了新的宣言，让我们重新回到基本功。
如果这次也一样，下一份宣言要讨论的将是"意义"。它会提醒我们，软件开发从来不只是写代码，更需要人的智慧。AI 应该为这种智慧服务，而不能取代它。
这份宣言的基础已经有了，来自过去三十年付出代价才学到的经验。
TDD 帮助我们设计软件、明确规格，一份写得好的测试，往往比泛泛的提示词更能说明预期行为。我们也可以借鉴结对编程的分工，让开发者掌舵，AI 执行。DDD 仍是创造工作的核心，因为业务知识和约束需要我们提供，AI 对领域的推断也需要我们验证。
整洁架构为代码生成划定边界，让生成的代码保持一致。整洁代码则要求我们练好阅读代码的功夫，因为审查并非自己编写的代码，如今已经是每个人的工作。
工具也在跟上这种思路：AI 的"计划"模式、反复迭代提示词、规格驱动的工作流，都开始体现同一种开发过程：先思考，再生成，随后不断调整，直到代码真正表达我们的意图。这些基本功不会妨碍我们使用 AI，恰恰是它能发挥作用的前提。
架构始终是软件的根本，今天或许比以往更重要。
这份信念也指引着我目前的工作。
在 Android 生态中开发多年，我反复看到同样的现象：做得好的开发者，靠的不是代码写得最多，而是结构上的决策做得最好。
因此，帮助工程师把握架构、在大规模系统中做出正确决策，才是重中之重。如今，AI 让生成代码变得前所未有地容易，却没有让理解代码同样容易，架构上的判断也就更有必要。
Éric Sadin 警告的"认知剥夺"，是指我们逐渐把思考和创造的能力让渡给 AI。他的批评触及了一个根本问题：如果我们连写代码之前的思考也一并交出去，包括理解问题、建立领域模型、权衡架构方案，那么我们就会走向一片"意义的荒漠"。他所描述的意义流失并非不可避免。只有当我们忘了把正确的价值观放在核心位置时，它才会发生。
Kent Beck 写过，勇气是软件开发的一项基本价值。
今天，我们也许需要一种新的勇气：暂时不生成代码的勇气。先设计、先建模，再输入提示词。在这个催着人几秒钟内给出答案的世界里，敢于说："我们还没有充分理解这个问题。"
二十年前，就有人说开发者以后再也不用写代码了。而我这十多年的工作经历让我明白，价值一直都在代码之前的理解里，而不在代码行数里。AI 没有改变这一点，只是让它变得更加迫切。
这关乎我们一起构建什么，又为什么要构建。基本功已经有了，现在该让它们在 AI 时代派上用场了。
下一次软件危机，不会出在写代码上。