ARTICLE · 1157409
AI时代,真的“是个人都能开发软件”吗?
AI时代,真的“是个人都能开发软件”吗?于是有些管理者开始畅想：不再需要架构师，不再需要资深工程师，甚至不需要开发团队，只需要几个会打字的人，就能批量生产软件。 开发人员的高薪、话语权、不可替代性，统统成为历史。听起来无比美好，但这美好建立在什么之上？不妨用“盖房子”来打一个比方。这个比方可能不太优雅，但足以揭开那张画皮。 你说：“我要一栋黄色顶、红色墙的房子。”AI很快给你生成了一张效果图，或者一套施工方案。你看了一眼，黄顶红墙，完全符合描述，连瓦片的纹理、墙面的色泽都像模像样。你觉得满意，甚至觉得盖房子不过如此。 但是，你拿到的是用黄色稻草做的顶、红色泥巴糊的墙。远看和真房子无异，近看也挺精致，可一阵风过来，墙皮簌簌落下；一场雨下来，屋顶直接塌了。你质问施工方，他们却说：“你要的就是黄色顶、红色墙，我们做到了。” 这就是当前许多人对AI开发软件的认知。他们对着某款对标产品，或对着脑海中隐约的界面形态，给出一些“表面需求”：要一个登录页面，要有订单列表，要有支付按钮，要能查数据。AI也不负众望，迅速生成一个原型，界面相似，按钮齐全，点击后也能蹦出几个弹窗。 在演示的几十分钟里，它活灵活现，好像完全可以投入生产。你把它当成成品验收，直接上线。然后，用户一来，并发一上来，数据量稍微像点样子，系统瞬间卡死、崩溃、报错、丢失数据。 你愤怒地找到开发人员，开发人员摊开手：你描述的需求里，根本没有负载均衡，没有数据库索引，没有事务回滚，没有缓存策略，没有安全防线，没有异常兜底。你要的只是一张黄色的顶和红色的墙，我给了你，但风吹雨打，不在承诺范围内。 这不是AI的问题，这是需求描述的问题。但更可悲的是，很多管理者认为只要自己写得出需求描述，就掌握了软件的定义权。于是他们把AI生成的“伪房子”当成了真房子，把开发人员的质疑当成不配合，把交付后的崩塌归结为运气不好或团队无能。 殊不知，你连一张完整的结构图纸都没画，凭什么要求房子能抗台风？ 
吃了第一轮亏，有些人开始进步了。他们说：“我要用黄色瓦片做顶，红色砖砌墙，木头做柱子，盖一栋2000平米的房子。”这个需求比上一个具体了不少：知道了材质，知道了面积，甚至还区分了承重结构。 施工方按照要求，认认真真用了黄瓦、红砖、木柱。结果呢？屋顶当初只考虑了颜色和形状，却不知道黄色瓦片该选什么容重、什么防水等级；红砖砌墙没问题，但墙体的厚度、砂浆标号、构造柱、圈梁一概没提；木头柱子确实用了，但立在关键位置了吗？承受得住屋顶荷载吗？防潮防腐抗震防火指标如何？统统没有。 最后房子盖好了，在无人居住、无风无雨时，看起来挺像回事。请三五个朋友喝茶没问题，二三十个人参观也撑得住。可是一旦正式投入使用，楼上楼下住满人，家具设备一压，柱子吱嘎作响，墙体出现裂缝，甚至局部坍塌。 对应到AI软件开发，这是第二层认知盲区。有些人确实接触过一点技术概念，知道“后端”“数据库”“微服务”“高并发”“缓存”这些词汇。于是他们把这些名词一股脑塞进对AI的描述里：“要使用微服务架构，使用Redis缓存，MySQL数据库，还要做分布式部署。” AI听了，也照做了。生成的项目结构里确实有微服务模块，有Redis配置，有数据库表，有集群部署的yml文件。但微妙之处在于：这些技术被用在了错误的地方。 缓存没有设置合理的过期策略，导致数据一致性一团糟；微服务被无意义地拆分，服务之间调用链混乱，一个请求穿十几个节点，延迟高得离谱；数据库表设计没有考虑业务关系，索引缺失，一条简单的查询都能拖垮整张表。 在开发环境，数据量大概几十条，并发用户三五个，一切正常。你甚至还会觉得“有点快”。可一旦上线，真实用户涌进来，数据量从几十条变成几十万条，并发从个位数变成几百几千，系统立刻原形毕露。快是假象，慢是天灾，崩是宿命。 为什么会这样？因为知道一个名词的读音，并不等于理解它背后的原理和适用场景。你能写“微服务”三个字，但你不知道什么时候该拆分，什么时候该合并，不知道服务间如何治理，不知道分布式系统的最终一致性意味着什么。 你能让AI配置一个Redis，但你不知道缓存击穿、雪崩、穿透的区别，更不知道如何设计缓存更新策略。在不需要Redis的地方强行加缓存，在不需要微服务的地方强行拆模块，就好比用木头柱子撑二十层大楼，柱子本身没毛病，但放错了位置、选错了规格、忽略了受力分析，最后只能是灾难。 更可怕的是，这种“一知半解”往往比“一无所知”更具迷惑性。一无所知的管理者至少还有敬畏心，而一知半解的管理者觉得自己“懂技术”，能够指挥AI，能够评判开发人员的产出。 他们在AI对话窗口里重复着那些从微信公众号文章里看来的术语，把拼凑出来的“技术栈描述”当成建筑设计图，然后质问：为什么你写的代码结构和我想的不一样？他们看不见的是，技术从来不是名词的堆砌，而是取舍、权衡、预判和兜底。同样一句话，背后的工程含义可能相差百年。 
现在，让我们想象一位真正懂得盖房子的人。他要造一栋古风宫廷建筑，要求是：覆盖面积2000平米，高度10米，既要保留古风韵味，又要满足现代安全标准。他怎么说？ 他不会只喊“黄瓦红墙”。他会说：顶部采用高强度材料制作仿瓦片结构，兼顾外观与耐久性；下方采用三角钢结构支撑，并根据建筑面积和材料重量计算承重构件的间距和角度。 墙体内部采用混凝土框架结构，设计承重柱分布，结合顶部荷载计算受力模型，满足不低于8级抗震设防要求。墙体根据建筑面积和高度计算采光与通风需求，确定窗户位置、大小和角度。墙体表面采用特定涂料与工艺涂装，既防腐防潮，又保持古建肌理。 地基结构根据整体建筑重量和场地土质进行专项设计，确保沉降量可控、整体稳定。走廊上的木质立柱采用真正的木材，但只做装饰性用途，表面做碳化防腐处理，底部和顶部采用金属构件与主体结构可靠连接，既保持视觉传统，又避免木材承重带来的安全隐患。 这番表述，才是完整的、可以指导施工的、能建出一栋真正百年建筑的描述。最终交付的成果，筋骨是钢筋和混凝土，表皮是仿古瓦和涂料，装饰是防腐碳化木。它扛得住暴雨狂风，也撑得住密集人流，更经得起时间检验。远看是古风，近看是现代工程，无人敢说它是“伪房子”。 对应到AI软件开发，这才是真正的“会与AI协作”的姿态。他不是把AI当成凭空变软件的魔法师，而是当成一个具备极强执行力的施工队。他要提供的是设计蓝图，是施工规范，是验收标准，是兜底预案。 他深入理解业务背后的核心需求：哪些是用户真正要的，哪些是伪需求；哪些功能必须弹性伸缩，哪些逻辑必须事务一致；哪些数据需要强约束，哪些只需要最终一致；哪些路径要实时响应，哪些可以异步处理。 他结合技术原理做出选型：不用最花哨的框架，而用最合适的工具；不为赶时髦引入微服务，而根据团队规模和业务阶段决定架构复杂度；不为“显得有AI含量”而堆砌模型，而是让算法在真正能产生价值的地方发挥作用。 他会提前考虑失败场景：数据量翻十倍怎么办，流量洪峰怎么办，第三方接口挂了怎么办，关键服务被攻击怎么办，某个核心同事离职了怎么办。这些思考，才是软件能够“上线稳定运行”的根本支撑。 而这些东西，恰恰是“是个人”就能跟AI聊出来的吗？恰恰是那些“价值论”信条中不值钱的吗？恰恰是靠“AI对话记录”就能交付的吗？远远不是。 
当前大量使用AI开发软件的人，其认知状态可以用一个词形容：把提问当设计，把生成当交付，把运行当合格。 他们以为，只要自己的语言描述足够贴近最终界面，AI就能实现背后的一切。但他们没有意识到，界面只是软件的外皮，就像一个建筑的外立面。真正支撑软件稳定运行的是：数据模型的设计是否合理，接口的定义是否严密，权限体系是否闭环，异常处理是否完备，日志监控是否到位，灰度发布机制是否健全，容灾备份策略是否可靠。 这些全是AI生成代码时不会主动为你考虑的“隐性工程”。AI更像一个经验丰富的搬砖工，你给它一个精细的图纸，它能高效地砌出合格墙体；你给它一句“盖个黄色顶红墙的房子”，它也只能还你一堆稻草和泥巴。 更危险的是，很多无知的推动者正在把这种“画符”式开发包装成“AI普惠大众”的进步。他们讲出“人人都是产品经理，人人都是开发”，本质上却是在为自己的“AI包办一切”想象买单。 他们开始削减技术岗位，压缩开发资源，要求工程师在更短时间内交付更复杂的系统，而理由仅仅是“AI已经很厉害了，你为什么还要那么久？”当系统崩了，他们不会反思自己的需求描述有多么糊弄，不会审视自己连“高可用”和“高并发”的区别都说不清，反而会指着那堆风中飘摇的“黄色稻草顶”说：AI这工具不行，给我换一个能生成稳定房顶的工具。 问题出在工具上吗？工具确实不完美，但工具被你用来完成了一项它本不该独自承担的任务。你没能描绘出承重结构、材料参数、抗震等级、地基方案，却指望工具把所有隐藏的工程智慧一次性补齐。这可能吗？ 诚然，AI的发展会降低很多技术门槛，但它降低的是实现层、编码层的机械成本，而不是设计层、架构层、判断层的心智成本。你告诉AI“我要一个电商系统”，AI能生成一堆增删改查的代码；但当你试图支撑千万级用户、处理超大规模商品数据、应对复杂促销规则、保障支付系统安全时，你依然需要一位真正理解系统架构的工程师来主导方向。 回到主题：用AI开发软件，真的是“是个人都会”吗？这个问题本身就混淆了“启动一个项目”和“交付一个系统”之间的界限。 任何人打开AI对话框都能生成一段代码、一个界面、一套原型，这没错，就像任何人开口都能说“我要一栋黄色顶红墙的房子”一样。但“说”从来不是“建”。真正的交付是从一句模模糊糊的愿景出发，层层拆解成精确设计，再结合材料力学、结构工程、施工组织、质量检验等一系列复杂决策的结果。 没有这些，你得到的只是一张渲染图，一栋经不起风雨的伪建筑，一段经不起流量的伪代码。 所以，那些认为开发人员毫无价值、可以无限压榨的管理者，或许应该先问问自己：你给AI提供的是“我要一座宫殿”的幻想，还是一份能指导建造的完整蓝图？如果你连建筑和废墟的差别都看不出，那真正需要被替代的，恐怕不是开发人员，而是你那套“是个人都会”的傲慢。 软件开发从未变得简单，它只是把“低级劳动”和“高级劳动”分开得更明显了。AI能帮你搬砖，但不能替你看图纸；能帮你敲代码，但不能替你做架构。 你尽可以继续对着AI打几行字就宣布“软件已生成”，但当服务器发出尖锐警报的时候，你最好已经找好了能真正看懂那堆代码的人。否则，风一吹，雨一来，塌在地上的，不仅是房子，还有你关于“AI替代一切”的幻梦。
AI时代，真的“是个人都能开发软件”吗？
近来有个论调颇为流行：AI都能写代码了，软件开发还有什么技术含量？找个业务人员跟AI聊几句，软件就出来了。
第一阶梯：我要一栋独特配色的房子，交付一栋风雨飘摇的伪房
第二阶梯：知道几个名词，就能盖出合格建筑吗？
第三阶梯：真正的建筑是怎么诞生的？