Vibe Coding下的架构师思维
过去一段时间，笔者频繁尝试用ChatGPT、Copilot以及它们的Agent模式来开发软件、编写代码。目的是想看看AI开发的极限在哪里，或者它的最大问题和最大的帮助在哪里？随着使用的深入，笔者逐渐摸索出一条新的开发路径：
把AI当作团队里的“初级开发人员”，而笔者自己则承担架构师、产品经理和代码审查员的多重角色。
这种方式并不是让AI替代程序员，而是让它成为开发协作的一部分。AI的速度和创造力，配合架构师的判断与取舍，最终形成了一种强调节奏感、强调人与AI之间分工边界的开发方式。
本文是分享笔者总结出的Vibe Coding过程中的几个关键步骤，以及在这些步骤里AI能做什么，不能做什么。
一、需求确认：AI 是最好的“问题放大器”
在软件开发中，需求阶段往往是最容易出现疏漏的，需求模糊、描述含糊、遗漏边界情况，都会导致后续开发中出现返工，或者大量的沟通，好的开发人员或许会主动寻求产品经理的确认，但也有开发人员会按照自己的理解进行开发，但会造成结果偏差，尤其是在产品经理和软件测试无法覆盖的部分。
AI 的优势在于，它会不停地追问你：
“你是否考虑过性能？”
“如果数据量扩大十倍，还能正常工作吗？”
“是否需要考虑多用户并发访问的情况？”
这些问题有时候显得多余，但它们确实能帮助我们发现需求中遗漏的点。比如，笔者利用AI编写一个视频处理的工具，最开始我只描述了“从视频中截取字幕”，但在需求确认中，AI却进一步确认：
是否要区分不同的字幕类型？
是否要考虑视频的文件格式？
输出的结果是否要考虑多批次？
这让原本以为是一个“简单的小工具”进一步涉及到输入数据的范围、输出结果的格式、性能的要求等多个问题。换句话说，AI把原本模糊的需求“照亮”了，迫使我们要更清楚地定义边界。
所以，在需求确认阶段，我会和 AI 反复来回对话，把需求梳理到足够清晰。这个过程很像是在开发前进行“需求评审会议”，这让最终得到的需求文档，比我单独思考时要更完整和缜密。
二、技术方案：架构师的“刹车”
需求确认之后，下一步就是设计技术方案。AI在这一环节的表现非常有趣：它往往会倾向于提供一个“大而全”的解决方案，或者说很多时候是杀鸡用牛刀。
比如，让AI设计一个简单的文件处理工具，它可能会给出这样的方案：
使用微服务架构来解耦不同模块；
引入消息队列以实现异步处理；
提供REST API接口方便未来扩展；
增加缓存层来优化性能；
使用容器编排系统以支持大规模部署。
听上去很美，但这对于一个临时性的小工具来说，显然是严重的过度设计。AI的思路更多像是“教材式的完美解答”，它希望覆盖所有的边界情况，展示出“专业感”。但在真实的项目里，这种“大而全”会带来巨大的负担：复杂度上升、学习成本增加、维护难度飙升。
这时就需要架构师来踩刹车。笔者的原则是：
区分当前需求与未来扩展：如果只是临时工具，就不要引入多余的技术栈。比如，一次性的数据清理脚本，完全可以硬编码输入输出，不必额外做参数化。
保持最小可用（MVP）：先解决问题，再考虑扩展。AI的答案里常常包含“扩展性的诱惑”，但扩展性是有代价的。
方案是阶段性的，不是终极性的：架构不是一次性设计好，而是随着需求演进不断调整。
一个形象的比喻是：AI提供的是“全套装修设计方案”，包括豪华吊顶、全屋智能家居、未来可扩展的地下酒窖。但你此刻的需求可能只是“租个房子住半年”，那最合理的方案就是买几件简单的家具。架构师的职责，就是在豪华方案和实际需求之间找到平衡。
三、框架搭建：地基必须自己打
技术方案确定了之后就是项目的框架搭建。笔者的经验是，这一步必须由我们亲自完成。
原因很简单，AI 在这方面有个致命的缺陷——它喜欢生成复杂的结构，而且常常没有全局观。比如，它可能会：
生成层层嵌套的目录结构；
引入多个配置文件和脚本；
创建很多你暂时用不到的辅助模块。
这些东西短期内看似“专业”，但长期维护却非常痛苦。因为你并不了解这些结构是如何拼接起来的，就像你搬进了一栋别人装修好的房子，插座、管道、线路全都被藏在墙里，你完全不知道它们的走向。
所以，笔者坚持自己搭建项目的核心框架，包括但不限于：
项目文件结构；
Docker镜像和环境配置；
数据库表设计和核心数据结构；
核心服务之间的调用关系。
只有亲手完成这些，后续才能在维护和扩展时心里有数。AI可以帮我们写一些初始化脚本，但最终的“地基”，必须自己来打。
四、单元开发：让 AI 做重复劳动，但要“守住边界”
当框架搭好之后，就进入了具体的单元开发阶段。这一步才是 AI 发挥最大价值的地方。比如：
写数据处理的循环；
实现一个常见的算法；
生成测试用例；
搭建接口的基本逻辑。
这些重复性、机械性的工作，AI 可以快速完成。但这里有两个关键原则：
1. 我来控制输入和输出
如果让AI自行决定函数的输入和输出格式，很容易导致整个项目的数据流失控。不同函数之间可能使用不一致的数据结构，逻辑也会因此变得混乱。
所以，我会明确告诉 AI：
输入是什么？
输出是什么？
中间的处理逻辑只在这两个边界内完成。
这样可以避免整个系统演变成“拼凑式”的产物。
2. 必须审查逻辑
即便是纯逻辑性的代码，我也会逐行检查。因为AI有时候会“自作聪明”，把简单问题复杂化。
举个例子：本来一个正则表达式就能解决的字符串匹配问题，AI却通过子字符串的处理逻辑写成了十几行处理语句。这样不仅性能下降，而且让代码难以维护。久而久之，整个项目就会被无意义的复杂性淹没。
因此，我会像PR审查一样，逐行检查AI生成的内容，确保逻辑合理、简洁和可维护。
五、AI 编程的核心：架构师与实习生的关系
整体看下来，Vibe Coding更像是一种进化后的软件协作：
AI就像团队里的初级开发，负责写代码、产出样板、处理重复劳动。
人类架构师则负责全局把控：需求澄清、方案决策、框架搭建、逻辑审查。
这和基于架构的开发流程非常相似，只是把原本的初级开发工程师替换成了AI。区别在于，AI的速度远快于人类，而且不会抱怨。但同时，它缺乏全局思维、缺乏取舍能力，所以不能放手让它独立工作，虽然很多时候它确实可以攒出一个可用的结果。
在这种模式下，架构师的角色反而更加重要：
架构师不是被AI替代，而是被AI解放出来，去做更有价值的工作。
不再沉溺于无休止的CRUD代码，而是专注于需求、产品和架构的平衡。
小步快跑，用AI的速度加快迭代，用人的判断保证质量和维护性。
所以，Vibe Coding中的所谓Vibe，不仅仅是氛围，更是节奏感。
AI提供的是速度和能量，但如果没有架构师的节奏控制，项目就会在复杂性里失控。相反，如果人和AI能形成清晰的分工，保持小步快跑的节奏，开发过程会变得既高效又可靠。
至少目前，AI不是万能的全栈工程师，而是一个效率极高的初级程序员，真正的掌控权，必须在架构师手里。
未来的软件开发，可能会越来越像今天这样：人类负责方向与节奏，AI负责执行与产出。人机协作，而不是单方面替代，才是AI编程真正价值的所在。