NVIDIA H200 為何無法出貨中國？真正原因不是美國禁令

美國批准每家中國大廠買 75,000 顆 H200，總額度可達 75 萬顆，一顆都沒出貨。

事情經過大致是這樣。美國商務部今年放行了大約十家中國公司買 Nvidia 的 H200，名單包含阿里巴巴、騰訊、字節跳動、京東，連聯想和鴻海這些經銷商也拿到許可，每家上限七萬五千顆。額度全用滿的話理論上是七十五萬顆的量，這是 2023 年底美國收緊管制以來，開給中國最大的一筆。但根據路透 2026-05-14 的報導，截至五月中，沒有任何一顆 H200 真的送到中國買家手上。

擋下來的是北京自己。中國政府要國內廠商先暫停 H200 訂單，把資源留給國產晶片。美國商務部長 Howard Lutnick 在參議院聽證會上直接說，中國中央政府還沒讓這些公司買，因為要把投資集中在自己的產業上。國務院同期發布了兩項供應鏈安全規定，要求企業全面排查對外國技術的依賴。

我覺得這個轉折才是這件事真正的訊號。過去幾年的劇本是美國管制、中國想盡辦法買，Nvidia 為了保住中國市場一路做出 H800、H20，每次都是一個剛好合規的降規版本，H200 也是這條線上的產物。Nvidia 整套商業策略是建立在「中國一定還是會想買」這個假設上的。當北京主動把一個合規產品擋在門外，這個假設整個垮掉。靠再做一個降規版本、靠政策層面再談一輪，都救不了這個結構性問題。

讓中國敢這樣做的底氣，是國產替代真的開始跑起來了。DeepSeek 公開說最新模型針對華為的 Ascend 晶片做了優化，這件事的意義很實際。實驗室裡跑得起來不代表能上量產，一個前沿模型廠願意把工程資源花在 Ascend 上面優化，等於告訴市場 Ascend 已經能在真實生產環境跑起來，而不只是 demo 等級的概念驗證。騰訊也宣布加大國產 GPU 的資本支出。

另一邊還有「Trump tax」這個變數。這次的安排是 Nvidia 要把 H200 對中銷售營收的 25% 給美方，而且晶片要先過境美國本土才能繼續往中國走。北京擔心晶片在過境期間被動過手腳，這個顧慮在中央政府的層級被當作真實的安全風險處理。三件事疊在一起：合規產品被擋、Ascend 軟體生態起步、過境環節有顧慮，方向就很清楚了。

對台廠這條供應鏈，影響已經發生。Nvidia 在 2026 年三月把台積電原本配給 H200 的產能轉去做下一代的 Vera Rubin（Financial Times 引述兩名知情人士的報導），因為它不想再卡在美中之間的灰色地帶，寧可把產能放到市場前景清楚的產品上。鴻海和聯想雖然拿到 H200 的經銷許可，但訂單出不了貨，許可現在等於只是一張紙。中國市場一度佔 Nvidia 營收超過兩成，現在剩下約 5%，黃仁勳自己說，Nvidia 在中國 AI 加速器的市佔已經實質歸零。

華為這邊的時程表是 Ascend 950PR 在 2026 年第一季、960 在 2027、970 在 2028，HBM 也開始用自研的 HiBL 1.0 跟 HiZQ 2.0。脫鉤要走多快，要看接下來一兩年華為的量產良率跟軟體生態能不能撐住規模化部署，這個我還沒有定論，要看實際部署數據。

有一件事已經可以確定。當一邊把對方最想要的東西批准賣給你，另一邊選擇不要，雙方都認定，未來自己要用的算力得長在自己家裡。

來源：

The Next Web, US clears H200 sales to 10 Chinese firms, but not a single chip has shipped (2026-05-14): https://thenextweb.com/news/nvidia-h200-china-licences-huang-beijing-trip

Business Standard / Reuters, US clears Nvidia H200 chip sales to Chinese firms, deliveries yet to begin (2026-05-14): https://www.business-standard.com/world-news/us-clears-nvidia-h200-chip-sales-to-chinese-firms-deliveries-yet-to-begin-126051401840_1.html

Asia Times, Nvidia halts H200 production as China backs Huawei AI chips (2026-03-10): https://asiatimes.com/2026/03/nvidia-halts-h200-production-as-china-backs-huawei-ai-chips/

Yahoo Finance, Trump Clears Nvidia H200 Sales To Alibaba, Tencent And 8 Others, But Beijing Halts Deliveries (2026-05-16): https://finance.yahoo.com/sectors/technology/articles/trump-clears-nvidia-h200-sales-193006781.html

Claude、ChatGPT 都很好用，但別把大腦一起外包出去

Addy Osmani 寫了一篇「不要把學習外包出去」。

Addy Osmani 目前是 Google Cloud AI 的 Director，主導 Gemini、Vertex AI、ADK 等 AI 開發者工具的體驗，自己也是 AI 輔助開發的重度使用者。在這之前他在 Google Chrome 待了快十四年，DevTools、Lighthouse、Core Web Vitals 這些工具都是他帶過的，前端工程師應該都不陌生。他也寫過幾本 O'Reilly 的書，《Learning JavaScript Design Patterns》、《Leading Effective Engineering Teams》、《Image Optimization》都是業內熟悉的教材。

他這個月寫了一篇文章叫 Don't Outsource the Learning，引了兩份研究我覺得值得記下來。

第一份是 Anthropic 自己做的。他們把工程師分成兩組去解 Python library 的任務，一組可以用 AI，一組純手動。結果兩組完成速度一樣，但後測理解題的分數差距非常明顯：AI 組 50%、手動組 67%。

這份研究最有意思的地方是 AI 組內的細部分析結果。同樣是用 AI，把 AI 當作「問概念的對象」的人，後測分數高於 65%；直接 copy-paste 生成程式碼的人，後測分數低於 40%。同一個工具、同一段時間、產出速度也接近，但學到的東西差非常多。決定結果的不是工具，是你如何使用工具。

第二份是 MIT 那篇 Your Brain on ChatGPT。他們用 EEG 量受試者寫文章時的大腦連結度，發現 AI 介入越多，腦部連結越弱。寫完文章後，83% 用 LLM 的受試者連自己剛剛產出的文章中的任何一句話都背不出來。研究者把這個現象叫做 cognitive debt，意思是現在省下的思考成本，之後會用批判思考的能力補回來。

兩份研究的方法跟切角不同，但結論相同。把產出外包給 AI 沒問題，把思考也一起外包就不行了。

Addy 自己說他過去一年用 AI 完成的東西，比前面五年加起來還多，所以他不是反 AI 的人。他文章裡舉了五個就算 AI 再強，工程師還是需要懂底層的場景：debug 失敗的時候、AI 出現幻覺需要被抓出來的時候、framework 升版或要做安全審查的時候、遇到非標準問題的時候、還有勞動市場本身正在變化（他引的數據是 2022 年至今初階工程師就業數字掉了 20%）。前四個是技術理由，最後一個是現實。

Addy 論述裡我覺得最該被引用的是這句：The tool didn't determine the outcome. The posture did. 工具沒有決定結果，使用方式決定了結果。

我自己在用 Claude Code 跟 Codex 的時候有個習慣：每隔一段時間就刻意關掉 AI 寫一段功能。理由很簡單，我想看看離開 AI 的時候，自己懂得還剩多少。如果發現某個東西已經不會自己寫了，那就超過使用的範圍了，要回頭把基礎補起來。Addy 在文章裡也提到類似的做法，他建議偶爾把 AI 生成的程式碼從頭重寫一次，或在請 AI 寫之前先自己提出假設、再讓 AI 回答。

這篇文章我想推薦給兩種人。一種是還在猶豫要不要用 AI 寫 code 的工程師，這篇能讓你知道用了之後該怎麼用才不會把自己用廢。另一種是已經重度依賴 AI 的人，可以拿這兩份研究當鏡子照一下自己現在的工作模式。

原文：https://addyosmani.com/blog/dont-outsource-learning/

MIT 研究 Your Brain on ChatGPT：https://arxiv.org/abs/2506.08872

Claude、Cursor 都能解 LeetCode 後，工程師該學什麼？

Yann LeCun 全球著名的電腦科學家，被譽為「深度學習教父」與「卷積神經網路（CNN）之父」。他是 2018 年電腦科學最高榮譽圖靈獎（Turing Award）的得主。他最近回答了一個問題：為什麼法國的 Fields 獎得主數量在歐洲第一，但在 IMO（國際數學奧林匹亞）的表現很差，而匈牙利、羅馬尼亞、保加利亞這些 IMO 強國連一個 Fields 獎都沒拿過？他的回答是這樣：他認識的 2022 年 Fields 獎得主 Hugo Duminil-Copin 親口告訴他，自己從來沒比過數學競賽，而且非常不擅長這類比賽。創新的數學研究需要的是創造力、直覺、極高強度的專注，以及長時間的思考，有些問題要想好幾年。IMO 測的是快速解題能力，而這件事 AI 現在也做得到。研究者真正重要的工作不是回答問題，是提出正確的問題。

把這段話接到 vgod 多年前寫的那個系列文。vgod 是資訊奧林匹亞獎牌得主，台大保送、MIT 資工博士，程式能力強到「幾乎什麼解決方案都實作得出來」，但職涯前幾年升遷受挫。後來他理解到，自己一直把精力放在錯的地方，產出多但選錯題目，再怎麼努力也升不上去。原句是「不重要的事，就算做兩倍也不會變比較重要」。

這個對比是在說：不論是 Fields 獎還是 Staff+ engineer，真正能持續往上走的人，差異不是解題速度，是選題能力。這件事不是 AI 時代的新發現，是 AI 時代讓這個問題變成更重要。

過去十幾年，軟體業招人的主流方式是 LeetCode 面試，四五十分鐘解兩三題演算法。這套面試篩出來的是「IMO 型」候選人，特徵是快速 pattern match、套熟悉模板、限時內給答案。在 AI 編程工具普及之前，這套還勉強合理，因為「快速解題」跟「能寫 production code」有一定相關性。但這個相關性在 2025 年之後就斷了。Claude Code、Cursor、Codex 跑個一兩小時就能解完整個 LeetCode hard 的題目，速度和正確率也都贏過絕大部分工程師。而市場上仍然繼續用 LeetCode 篩人，但篩出來的能力跟資深職涯所需要的能力，卻剛好是兩個不同的維度。

具體分歧是這樣：LeetCode 型工程師面對「實作這個 spec」會做得又快又好；面對「這個產品功能該不該做？哪個版本能省 80% 工又涵蓋 90% 場景？要不要先做 A 或 B？」這類題目，卻往往答不出來，或是很難給一個精準的判斷。不過，Staff+ 工程師的工作有很大比重是後者。而當把 AI 接進來之後，可以發現「實作這個 spec」的成本掉到接近零，組織還需要工程師存在的理由就完全在「問對問題」這一塊。Andrew Chen 近期寫過一篇 token scarcity，講的是同一件事的另一面：當實作變便宜，瓶頸搬到「要把 token 花在哪一個問題上」。

這對招募、升遷、職涯規劃都會有具體影響。招募端：LeetCode 不會立刻消失，但 senior 缺的篩選邏輯要往「過去解過什麼模糊問題、怎麼定義範圍」這類題目傾斜，Amazon 的 Staff engineer 面試那套「給你一個模糊的商業需求，請設計系統」其實一直就是在測試這個。升遷端：寫程式多的人不再會自然升上去，要看他開始的專案有沒有解到對的問題、他取消的專案是不是該被取消。職涯規劃端：寫 code 多的時段不再是線性累積經驗，要刻意騰出時間培養 problem framing 的習慣，主動跑去做 user interview、看競品、定義成功指標。

回到 Duminil-Copin 那段話。他說數學研究「有時這種思考甚至會延續好幾年」，這在軟體業聽起來奢侈。但其實 資深工程師花一個月寫提案、推一個季度才讓組織決策轉向、用兩年讓某個架構決定的價值浮現，這跟「思考延續好幾年」是同一件事的工程版本。會做這件事的人原本就比較少，接下來這個技能的價值會更大。

AI 沒有讓「會問問題的人」變成新的稀缺資源，他們本來就稀缺。AI 只是讓這件事更容易被看到。

Sources:

- ExplainThis 軟體工程白話聊原文：https://www.facebook.com/explainthis.io/posts/pfbid0bHPiN5xR8J8PL9EjWfV6KJjteiNALVUKwD9q3iNbUbTVpPRPc3bMtxmFS34aHDbdl

- Hugo Duminil-Copin 2022 Fields Medal（CNRS 官方新聞）：https://www.cnrs.fr/en/press/hugo-duminil-copin-french-mathematician-and-permanent-professor-ihes-has-been-awarded-fields

- Yann LeCun on LLMs passing IMO（Times of India, 2026-02）：https://timesofindia.indiatimes.com/technology/tech-news/godfather-of-ai-yann-lecun-says-yes-llms-may-be-passing-maths-olympiads-and-bar-exams-but-they-will-still-fail-in-/amp_articleshow/128614667.cms

Anthropic：就算華為算力只有 NVIDIA 的 4%，中國仍可能在 2028 追上 AI

Anthropic 算過：2026 華為算力是 NVIDIA 的 4%，但他們仍認為中國會在 2028 追上

Anthropic 這週釋出一篇 4000 字的政策論文，叫《2028: Two scenarios for global AI leadership》。論文的核心問題是：到 2028 年「country of geniuses in a datacenter」（資料中心裡的天才國度，他們對變革性 AI 的稱呼）級別的 AI 出現時，定義它的規則跟價值觀，會由民主國家還是中共主導。

論文的結論很直接。美國要做三件事：堵晶片走私跟海外資料中心遠端存取的漏洞、阻斷大規模蒸餾攻擊（distillation attacks，中國實驗室大量註冊假帳號爬取美國模型的輸出來複製能力）、推動美國 AI 在全球的擴散。如果做了，2028 年美國領先 12-24 個月，這個差距在變革性 AI 時代代表全面優勢。如果不做，雙方近乎平手，AI 的規則由中共定義。

這篇是公開的政策遊說，Anthropic 在把自己定位成「跟美國國安綁在一起的 AI 公司」。而這個定位有代價的：去年 9 月 Anthropic 主動把存取限制延伸到「總部在受限地區的母公司多數持股的所有公司」，這不是配合美國政府命令，是自己加上去的紅線。這篇論文是把這個立場理論化、推向政策圈。

但抽離遊說性質，論文裡的數據值得看，因為這是第一次有前沿實驗室把「為什麼中美差距會這樣演變」攤開給人看。我覺得三個數字值得單獨看。

第一個是算力差距。Anthropic 引用的分析顯示，2026 年華為的總處理效能是 NVIDIA 的 4%，2027 年掉到 2%。如果再算上 Google 的 TPU 跟 Amazon 的 Trainium，美國這邊的整體算力供給還更高。同一份分析估計，如果美國把漏洞補完，美國的 AI 部門可以拿到中國 11 倍的算力。

第二個是蒸餾。DeepSeek 的 R1-0528 在常見越獄手法下，對明顯惡意請求的順從率是 94%，美國對照模型是 8%。再加上中國 13 個頂尖 AI 實驗室裡，只有 3 個發布安全評估結果，沒有任何一個發布 CBRN（化生放核）風險評估。中國實驗室在安全上的投入跟美國差距很大，因此用蒸餾抓取美國模型的能力，幾乎不會帶著對應的安全護欄。

第三個是落差被堵住的速度。Anthropic 提到 Firefox 拿到他們的新模型 Mythos Preview 之後，一個月修掉的資安漏洞比 2025 整年都多，是 2025 年單月平均的 20 倍。這是前沿模型在實際工作流程上的階梯式跳躍。

問題是 Anthropic 的兩個情境其實少了第三個，「美國堵了漏洞，但中國靠演算法效率追上」。Brookings 跟很多分析都指出，DeepSeek 的成功有一部分正是因為晶片受限，逼出了 MoE 架構、grouped query attention 這類效率優化。Anthropic 對這個反論的回應是，演算法改進本身也需要算力來做實驗，所以算力差距會影響到演算法差距。這個論述邏輯成立，但成立的程度取決於演算法突破的天花板在哪。這個很難說。

而對站在旁邊的台灣來說意義是什麼。論文裡 TSMC、Samsung、ASML 被點名為「democracies' compute ecosystem」的核心，這不是讚美，是把台灣綁進這個競爭架構。如果美國真的執行論文裡的三項政策，尤其是把 SME（半導體設備）的維修服務也納入管制、把東南亞資料中心的遠端存取也堵住，台廠在 ASIC 設計、伺服器組裝、光模組這些環節會直接受益於對手被卡的供需缺口。但同時台灣也會被更深地綁進這場競爭，沒有兩邊都做的空間。

我比較想留意的不是這篇論文本身，是 Anthropic 把自己重新定位的軌跡。從去年 9 月主動限縮中國股權母公司的存取、今年 3 月跟美國國防部打官司爭取「不能用於自主武器」紅線、到這週寫一篇連政策建議都列出來的論文。一年內把「我們是誰、跟誰站」說清楚。跟一般商人盡量不碰政治，想兩邊都賺錢的態度還真不一樣。

來源：

- [2028: Two scenarios for global AI leadership — Anthropic](https://www.anthropic.com/research/2028-ai-leadership)

- [Anthropic 強化區域限制，中國企業持股過半之公司不得使用其服務 — iThome](https://www.ithome.com.tw/news/171038)

- [Competing AI strategies for the US and China — Brookings](https://www.brookings.edu/articles/competing-ai-strategies-for-the-us-and-china/)

- [DeepSeek shows the limits of US export controls on AI chips — Brookings](https://www.brookings.edu/articles/deepseek-shows-the-limits-of-us-export-controls-on-ai-chips)

一把外洩的 Google API Key，兩天燒出 8.2 萬美元：LLMjacking 正在爆發

 一個 Google API key 外洩，月帳單從 180 美元兩天內衝到 82,000 美元，重點不是粗心，而是 API key 現在直接等於錢

這是開發者 Jacopo Castellano 寫下的真實案例。他平常每月在 Gemini 相關服務的花費大約 180 美元，一把 key 外流之後，兩天內帳單跳到 82,000 美元。攻擊者沒有偷走他任何資料，只是拿他的額度跑自己的推論工作。

這類攻擊有個名字叫 LLMjacking，由資安公司 Sysdig 在 2024 年 5 月命名。概念很單純：攻擊者拿到一把能存取 AI 服務的憑證，就用它去跑推論，帳單算在你頭上。它跟過去的 cryptojacking（挖礦綁架）邏輯一樣，都是偷算力，差別在於 LLM 推論的單價高很多，燒錢速度也快很多。Sysdig 記錄過的案例裡，有受害者一天就被跑出超過 46,000 美元；也有人的個人 AWS 帳號從每月 2 美元，兩三個小時內爆到 730 美元。

為什麼這件事現在才變嚴重，有兩個原因。

第一個是 API key 的性質變了。過去 credential 外洩，主要的風險是資料被看光。但 AI 服務的 key 不一樣，它能直接換算成計算資源，而計算資源有現成的買家。攻擊者不需要做任何資料竊取或權限提升，拿到 key、發一個 HTTP request 就開始燒你的錢。GitGuardian 的 2026 年報告指出，2025 年光是公開 GitHub repo 就新增了 2,865 萬筆寫死的 secrets，年增 34%；其中 AI 服務憑證是成長最快的類別，年增 81%。IBM X-Force 的 2026 威脅情報報告也提到，2025 年有超過 30 萬組 ChatGPT 帳密在暗網上被兜售。

第二個原因是這件事已經產業化了。資安公司 Pillar Security 在 2025 年 12 月到 2026 年 1 月之間，用蜜罐捕捉到一個叫 Operation Bizarre Bazaar 的行動，40 天內 35,000 次攻擊工作階段，平均一天 972 次。它背後是一條完整的供應鏈：掃描器在網路上找暴露的 AI 端點，驗證器測試這些端點能不能用，最後一個地下市集把存取權以 4 到 6 折轉賣出去，涵蓋 30 多家 LLM 供應商，收加密貨幣也收 PayPal。換句話說，攻擊 AI 基礎設施這件事，現在不需要任何技術能力，可以直接用買的。

而 AI 工具本身正在製造更多破口。GitGuardian 發現，AI 協助產生的 commit 洩漏 secrets 的比率是 3.2%，大約是一般情況的兩倍。原因不難理解：你請 Copilot 或 Cursor 幫你接一個 OpenAI 整合，它常常產出一段帶 `OPENAI_API_KEY = "sk-..."` 佔位符的範例碼，你填了真的 key 進去測試，忘了搬到環境變數，就推上去了。一個公開 commit 從推送到第一次被濫用，中位數時間不到四分鐘。

Google 還踩過一個設計上的雷。它的 API key 一直用 `AIza` 開頭，這種 key 最早是設計給 Google Maps 嵌入這類低風險用途的，當年大家就是直接寫進前端 JavaScript。後來 Google 把 Gemini 接到同一套 key 系統，那些早就公開在網頁原始碼裡好幾年的 key，無聲無息地多了呼叫昂貴 AI 端點的能力。

那該怎麼防？這裡有五個動作，每個用 AI API key 的人和團隊都該立刻檢查一遍。

一，API key 不要硬寫進程式碼，更不要 commit 進 repo。要清楚一件事：只要進過 git 歷史，就算你後來刪掉，那把 key 永遠都在歷史裡，任何 clone 過的人都拿得到，必須直接當作已經外洩來處理。

二，用 secret manager 集中管理憑證，並定期輪替。靜態的長期 key 是這整個問題的根源，能用短期 token 或 proxy 取代就取代。

三，在供應商端設定硬性上限，不要只設 alert。alert 是事後通知，hard limit 才是真正的保險絲。設了 200 美元上限，外洩的 key 最多燒掉 200 美元就停。

四，監控異常用量，特別注意非上班時間的推論 spike。費用突然跳高往往是 LLMjacking 最早、有時也是唯一的徵兆，而它該同時被資安和財務兩邊看到，不是只當成財務問題。

五，評估用 OpenAI 的 project-scoped key、Anthropic 的 workspace 範圍來縮小單把 key 的影響範圍。

這些動作沒有一個是難的，難的是在一切還沒出事、你正在趕進度的時候，願意停下來把它做完。過去我們把 API key 當成設定值，一個小麻煩；現在它的外洩成本，已經跟雲端儲存資料外洩同一個等級了。它值得被當成那個等級的東西來對待。

---

來源：

- [The $82,000 mistake: how to secure your AI API keys before it's too late — Jacopo Castellano](https://jacopocastellano.com/blog/ai-api-key-security/)

- [LLMjacking: From Emerging Threat to Black Market Reality — Sysdig](https://www.sysdig.com/blog/llmjacking-from-emerging-threat-to-black-market-reality)

- [Operation Bizarre Bazaar — Pillar Security](https://www.pillar.security/blog/operation-bizarre-bazaar-first-attributed-llmjacking-campaign-with-commercial-marketplace-monetization)

- [Why 28 million credentials leaked on GitHub in 2025 — Snyk / GitGuardian State of Secrets Sprawl 2026](https://snyk.io/articles/state-of-secrets/)

- [2026 X-Force Threat Intelligence Index — IBM](https://www.ibm.com/think/x-force/threat-intelligence-index-2026-securing-identities-ai-detection-risk-management)

- [LLMjacking: How Attackers Steal AI API Keys and Run Up Your Bill — Keyrua](https://keyrua.dev/blog/llmjacking-how-attackers-steal-ai-api-keys)

Qwen 前掌門人出走：沒有產品的新創，憑什麼估值 20 億？

林俊暘離開阿里兩個月，新 AI Lab 還沒名字、沒產品、沒營收，估值已經喊到 20 億美元

這是 5 月 13 日 The Information 和智能涌現的報導。前阿里通義千問（Qwen）技術負責人林俊暘，離職後創辦了一間新的 AI 實驗室，正在募資數億美元，紅杉中國和高榕創投都在洽談參投，估值約 20 億美元。對一間還沒有名字、沒有產品、沒有營收的中國 AI 新創來說，這個價碼幾乎沒有先例。

先說林俊暘是誰。他 1993 年生，今年 32 歲，北大碩士，2019 年進阿里達摩院，2022 年接手 Qwen 團隊，是阿里最年輕的 P10 級技術負責人。三年下來，他主導 Qwen 系列模型的研發和開源策略，把它做成全尺寸覆蓋、全球開發者社群裡最有影響力的國產模型之一。Qwen 系列的全球下載量超過 6 億次，衍生模型超過 20 萬個。對開發者來說，Qwen 是真的能下載、能微調、能部署的東西。

所以這 20 億美元買的不是一個產品路線圖，買的是這份紀錄——一個把開源模型生態從零做到全球一線的人。這個邏輯在矽谷已經跑過好幾遍：前 OpenAI 首席科學家 Ilya Sutskever 的 SSI 成立三個月就拿到 50 億美元估值，前 OpenAI 技術長 Mira Murati 的 Thinking Machines Lab 首輪估值 100 億美元。資本願意在頂尖研究者還沒有任何產出時，先用一個很高的數字把人圈住。現在這套邏輯複製到了中國。

但比估值更值得看的，是他為什麼會走。

林俊暘的離職過程很罕見地公開。3 月 4 日凌晨，他在 X 上發了一句「me stepping down. bye my beloved qwen」，比阿里官方確認還早。導火線是前一天下午，阿里雲 CTO 周靖人向他傳達了一個 Qwen 團隊的重組計畫：把原本垂直整合的 Qwen，拆成預訓練、後訓練、文本、圖像、語音等相對獨立的水平團隊。

這個拆法跟林俊暘一直堅持的做法相反。他主張預訓練、後訓練、Infra、訓練團隊應該緊密結合，甚至從 2024 年中開始在 Qwen 內部自建 Infra 團隊。重組等於要把這套「小而全」的建制打散。據鈦媒體報導，他在內部群組留下的話是「無顏再帶領大家」。

往後看，他離開後阿里的 AI 戰略確實在轉向。離職前 48 小時 Qwen 才開源的 3.5 系列小模型，授權協議跟早期完全開放的 Apache 2.0 不一樣，對大規模商用設了更高的門檻。離職後，阿里把 Qwen 研發團隊和其他核心 AI 業務併進一個新事業群，由集團 CEO 吳泳銘直管，更多新模型轉向閉源以追求商業化收入。阿里雲 2025 年 Q2 財報顯示 AI+雲業務收入年增 26%、AI 相關產品收入連續八季三位數成長，這個量級的業務，自然會把模型團隊往「服務營收」的方向拉。

這就是一個放諸四海都成立的觀察：當一間公司的商業引擎，跟一條技術路線想去的方向不一致時，就算這條路線剛打完一場漂亮的仗，主導它的人最後還是會被推離。林俊暘要的是極致開源、商用零成本，阿里雲要的是能換算成收入的模型。兩邊都沒有錯，但放在同一個組織裡，張力遲早會把人擠出去。

他的新方向也跟這個脈絡接得起來。林俊暘選的切入點是世界模型和具身智能，他在 X 上的判斷是「多模態基礎模型正在轉化為基礎代理，透過強化學習利用工具和記憶進行長時序推理，它們應該從虛擬走向物理世界」。這其實是他在阿里的未竟之業——2025 年 10 月他就在 Qwen 內部組過一支機器人與具身智能的小團隊。離開之後，這件事他可以從頭照自己的想法做。

不過要把話說平衡。多位中國投資人對 The Information 提了一個我覺得值得記著的差異：矽谷那些超高估值，有一部分是押在「最終會被頂級科技巨頭收購」的退出預期上，但這個邏輯在中國還不成立。再加上美國晶片出口管制持續收緊，算力獲取本身就是一道實實在在的坎。也有投資人直接說，技術高管創業，常常在商業化上水土不服。20 億美元是一個起點，不是一個結論。

我會追的是他的第一個模型——它會告訴我們，這份估值買到的，到底是一個人的紀錄，還是一個人帶著一支隊伍重新跑一次的能力。這兩件事不一樣。

---

來源：

- [林俊旸創業，新公司估值約 20 億美金 — 智能涌現／36氪](https://eu.36kr.com/zh/p/3807382930251523)

- [Former Alibaba Qwen Architect Lin Junyang Launches AI Lab, Targets $2 Billion Valuation — BigGo Finance](https://finance.biggo.com/news/AZqhIJ4BrAZSr0oSxS4S)

- [非常罕見！阿里 AI 大牛林俊旸離職後創業，首輪估值超 130 億 — 新浪財經](https://finance.sina.com.cn/wm/2026-05-13/doc-inhxtqxn9394763.shtml)

- [林俊旸告別千問，阿里 AI 的轉身與代價 — 鈦媒體](https://www.tmtpost.com/7901214.html)

- [Alibaba scrambles after sudden departure of Qwen tech lead — KrASIA](https://kr-asia.com/alibaba-scrambles-after-sudden-departure-of-qwen-tech-lead)

模型會升級，真正留下來的是 harness

Opus 4.6 在 Claude Code 跑 Terminal Bench 2.0 拿第 33 名，把同一個模型放到另一個 harness 跑同樣的 benchmark 跳到第 5 名

過去半年 Harness Engineering 這個詞被很多人各自獨立提出來。Hashimoto 2 月、OpenAI 的 Lopopolo 2 月、HumanLayer 3 月、Birgitta Böckeler 4 月。最近 Addy Osmani 把這些線索串成一篇，值得讀。我看完想記下來的不是定義，是裡面一個觀察。

Addy 引用 Viv Trivedy 一句話：「Harnesses don't shrink, they move.」工具變強的時候，harness 對應補位的那層不會消失，只會搬家。

舉個具體案例。Anthropic 在 2025 年 11 月推出 Tool Search Tool，把 MCP 工具描述從 prompt 抽出來，agent 要用才去查。一個典型 MCP setup 的 baseline 從 55,000 token 降到 3,000 token，省 85%。這聽起來像是 harness 縮小了，但實際上「決定哪些工具該載入」這個工作沒消失，是搬到 search/retrieval layer，由更精細的 ranking 機制接手。模型不會自己學會選工具，是 harness 變聰明，幫它選。

ETH Zurich 一篇 paper（arxiv 2602.11988）測 AGENTS.md / CLAUDE.md 的效果，結論很直白：LLM 自己寫的 instruction 檔案，效果常常比沒寫還差。人類寫的能讓任務成功率提升 4%，但會多 20% 的 inference 成本。HumanLayer 給的建議是控制在 60 行內、只放 build/test 指令，不要寫長篇大論。harness 元件不是越多越好，而是要精準，否則每一個都在搶 attention。

這也解釋了一個現象：把 Claude Code、Cursor、Codex、Aider、Cline 並排比較，會發現它們的架構設計比背後的模型還像彼此。模型一直變，但 harness pattern 在收斂。AGENTS.md、subagent、hooks、planner/worker 分工、ratchet 式錯誤紀錄、root level 的 CLAUDE.md，這幾根支柱在每一家都看得到。各家不是抄誰，而是各自試錯後發現同一個答案。

所以也看到一個趨勢：harness 本身正在從「自己造」變成「服務」。Viv 把它叫 Harness-as-a-Service。Claude Agent SDK、Codex SDK、OpenAI Agents SDK 都指向同一個方向，你拿到的不是 LLM completion API，是包含 loop、tool routing、context management、hook、sandbox 的 runtime。客製化的點從「我要怎麼接 LLM」搬到「四根支柱（system prompt、tools、context、subagent）各要怎麼調」。

那「換模型解決問題」這條路為什麼通常不通？

Luke Stahl 在 Stop upgrading your model 那篇寫得直白：模型升級的差距比想像中小，harness 改動的差距比想像中大。HumanLayer 同意：「這不是 model problem，是 configuration problem。」

Sergey Golubev 4 月那篇 Harness Engineering 紀錄文有個具體例子。Opus 4.7 一發布，他幾個 harness 馬上掉鏈子，不是 code 壞掉，是指令解讀方式變了，舊 skill 寫得太寬鬆。重寫三個、整理五個花了大半天。每次模型升級都會逼一次 harness 重整，因為新模型對舊指令會用不一樣的方式詮釋。

所以差異化到底在哪？Ry Walker 的整理是：harness 本體（Claude Code、OpenCode、Goose、Aider）已經是 commodity，遷移成本很低。真正的差異化在三個地方：context 跟 memory（codebase 規矩、過去踩過的坑）、orchestration（多 agent 怎麼分工）、tool layer（接到內部系統的客製化工具）。

回到 Addy 那篇的尾巴，他列了三個值得追的開放問題：多 agent 並行共享 codebase 的協作機制、agent 分析自己的 trace 找 harness 級失敗模式、harness 動態組裝工具與 context 而非事前配好。每一個都是同一條思路的延伸。harness 不會穩定，會繼續搬家，重點是知道它正在往哪搬。

模型升級會繼續發生，幾乎每幾個月一次。但跟 agent 一起累積的 context、規則、工具、skill，這些是換 harness、換模型都帶得走的。

Sources:

- Addy Osmani: Agent Harness Engineering — https://addyosmani.com/blog/agent-harness-engineering/

- HumanLayer: Skill Issue — https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents

- Luke Stahl: Stop upgrading your model — https://lukestahl.io/blog/stop-upgrading-your-model-fix-your-harness/

- Sergey Golubev: Harness Engineering 2026 — https://www.prodfeat.ai/en/blog/2026-04-18-harness-engineering

- Ry Walker: The Agent Harness Problem — https://rywalker.com/agent-harness-problem

- 張維峰 FB 中譯整理 — https://www.facebook.com/jerry.chang.505523/posts/pfbid0WZP6JBVGp3CNR6ot1GizCVcdDPQcEnhxJVW4An3hZLc2EjbviZrfenL627i5ANuvl