最近大家都在讨论Cursor AI写的300万行代码跑不起来的问题,虽然偶尔有嘲笑,但更多技术朋友在理性讨论:目前 AI Coding 的上限在哪。
在我来看,Cursor这次测试还是非常有价值的,一方面验证了当前大模型复杂度控制的实际能力,另一方面也给AI Coding领域一个警示:暴力Vibe Coding不可取。实际工作中(特别是大型工程项目)“一键成片”的时代还没有到来。
从技术角度,Cursor这次尝试之所以没能真正跑通整个系统,表面上看,这是上下文窗口限制导致的;更本质的原因,是缺乏足够的 thinking 和 plan——也就是说,没有在架构和规划层面,预先设计出抵抗上下文限制的工程方法。
AI 往往是按“当前对话上下文”局部生成代码,而不是先做领域建模(核心对象、边界)、模块划分(服务拆分、层次结构)、接口协议约定(API、DTO、事件);
结果是模块之间风格不统一、职责混乱,命名、数据结构、错误处理方式不一致;
虽然相比早期 AI Coding,循环依赖、数据流完全对不上的低级错误在工程化实践中正在减少,但调用链混乱、难以排错的问题仍然大量存在。
再加上大模型上下文窗口有限,导致“遗忘”和“自相矛盾”,早期定义好的接口 /数据结构,模型在后面生成时不一定记得住。这类问题在大型项目中(比如 300 万行规模下)会被无限放大,综合效应就是“跑不起来”。
Cursor 这次实验其实是当前 Vibe Coding 思路的一种极端体现:把尽可能多的实现交给模型自动铺开。然而实际业务应用中,尤其是在 Vibe Coding 和 background agent 模式下做 AI Coding 时,统一的工程架构设计仍然非常重要。
这种情况下,有经验的架构师在这次AI Coding范式转型中将显得越发重要;在当下可预见的发展阶段,AI Coding 的实际效率与效果,很大程度上将取决于技术团队的工程架构能力上限。