为什么 AI 替不掉一个工程团队

「我周末就做出这个 App 了，你们团队为什么还要两个月。」这句话一旦从老板嘴里说出来，团队的处境就变了。

一、发生了什么

IEEE Spectrum 的职业专栏发了一篇由 Brian Jenney 写的文章，标题就是「为什么 AI 不能替代工程团队」。作者是 Parsity 的负责人，这家机构做工程师培训，所以他的立场需要打个折扣看——文章是经验判断，不是研究结论。

他讲了自己亲历的场景：2024 到 2025 年，AI 热潮正盛，他所在团队的管理层直接对工程师说过类似的话。他给这种现象起了个名字：演示驱动的开发。

他的论证不复杂。AI 演示之所以显得轻松，是因为它藏起了复杂度。一个能打开的网站，要接进几百万行老代码，要过法务要求，要满足无障碍标准，还要塞进一套复杂的部署流程。他用了一个比喻：把写代码当成上线的唯一瓶颈，就像泰坦尼克号只看见冰山尖，就以为水下什么都没有。

文章给工程师的建议有四条：搞懂模型的基本原理，至少能说清它是概率性的、token 是什么、训练数据为什么重要；把知识往上传，让决策者明白 demo 和生产系统是两种东西；愿意承认某些流程确实太慢，用这个换取对关键环节的辩护权；最后是敢发声，因为会议室里没有别人会替工程团队说这些。

二、跟你有什么关系

一线工程师：当有人拿 demo 跟你比速度，别争「AI 行不行」，直接列生产清单——权限、审计、兼容、回滚。清单越长，对方越明白差在哪。

技术管理者：你的上级大概率不是被 AI 骗了，是被销售演示和同行案例夹住了。给他一套能向董事会解释的成本结构，比讲原理有用。

采购和外包负责人：报价里最贵的从来不是写代码，是集成和验收。任何按「页面数量」计价的方案，都要问清后续谁维护。

三、怎么判断

1. 让 demo 过一遍生产清单。老系统怎么接、数据从哪来、出错怎么回滚、谁审批上线，四问答不上来，就还停在演示阶段。
2. 算集成面，不算代码量。让团队列出要改动的模块、要过的合规项、要联调的外部系统，这个数字才是工期的真实来源。
3. 用决策者的语言说。把风险折算成上线延迟、事故成本、客户投诉，而不是「这个架构更优雅」。

四、三个别信的说法

「demo 能跑，说明东西已经做完了。」 演示是在理想条件下、没有真实用户、没有历史包袱的一次运行。它证明的是可行性，不是可交付性。

「AI 写代码快，所以交付就快。」 写代码只占交付周期的一部分。需求澄清、评审、测试、灰度、运维，这些环节没有被 AI 缩短多少，反而可能因为代码量变大而变长。

「工程师反对 AI，是在保饭碗。」 有一部分是。但更多反对意见指向具体问题：谁来审这段代码、出了事谁负责、三个月后还有人看得懂吗。这些问题不因为提出者的动机而失效。

五、一句话结论

AI 让「做出来」变便宜了，但「交出去」的价格没怎么降，这一段落差就是工程团队还在的理由。

信息来源

• IEEE Spectrum：为什么 AI 不能替代工程团队，2026 年 10 月

功能与价格以官方公告为准。本文写于 2026 年 10 月 23 日。