今天是 2026-01-07。
使用 Vibe Coding 大失败，AI 给我写的代码质量太差，完全没法用。迫不得已将 ZEN 项目全部重写了一遍，改用传统的古法编程来实现。
我使用 AI 从零开始生成代码，迭代了多轮之后，工程质量开始崩溃，新功能无法集成进去，bug 层出不穷，代码结构混乱，连删除功能都变得异常困难。这是技术债务爆炸的典型症状。于是，我果断介入，决定重写整个项目。其中比较关键的是，我发现 AI 写的 OOP 代码质量特别差，每次新功能就给我单开一个类，然后给其他相关的类打一个洞来调用它，出现了大量无用的类和方法。这哪里是面向对象编程，分明是面向需求清单编程。
究其原因，我认为：
- AI 对于面向对象编程范式设计能力不足，这可能是由于缺乏对业务领域概念的建模导致的。
- AI 不清楚自己在做一次性代码还是长期维护的代码，缺乏架构指导，采取了偷懒一把梭的策略。
- 缺乏一个 AI 友好的脚手架，AI 从零开始自举的过程比较艰难。
- AI 对于兼容性的要求把握过于保守，导致代码臃肿。
面向对象迷思
我认为，AI 目前还不适合写面向对象编程的代码。面向对象编程要求对业务领域有深刻的理解和建模能力，而 AI 目前还无法胜任这一点，甚至比较可笑的是，人类也无法轻易胜任这件事。相反，面向过程和函数式编程更适合 AI，因为它更关注于数据转换和处理，而不是对象的状态和行为。
如果你使用了面向对象，你需要同时让 AI 精通设计模式，精通重构。这样才能写出高质量的面向对象代码。而如果你使用面向过程和函数式编程，AI 只需要专注于算法和数据结构，就能写出不错的代码。
那么面向对象的收益是什么呢？封装？继承？多态？这在 AI 时代似乎并不那么重要，因为它们都是为了少写代码和团队分工合作而生的，而 AI 无所谓这些。相反，代码的可读性、可维护性和可测试性才是关键。而这些特性更容易通过函数式编程和面向过程来实现。
过度向后兼容
AI 对于向后兼容的要求过于保守，导致代码臃肿不堪。AI 总是试图保留所有的旧功能和接口，以防止破坏现有的代码。然而，这种做法往往适得其反，因为它增加了代码的复杂性和维护成本。有时候，删除旧功能和接口反而能简化代码，提高性能。但是 AI 很难做出这种权衡，因为它缺乏对业务需求和用户行为的理解。
如果 AI 认为所有的 public export 都是需要保留的，它在创建新功能的时候引入这些接口很随意，但是在后续维护中却像对待宝贝一样对待这些垃圾接口，生怕一不小心就把它们删掉了。结果就是代码越来越臃肿，复杂性越来越高，bug 也越来越多。
我尝试了引导 AI 使用“允许破坏性变更” 的策略以后，效果明显改善。说明我们定位到了问题所在。但是这也带来了新的问题：如何管理破坏性变更的风险？
必须让 AI 理解 奥卡姆剃刀原则：如无必要，勿增实体。 也就是说，代码应该尽可能简单，避免不必要的复杂性和冗余。只有在确实需要的时候，才引入新的功能和接口。这样才能保持代码的清晰和可维护性。
AI 如果不分离设计和编码任务，就很难做到这一点。
结论
- 强调不使用 OOP，转向面向过程和函数式编程。这是一个非常关键的捷径，可以大幅提升 AI 生成代码的质量和可维护性。
- 引导 AI 理解 奥卡姆剃刀原则，避免过度向后兼容，减少代码臃肿。
其他我还没想好怎么办，比如脚手架的问题，架构指导的问题等等。
