现在是 2026 年 2 月 3 日，早上 9 点。
让 Opus 4.5 给资本持久战的实验仓库还了一些技术债务，虽然这些技术债务同样是它一手产生的。
如同我曾经提过的 AI 编程实践反思：避免 OOP 与过度兼容 一文中提到的那样，AI 目前还不适合写面向对象编程的代码。面向对象编程要求对业务领域有深刻的理解和建模能力，而 AI 目前还无法胜任这一点。目前，即便是 SOTA 模型 Opus 4.5 也不例外。
AI 能通过特定的流程来归还技术债务。这可真是“冤有头债有主”，至少我不需要为它写的烂代码买单了。
再次强调 OOP 和过度兼容的问题。
编程的本质上是需要对这个世界建模的，属于认知科学问题。大部分的编程任务，都需要处理很多业务独特的问题。而实验性的代码，更是如此，任务本身往往要求推陈出新，因此，AI 有时候很难理解用户突然抛出的一个新概念，导致它无法正确地建模这个新概念，从而产生错误的代码。而少数已经被充分认知了的任务，通常已经有了优秀建模了的代码...你为什么还要再造一次轮子呢？
而过度兼容本质上还是 AI 不知道这个代码是否还有用，不敢轻易删除它，从而导致代码臃肿，难以维护。面向对象中的状态和方法，即便无人使用，也会被认为可能有用，从而被保留下来。它带来的影响类似于 OOM (Out-Of-Memory)，只是 OOM 带来的是进程崩溃，而过度兼容带来的是认知崩溃。这是一个暗坑。
认知的发展是螺旋上升的过程。无论是 AI 还是人类，都无法一蹴而就。如何在螺旋上升的过程中，维护功能和债务，是一个重要的课题。有意思的是，代码或者说实验本身，能帮助我们获得认知，而认知又能帮助我们写出更好的代码。
我记录下这些思考，方便未来回顾。现在一边等着 Opus 给我干活，一边记录我的思考，真是美妙的体验。
