生产级应用的开发 可不敢完全交给AI自己鼓捣

寂静回声

一个多月前，开发者社区 V2EX 上一篇题为《公司 vibe coding 的项目，团队已经无法掌控了》的帖子，折射出 AI 编程浪潮下的真实落地困境。
帖中提到，今年年初智能体技术的爆发让企业管理层看到了 AI 替代部分客服岗位的可能性，随即下达了客服 Agent 项目的建设目标，要求覆盖 App 在线客服与电话线路客服两大场景。该开发团队并无专职 AI Agent 工程师，成员以 Java 与前端开发人员为主。面对陌生的技术栈，团队只能边学习边借助 Codex 等 AI 编程工具，完成系统设计、架构搭建与业务开发。经过数月赶工，项目第一版正式上线，但核心问题也随之暴露。

系统上线后的实际效果远低于预期，各类异常频繁出现，团队却难以定位问题根源。由于大量核心代码由 AI 自动生成，代码结构混乱、抽象层级不清，很多逻辑连开发人员自身都难以理解，更无法高效开展维护与排查工作。
项目由此陷入恶性循环：开发人员因读不懂代码，只能继续委托 AI 进行修改；AI 修复单个问题的同时，往往又引入新的故障，今日修复 A 模块，明日 B 模块又出现异常，整个系统逐步进入越修越混乱的状态。
随着业务量增长，问题集中爆发。电话线路并发量稍高时，系统便会出现性能瓶颈甚至直接崩溃；在线客服与语音客服对话过程中，频繁出现长时间沉默、响应超时、上下文丢失等问题，用户无法获得正常服务。最终项目不仅没有提升客服效率，反而冲击了原本稳定的人工客服体系。客服人员需要频繁接管异常会话、处理系统故障、安抚用户投诉，整体工作效率较项目上线前不升反降。帖主最终向社区求助，询问该类局面的破局方法。

AI 技术的出现，在很大程度上改变了行业生态与程序员的工作模式，但现实中的落地体感，与舆论中的叙事存在明显差异。
2024 年 GPT-5 发布时，行业内便出现了程序员职业将被淘汰的论调，当时我也产生过职业焦虑。
但到 2026 年的当下，两年时间过去，AI 编程工具的普及并未减少程序员的工作量。相反，多数程序员的工作强度反而有所提升，需求开发周期被不断压缩，工作时长持续增加。
另一个行业普遍关注的问题，是 AI 能否胜任大型软件工程开发。2026 年之前，行业共识普遍认为 AI 难以承担大型软件工程的开发任务，幻觉问题、上下文长度限制都是明显的技术短板。进入 2026 年，行业形势出现变化，随着 hermes 开发理念的兴起与 loop engineering 等工程实践的出现，AI 编程的渗透速度加快。2025 年之前，仍有不少开源团队坚持传统人工编程模式，而到 2026 年，Linux、K8s 等基础软件项目都已开始拥抱 AI 辅助编程，纯人工编写的传统代码项目越来越少见，全行业接纳 AI 编程已经成为新的共识。
尤其是今年 5 月，Bun 项目借助 Fable 5 完成百万行 Zig 代码到 Rust 的重构事件，让很多人认为 AI 已经无所不能，甚至产生了大模型如同许愿池，任何人只要提出需求就能得到可用软件的认知。

但从实际落地来看，这样的判断显然过于乐观。用 AI 开发小型演示项目并无障碍，但生产级应用的开发，始终离不开人类开发者的专业判断。正如帖子中的案例所示，AI 可以生成可运行的代码，但技术选型、模块划分、架构设计、数据库设计等核心环节，仍然需要人深度参与并做出决策。
如果缺失了人的顶层设计与过程把控，最终只会得到一个能够运行但无人能理解的系统，就像年初的 OpenClaw 项目，看似功能简单，却堆积了数百万行难以解读的代码。人类无法对自己完全不理解的系统做出有效决策，最终只能将所有需求直接抛给 AI，陷入被动状态。当需求迭代从工程设计退化为向 AI 许愿，系统失控也就成为必然结果，最终出现全员参与开发、数月后却无人能读懂 AI 生成代码的局面。

从技术本质来看，AI 模型的每次版本变动、能力波动、代码评审中的过度防御策略、上下文压缩机制，本质上都是在向代码库引入不确定性。这种影响单次看似微小，如同行星轻微偏离轨道，但经过长期累积，最终会大幅偏离初始设计方向。一次模型能力波动，可能让局部实现出现偏差；一次上下文丢失，可能让 AI 忽略核心设计文档；一次过度防御的代码评审，可能让模块实现变得冗余臃肿。长此以往，AI 不仅无法避免低质量冗余代码的产生，反而会以远超传统人工开发的速度制造出难以维护的代码资产。

现阶段，代码编写工作确实可以大量交给 AI 完成，但在完整的软件生命周期中，编码只是其中很小的一部分。需求定义、功能取舍、模块与架构设计、数据库设计、现有基础设施适配等环节，都需要工程师深度参与决策。Bun 项目的 AI 重构之所以能够成功，很大程度上得益于项目早期积累了大量完备有效的测试用例，为 AI 提供了清晰的验证标准。如果没有任何约束与验证体系，仅靠模型能力堆砌来完成百万行代码的重写，几乎不可能实现。
换言之，无法被有效验证的任务，是当前 AI 技术的核心短板。我自身也有类似的经历：此前协助同事将应用迁移部署到公司内部平台，如果是部署到标准化公有云平台，AI 可以一站式完成全部工作，使用者无需掌握数据库设计与编码能力，只需描述需求即可。但迁移到企业内部平台时，AI 需要在复杂的企业规则体系内运作，涉及 Git 仓库申请、数据库申请、变更单创建、测试执行、DNS 配置、域名申请等一系列固化流程。面对企业内部层层嵌套的流程规则，AI 的能力会受到极大限制，即便是主流大模型也无法独立完成，最终必须由人类程序员介入操作。

最后需要明确的是，即便当前大模型已经具备百万级的上下文能力，现实世界的复杂度仍远超模型的处理边界。需求沟通中的分歧协调、投入产出比的评估、责任边界的划分，都是软件需求生命周期中不可或缺的部分。AI 在现阶段本质上仍然是工具，工具价值的上限，始终由使用者的认知水平决定。相比编码能力，专业判断力才是软件工程中更核心的能力。