幾週前，許多程式設計師（或者該說前程式設計師）開始注意到 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 畫布中所有資訊都以平面反應式物件（或稱為「records」）的映射儲存。它是一個簡單的檢查，更多是為了指定型別，而不是真的要保護 store.As。就我所知，這幾行程式碼就是編碼模型如此鍾愛 isRecord 的源頭。如果你在 GitHub 上搜尋這段程式碼，你會找到 tldraw 以及許多 tldraw 的複製品，緊接著就是由 Codex 編寫的新程式碼。
我發現另一個在「史前時代」就使用了 isRecord 的儲存庫，是 RocketChat 的版本，於 2025 年 7 月加入：
不是要炫耀，但 我們的 isRecord 比那個早了至少兩年。事實上，我認為我們是在 2022 年夏天寫下這個儲存結構的，不過 git blame 只能追溯到 2023 年，當時我們把程式碼從私人儲存庫搬到公開儲存庫。
一萬年的 isRecord
最後，我必須承認，對於能對如此驚人的模型權重產生一點點影響，我感到有些驕傲。下次當你在程式碼庫中看到 isRecord 時，請想想 tldraw。
