一位拿到終身教職、endowed research chair、編輯一份國際期刊的教授，這週在自己的部落格上發了一篇文章。標題很狠：「AI Has Already Killed Academia as we Know it」。
他是業內贏家，所有學術圈定義的成功——tenure、研究椅、得獎名單、期刊主編、帶出去能獨當一面的學生——他全拿了。然後他寫：「如果學術界是一場遊戲，我贏了。但這場遊戲已經沒意義了。」
我把那篇看完，腦袋裡只跳出一句話：軟體業也是。
他講了什麼
他講的是三套機制，被 AI 從不同角度拆掉。
學生作業已經抓不到了。過去我們抓 AI 抓的是「用得爛」的學生：ChatGPT 排版、一句三項列表、幻覺引用、沒有段落縮排。但抓不到的才是真問題——一個學生用兩個付費帳號，Claude 寫初稿、ChatGPT 反覆批改，迴圈到語感乾淨、論證緊實，再叫 AI 三重檢查引用跟格式。這種作業不只偵測不出，還比一般學生寫得好。系統現在做兩件事：懲罰自己寫的學生（自然有瑕疵），給最會用 AI 的學生最高分——而後者不是「懶」或「不誠實」，他們只是看到了 AI 用得越好、成績越好的因果。
論文已經能量產了。Review article、方法學論文、理論綜述、二次分析——一個研究者今天綁定 Consensus + Claude 兩個 Pro 訂閱，接近一天可以產出一篇。有些 reviewer 會抓出來太空泛，但只要訓練 AI 不要堆形容詞、不要寫空話前提，發十篇大部分會過。一個願意這樣幹的人，CV 膨脹速度會把獨立思考的同事甩到看不見。
Grant 申請也被破解了。想像五個同事在加拿大 CIHR 一輪裡輪流當 PI 投十份申請——光靠數量中標機率就拉高，更別說 AI 對申請書常見死因（預算錯誤、漏引關鍵 paper、資格欄位填錯）抓得比 reviewer 還準。過去要試錯好幾輪才寫得出來的乾淨申請書，現在第一份就到位。
他的核心結論很簡單：靠「寫作量」評價學術人的時代，已經死了。我們只是還沒辦葬禮。
把這套邏輯搬到軟體業
我讀的時候一直想，這三條換到軟體業，哪一條不成立？
PR 數、commit velocity？ 我自己用 Claude Code 配幾個 MCP server，一個下午 push 二十幾個 commit 是日常。如果再有意識地把每個 task 切細一點——一個 bug fix 一個 commit、一個重構一個 commit、文件更新另一個——一天五十個不誇張。同事看 GitHub graph 會以為我在拼命，事實上我可能寫了三個小時、剩下時間 Claude Code 在跑。GitHub 那個小綠塊熱力圖以前是工程師勤勞的證據，現在更像是「他比較會分派 task」。
Code review？ 那位教授寫到 grant 評審時甩了一句：「你的 AI 在 review 我的 AI...cool, cool, cool」。軟體業更糟。我看過 PR 跑 CodeRabbit 留下八條精緻 comment，作者用 Cursor 一條一條回覆、修改、re-push，最後 squash merge。整個過程沒有人類腦袋介入過——但 review log、approval、coverage report 一條都不缺。從制度紀錄看起來，這份 code 是經過嚴格審查的。
Story points、velocity？ 一個 sprint 切 21 個 story、做完 19 個——這數字以前是工程能力的證據。現在更可能是「他比較會用 Cursor」。更尷尬的是 story 切細這件事本身就是 AI 強項。把一個含糊的 user story 拆成 7 個明確 task，AI 比多數 PM 拆得好。
面試白板題？ 我們還在量一個工程師能不能徒手寫出 LRU cache、能不能在白板上推 dynamic programming。但他真實工作 90% 的場景是在 IDE 裡開 Claude Code 對話。白板題量出來的數字，跟他在你公司能不能交付，已經沒什麼關係。我們現在的面試制度，正在淘汰一批「不擅長徒手寫但極擅長用 AI 把事做完」的人。
評鑑制度也死了，只是還沒辦葬禮
學術圈那套「以寫作量換取地位」的制度，軟體業有它精確的對應物：以 commit 量、PR 量、story 點數、code 行數，換取績效評等、升等、bonus。這套制度從來不是直接量「工程能力」，它量的是「人類獨立產出的工作量」這個 proxy。Proxy 之所以以前還能用，是因為產出工作量這件事卡在人的速度限制上。
那個限制現在沒了。
有人會反駁：commit farming、10x developer 神話本來就存在，AI 不過放大了一個老問題。沒錯——但 AI 把那個放大鏡從 2 倍開到 1000 倍。本來只有少數會 game system 的人能拿好處，現在每個會綁訂閱、會用 Claude Code 的人都能。系統不是被 AI 弄壞，是被踩到極限，然後現在裂縫處處都是。
業界這兩年講「AI 不會取代工程師，但會用 AI 的工程師會取代不會用的」，這句話聽起來像安慰。但翻一層看，它說的其實是：舊的評鑑制度會把不會用 AI 的人篩掉，留下的那群人裡，誰刷量刷得快誰就贏。這跟那位教授描述的學術圈——「系統現在獎勵最會用 AI 的學生」——是一回事。學術圈的機構回應已經慢了兩年（Tri-Councils 從禁用改成允許、期刊只要求自我聲明）。軟體業更慢：個別團隊試 outcome-based 績效、有人乾脆放棄量化評鑑，但主流 HR 制度、升等委員會、面試 pipeline，都還在用 commit 數跟白板題運轉。
我的應對
我自己這一年多的應對方式很土。一開始其實放不下，我習慣每週看 GitHub graph 那塊熱力圖，看到一週全綠會有點滿足感——後來發現那個滿足感跟我真的解決的問題完全脫鉤，最深綠的那週可能只是我在大量批次改格式。慢慢地我把那個分頁關了。我停止看自己的 commit 數、停止把 PR 量當交付指標、停止用「行數」自我評估。我看的東西變成：這個系統線上撐了多久沒爛、用戶有沒有真的在用、Bug 進來時我自己有沒有能力 5 分鐘內 root cause——這些 AI 還沒辦法替我做。
這套個人應對在公司制度面前當然沒有用。HR 不會看我 root cause 了幾個讓人睡不著的 P0，他們看 OKR、KPI、PR 數、ticket 數。但內在標尺跟外部評鑑不需要是同一把——這是我在制度斷裂期守住的最後一條線。
那位拿到 tenure 的教授寫他文章結尾時，沒有提解方。他擔心的不是後進學者超車他，他擔心的是整個學術界開始空轉。
軟體業會走一樣的路。當業內贏家自己宣布遊戲已死，下面的人最好開始想一件事：如果舊規則已經量不到任何東西，新規則應該量什麼？我猜新規則會圍繞著「AI 替不了的部分」長出來——root cause 速度、線上判斷力、品味、跨領域翻譯能力——但這話現在說都還太早。
葬禮會辦的。只是看誰先辦。
