混沌随想2025年9月20日
软件设计在 AI 编程时代还有用吗
#AI 编程的趋势
当前 AI 编程流行 “vibe code”——即氛围编程。 什么是氛围编程呢？ 简而言之，它只看效果，说出需求，其他全部扔给AI。发现哪里不满足？只需再次告诉AI，“马上调、马上反馈”，沉浸感拉满，所以也叫“沉浸式编程”。
在它披上 “vibe code” 名词之前，这种 AI 编程的方式其实已经被很多人应用：它是最自然，且符合直觉的自然语言编程方式。丢弃那些高级编程语言的语法，不管是 java、python、js、ts、rust、c++ 等，忘记那些框架的 API，不管是 react、vue 或是 django、 spring等。“vibe code” 就是全程自然语言驱动，不断反复让对 AI ： “说想法 —> 看结果—> 继续优化 —>再出结果” 的循环里实现功能。
说实话，这几乎是我近 1-2 年的大部分工作方式。这种编码方式会迫使你像一个无情的老板，不断指挥着你的下属工作，能自己不动手，尽量自己不动手。 这种工作模式会塑造的编程思维方式，甚至可以让人极端到， 我明明看出了 AI 把某个地方改坏了，我只需要把光标移动道某行，轻松的键入一个文本就能修复， 但我却还要不厌其烦的指挥 AI：“你去把那个地方修复好，应该这样，而不是那样 XXXX ” 等喋喋不休之类的话。 咋一看，似乎不如自己改来得快，但好处是: 人的思维负担非常低，你几乎能同时并发的让 AI 同时完成大量任务，就好比老板们不会亲自动手，可以靠语言指挥一堆人干活，从而不用陷入太多细节而分散了自己的精力。一个人干活变成指挥 N 个 AI 任务，这种效率不言而喻。
但我不喜欢 “vibe code” 这个名词，它没有指出任何编程的方法论，或者和 AI 交互的技巧。更像是“自然语言”替代“人工 coding”的包装。
并且大量 “vibe code” 隐形的痛点没有指出，网上有一个调侃 AI 编程的段子： AI 八荣八耻。
经历过 “vibe code” 编程，并且和 AI 反复对话博弈过的同学应该会被这上面这个图戳到痛点：AI 并非无所不能，有时候会让你疯掉。
事实上，笔者认为这个痛点，正是我们不恰当使用了自然语言指令 ，或者说 “vibe code” 这个名词带来的误解。"vibe" 给人一种，人类可以下达非常自由、任性的指令，没有指出人应该如何和 AI 协作本身。并且 “vibe code” 的传播让很多人以为，我们真的不再需要掌握编写代码，不再需要熟悉语法、甚至打破传统几十年以来沉淀的软件开发实践，可以丢弃掉诸如设计模式，设计原则等之类的经典方法论。
这些言论的背后的论点也很简单：人类不再关注代码本身，而是转成上层的自然语言表达，那传统的给人看的设计模式和原则又有什么必要呢？
但这正是今天笔者想要反驳和澄清的地方：“vibe code” 是 AI 编程的趋势，但自然语言编程的方法论却依旧无法离开经典的软件设计方法论，以及人类对软件过程的深入洞察。
#为何有软件设计模式
笔者在这里所讨论的设计模式不仅仅包括 Erich Gamma 所谈论的《24 种经典设计模式》， 还包括了任何对代码设计提高有帮助的编程手段，诸如：高级语言、编程范式、设计原则等。
最早的编程语言是二进制，人们敲下 01 01 01 来实现功能，每一步都得精确到机器层面。后来有了汇编，用助记符代替机器码，稍微贴近了人类思维。再往后是高级语言的出现，C、Pascal、Java 等，逐步抽象，让程序员不再纠缠于寄存器和内存地址。
但问题依然存在：代码越来越复杂，goto 语句像野马一样四处跳跃，程序结构混乱，维护困难。于是结构化编程被提出——用顺序、分支、循环来组织逻辑，大大降低了理解成本（《架构整洁之道》的作者在书中提到当年历史，我们如今常见的 if-then-else ，do while 等设计在当年是经历过无情的嘲讽，然而这些设计是现代模块和组件拆分的基本理论）。再后来，面向对象编程兴起，封装、继承、多态，把数据和行为打包成对象，进一步贴近人类对现实世界的认知方式。
这一路演进的核心，其实是减轻人的思维负担。
从 LLM 的底层原理看，AI 也是“人”——这里的“人”，是指一个需要理解问题、组织逻辑、输出结果的智能体。它的注意力同样有限，处理能力也有上限。如果你让 AI 直接生成汇编代码，它得考虑寄存器分配、内存布局、跳转地址……细节爆炸，出错概率陡增。而如果让它用高级语言、结构化的方式表达，逻辑清晰，复用性强，效率自然提升。
这些设计方法论，它们不仅仅是给人类程序员看的“圣经”，更是我们与 AI 高效协作的“通用语言”和“脚手架”。在 “vibe code” 模式下，我们可以用自然语言驱动 AI 明确地指挥： “用单例模式管理配置”，而不是模糊地说“搞个配置变量”。 如果你尝试通过 vibe 对 AI 说 “整合支付宝和微信支付，实现支付功能”，AI 给出的代码方案是无穷的，可以把支付逻辑和订单逻辑搅和在一起，也可以分开实现，堆砌全局变量飞来飞去。但如果你调整指令：“遵守单一职责原则，把支付服务抽成独立模块，使用接口隔离，支付宝和微信实现同一个 PaymentGateway 接口”，AI 瞬间能理解，并按你的方案执行。
这样，不仅减轻了我们的负担，还让 AI 像个靠谱的下属，避免那些八荣八耻的坑。别指望 AI 靠蛮力解决一切，我们要做的，是像当年设计高级语言那样，为 AI 构建更合适的表达方式——让它的思维有结构，有模式，有抽象。
#AI 编程的新内核
当我们借助 “vibe code”，将双手从繁琐的语法和样板代码中解放出来时，一个普遍的误解是：我们似乎可以丢弃那些沉重而“过时”的软件工程能力了。然而，现实恰恰相反。这种新的工作模式，非但没有降低对工程师的要求，反而对我们的软件设计和架构能力提出了更高挑战。
过去，我们的价值很大程度上体现在对语言细节的精通和对框架 API 的熟练运用上。但在 AI 编程时代，这些实现层面的工作被大量外包给了 AI。人类工程师的角色，正不可逆转地从“代码实现者”转变为“系统设计师”和“技术决策者”。我们的核心任务不再是“如何写”，而是“应该怎样设计”。我们需要向 AI 下达清晰、正确且高质量的指令，而这些指令的源头，正是我们对软件架构、设计原则和业务逻辑的深刻理解。
想象一下，给一个完全不懂编程的产品经理一个功能强大的 “vibe code” 编辑器，让他去实现一个复杂的电商交易系统。他或许可以对 AI 说：“给我创建一个订单页面”。AI 确实能生成一个看起来不错的界面。但接下来呢？他知道应该如何设计订单状态的流转吗？他会要求 AI 将库存服务、支付服务和物流服务进行解耦吗？他能判断 AI 生成的方案是否考虑了前后端通信，测试、生产、接口对接、联调等工作吗？
答案显然是否定的。这正是问题的关键所在：AI 能够高效地铺设砖瓦，但它无法独立绘制出宏伟而坚固的建筑蓝图。 这份蓝图，源自人类对现实业务的抽象能力，对系统复杂度的控制能力，以及对长期可维护性的预见能力。我们必须持续地和产品、业务方深度互动，将模糊的、多变的需求，精准地翻译成稳定、合理的技术模型和架构决策，最终再将这些决策作为“指令”交由 AI 去执行。
因此，软件开发的内核——理解问题、拆分问题、构建模型、保证质量——丝毫没有改变。我们只是将工具从键盘和编译器，升级为了一个需要更高层智慧去驾驭的强大 AI。如果我们自己脑中没有清晰的架构和设计，那么我们给 AI 的指令必然是混乱的、摇摆的，最终得到的也只会是一个难以维护的“代码垃圾堆”。“vibe code” 加速了从思想到代码的过程，但前提是，你必须先有“思想”。
#AI 亦能协助人类设计
既然人类工程师的重心已经上移至“系统设计师”，那么设计过程本身，是否依然是人类独有的？答案并非如此。过去，一个架构师在做技术选型时，需要依赖自己多年的经验积累，或花费大量时间去调研、对比不同方案的优劣。而现在，我们可以把 AI 当作设计的“陪练”或“副驾驶”。当你构思一个功能模块时，完全可以向 AI 发起一场技术探讨：
“我正在设计一个高并发的秒杀系统，请给我提供三种主流的架构方案，并用表格对比它们的优缺点，包括技术栈、瓶颈和适用场景。”
AI 不仅能迅速罗列出基于分布式锁、消息队列或缓存的方案，还能就每个方案的细节展开讨论。它甚至可以根据你的追问，生成方案的初步代码、关键配置，乃至绘制出相应的架构图（例如生成 Mermaid 语法）。在这个过程中，AI 扮演了一个知识渊博的顾问，它极大地拓宽了我们的思路，并把我们从繁琐的信息收集中解放出来，让我们能将全部精力聚焦于权衡利弊和“设计决策”本身。同样的，你可以将一段初步的设计思路和草案扔给 AI，并向它提出指令：“请以 SOLID 原则审视这段代码，并提出具体的重构建议”，或者说：“让我们退回到最基础的软件设计，分析一下这个模块是否有任何问题？”。LLM 会基于它庞大的知识库，给出通常八九不善离十的反馈。
但所有建议都需要由人类最终裁定，它可能会缺乏对特定业务背景的深入理解，也可能无法预见现实妥协的问题。毫无疑问，这种人机协作设计，是AI 编程时代工程师的核心竞争力之一。
#规模困境
代码行数越少，对高级设计的依赖也越低。对于一个仅有几百或几千行代码的工具或脚本，LLM 的上下文窗口几乎能全部覆盖，其注意力也能很好地处理所有细节。在这种场景下，AI 一次性生成高质量代码的能力非常强，对人的依赖也降到了最低。
然而，现实世界中的软件项目规模分布并非如此。我们可以用一个简单的关系图来描绘这种挑战：
上面是随手用绘的（数据大概给的不需要当真），主要想表达两个现状：第一，人类干预程度与代码规模正相关。第二，绝大多数的商业项目，其代码规模恰好落在几万到几十万行这个“陡峭爬升”的区间内。只有少数 MVP 或小型工具位于曲线的起点，而超过百万行的巨型系统则是少数。
这正是“vibe code”的困境所在。当项目进入中等规模后，AI 无法一次性关注到所有细节，它看不到那些没有在上下文中明确提出的隐形业务逻辑，也无法理解项目中积累的历史问题和技术债。此时，如果你仅仅是“氛围式”地提出需求，AI 很可能会在修改中顾此失彼，破坏原有的设计。
这些工作，必须由人类工程师在“vibe code”的过程中明确地告知 AI。有效的做法是，为项目维护一个良好的 AI 指导文档（类似一个 PROJECT_README_FOR_AI.md，cursor 和 claude code 等都有类似设计），将项目的核心架构、关键业务规则、重要模块的职责、需要避开的“坑”等信息进行浓缩抽取，在每次与 AI 交互时，让它能够“看到”这份蓝图。
对于更大型的项目，人类则必须牢牢掌控方向盘，持续进行高阶的提示和纠偏。但 AI 好处依然显著：即便是在搭建巨大的建筑，你也基本上不再需要亲手去搬砖了。
#避免发疯
“vibe code”这个名词也许是让大多数人误导，并陷入和 AI 对代码修改的左右博弈疯狂的罪魁祸首。它给出了错误的心理暗示：编程可以是一种随性的、跟着感觉走（vibe）的行为。然而，软件工程从来都不是靠情绪和氛围驱动的，它是一门关于代码设计与业务权衡的艺术，把和 AI 的对话从 “vibe” 变成更严肃的工程对话，能避免更多的发疯。
让 AI完全发挥，不如由人先深入思考业务，给出基本洞察。让 AI 自由编写，不如人和 AI 一起思考和讨论出架构方案与约束，再由 AI 提供选型对比和细节参考。让 AI 自由生成代码文件和目录，不如花几分钟人为的思考拆解任务和模块，AI 再负责生成具体的实现代码。
在这个对话循环中，AI 承担了几乎所有的“体力活”，而人类则专注于最核心的创造性工作：思想与决策。我们并没有丢弃传统软件工程能力，而是将它们运用在了更高的维度上。我们必须能随时理解 AI 生成的任何代码，并在必要时接管它、修正它，因为我们才是那个唯一对最终系统质量负责的人。
所以，忘掉“vibe”。编程的未来，不是放弃软件设计和思考，而是更纯粹地聚焦于思考。
——————
文档信息
发表时间：2025年9月20日
笔名：混沌随想
版权声明：如需转载，请邮件知会 imwangfu@gmail.com，并保留此文档信息申明
更多深度随想可以关注公众号：混沌随想
知乎：混沌随想
——————
更新时间:
基于 AI 自动同步自 imwangfu.com2025年9月22日, 08:45:43
基于 AI 自动同步自 imwangfu.com
