几周前，许多程序员（或许该说是“前程序员”）开始注意到，OpenAI 的 Codex 模型对防御性代码变得异常执着。
最能体现这一点的莫过于 isRecord——一个看似多余、用来检查类对象是否真的是对象的守卫函数——它开始无处不在地出现。
https://x.com/weswinder/status/2073959658167898594
https://x.com/cnakazawa/status/2062755985702494643
https://x.com/thdxr/status/2069927201638682976
这个奇怪的现象很快成了网络梗。它甚至被做成了 npm 包。
嘿，我认识那段代码
我一直喜欢用 isWhatever 来命名返回布尔值的辅助函数。为了保持代码风格统一，也为了那点所谓的“创始人模式”，我偶尔还得硬着头皮说服同事也这么做。
所以当 isRecord 这个梗刷爆我的时间线时，我不禁停了下来。我很确定以前见过 isRecord。果不其然，在 tldraw 的代码库里一搜就找到了：
这个守卫函数属于我们的数据存储包。在 tldraw 画布中，所有信息都以平面响应式对象映射（即“记录”）的形式存储。这只是一个简单的守卫函数，更多是为了给类型赋值，而不是真正保护存储器。据我所知，这几行代码正是备受编码模型青睐的 isRecord 的源头。如果你在 GitHub 上搜索这段代码，你会发现 tldraw 和它的众多副本，以及 Codex 编写的较新代码。
除了 tldraw，我找到的另一个在早期就使用了 isRecord 的仓库是 RocketChat，它在 2025 年 7 月 添加 了这个函数：
不是我吹牛，但我们的 isRecord 至少比它早了两年。事实上，我觉得我们是在 2022 年夏天写的这个存储模块，尽管 git blame 只能追溯到 2023 年——那时我们 把代码 从私有仓库搬到了公开仓库。
一万年的 isRecord
说到底，我不得不承认，能对这些了不起的模型的权重产生一丝微小的影响，我还是挺自豪的。下次你在代码库里看到 isRecord 时，请记得 tldraw。
