AI焦點｜AI Demand Is Outstripping Supp・兩種不碰聯邦基金利率的升息暗招：Kevin Warsh 與・你真的不該把錯誤訊息直接複製貼進Claude Code

📰 1. AI Demand Is Outstripping Supply — Even Google Can’t Keep Up

TITLE:AI需求持續超越供給——連Google也應付不來

原文摘要：當AI軍備競賽撞上物理極限

最近一份市場報告點出一個殘酷現實：AI的算力需求已經超過整個產業的供貨能力，甚至連Google這種自研晶片、自建資料中心的巨頭，也沒辦法完全跟上。報導提到，從NVIDIA的H100/B200 GPU到Google自家的TPU，每一代晶片幾乎都在量產前就已被預訂一空。訓練大型語言模型（LLM）需要的算力每幾個月就翻倍，但晶圓廠的產能擴張卻需要兩三年。更糟的是，先進封裝（CoWoS）成為新的瓶頸，台積電即便瘋狂擴產，仍無法滿足所有客戶。簡單說：錢準備好了，但晶片生不出來。

我的觀點：這不是缺貨，是整個產業的「頻寬」跟不上

我完全贊成報導的判斷——AI需求的確正在失控。但我想點出更深層的問題：這不是單純的「供給不足」，而是整個供應鏈的吞吐量（throughput）到了極限。從上游的EUV光刻機、矽晶圓，到中游的晶圓代工、封測，再到下游的伺服器組裝、資料中心電力，每一個環節都在拉扯。Google的優勢在於垂直整合（自己設計TPU、自己蓋資料中心），但現在連他們都說「餵不飽」需求，代表問題已經從商業競爭升級成物理限制——摩爾定律放緩、先進封裝良率爬升慢、電力供應審批卡關。我擔心的是，如果需求再這樣指數成長，2025年可能會出現「AI算力泡沫化的前兆」：企業砸錢買不到卡，被迫轉向低效方案，最終導致模型訓練延遲、產品品質下降，反過來打擊市場信心。

延伸思考：台灣半導體是解方還是新戰場？

這個短缺對台灣來說既是機會也是壓力。台積電的CoWoS先進封裝產能幾乎被NVIDIA和AMD包下，Google、Amazon也開始搶著要。但短期內擴產有限，因為設備交期長、技術人員不足。我認為接下來的關鍵不在於「蓋更多廠」，而在於重新設計AI晶片的架構——例如用更小的晶片（chiplet）組合、光互連（optical interconnect）來繞過封裝瓶頸。另外，電力也是隱形成本：一座大型AI資料中心的用電堪比一座中型城市，台灣的綠電和電網負載能否支撐？如果Google未來在台灣設資料中心，我們真的準備好了嗎？這不只是工程問題，更是國安與能源政策的考驗。

📝 編輯說：:這篇報導在科技論壇引發熱議，筆者認為最有價值的觀點是把「需求超出供給」從商業新聞提升到物理極限的討論，值得所有半導體從業者深思。

📰 2. 兩種不碰聯邦基金利率的升息暗招：Kevin Warsh 與 FOMC 的隱形工具箱

🔗 原文連結

原文摘要

最近 Yahoo Finance 一篇分析挖出一個有趣的觀點：如果 Kevin Warsh 真的接掌聯準會，他跟 FOMC 其實有辦法「偷偷摸摸」升息，完全不用動到大家最熟的聯邦基金利率。報導點出兩招：第一是調整超額準備金利率（IOER），第二是操作隔夜逆回購利率（ON RRP）。這兩樣東西平常比較少上新聞，但卻是聯準會控制短期利率的隱藏槓桿。比如說，IOER 決定了銀行願意把錢存回央行的報酬，調高它就能引導市場利率往上走；ON RRP 則像一個利率地板，調高它會讓貨幣市場基金不願意低價借錢出去。表面上聯邦基金利率不動，但實際借貸成本已經悄悄上升。

我的觀點

這裡面最值得注意的矛盾是：明明說「不調整聯邦基金利率」，但 IOER 和 ON RRP 就是聯邦基金利率的「天花板與地板」啊！調整它們根本就是在間接控制聯邦基金利率的區間，市場上的隔夜拆款利率照樣會跟著跑。我的判斷是，這與其說是「偷偷摸摸」，不如說是聯準會早就玩熟的技術性微調——2018 年鮑爾就多次用 IOER 來壓住有效聯邦基金利率，避免它突破目標區間。Kevin Warsh 如果拿這套來用，等於是在不驚動大眾媒體的情況下，讓短期利率逐步緊縮，對股市的殺傷力反而更難預測，因為散戶還以為利率沒變。

另外還有一個關鍵風險：如果市場習慣了這種隱形升息，聯準會的溝通效果會打折。以前只要看聯邦基金利率目標就能知道政策方向，現在還得盯著 IOER 跟 ON RRP 的動向，搞到投資人還得去算 effective fed funds rate 跟 IOER 的利差，實在有點燒腦。而且這種做法對於長天期利率的傳導效果不明顯，對房貸、公司債的壓制力有限，最後可能變成「只升短端、不升長端」的扭曲曲線。

延伸思考

如果未來 Fed 越來越常用這些「暗器」，那聯邦基金利率作為政策指標的意義會不會被稀釋？實際上歐洲央行跟日本央行早就玩過類似把戲，搞到市場要同時追蹤好幾個利率走廊的參數。對一般投資人來說，我覺得該開始留意 SOFR（有擔保隔夜融資利率）和 IOER 的差距，這比單純看聯邦基金利率更能反映真實的流動性緊縮程度。另外，這種策略也給了 Fed 更多政治上的操作空間——不用在記者會上大聲喊「我們要升息了」，避免被白宮或國會釘，但該緊的時候還是能緊，夠狠吧？

📝 編輯說：:** 這篇文章在 Bloomberg 終端機的「Fed 工具箱」討論串被瘋狂轉傳，筆者認為最有價值的觀點是「聯準會的隱形升息手段，反而讓散戶更難察覺資金成本變化，進而低估風險」。

📰 3. 你真的不該把錯誤訊息直接複製貼進Claude Code

🔗 原文連結

原文摘要

Robusta Blog 最近發了一篇文章，標題直接點出「You really shouldn't copy-paste errors into Claude Code」。雖然原文被一堆 cookie 同意和 PostHog 追蹤腳本淹沒（技術部落格日常），但核心論點很清楚：很多開發者習慣把終端機看到的錯誤訊息整段複製，丟進 Claude Code 之類的 AI 工具，然後期望它直接給出解決方案。但作者認為這種做法其實很危險——錯誤訊息往往只是症狀，不是病因。AI 缺乏你當下的專案脈絡、變數狀態、環境設定，甚至可能被錯誤訊息中的字詞誤導，給出看似合理但完全無效的建議。

我的觀點

讀者可以回想一下這個場景：你寫了一下午的程式，終於 build 出一個紅通通的錯誤，心累之餘順手把 terminal 那堆亂碼選起來 Ctrl+C，然後貼到 Claude Code 的對話框，打一句「為什麼會錯？」。我懂，這超省事，我過去也這樣幹過。但問題在於，錯誤訊息只是事故現場的碎片，不是你該直接複製的筆記本。

真正的除錯流程應該是：先搞清楚你做了什麼，環境長怎樣，預期行為是什麼。錯誤訊息可能指向某個檔案第 42 行，但問題根源常常在三個檔案外的變數型別、環境變數沒設、或是依賴版本衝突。你把錯誤丟給 AI，它只能從字面上猜，然後給你一個看起來像答案的答案——但那個答案很可能讓你繞更大一圈。

比較好的做法是：把上下文描述清楚，像是「我正在用 Django 3.2 跑 migrate，資料表已經存在，但出現 IntegrityError，我猜是之前 migration 沒跑乾淨」。這樣 AI 才有機會理解真正的問題，而不是被錯誤訊息表面的字句牽著走。簡單來說，把你的除錯筆記也給 AI 看，不要只給錯誤。

延伸思考

這件事延伸出來的是整個 AI 協作開發的習慣題。工具越來越強，但人的思考品質不能跟著變懶。如果你只是把 AI 當成高級複製貼上過濾器，那你永遠學不會自己找出問題的根源。反過來說，懂得問對問題、提供對的脈絡，才是讓 AI 變成真正助手的關鍵。

另外，對新手工程師來說，直接複製錯誤可能是一種無意識的依賴；對老手來說，則可能是一種節省時間的捷徑。但兩者其實都忽略了「理解錯誤本質」這個核心能力。未來 AI 可能會有更好的脈絡感知，甚至自動幫你抓專案歷史記錄，但現階段，我們還是得自己當那個負責「判斷問題在哪裡」的人。

📝 編輯說：: 這篇文章在 Hacker News 上引起不少討論，很多開發者留言說「我中了好幾槍」，也有人分享自己改用結構化提問後，AI 的回覆品質明顯提升。筆者覺得最有價值的觀點是：真正該訓練的不是 AI，而是我們描述問題的能力。

📚 本日原文來源

本文由JK Space News彙整，不代表任何投資建議。