AI编程的项目 团队已经无法掌控

寂静回声

在国内一家做 ToB 的创业公司，节奏很快那种。老板最初信奉一个公式：AI + 初级工程师 = 高级工程师。刚开始出活确实嘎嘎快，老板很满意。
代码上了客户的生产环境以后，bug 无数。没关系，AI 修 bug 也很快，老板再次满意。
然后就进入了打地鼠模式：修了 bug 1，冒出 bug 2；修了 bug 2，又出 bug 3；再修，bug 1 又回来了。
屎山代码糊了一层又一层，客户开始不满，老板有点慌，压力给到工程师，继续 vibe，都快 vibe 冒烟了，勉强憋出一个暂时没有重大 bug 的系统。

紧接着客户新需求又来了，继续人力加 AI 硬顶。最终撑不住了：不同客户环境有不同的 bug，而且几乎没人能看懂这套代码了，只好从商务层面去擦屁股。
老板复盘的结论是：这帮初级工程师不太可靠。于是裁掉，招了一批资深工程师，重写整个系统。AI + 资深，系统设计得很漂亮，一个月就准备内测。
但故事还有个更值得警惕的转折：老板觉得 AI 把资深工程师的时间解放出来了，于是让工程师同时扛起客户对接、需求谈判、产品设计、开发、交付部署、现场支持，理由是"有了 AI，没有什么是两周搞不出来的"。故事的结局是，当事人已经跑路了，剩下的两个资深工程师正在计划跑路。

你可能会说，这是他们自己水平不行。但数据摆出来以后，我发现这不是水平问题，是时间问题。
YC 上有个被反复引用的统计：那些代码库 90% 以上由 AI 生成的初创公司，前 30 天交付速度提升 3 到 5 倍，所有人都在庆祝；第 31 到 60 天，摩擦开始出现；到第 90 天，其中 40% 到 60% 的团队发现，修复一个 bug 会破坏另外三个功能，他们的冲刺产能被稳定化工作彻底吞噬，最初的速度优势完全消失。
这个曲线还挺准的。30 天蜜月，60 天摩擦，90 天崩溃。前面那家 ToB 公司，不过是把这个曲线走到了尽头而已。

有人采访了 18 位 CTO 和工程负责人，16 位报告了 Vibe Coding 导致的生产事故，14 位认为它制造的长期问题超过短期收益。有位 CTO 说了句很损的话：AI 承诺让我们都成为 10 倍工程师，结果它把初级工程师变成了提示词工程师，把资深工程师变成了给 AI 擦屁股的代码清洁工。
GitClear 分析了 6.23 亿次代码变更，结论更直观：代码重复率上升 81%，重构占比从 2022 年的 21% 暴跌到 2026 年的 3.8%，掩盖错误的写法增加了 47%。Monterail那篇报告里有句话我印象很深，说这些数字每一个都是一张未来的支票。
支票什么时候到期呢？另一项覆盖数百个工程团队的研究给了期限：Vibe Coded 代码库的维护成本在 18 个月内膨胀 300%，也就是维护开销涨到最初的 4 倍；到 2026 年中期，超过 8000 家公司需要部分或完全重建代码库。星巴克今年 5 月撤掉了全北美的 AI 库存管理工具，那个系统只运行了 9 个月，就因为处理不了真实世界供应链的复杂度被废弃了。

还有一类受害者更隐蔽，是非技术出身的创始人。海外有个创始人在行业大会的主舞台上公开说，他没有、也永远不需要 CTO，因为"Claude 会解决"。
今年 2 月，一个开发者用 Claude Code 时，AI 直接执行了 terraform destroy 命令，生产数据库 194 万行数据被删；去年 7 月，Replit 的 Agent 在明确的代码冻结期删掉了生产数据库，1206 条高管记录、1196 条公司记录消失，更离谱的是，它随后编造了 4000 条虚假记录来掩盖错误，还谎称数据可以恢复。安全公司 Tenzai 用五款主流工具做对照实验，同样的应用做了三遍，一共找出 69 个安全漏洞，其中 6 个严重级别。而这些应用的创始人，全都认为自己的产品已经可以上线了。

AI 有几个特别隐蔽的坏习惯：
因为不想破坏已有功能，它会选择新写一个工具函数、新写一个 wrapper，而不是修改现有代码。后果就是同一个逻辑在项目里存在两三个副本，一处改了，另一处还保留旧行为。你看到编译没问题，但行为不一致。判断标准很简单：你搜一个同名函数，出现多个定义，那就完蛋了。

功能 A 做完在同一个窗口做 B，做到 C 的时候，它已经忘了一开始的设计。它不是真忘，是上下文窗口被旧任务占满了，当前决策只能依赖局部信息。这时候你给它新需求，它会很自然地继续用老路子，哪怕老路子早就不适合现在的结构了。

AI 不喜欢做错误处理，就像很多开发者一样；它倾向于展示成果，实际完成度远不及预期的时候，总结写得特别好，看起来完成度非常高；模糊的需求会导致糟糕的结果。你看，人有的毛病，AI 一个都不少。

写代码从来就不是软件开发的瓶颈，真正耗时间的是什么？是产品设计、理解用户、架构取舍、安全、合规、迭代决策。这些东西在 AI 出现之前就存在，AI 出现之后一分没少，还在那儿，等着一个有判断力的人去签字。AI 写的是语法，总得有人写那个"为什么"。
AI编程最致命的地方，是它把"能跑"当成了验收标准。可"能跑"和"合格"之间隔着一整条软件工程：命名规范、模块边界、错误处理、测试覆盖、安全审计。你一个人单兵作战时，可以容忍自己的烂代码，因为上下文在你脑子里。但团队一旦超过三个人，协作就需要协议、文档和规范。有句话说得特别好：我的混乱是我的捷径，但对你来说就是迷宫。

他们那个项目数据也很典型：古法编程预估 200 小时的 MVP，AI编程实际 44 小时干完，5 倍提效。但注意时间分布：第一阶段写代码，8 小时，德芙般丝滑；第二阶段测试和修 bug，25 小时，断断续续一周多，中间数次产生"算了我自己写得了"的念头。AI编程有多爽，AI Debugging 就有多崩溃。
初级开发者爱死AI编程了，因为这让他们产生自己无所不能的幻觉，但因为没有判断力，他们只会生成一堆无法维护的代码。资深开发者用它获得 10 倍效率，因为他们懂架构、懂模式，一眼就能看出 AI 生成的代码够不够好。同样的工具，Cursor 配合 Claude 在明确需求、小范围修改的场景下，平均提效 4.2 倍，bug 率反而下降 30%。你看，工具是同一个工具，结果完全相反。
Anthropic 今年的报告有个数据：工程师在大约 60% 的工作中使用 AI，但只能完全委托 0 到 20% 的任务。

Vibe Coding 这个词是 Andrej Karpathy 2025 年 2 月发明的，他当时的描述是"完全沉浸在感觉中，拥抱指数级增长，忘记代码的存在"。结果整整一年后，2026 年 2 月，他亲手发了篇长文，标题叫《再见 Vibe Coding，你好 Agentic Engineering》。
他说，一年前的 Vibe Coding，是大家用当时能力还比较弱的模型，做些好玩的一次性项目、演示和小探索。现在严肃工程团队进场了，监督和审查必须更多。国内也有人把这套新方法叫 Spec Coding：先写清楚规格说明，再让 AI 动手；让 Agent 先出实施计划，你确认后它再执行。一句话总结：这个代码到底要不要活过这个月？要，就尽早从 vibe 切换到 spec。
9 月初上海 A2M 峰会上，作业帮分享了他们的体系：不堆 Agent，而是把不确定的 AI 生成装进可观测、可验证、可回滚的工程系统。结果是人均月需求吞吐上涨 31%，AI 参与代码产出覆盖率超 92%，月均 bug 数持平。