2026.07.20 —— 今日 10 則
TODAY'S THREAD 今天的線索是「別太快相信那個數字」——不管是 AI coding 省下的工時、一個看似 3 倍的加速、Netflix 的影像品質分數，還是兩個大數相乘最快能有多快，這些看起來明確的量測背後，都各自藏著一個沒人再回頭追問的前提。
審查 AI 生成的程式碼，撐不起 AI coding 的效率神話
「AI 寫的程式你全部 review 一遍就好」是這波 AI coding 最常見的辯護，作者用 code review 的實證研究把它拆開：一場 review 超過一小時就進入邊際效益遞減，人一小時能有效看的程式碼大約只有 400 行，換算下來一天實際能安全提交的仍然不到 1k 行。更麻煩的是有研究指出，人在 review AI 生成的程式時「更有信心、卻抓到更少 bug」，而最該被小心對待的 shell script 偏偏又是最難 review 的一類。
In-Place Tokenizer Expansion：不重訓，就替小模型換上更大的 tokenizer
一個在預訓練初期就固定下來的 tokenizer，會照當時的語料比例分配詞彙，之後才加進來的語言就得用更多 token 才拼得出一個詞，延遲與算力跟著上升。這篇提出一套 in-place 的作法：在多語語料上延續原本的 BPE merge，讓大多數 token 原封不動保留、每個新 token 都能拆回舊 token，新的 embedding 用子詞平均初始化，再分兩階段續訓。用在 LFM2-8B-A1B 上，印地語與越南語的 token 數各降到約 1/2.4 與 1/2.6、泰語最多到 1/4，換算每字元解碼加速 2.2 到 3.7 倍。
Generative Compilation：讓編譯器在 AI 生成程式碼的當下就介入
像 Rust 這種靜態語意很嚴的語言，AI 生成完才拿到編譯器的錯誤往往為時已晚。作者提出 generative compilation：用一個叫 sealor 的輕量轉換，把「還沒寫完」的程式補成一個標準編譯器就能診斷的完整程式，於是在 autoregressive 解碼的當下就能就地抓錯、把 error cascade 壓下來。它不需要像 constrained decoding 那樣改動模型內部，對黑箱模型與現成編譯器都適用，實測降低了編不過的比例、也拉高了功能正確率。
研究 Linux 排程器時，一個選錯的 metric 讓 3 倍加速憑空消失
一組研究者想知道把執行緒綁在同一個 socket、留在單一 LLC 網域裡能不能加速，用 numactl 一限制，果然看到最高 3 倍的差距。問題是他們的 mediawiki benchmark 跑的是固定 10 分鐘，吞吐量的提升被固定時長吃掉了——真正變快的是每秒指令數，選錯 metric 差點讓結論整個反過來。文章把 EEVDF 與 LAVD、L3 的 read-for-ownership miss 都攤開來講，重點只有一句：用錯 metric，會讓結果偽裝成另一個樣子。
人類還是不知道兩個大數相乘最快能有多快
兩個 n 位數相乘到底最快能有多快，這個看似基本的問題其實還沒有答案。小學直式是 O(n²)，Karatsuba 在 1960 年把它壓到約 O(n^1.585)，而 Harvey 與 van der Hoeven 在 2019 年給出 O(n log n)——理論上幾乎只比讀完輸入多一點點，卻是個大到現實用不上的「galactic algorithm」，Python 要到約 630 位數才會切去用 Karatsuba。大家普遍相信 n log n 就是極限，但至今沒人證得出來。
Netflix 釋出 VMAF v1：更準，但刻意對齊舊分數
Netflix 把影像品質指標 VMAF 推到 v1，並把舊版重新命名為 v0。新演算法準度更好，但為了不讓多年累積的判讀經驗作廢，他們用一個 score transform 把 v1 的刻度對齊回 v0，讓同一個數字維持原本的意義。對做轉碼與 ABR 決策的人，這是個「底層更準、上層門檻卻不用重訂」的務實升級。
有人做出能開機 Windows 的 IA-64 Itanium 模擬器
開發者 Yufeng Gao 放出 0.1 版的 Intel Itanium（IA-64）模擬器，能把 Windows Server 2003 與 XP 64-bit 版開起來——這在目前是少見、甚至沒有商用對手的成就。代價是速度：在 Ryzen 5000 上大約只有 486 等級的效能，等於用現代硬體跑出 1980 年代末的速度。Linux／BSD 目前還開不起來，程式碼暫時未開源，但作者說之後會放上 GitHub。
Shipyard：Slack 用不可變映像重建下一代 EC2 平台
Slack 把管了多年的 EC2 從「長命實例＋定期跑 Chef 收斂設定」整個翻掉，改成 Shipyard：把基礎設施當成可部署的產物，而不是可以一直改的實例。核心是一張叫 slack-zero 的黃金基底映像，服務團隊在上面疊自己的 AMI，重活都在 bake 階段做完、開機只做輕量設定，於是實例「幾秒就能上線」。再配上 Peekaboo 盤點、Gondola 部署編排與會定期汰換實例的 Reaper，管的是數以萬計的 EC2。
Gleam 把原始碼鏡像到 tangled——一個架在 AT protocol 上的 forge
Gleam 語言把自己的原始碼鏡像到了 tangled，一個建在 AT protocol（也就是 Bluesky 底層那套協定）上的程式碼 forge。意思是 repo 的身分與社交圖譜不再綁死在單一平台，而是掛在去中心化的 AT 網路上，理論上能跨 forge 搬遷、不被單一供應商鎖住。這是「把 git 託管從平台手裡拿回來」這股嘗試裡，比較具體的一步。
Kube-Policies：Square 給 Kubernetes 應用加上部署護欄
Square 分享他們給高度敏感的 Kubernetes 環境設計的 Kube-Policies：一套在部署路徑上先攔一道的護欄，用來擋掉不合規的工作負載設定，而不是等出事再補。文章談的是在多團隊共用叢集時，怎麼把安全與合規的預設值變成「預設就對」，而不是靠每個人記得。對正在跑 platform engineering 的團隊，這是把 policy-as-code 落到 K8s 的一個具體實例。