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

一位名叫Swinburne Portel的开发者最近发表了一篇在技术圈引发广泛共鸣的文章——《I'm going back to writing code by hand》。他用AI进行Vibe Coding长达七个月，完成了234次提交、约30个周末的投入、1690行核心代码，最终却不得不将整个项目归档，从零重写。

Vibe Coding（氛围编程）是AI领域知名人物Andrej Karpathy在2025年初提出的概念，指的是开发者完全通过自然语言描述需求，让AI生成全部代码，自己只负责验证结果是否"看起来对"。这种模式随着Claude、GPT-4、Cursor等工具的成熟而迅速流行，极大降低了编程的门槛和速度瓶颈，但也引发了关于代码质量、可维护性和开发者技能退化的广泛争论。

而Portel的结论掷地有声：AI写功能，不写架构。你让AI无约束驾驶的时间越长，残骸就越难看。

魔法般的开局：3个周末完成一个K9S克隆

Portel在2025年9月底启动了一个名为K10S的项目，目标是做一个GPU感知的Kubernetes仪表盘——类似K9S，但专为管理NVIDIA GPU集群的人设计。

K9S是一个广受欢迎的开源终端UI工具，用于管理和观察Kubernetes集群，以Vim风格的键盘操作著称，让运维人员无需离开终端就能浏览Pod、Service、Deployment等资源。Kubernetes本身是Google开源的容器编排系统，已成为云原生基础设施的事实标准。随着AI/ML工作负载的爆发，越来越多的团队需要在Kubernetes上管理GPU资源，但原生工具和K9S都缺乏对GPU拓扑、显存分配、DCGM指标的原生支持，这正是K10S项目试图填补的空白。

最初的体验堪称魔法。"给我加一个带实时更新的Pods视图"——3秒钟后代码就能跑了。资源列表、命名空间过滤、日志流、Describe面板、键盘导航、Vim风格键绑定……一个完整的K9S克隆，只用了大约3个周末，全部通过自然语言提示完成。

Portel估计当时的开发速度是自己正常手写的10倍。每次提示后，他只会扫一眼终端，确认编译通过、测试Happy Path，然后继续下一个功能。七个月里，他从未坐下来完整读过AI生成的代码。

这种工作模式在早期看起来毫无问题——功能在增长，项目在推进，一切似乎都在掌控之中。

崩溃时刻：GPU舰队视图上线后的连锁反应

转折发生在GPU舰队视图功能上线之后。这是K10S的核心卖点——一个专用界面展示每个节点的GPU分配、DCGM利用率、温度、功耗，用颜色编码状态。这里的DCGM（Data Center GPU Manager）是NVIDIA提供的一套GPU管理和监控工具，广泛用于数据中心环境，能采集GPU利用率、显存使用、温度、功耗、ECC错误等关键指标，并通过Prometheus等监控系统暴露数据。在大规模AI训练场景中，一个集群可能包含数百甚至数千块GPU，运维人员需要实时了解每块GPU的健康状态和负载分布，K10S的舰队视图正是为这一需求而设计的。

AI一次性生成了FleetView Struct、标签过滤、自定义渲染、分配进度条，看起来完美。

然后Portel按下快捷键切回Pod视图——什么都没渲染了。表格空了，实时更新停了。切到Notice视图，显示的是舰队视图过期的缓存数据。再切回舰队视图，标签过滤又错了。

他第一次坐下来认真读了model.go——1690行代码，一个名为Model的Struct包揽了一切：UI状态、K8S客户端、每个视图的状态、导航历史、缓存、鼠标处理、取消函数、原始对象列表，全部塞在一个结构体里。

这就是面向对象编程中最臭名昭著的反模式之一——God Object（上帝对象）。它指的是一个类或结构体承担了远超其应有职责的功能，直接违反了SOLID原则中的单一职责原则（SRP）。God Object的危害在于：任何一处修改都可能产生意想不到的连锁反应，单元测试几乎不可能编写，多人协作时冲突频繁。在Portel的案例中，AI之所以持续向同一个Model结构体堆叠功能，是因为每次提示的上下文中这个结构体已经存在且"能工作"，AI自然选择了阻力最小的路径——往里面加代码，而不是重构出新的模块。

更恐怖的是Update()方法：500行代码，110个switch case分支，根据消息类型分发到各个视图的逻辑。每个新功能都被AI直接塞进这个"上帝对象"，因为AI的上下文窗口里只有"让这个功能现在就能工作"，完全没有对其他49个功能如何共享状态的感知。

五条血泪教训：AI辅助编程的边界在哪里

Portel从这次失败中总结出了几条深刻的经验教训，每一条都值得正在使用AI写代码的开发者认真反思。

教训一：AI建造功能，不建造架构

每次提示都能得到完美工作的功能，但每个功能都是在"让此刻能运行"的上下文中实现的，对共享状态毫无意识。当50个功能共享同一个Mutable State时，系统必然崩溃。

这是AI编程最根本的局限性。当前大语言模型的上下文窗口（Context Window）虽然已从最初的4K token扩展到128K甚至更长，但对于一个真实的软件项目来说仍然远远不够。一个中等规模的项目可能包含数十万行代码、数百个文件、复杂的依赖关系图和隐式的架构约定。即使模型能"看到"所有代码，它也缺乏对项目演化历史、设计决策背景和团队约定的深层理解。这就是为什么AI在项目早期（代码量小、结构简单）表现出色，但随着项目膨胀，它的输出质量会急剧下降——它本质上是在做局部最优决策，而非全局最优。AI不会主动告诉你"这里应该抽象出一个接口"或"这个状态应该用事件总线来管理"。

教训二：速度是幻觉，直到它不是

Vibe Coding的快感来自于即时交付，但这种快感掩盖了技术债务的指数级累积。在代码量小的阶段，AI能hold住全局；一旦项目膨胀到超出上下文窗口，AI就开始重复造轮子、在已有功能上打补丁。

技术债务（Technical Debt）是Ward Cunningham在1992年提出的隐喻，将代码中的权宜之计比作金融债务——短期内加速交付，但长期需要支付"利息"（维护成本）。在传统开发中，技术债务通常是线性累积的，因为人类开发者会本能地感知到代码的"味道"变差并主动重构。但在Vibe Coding模式下，这个自然的反馈回路被切断了：开发者不读代码，AI不会主动重构，每个新功能都在已有债务之上叠加新债务。这导致债务以指数而非线性速度增长，直到某个临界点——就像Portel遇到的那样——系统突然变得不可维护。

10倍的开发速度，换来的可能是10倍的技术债务。

教训三：浅层审查不够，你必须读代码

Portel承认自己七个月来只做了"编译通过+Happy Path测试"的最低限度审查。如果他在第100次提交时就坐下来读完model.go，可能会在500行而非1690行时发现问题。

这揭示了一个反直觉的事实：AI越是让你不需要读代码，你就越需要读代码。 传统的代码审查（Code Review）之所以有效，不仅仅是为了发现Bug，更重要的是让开发者保持对代码库的心智模型（Mental Model）。当你亲手写代码时，这个心智模型是自然建立的；但当AI代劳时，你必须通过刻意的阅读和审查来弥补这一缺失，否则你对自己项目的理解会随着代码量的增长而越来越模糊。

教训四：提示工程不能替代软件设计

当系统出现故障时，Portel的第一反应是继续提示AI修复。但上帝对象的问题无法通过增量提示解决，因为它需要的是自上而下的架构重构，而不是又一根switch case分支。

这是很多Vibe Coder的通病——遇到问题就加提示，而不是退后一步思考设计。提示工程再精妙，也弥补不了架构层面的缺陷。软件架构的本质是关于"如何分解复杂性"的决策：哪些模块应该独立、状态如何流转、接口如何定义、变化如何隔离。这些决策需要对业务领域的深刻理解、对未来需求的预判、以及对各种设计模式权衡取舍的经验——这些恰恰是当前AI最薄弱的环节。

教训五：AI是加速器，不是司机

Portel最终选择归档整个代码库从零手写，不是因为AI不能写代码，而是因为他意识到：在没有人类架构约束的情况下，AI会沿着最小阻力路径不断堆叠功能，直到整个系统被自身的重量压垮。

这与软件工程中的"熵增"概念高度吻合——任何软件系统如果不经过刻意的重构和治理，其复杂度会自然趋向混乱。人类开发者通过经验和直觉来对抗这种熵增，而AI在当前阶段还不具备这种能力。它是一个极其高效的代码生成引擎，但不是一个能理解系统演化方向的架构师。

正确的人机协作模式：人管架构，AI填细节

Portel的经历揭示了一个核心问题：Vibe Coding让你不需要理解代码就能构建产品。 这在原型阶段或许成立，但当项目进入生产环境、需要长期维护和多人协作时，不理解代码意味着无法判断债务、无法预测故障、无法修复根因。

不过，他的反思并非全盘否定AI编程。他明确表示，重写后的K10S仍然会引入AI辅助，但协作方式完全变了：

• 由人设计架构，划定模块边界，定义状态流
• 然后让AI在约束内填充实现细节

这种模式在软件工程中有着深厚的理论基础。它本质上是将"架构决策"和"实现细节"分离——前者需要全局视野、领域知识和长期思维，后者则是相对机械的编码工作。这与经典的"关注点分离"（Separation of Concerns）原则一脉相承。在实践中，这意味着开发者需要先用人类的方式完成系统设计——定义模块、接口、数据流和状态管理策略——然后在每个明确界定的模块内部，让AI来加速具体的编码实现。

这可能才是AI辅助编程的正确姿势——不是把方向盘交给AI，而是画好路线图后让AI帮你踩油门。架构决策、状态管理、模块边界这些需要全局视野的工作，仍然是人类开发者不可替代的核心能力。

234次提交、7个月的时间成本，换来的这个教训虽然昂贵，但对整个开发者社区来说，却是一份极其宝贵的实践报告。在AI编程工具越来越强大的今天，搞清楚人和AI各自的边界，比学会写提示词重要得多。

核心要点

• AI擅长生成单个功能但缺乏全局架构意识，会不断向'上帝对象'堆叠代码直到系统崩溃
• Vibe Coding带来的10倍速度提升是一种幻觉，掩盖了指数级累积的技术债务
• 开发者七个月未完整审查AI生成的代码，导致1690行的God Object和110个switch case分支
• 提示工程无法替代架构设计，增量提示修复不了需要自上而下重构的结构性问题
• 正确的人机协作模式是人类负责架构和模块边界设计，AI在约束内填充实现细节