Shopify 說是 agent 讓重複寫兩次變便宜、trusting-trust 論文說後門根本不必碰編譯器、量化模型的 agentic 軌跡連 seed 都對不上——這週三篇 investigation 湊在一起讀，講的其實是同一件事：你以為抓到的原因，往往只是離真正機制最近的那個說法。
第 37 週 —— 原因不在說法裡
這週的主軸
這週三篇 investigation 湊在一起讀最扎實：Shopify 把 React Native 換回原生，官方給的理由跟 2020 年換成 React Native 時一模一樣——都是「不想把同一個功能寫兩次」，但真正撐住這次決定的，是自建的 Helix 檢查系統跑得比 agent 寫程式還慢，12 週重建完成的 Shop app，佐證的其實是搬遷成本，不是重複成本。不用碰編譯器，改 strip 就夠了那篇裡，3,799 支使用者可執行檔裡有 3,790 支印出同一個訊號，動手腳的那份 GNU strip 早在攻擊完成前就已經離開系統的相依圖——只要一個 post-build 工具同時滿足「先被信任、能寫下一代、下一代接手同一角色」三個條件，換掉編譯器根本不必要。同樣的請求，快取開著就不是同一個答案那篇量出來，固定 model、decoding 參數、seed、送出順序，四位元權重下打開 prefix cache 讓四分之三的 episode 走上不同執行路徑，關掉快取則 800 次重跑逐位元相同——問題不在隨機性，在一顆沒被追蹤、也不會被重置的 cache state。
三個案例湊在一起最扎實的地方，是三次「看起來合理的說法」都不是假的，只是不夠。Shopify 的官方理由是真的——沒人想把同一個功能寫兩次；trusting-trust 稽核向來盯編譯器的直覺也是真的——供應鏈攻擊史上多數案例確實從那裡進來；開發者對快取的假設同樣是真的——關掉隨機性本來就該拿到相同結果。真正驅動結果的機制，每次都藏在說法蓋不到的那個角落：一套自建的驗證系統、一個不起眼的 post-build 工具、一顆不出現在 request 裡的快取設定。稽核一個因果解釋，問的不該只是「這個理由合不合理」，還要問一句：合理的說法蓋住的那個角落，到底有沒有人真的去查過。
沒被合稱的個別亮點
RSA-260 倒下，帳單是四十萬美元——Steve Weis 想找 Anthropic 要兩週、1024 顆 GPU 的資源去解開 RSA-260，結果被別人先解開：整條 GNFS 管線跑完花了 4,900 個 GPU-day，約合四十萬美元，外推到 RSA-1024 大約三千萬美元；RSA-2048 因為次指數複雜度差了十億倍，沒有被這次工作實質影響。真正該緊張的是還留著 1024-bit RSA key 的系統——這個位元數早在 2013 年就該淘汰。
一個值不該佔到 128 個位元——Plush 直譯器把原本 128 bit 的 tagged enum 換成手寫的 64-bit tagged word，陣列密集的 benchmark 記憶體最多降 37%，沒有一個 benchmark 變慢；代價是新的上限只剩 62 bit，寫左移運算或靠溢位生成亂數之前，得先知道這條邊界在哪裡。
最後一個 cgo 相依，用 Go SIMD 換掉了——Debian Code Search 拆掉用了七年的 cgo/TurboPFor，中途踩過 PGO 對齊陷阱讓效能倒退 13%，疊上配置搬遷、generics 特化、AVX2 向量化、positional popcount 五輪優化；把同樣技巧反向移植回 C 版本做真正對等比較後，Go 版本仍慢了大約 1.4 倍——重點不是打贏 C，是這條效能關鍵路徑第一次能完全用 Go 寫、用 Go 測，不必再回頭寫組合語言或維護 cgo 綁定。
每個 shard 都還是真的 Postgres——PlanetScale 把 Neki 定的規則反過來寫：不繞過 Postgres、不假裝相容、不轉頭換一顆新資料庫，一個 Postgres 橫著切成很多份，每一份的 extension、SQL 支援、效能表現都跟原生一致。9 月 10 日進入 platform preview，PlanetScale 自己把「不要拿去跑 production workload」寫進了發布文。
握手之前，先把 origin 支援什麼量出來——固定押 X25519 的年代，真正觸發 HelloRetryRequest、要多付一次來回的連線比例長期停在 52% 左右；換成先量再決定之後，這個比例降到 3.7%，p90 握手延遲省下超過 150 毫秒。代價是約 0.34% 的 origin 因為跨封包的 keyshare 直接握手失敗——這正是「先量再決定」比「先猜再處理例外」划算的證據。
本週動向
把這週（09/07–09/13，三天出刊）跟上週（08/31–09/06，同樣三天出刊）放在一起量，五個 domain 一樣沒有一個碰到慣常拿來說故事的 10 pp 門檻——這週最大的單一位移是 web 的 −3.2 pp（21.1% 退到 17.9%），其次是 ai 的 +2.3 pp（15.6% 漲到 17.9%）與 backend 的 +2.2 pp（18.3% 漲到 20.5%），infra 與 systems 兩個 domain 幾乎不動，分別只有 −0.8 pp 與 −0.6 pp。
位移不夠看，這次標籤動向也沒有 surge 或 faded 可以講，反而是新進榜（本週至少 2 次）的名單值得記：cryptography 一次衝到 3 篇——RSA-260 被以四十萬美元拆開、消費級桌機分解掉一份 512-bit 根憑證、1.1.1.1 開始驗證 2,420 位元組的 ML-DSA-44 後量子 DNSSEC 簽章，三篇分別從不同角度戳了一次「看起來夠安全的密碼學假設」。同一份新進榜名單裡還有 coding-agents、interpreter、linux、quantization、security、sharding、supply-chain，各 2 次。
一週的形狀
三天出刊、九篇 deep story，archetype 這頭 investigation 與 technical-deep-dive 並列最厚，各 3 篇；narrative 2 篇；comparison 只有 1 篇。這個形狀跟這週的主軸是同一件事的兩種讀法——investigation 拆的是「說法跟機制之間的落差」（Shopify、trusting-trust、prefix cache 三篇都是），technical-deep-dive 拆的是機制本身怎麼運作（Debian Code Search 的 SIMD 路徑、Cloudflare 的 key exchange、PlanetScale Neki 的 sharding）；narrative 兩篇（RSA-260、Plush）走的是「一件事发生了、代價或效益是多少」的直線敘事，不太需要先拆假設或先鋪機制，comparison 因此只有 ORM 那一篇撐住。
domain 這頭 infra 最厚，3 篇；systems、backend 各 2 篇；web、ai 各 1 篇，跟上週比略微分散，但沒有一個 domain 碰到本週動向那段講的 10 pp 門檻。infra 領先跟 trusting-trust、cloudflare key exchange、RSA-260 三篇的份量相符——這三篇分別是供應鏈稽核、TLS 握手、公鑰密碼學，題材夠雜，才撐得住這個佔比。
9 篇 deep story × 3 天（09/07、09/09、09/11）
下一週可能會展開的線索
PlanetScale Neki 目前只到 platform preview——PlanetScale 自己把「不要拿去跑 production workload」寫進了發布文，值得追蹤的是這句警語什麼時候鬆綁。RSA-260 那篇的作者也留了一個開放的數字：他自己承認目前的 GPU 版 GNFS 實作還遠不是最優，「如果再花一些力氣優化，把成本再砍一半我不會意外」——三千萬美元這個 RSA-1024 估算，接下來會不會被進一步壓低，是這條線索值得繼續盯的地方。
這週的落點——三篇 investigation 湊在一起最扎實的地方，不是官方或直覺給的理由是假的，是它們都只夠不到最後一步：Shopify 的「不想寫兩次」是真的，trusting-trust 稽核盯編譯器的直覺是真的，「關掉隨機性就該拿到相同結果」的假設也是真的。真正驅動結果的機制，每次都藏在說法蓋不到的那個角落——一套自建的驗證系統、一個不起眼的 post-build 工具、一顆不出現在 request 裡的快取設定。下次拿到一個聽起來合理的因果解釋，除了問「這個理由合不合理」，也該問一句：合理的說法蓋住的那個角落，到底有沒有人真的去查過。