夜雨聆风
最近，AI Coding工具越来越强。即使不懂编程，只要把需求描述清楚，也可以让AI生成页面、接口和数据库，很快做出一套能够运行的软件。
于是有人认为，以后只需要产品经理或行业专家，不再需要程序员。
这个判断只说对了一半。
对于有软件工程经验的人，AI是强大的效率工具，AI生成的代码当然可以上线。问题在于：
AI降低了写代码的门槛，却没有自动赋予不懂编程的人完整的软件工程能力。
产品功能清楚，不代表系统方案清楚
假设要开发一个AI直播系统。观众在直播间提出问题，系统识别语音或文字，调用大模型生成答案，再通过语音合成和数字人实时回答。
产品经理可以把流程描述得很清楚：
接收问题，理解问题，生成答案，数字人口播。
AI也能很快做出一个Demo。但真正上线时，还要回答很多产品需求中没有的问题。
语音识别、大模型回答、语音合成和数字人渲染，是放在一个程序里依次执行，还是拆成多个独立服务？服务之间采用HTTP同步调用，还是通过消息队列传递任务？
直播要求实时响应，如果每一步分别耗时一两秒，最终用户可能要等待十几秒。系统是否要采用流式语音识别？大模型生成到一半时能否提前合成语音？声音和数字人的口型怎样保持同步？
这些已经不是页面和功能问题，而是系统架构问题。
难点不是生成代码，而是组织整套系统
一套AI直播系统可能同时使用CPU、GPU、数据库、Cache、对象存储和消息队列。
音频采集和格式转换可以使用CPU，大模型推理、语音合成和数字人渲染可能需要不同GPU。哪些模型长期驻留显存？不同型号的GPU分别运行什么任务？直播任务和离线视频生成任务如何争夺计算资源？
观众的会话状态放在Cache还是数据库？知识库和用户资料如何读取？生成过的相似答案是否缓存？直播录音、字幕和视频片段保存在哪里？
Cache可以提高速度，却会产生失效和数据一致性问题；消息队列能够削峰和重试，却可能让实时回答变慢；所有模型部署在一台机器上最简单，但其中一个环节出现故障，整场直播都可能中断。
AI可以分析每一种方案，但前提是有人知道这里存在选择，并能够提供延迟、成本、并发量和可靠性等真实约束。
AI能协助部署，但很难主动完成整个工程
在安装模型、配置CUDA、解决依赖冲突、部署Redis和消息队列时，AI已经非常有帮助。把报错日志交给它，它经常能够快速找到原因。
但它更像一个能力很强的协作开发者。
它可以告诉你怎样启动语音模型，却未必主动规划：服务重启后直播如何恢复，某张GPU故障后任务怎样转移，大模型超时后是否使用备用回答，数字人渲染变慢时是降低帧率还是停止回答，版本升级时怎样做到直播不中断。
AI可以帮助解决已经意识到的问题，但很难自动补齐使用者不知道应该提出的问题。
软件工程师的经验，不只是知道怎样写代码，更是知道一个实时系统还可能在哪些地方出问题，以及应该在性能、成本、复杂度和可靠性之间怎样取舍。
AI Coding没有消灭软件工程
不懂编程的人可以借助AI逐渐学习架构、部署和运维，最终独立完成线上产品。但到了那时，他并不是绕过了软件工程，而是在AI帮助下掌握了软件工程。
未来，亲手编写普通代码的人可能会减少，但能够把模型、数据、服务器、网络和计算资源组织成稳定系统的人，仍然不可缺少。
AI让更多人能够做出软件，软件工程则决定这个软件能不能面对真实用户，稳定地运行下去。
打算下一篇文章聊聊“当AI越来越会写代码，软件工程师还应该学什么？”
关于作者：蒋能学（Neil），杭州学以致用科技创始人兼CEO，妙言小智产品创始人。曾任网易云音乐高级技术总监、百度国际广告平台技术负责人，获美国马里兰大学MBA。长期关注AI技术、产品落地与创业实践。
