Vibe Coding七个月后彻底翻车：234次提交全部归档，从零手写

今天聊一个特别有意思的故事。一个开发者用AI写了七个月代码，234次提交，最后把整个项目归档，从零手写。你第一次看到这个案例的时候什么感觉？ 我第一反应是——终于有人把这个坑踩到底了。其实很多人都在用AI写代码，但大部分人要么项目还不够大，要么还没到那个临界点。这位叫Portel的开发者，他是真的把整个过程走完了，从狂喜到崩溃，非常完整的一个案例。 对，先说说他做的是什么项目。他做了一个叫K10S的东西，本质上是一个GPU感知的Kubernetes仪表盘。简单说就是，现在很多团队在Kubernetes上跑AI训练任务，需要管理大量GPU资源，但现有的工具对GPU的支持不太好，他想填补这个空白。 嗯，对标的是K9S，一个非常流行的Kubernetes终端管理工具。K10S就是在K9S基础上加了GPU拓扑、显存分配、DCGM监控指标这些功能。这个方向其实挺好的，需求是真实存在的。 关键是他的开发方式——完全的Vibe Coding。这个概念是Andrej Karpathy今年初提出的，就是你用自然语言告诉AI你要什么，AI生成全部代码，你只管看结果对不对就行。 而且他开局体验简直是魔法级别的。你看，他跟AI说'给我加一个带实时更新的Pods视图'，三秒钟代码就能跑。资源列表、命名空间过滤、日志流、Vim风格键绑定，一个完整的K9S克隆，三个周末就搞定了。他自己估计速度是正常手写的十倍。 十倍速度，这谁不心动啊。 对吧！而且他七个月里从来没有完整读过AI生成的代码。每次就是看看编译通过了，跑一下主要流程没问题，就继续下一个功能了。 这个习惯后来被证明是致命的。那转折点是什么时候？ 转折发生在GPU舰队视图上线之后。这是K10S的核心卖点——一个专门展示每个节点GPU分配、利用率、温度、功耗的界面。AI一次性生成了完整的FleetView结构、标签过滤、自定义渲染、进度条，看起来完美。然后他按快捷键切回Pod视图——什么都没了。表格空了，实时更新停了。切到别的视图，显示的是舰队视图的过期缓存数据。再切回来，标签过滤又错了。 经典的连锁崩溃。 他这时候第一次认真读了核心文件model.go——1690行代码，一个叫Model的结构体包揽了所有事情。UI状态、Kubernetes客户端、每个视图的状态、导航历史、缓存、鼠标处理、取消函数，全塞在一个结构体里。这就是典型的God Object，上帝对象。 上帝对象这个名字起得真好，一个对象觉得自己是上帝，什么都管。 哈哈对，而且更恐怖的是它的Update方法——500行代码，110个switch case分支。每加一个新功能，AI就往这个巨型方法里再塞一个分支。因为AI每次看到的上下文里，这个结构体已经存在而且'能工作'，它自然就选择阻力最小的路径——往里面加，而不是拆出新模块。 这其实揭示了一个很根本的问题。AI在做的事情本质上是局部最优决策——让当前这个功能现在就能跑。但它完全没有全局视野，不知道这50个功能共享同一个可变状态会出什么问题。 你说到点子上了。其实大语言模型的上下文窗口虽然已经扩展到128K甚至更长，但对一个真实项目来说远远不够。而且即使它能看到所有代码，它也缺乏对项目演化历史和设计决策背景的理解。所以AI在项目早期表现特别好，因为代码量小、结构简单，但随着项目膨胀，输出质量会急剧下降。 Portel总结了五条教训，我觉得有几条特别值得聊。第一条他说'AI建造功能，不建造架构'，第二条说'速度是幻觉'。这两条其实是一体的。 完全是。你看，传统开发中技术债务通常是线性累积的，因为人类开发者写着写着会觉得'这代码味道不对了'，会主动重构。但Vibe Coding模式下，这个反馈回路被切断了——开发者不读代码，AI不会主动重构，每个新功能都在已有债务上叠加新债务。所以债务是指数级增长的，直到某个临界点突然爆炸。十倍的开发速度，换来的可能是十倍的技术债务。 还有一条我觉得特别反直觉——他说AI越是让你不需要读代码，你就越需要读代码。 这条太精辟了。你自己写代码的时候，对代码库的心智模型是自然建立的，你知道每个模块在干什么、状态怎么流转。但AI代劳之后，如果你不刻意去读和理解，你对自己项目的认知会越来越模糊。他要是在第100次提交的时候就认真读一遍，可能在500行的时候就发现问题了，而不是等到1690行。 还有一个很典型的行为——系统出问题之后，他的第一反应不是去理解问题根源，而是继续给AI写提示让它修。 对，这是很多Vibe Coder的通病。但上帝对象的问题你没法用增量提示解决，它需要的是自上而下的架构重构。提示工程再精妙，也弥补不了架构层面的缺陷。架构设计的本质是'如何分解复杂性'——哪些模块该独立、状态怎么流转、接口怎么定义——这些需要领域理解、需求预判和设计模式的经验，恰恰是当前AI最薄弱的地方。 那他最后的结论是什么？全盘否定AI编程吗？ 没有，这一点我觉得他很理性。他说重写后的K10S仍然会用AI辅助，但模式完全变了：人来设计架构，划定模块边界，定义状态流，然后让AI在约束内填充实现细节。本质上就是把架构决策和编码实现分离开——前者需要全局视野和长期思维，后者是相对机械的工作，正好发挥AI的优势。 我觉得这个比喻特别好——不是把方向盘交给AI，而是你画好路线图，让AI帮你踩油门。 嗯，而且这个故事还有一个更深层的启示。软件系统天然有熵增的趋势，不经过刻意重构就会趋向混乱。人类开发者靠经验和直觉来对抗熵增，但AI目前还不具备这种能力。它是一个极其高效的代码生成引擎，但不是一个能理解系统演化方向的架构师。 234次提交、七个月的时间成本，这个教训确实昂贵。但我觉得对整个开发者社区来说，这可能是今年最有价值的实践报告之一。在AI编程工具越来越强大的今天，搞清楚人和AI各自的边界，可能比学会写更好的提示词重要得多。 完全同意。说到底，AI改变的是编码的速度，但没有改变软件工程的本质。架构能力、系统思维、对复杂性的管理——这些反而因为AI的存在变得更重要了，而不是更不重要。