六月，Stripe 交出一個數字：一個前沿模型，在一個五千萬行的 Ruby 代碼庫裡，一日之內完成了一次全庫遷移——人手估算，是一整隊工程師做足兩個月。數字在行內轉了一圈，照例收穫一批掌聲、一批白眼，然後落入那堆「你總得有點意見」的 AI 里程碑裡。
這個數字值得更好的對待。不是因為它證明了掌聲以為的事——寫代碼從此完結——而是因為它悄悄改寫了一個決定的價錢，一個每間工程組織每年都要做幾次的決定。「遷移，還是就這樣住下去」，向來以「工程師‧月」計價。這種貨幣剛剛作廢。取而代之的，是一個幾乎沒有人量過的數字：你的驗證機器，一日吞得下多少變更。
真正塌下來的是甚麼
一場遷移，是三種成本共用一個名字。
執行。把一個模式記在腦裡，重複套用四萬次而不走樣。人人口中「這場遷移要兩個月」，說的就是這一項——也正是模型剛剛刪走的一項。長時程的 agent 天生就是做這種性質的工作：單元層面機械，總量層面殘酷，而且有規則可對。
協調。十四個工程師、口中的兩個月悄悄變成兩個季度、一張模組負責人名單，加上要等這個 sprint 完結才輪到自己目錄的長尾。這項也差不多刪走了。一個通宵工作的 agent 不用開早會，交接時也不會斷線——因為根本沒有交接。
驗證。確認模式套到第四萬次那一下，沒有悄悄改變行為。這項成本一分錢都沒有跌。驗證從來都是難的那部分；現在更是價錢的全部。
三項成本，兩項歸零；價錢不會消失——只會集中。
那一日，是多年前買下的
把 Stripe 那個數字的細節讀完，故事會變形。「一日」是 Stripe 專屬的，而且不是因為他們拿到的模型有甚麼特別。以那種規模的代碼庫來說，他們的構建、測試與審查基建快得出名——多年累積的測試覆蓋、靜態檢查、部署安全，全是在沒有人想過 agent 的年代，一磚一磚砌起的。模型交出 diff，組織負責消化。兩邊缺一不可；新的只有一邊。
反過來想：同一個模型，對着另一個五千萬行的代碼庫——CI 一趟要跑四十分鐘，還時不時無故轉紅，工程師早已習慣「不綠就重跑」。agent 照樣在下午交出 diff。然後 diff 就停在那裡：等一套沒有人完全信任的測試，等每日頂多能專心讀二千行的審查者。對這個組織來說，一日遷移並不存在——換哪一級的模型都不存在，出多少錢都不存在。
模型一個下午寫完 diff。你能不能在黃昏前合併，取決於你的測試，不是你的模型。
驗證能力像基建，因為它就是基建：累積得慢、無聲無息、毫不風光——然後在某個星期二，一次過花掉。
開工容易，收尾難
比頭條更令我擔心的，是第二層效應。遷移還要花兩個月人力的年代，成本本身就是配額：只有跨得過高門檻的改動才會開工，等候驗證的積壓，大致跟組織排走的速度打平。
現在開一場遷移，成本是一句 prompt。這句話裡，沒有任何東西在把關。未來幾年的失敗模式，不是 agent 寫出爛 diff，而是組織批出多過自己能誠實驗證的變更，再讓「agent 做的，測試是綠的」頂替「我們確認過這是安全的」。執行跌價，積壓不會消失——只會往下游移，移進審查那一段：更難看見，更易放行。
這是博觀約取，審問明辨裡那份操作者的紀律，放大到整張組織架構圖。決定一場對話值不值的習慣——驗證不了的輸出，一概不信——同樣決定一份五千萬行的 diff 是資產還是事故。兩個尺度，模型都替你做不了。
新的一盤數
執行不再是貴的那部分，一些老結論就要重新推導。
- 量吸收，不要量工時。計劃要問的不再是「這場遷移要多少個工程師‧月」，而是「我們一日能驗證多少行改動，而不自欺」。這個數字你不去量，就會在事故中途認識它。
- 把信任買在能規模化的地方。如果「怎麼知道它安全」的答案，是請一位資深工程師逐行讀 diff，你的天花板就是一個人的閱讀速度。測試、類型、金絲雀發佈、契約——這些才跟得上新的吞吐量；英雄主義跟不上。
- 替積壓重新標價。每一項「有空才做」的升級——棄用的 API、落後兩個大版本的框架、一直沒推行的 lint 規則——都是按「工程師‧月」的舊價擱置的。按新價，架上大部分東西都值得做了。但仍要過同一道驗證閘。定日程的是閘，不是願望清單。
Stripe 買到的不是一日遷移。他們先花了多年，養出一個消化得下這種改動的組織，模型才出現。diff 在同一日對所有人跌價；消化沒有。
所謂一日之功，從來非一日之功。