102秒內火速發佈！臺灣第一個地震速報系統的誕生──《地震：火環帶上的臺灣》

本文與 高柏科技 合作，泛科學企劃執行。

當我們談論能擊敗輝達（NVIDIA）、Google、微軟，甚至是 Meta 的存在，究竟是什麼？答案或許並非更強大的 AI，也不是更高速的晶片，而是你看不見、卻能瞬間讓伺服器崩潰的「熱」。

 2024 年底至 2025 年初，搭載 Blackwell 晶片的輝達伺服器接連遭遇過熱危機，傳聞 Meta、Google、微軟的訂單也因此受到影響。儘管輝達已經透過調整機櫃設計來解決問題，但這場「科技 vs. 熱」的對決，才剛剛開始。 

不僅僅是輝達，微軟甚至嘗試將伺服器完全埋入海水中，希望藉由洋流降溫；而更激進的做法，則是直接將伺服器浸泡在冷卻液中，來一場「浸沒式冷卻」的實驗。

但這些方法真的有效嗎？安全嗎？從大型數據中心到你手上的手機，散熱已經成為科技業最棘手的難題。本文將帶各位跟著全球散熱專家 高柏科技，一同看看如何用科學破解這場高溫危機！

運算=發熱？為何電腦必然會發熱？

這並非新問題，1961年物理學家蘭道爾在任職於IBM時，就提出了「蘭道爾原理」（Landauer Principle），他根據熱力學提出，當進行計算或訊息處理時，即便是理論上最有效率的電腦，還是會產生某些形式的能量損耗。因為在計算時只要有訊息流失，系統的熵就會上升，而隨著熵的增加，也會產生熱能。

換句話說，當計算是不可逆的時候，就像產品無法回收再利用，而是進到垃圾場燒掉一樣，會產生許多廢熱。

要解決問題，得用科學方法。在一個系統中，我們通常以「熱設計功耗」（TDP，Thermal Design Power）來衡量電子元件在正常運行條件下產生的熱量。一般來說，TDP 指的是一個處理器或晶片運作時可能會產生的最大熱量，通常以瓦特（W）為單位。也就是說，TDP 應該作為這個系統散熱的最低標準。每個廠商都會公布自家產品的 TDP，例如AMD的CPU 9950X，TDP是170W，GeForce RTX 5090則高達575W，伺服器用的晶片，則可能動輒千瓦以上。

散熱不僅是AI伺服器的問題，電動車、儲能設備、甚至低軌衛星，都需要高效散熱技術，這正是高柏科技的專長。

「導熱介面材料（TIM）」：提升散熱效率的關鍵角色

在電腦世界裡，散熱的關鍵就是把熱量「交給」導熱效率高的材料，而這個角色通常是金屬散熱片。但散熱並不是簡單地把金屬片貼在晶片上就能搞定。

現實中，晶片表面和散熱片之間並不會完美貼合，表面多少會有細微間隙，而這些縫隙如果藏了空氣，就會變成「隔熱層」，阻礙熱傳導。

為了解決這個問題，需要一種關鍵材料，導熱介面材料（TIM，Thermal Interface Material）。它的任務就是填補這些縫隙，讓熱可以更加順暢傳遞出去。可以把TIM想像成散熱高速公路的「匝道」，即使主線有再多車道，如果匝道堵住了，車流還是無法順利進入高速公路。同樣地，如果 TIM 的導熱效果不好，熱量就會卡在晶片與散熱片之間，導致散熱效率下降。

那麼，要怎麼提升 TIM 的效能呢？很直覺的做法是增加導熱金屬粉的比例。目前最常見且穩定的選擇是氧化鋅或氧化鋁，若要更高效的散熱材料，則有氮化鋁、六方氮化硼、立方氮化硼等更高級的選項。

典型的 TIM 是由兩個成分組成：高導熱粉末（如金屬或陶瓷粉末）與聚合物基質。大部分散熱膏的特點是流動性好，盡可能地貼合表面、填補縫隙。但也因為太「軟」了，受熱受力後容易向外「溢流」。或是造成基質和熱源過分接觸，高分子在高溫下發生熱裂解。這也是為什麼有些導熱膏使用一段時間後，會出現乾裂或表面變硬。

為了解決這個問題，高柏科技推出了凝膠狀的「導熱凝膠」，說是凝膠，但感覺起來更像黏土。保留了可塑性、但更有彈性、更像固體。因此不容易被擠壓成超薄，比較不會熱裂解、壽命也比較長。

OK，到這裡，「匝道」的問題解決了，接下來的問題是：這條散熱高速公路該怎麼設計？你會選擇氣冷、水冷，還是更先進的浸沒式散熱呢？

液冷與 3D VC 散熱技術：未來高效散熱方案解析

傳統的散熱方式是透過風扇帶動空氣經過散熱片來移除熱量，也就是所謂的「氣冷」。但單純的氣冷已經達到散熱效率的極限，因此現在的散熱技術有兩大發展方向。

其中一個方向是液冷，熱量在經過 TIM 後進入水冷頭，水冷頭內的不斷流動的液體能迅速帶走熱量。這種散熱方式效率好，且增加的體積不大。唯一需要注意的是，萬一元件損壞，可能會因為漏液而損害其他元件，且系統的成本較高。如果你對成本有顧慮，可以考慮另一種方案，「3D VC」。

3D VC 的原理很像是氣冷加液冷的結合。3D VC 顧名思義，就是把均溫板層層疊起來，變成3D結構。雖然均溫板長得也像是一塊金屬板，原理其實跟散熱片不太一樣。如果看英文原文的「Vapor Chamber」，直接翻譯是「蒸氣腔室」。

在均溫板中，會放入容易汽化的工作流體，當流體在熱源處吸收熱量後就會汽化，當熱量被帶走，汽化的流體會被冷卻成液體並回流。這種利用液體、氣體兩種不同狀態進行熱交換的方法，最大的特點是：導熱速度甚至比金屬的熱傳導還要更快、熱量的分配也更均勻，不會有熱都聚集在入口（熱源處）的情況，能更有效降溫。

整個 3DVC 的設計，是包含垂直的熱導管和水平均溫板的 3D 結構。熱導管和均溫板都是採用氣、液兩向轉換的方式傳遞熱量。導熱管是電梯，能快速把散熱工作帶到每一層。均溫板再接手將所有熱量消化掉。最後當空氣通過 3DVC，就能用最高的效率帶走熱量。3DVC 跟水冷最大的差異是，工作流體移動的過程經過設計，因此不用插電，成本僅有水冷的十分之一。但相對的，因為是被動式散熱，其散熱模組的體積相對水冷會更大。

從 TIM 到 3D VC，高柏科技一直致力於不斷創新，並多次獲得國際專利。為了進一步提升 3D VC 的散熱效率並縮小模組體積，高柏科技開發了6項專利技術，涵蓋系統設計、材料改良及結構技術等方面。經過設計強化後，均溫板不僅保有高導熱性，還增強了結構強度，顯著提升均溫速度及耐用性。

隨著散熱技術不斷進步，有人提出將整個晶片組或伺服器浸泡在冷卻液中的「浸沒式冷卻」技術，將主機板和零件完全泡在不導電的特殊液體中，許多冷卻液會選擇沸點較低的物質，因此就像均溫板一樣，可以透過汽化來吸收掉大量的熱，形成泡泡向上浮，達到快速散熱的效果。

然而，因為水會導電，因此替代方案之一是氟化物。雖然效率差了一些，但至少可以用。然而氟化物的生產或廢棄時，很容易產生全氟/多氟烷基物質 PFAS，這是一種永久污染物，會對環境產生長時間影響。目前各家廠商都還在試驗新的冷卻液，例如礦物油、其他油品，又或是在既有的液體中添加奈米碳管等特殊材質。

另外，把整個主機都泡在液體裡面的散熱邏輯也與原本的方式大相逕庭。如何重新設計液體對流的路線、如何讓氣泡可以順利上浮、甚至是研究氣泡的出現會不會影響元件壽命等等，都還需要時間來驗證。

高柏科技目前已將自家產品提供給各大廠商進行相容性驗證，相信很快就能推出更強大的散熱模組。

今天來分享我們用 notion 做知識管理的實作過程與心得，不過，我們發現這樣還不夠用，生為 AI 懶人 YOUTUBER，最好有天上掉下來的題目跟素材，所以還串了 zapier 做自動化 AI 新聞收集！

不過在分享實做過程跟心得前，想先跟大家分享我跟 AJ 有在用的筆記工具，這樣你會知道為什麼我們最後選擇用 notion 了。

如果你只想看 notion 自動收集資料，可以直接下滑教學。

Notion

首先是 notion 端，我們先把 papaya 的模板 複製過來。

調整一下資料表格式，後面主要會用到的是名稱、URL、標籤、狀態。

首先，我們先點選標籤，

新增你想要自動化的youtube頻道名稱。

然後到狀態，把原本 index 改名成 youtube 自動串連。

這樣就完成 notion 端的設定。

Zapier

接著來到 zapier，登入後點 create。

進到自動化流程的編輯畫面，你會看到上面有一個 AI 協作的對話框。

輸入「特定 youtube channel 發布影片後，會把影片標題跟連結傳送到 notion 的資料庫」

這樣流程 flow 就出來啦！

如果 AI 給你的長這樣，要把中間的 get report 刪除。

這邊簡單說一下，畫面上看到的這一串，叫「flow」。

「flow」的最上面是「trigger 觸發器」，是啟動 flow 的條件，

其餘的叫「action」，trigger 觸發後會依序執行下面的 action。

我們先點進第一個 trigger 進行設定，

在這邊確認 event 是 new video in channel。

然後在 account 這邊，串聯你的 youtube 帳號，用哪個沒差，除非你是頻道主要觀察自己的數據。

接下來就到了重頭戲 trigger 啦，這邊要填的是 channel ID。

提醒，channel ID 不是網址後面這串，

你可以到想要抓的頻道首頁，按 ctrl+U 開啟原始碼，再按 ctrl+F 尋找這串文字，

後面那串亂碼就是 channel ID 了。

貼回去按 refresh，

如果有成功抓到，下面的 countinue 就會亮起來，

按下去進到測試頁面 test trigger 按下去。

成功的話，你就會看到他把影片資料抓過來嘍，下面是選後面用的測試資料，選哪個都可以，選完點 countiune。

就會進到 notion 設定，確認一下 event 的設定是不是 create database item，

確認完按下一步，account 這邊設定連接到你的 notion 帳號，連完一樣按下一步。

重頭戲又來啦，action 這邊是設定 youtube 資料要怎麼存進 notion？

我們先點開 database，選擇剛剛整理過的資料庫，

然後就會跑出很收熟悉的選項，沒錯，這就是剛剛在notion設定好的資料表欄位，現在只要告訴他要把資料放入哪個欄位就好。

名稱，放影片的 title。

標籤，放剛剛設定好的頻道名稱標籤。

URL，就選影片連結的 URL。

狀態選 youtube 自動串連。

這樣新影片就會出現在 notion 頁面的左邊自動呈現囉。

這樣就完成啦，又可以點 countinue 了，不過我自己還會在 content 這個欄位選 description，把影片描述也放入 notion。

點完 countine 進入測試環節，

按 test step。

成功的話，就會看到 test step 變成 publish，

這時回去看 notion 的資料庫，你會發現多一筆剛剛測試的數據。

最後按下 publish，這樣就完成啦。

之後就坐等別人發片，再跟風就好！想企劃就是這麼簡單。

結語

最後來分享一下實做心得吧！

這次實做讓我體會到 notion 的美妙之處，之前都單純把他當成昇級版的 evernote，但跟 Zapier 之類的自動化服務串聯後，馬上變成不同檔次的東西，集前台後台於一身，甚至還能做網站！

這自由度真的是只有想不到，沒有做不到，沒程式基礎的人也能輕鬆入門，難怪會紅。

最後，想問大家會想用 notion 跟 zapier 來做什麼呢？

如果看到有趣的留言，我會試著做做看，有其他想要看的 AI 工具測試或相關問題，也可以留言分享喔！

如果喜歡這支影片的話，也別忘了按讚、訂閱，加入會員，我們下集再見～掰！

更多、更完整的內容，歡迎上泛科學院的 youtube 頻道觀看完整影片，並開啟訂閱獲得更多有趣的資訊！

• 作者／林書帆、黃家俊、邱彥瑜、李玟萱、王梵

臺灣速報的優勢：利用即時強震訊號自動定位

「當年，沒有一個國家用即時強震訊號做地震觀測，臺灣是第一個！」吳逸民指出，能在一百零二秒內傳出地震速報的關鍵有二：一是善用「即時強地震觀測訊號」，第二是以此資訊做自動定位，並在短時間內提出預警。

此一轉捩點正是一九九五年。在鄧大量的建議下，強地動觀測網（TSMIP）與中央氣象局地震觀測網（CWBSN）共站的加速度型地震儀，利用了同一條傳輸專線把強震資料同步傳回氣象局，相較於七○年代區域性的強震儀陣列，受限於當時僅能以類比訊號傳輸紀錄，後來拜數位發展之賜，一九九五年的強震資料即能藉由數據專線立即傳回臺北，做到「即時」監測。

以此「即時強地動系統」為骨幹，臺灣的地震測報進入「速報」階段。直到九二一地震，當時全臺已有超過六百三十個自由場強震站，其中具有即時傳輸功能者約有六十個， 蒐集地動訊號後即時傳輸回氣象局。

一九九五年阪神大地震，日本首相村山富市在震後一個多小時才收到地震速報，吳逸民解釋，當時日本震度七以上地震必須由人為判斷，才能發布，而臺灣領先的關鍵就在於以自動化加快速報發展。至於自動定位與預警系統如何做到，得從「B 計畫」的故事講起。

本土 B 計畫勝出

當時服務於美國地質調查所的顧問李泓鑑提點臺灣可能有發展地震預警潛力，也成為氣象局一九九四年提出臺灣第一部《氣象白皮書》納入「地震預警」的契機。當年，氣象局啟動第一個地震預警的實驗，由加拿大一間商業公司主導，選在地震活躍的花蓮設立十個測站，資料透過專線匯集至花蓮氣象站做即時處理，並將結果傳至臺北的氣象局本部評估、分析，這也是臺灣地震預警系統發展的雛形，在內部被稱為 A 計畫。

當時，傳輸地震訊號的電話線路尚有一半頻寬容量可使用，中研院地球科學研究所院士鄧大量便建議發展 B 計畫做為備案。B 計畫的基礎技術由李泓鑑提供，執行者就是氣象局內的吳逸民，他們隔著太平洋時差一起工作。

當時 A 計畫與 B 計畫都是藉由撰寫程式讓計算流程自動化，藉由強震紀錄的 P 波與 S 波自動定位，計算地震規模，同時能將地動加速度換算成規模。其中自動定位技術，是 A 計畫與 B 計畫競逐的核心目標。

為了縮短時間，必須利用地震初始震動定出規模，但是如何保有一定的準確度，成為技術上最難以克服的瓶頸，這也讓當時國內外許多學者都不看好臺灣發展預警系統。

由於 A 計畫測站大多僅分布於花蓮狹長的海岸線地帶，雖然可在十幾秒獲得地震訊息，但定位準確度不理想，震央位置平均誤差達二十二公里，規模誤差也達到○．七個規模單位。吳逸民認為，A 計畫在通訊、展示介面跟軟體程式方面表現不錯，但執行團隊缺乏地震學人才，對於地震核心掌握度不足，以至於重要資訊誤差很大，實用性不高。

一九九五年即時強震資訊的啟用，免除需人工電話撥接的時間，吳逸民主責的 B 計畫順利發展出自動挑選 P 波與 S 波的系統，將發布地震時間縮短至五分鐘。以 B 計畫的成功為基礎，吳逸民馬不停蹄投入預警工作，利用宜蘭、花蓮、南投等地共六十至七十個測站的即時強震訊號建立「花蓮子網」預警系統，由於串連多個地區即時強震訊號，覆蓋性較廣，將定位誤差控制在二十公里內、規模誤差○．三單位內，獲得地震資訊的時間大幅縮短至二十秒。

最終，B 計畫淘汰了受限於商業系統而無法修改的 A 計畫，原有測站都併入 B 計畫，成為臺灣第一個成功的地震速報系統。

——本文摘自泛科學 2019 年 11 月選書《地震：火環帶上的臺灣》，2019 年 10 月，春山出版

上次 notion + zapier 做完後，開會總算沒挨罵了，自動化服務真的讚！

而這次介紹 MAKE 串 LINE 做重要信件通知，也源自於我遇到的問題。

如果你不想聽故事，可以往下看教學。

Line Notify

首先，我們會用到 line notify 的服務，要先到官網登入申請。

登入後如果完全沒用過，會直接進到登錄服務畫面。

這邊除了 email 以外可以隨便填，email 之後要收確認信用的，請用你常用的 email。 然後提醒一下，網址跟 callback URL 不要用 google 之類常見的網址，會沒辦法通過，請隨便打一串看起來正常的網址。

設定完成後按登錄。

這時回去剛剛填的 email 收通知信，開通剛設定好的 line notify。

大功告成，這時點右上角的「管理登入服務」，就會看到剛剛設定好的 line notify，這樣 line 的部分就設定好了，可以去 make 做自動化串連。

Make

接著登入 make，如果是第一次使用，他會問你很多廢話。

不用管他隨邊點，直到你看到這個畫面。

點右上角 creat a new senario。

一進去會看到的這個圓圈，這個圓圈跟之前 Zapier 說的 trigger 是一樣的東西，可以手動自己設定流程 flow。

但我們還是叫 AI 幫我們啦，點右下角的 AI Assistant，對話框選選 creat or edit a senario。

輸入「if my gmail get a new email, then send LINE notification」

然後得到畫面上的 flow，左邊是 Gmail watch email，右邊是 line send a notification。

如果你用中文輸入類似的內容，常會跑出很複雜的 flow，這種 flow 裡面有很多有趣的功能。

但這集用不到，我們還是先回到正確的 flow 上。

點開 gmail，連上要整理的信箱。

連接完成後進入設定，先點選藍色的 click here to choose folder。

這邊會出現你在 gmail 裡做的標籤分類，由於我完全沒有按照規則整理，就直接選 inbox，對所有郵件進行分析。

filter type 用 simple filter。

下面的 Criteria 選 all emails 就好了，我們後面會再用 filter 細分。

然後這個，選 no。

選擇 yes 會把偵測過的 email 變成已讀，我不想這樣。

然後這邊是每次執行 flow 時，會抓取多少筆最新的 email 到 line 上發布通知。

免費的 make 是 15 分鐘執行一次 flow，請自己評估每 15 分鐘會收到多少封有用的信件，設定太多你的 LINE 通知會炸裂。

我自己測試後，設定為 5 就差不多了。

設定好點下 OK，會跳出從哪封 email 開始抓資料，用 from now on 就好，之後的新郵件就會自動讀取了。

按下OK，接下來就可以來設定 filter 啦。

點連接線旁邊的板手會跳出選單，選第一個 set up a filter。

進入 filter 設定畫面，上面的 label 是幫這個 filter 上標籤，填你喜歡的就好。

然後點 condition 下面的輸入框，選 subject 標題跟 text content 內文。

然後在 text operator 這裡，選擇 contains。

contains 是在特定字串中如果包含某個關鍵字，就可以通過。

這邊說的特定字串，就是上面欄位設定的標題跟內文。

接下來，在下面空格打上關鍵字，就完成啦。

如果有多個關鍵字要篩選，點選 add OR rule 設定其他關鍵字，不能多個關鍵字打在一起。

按下OK，你會看到板手變成一個漏斗，這樣 filter 就設定完成。

接著點開 line，他會要你輸入 notify API。

回到 line notify 的「管理登入服務」頁面，點擊剛剛設定好的服務，進入服務細節的頁面，複製上面的 client ID。

回到 Make 複製貼上按SAVE。

接著會進到這個頁面，這邊是設定你要在哪個聊天室發送通知，你可以設定在工作群組發送，我這邊先設定我自己就好。

然後進入 line 推播訊息的設定頁面。

message 這欄可以打成這樣，這樣就不會丟一個不知道在做什麼訊息，你也可以發揮創意寫一些幹話進去，增添趣味。

下面的設定用不到，我們直接按OK就完成了。

接下來就要測試啦，我先分別寄三封信件到公用信箱中，分別是：

1. 標題有關鍵字
2. 內文有關鍵字
3. 沒有關鍵字

寄完後，按下 run once。

成功的話就會在 line 上收到通知，果然，沒有把不含關鍵字的信件傳到 line 上，測試成功。

現在把下面的 scheduling 打開，就完成所有設定了。

以後再也不用擔心自己漏接公用信箱的重要信件啦！

結論

最後分享一下實做心得：

比起 zapier 跟 ifttt，make 用起來更有寫程式的感覺，對完全沒有程式背景的人，Zapier 跟 ifttt 會比較好上手，但在免費版的情況下，make 能做到比 zapier 更複雜的自動化功能。

像前面有出現過的複雜流程圖，就可以用 router 做出複數條件判斷的流程，例如前面抓gmail的流程，加上 router 後就不只能傳送提醒到line，還能自動回復罐頭訊息給符合條件的郵件，這如果要在zapier做，就要做兩個流程才能達成了。

另外如果你的公司信箱不是使用Gmail，前面的模組可以從Gmail改成Email，Connection type選用Microsoft系列。

理論上只要這邊按 save，就可以選擇你要串連的microsoft帳號。我串完之後還是抓不到信件，但 make 跟 microsoft 帳戶上，都顯示授權成功，如果有人知道這是什麼問題，請一定要留言告訴我⋯⋯

這次的分享就到這邊，如果有其他想看的 AI 工具測試或相關問題，可以直接留言 ，或給加入 Discord 跟我們一起討問喔。

如果喜歡這支影片的話，也別忘了按讚、訂閱，加入會員，我們下集再見～掰！

更多、更完整的內容，歡迎上泛科學院的 youtube 頻道觀看完整影片，並開啟訂閱獲得更多有趣的資訊！