📜 歷史腦洞
現代軟體工程師穿越到漢朝：幫張衡設計地震預測 App，提前預警所有地震
「該死的 compile error！就差一個分號！」李明（化名）用力敲了一下鍵盤，螢幕上的 TypeScript 錯誤訊息像嘲諷般閃爍著。他揉了揉佈滿血絲的眼睛，眼前的程式碼逐漸模糊……下一秒，一陣天旋地轉，他發現自己躺在一片黃土地上，身旁是一群穿著深衣、束著高冠、滿臉驚恐的古人。而站在他面前的，正是歷史上鼎鼎大名的科學家——張衡。
「閣下從何而來？為何衣著如此……怪異？」張衡捻著鬍鬚，好奇地打量著李明身上那件印著「I ❤️ Kubernetes」的 T-shirt。
李明腦中一片混亂，但職業病使然，他迅速掃描了四周環境：木構建築、青銅器、沒有 Wi-Fi 訊號、沒有電源插座……完了，這不是一場惡搞的 team building，他百分之百穿越了，而且還是穿越到了東漢時代的洛陽。
張衡眼神一亮：「地動儀？此物尚未問世，不過我確實正在構思一種能偵測『地動』的機關。你從『天外』而來，莫非知曉這其中的奧秘？」
李明的心臟砰砰直跳。一個大膽、荒謬、卻又極度吸引人的念頭浮現：「如果我幫張衡開發一款『地震預警 App』，用現代科技提前預警所有地震……這歷史會變成什麼樣子？」於是，一段史上最荒唐的跨時代軟體開發專案，就此展開。
李明的第一反應是掏出手機。「靠！竟然有 5% 的電量！」他興奮地打開手機，但映入眼簾的是「No Service」。沒有電信業者，沒有 Wi-Fi，沒有衛星訊號。他打開手機裡的「地震預警」App（這是他在台灣老家安裝的），螢幕上空白一片，只有一行小字：「目前無網路連線」。李明仰天長嘯：「這比 production 環境出包還要絕望啊！」
李明無奈地解釋：「這叫智慧型手機，是我們那邊的通訊工具。不過在這裡，它就跟一塊磚頭沒兩樣。」他嘆了口氣，但隨即眼神堅定起來：「沒關係，沒有手機，沒有網路，我還有這裡——」他指著自己的腦袋，「還有我的十年軟體開發經驗。張大人，我們來合作吧！」
張衡帶著李明參觀了他的「實驗室」。說是實驗室，其實就是一個擺滿青銅器、竹簡和各種奇形怪狀機械的書房。張衡指著一張草圖，興奮地介紹：「此乃我心中設想的『地動儀』。以精銅鑄成，圓徑八尺，狀如酒樽。內部設有都柱，並沿八個方向設置機關。若某方發生地動，則該方向的龍口便會吐出銅丸，落入下方蟾蜍口中，以此測知地震方位。」
李明聽得目瞪口呆，內心暗道：「這根本就是古代的加速度感測器（Accelerometer）加上簡易的觸發器！利用慣性原理偵測縱波（P-wave）和橫波（S-wave）的差異。張衡根本是漢朝版的感測器工程師啊！」
「張大人，」李明正色道，「您的設計非常精妙，但這只能做到『事後偵測』，告訴我們哪裡發生地震。我要幫您做的，是『事前預警』，在地震波到達之前，提前告訴百姓避難。這在我們那個時代，叫做 Earthquake Early Warning（EEW）系統。」
「當然可以！」李明眼中閃爍著光芒，「地震發生時，會產生兩種波——速度較快但破壞力較小的縱波，以及速度較慢但破壞力極強的橫波。如果我們能在偵測到縱波的瞬間，立刻透過某種方式發出警報，百姓就能在橫波到達前，爭取到幾秒甚至幾十秒的逃生時間！」
李明的第一份專案文件（Project Charter）是在一片竹簡上刻出來的。他苦笑著看著自己精美的 MacBook Pro 變成了一台沒有電源的擺設，只好拿出古人最原始的開發工具——毛筆。
「張大人，我們首先需要定義清楚目標和範圍（Scope）。我想先確認一下：我們的目標是『提前預警所有地震』，對吧？」
李明在地板上鋪開一張絲綢地圖，開始規劃：「在我們那個時代，地震預警系統仰賴的是密集的地震感測器網路（Seismic Sensor Network）、低延遲的通訊骨幹（Communication Backbone），以及大數據分析（Big Data Analytics）。在這裡，我們沒有電、沒有網路線、沒有衛星。所以，我們必須打造一套『類比』的基礎設施。」
他指著地圖上幾個戰略要點：「我計劃先在洛陽、長安、南陽、成都、以及西域的敦煌這五個地方部署『改良版地動儀』，作為我們的感測器節點。然後，利用驛站系統當作我們的『資料傳輸網路』。最後，在洛陽設立一個『中央處理中心』，也就是我們的『伺服器機房』。」
張衡眼睛一亮：「驛站系統？此法可行！漢朝驛站遍佈全國，以快馬傳遞消息，一日夜可行數百里。若各節點偵測到異動，即刻以快馬通報洛陽……」
李明的第二個難題是，他的「地震預測演算法」需要大量的歷史地震資料來訓練模型。在現代，他可以直接調用氣象局的地震目錄，但在漢朝，這些數據可能存在於各種野史、地方志、以及人們的口耳相傳之中。
「張大人，我們需要資料。請您下令蒐集過去五百年來，全國各地關於地動的記載，包括時間、地點、規模（雖然沒有芮氏規模這個概念）、以及造成的損害。」李明說。
於是，張衡動用了他的影響力，向太史令（當時掌管天文曆法的機構）調閱了大量典籍。李明也跟著張衡，花了整整兩個月的時間，將這些零散的記載整理成了一份「古代地震資料庫」。李明用毛筆在竹簡上畫出了他的第一張資料表（Table），欄位包括：日期（用干支紀年）、地點、震感描述、建築損害程度、人員傷亡等等。
不過，這份手工打造的「資料庫」雖然簡陋，卻讓李明對古代地震的分佈有了初步的認識。他發現，關中地區（今日陝西一帶）地震頻率相當高，這也解釋了為何張衡會對地震偵測如此感興趣。
李明花了三天時間，與張衡進行了無數次「需求訪談」（Requirement Elicitation），他坐在張衡對面，擺出一個專業產品經理的姿態：「張大人，請告訴我，您希望這個『App』在使用情境上是什麼樣子？」
張衡思考片刻：「我希望當洛陽西邊發生地動時，我能立刻知曉方向；而其他地方的百姓也能提前知道，跑出屋外避難。」
「很好！」李明在竹簡上記下，「使用者故事（User Story）第一條：作為一位漢朝百姓，我想要在地震發生前收到警報，以便我能跑到空曠的地方避難。第二條：作為洛陽的中央官員，我想要知道地震發生的精確方位，以便組織賑災。」
張衡說：「以前我設計的地動儀，只能偵測『已經發生』的地震。現在你跟我說要『預測』，難道我們要隨時監測地下的動靜嗎？」
李明解釋：「不是『預測』，而是『提早偵測』。原理就像我剛才說的，利用縱波與橫波的時間差。我們不預測地震本身，我們預測的是『破壞性震波（S波）抵達的時間』。這個目標更實際，也更可行。」
要實現李明心目中的「地震預警 App」，原本的地動儀設計必須徹底改造。李明把自己關在工坊裡，跟一群銅匠和木匠奮戰了數週。他畫出設計圖——這個設計圖對銅匠來說，根本是天書。
「拜託，這是邏輯閘（Logic Gate）的概念！我需要一個裝置，當它感受到 P 波時，會立刻觸發一個機械訊號，將這個訊號傳遞出去！同時，它必須能區分 P 波和 S 波，避免誤報。」李明對著銅匠們比手畫腳。
「所以，這個系統的本質是：用機械方式處理類比訊號，再用烽火作為數位訊號來傳輸！」李明興奮地對張衡介紹，「這就是我的『硬體 API』！」
然而，現實是殘酷的。第一次測試時，蜂火台沒有點燃，反而是銅鈴被重錘砸壞了。第二次測試，系統把一匹路過馬車的震動誤判為地震，引發了一場虛驚。李明焦頭爛額，他的「敏捷開發」（Agile/Scrum）方法在沒有 Jira 和 CI/CD（持續整合/部署）的環境下，變得舉步維艰。
李明的「感測器節點」終於在五個城市完成部署。現在的挑戰是，如何將警示傳遞出去。李明原本想建立一個「專屬網路」，但挖壕溝、埋銅線的工程浩大到不切實際。他只好遷就現實，採用漢朝最成熟的「長距離訊息傳輸系統」——烽火台。
「沒錯，但我們可以借用它！」李明說，「我們在每個地震感測站附近設置一座特別的烽火台。當地動儀 2.0 偵測到 P 波時，會自動點燃烽火。相鄰的烽火台看到煙火後，會依次點燃，以極快的速度向洛陽傳遞訊號。」
李明邊說邊盤算著：「以烽火傳遞的速度，理論上大約是每小時 300 到 400 公里。如果地震發生在這些節點附近，我們可以爭取到幾分鐘的預警時間。不過，如果地震發生在沒有任何節點的偏遠地區，那就是『資料空窗期』了。」
「正是。」李明嘆道，「這就是硬體覆蓋率的限制。在我們那時代，地震感測器密度極高，但在漢朝，我只能依靠這幾台設備打天下。」
事實上，這個系統的「延遲」（Latency）對軟體工程師來說是難以忍受的。現代的地震預警系統，延遲要求是毫秒級（milliseconds），而烽火台的延遲是以「分鐘」甚至「刻」來計算。但李明無計可施，總不能像 SpaceX 那樣發射低軌道衛星吧？
「好吧，」李明在開發日誌上寫道，「這就是一個 High Latency（高延遲）、Low Bandwidth（低頻寬）、且帶有誤報風險的系統。但至少，它是可行的。」
專案上線三個月後，張衡和李明的「地震預警系統」已經成功預警了兩次中型地震，讓洛陽百姓提前逃出屋外，救了數百條人命。這個消息傳到了漢順帝的耳中。
李明雖然開心，但身為工程師，他馬上意識到：「皇室贊助」代表著更多的「利益相關者」（Stakeholders）和官僚體系。沒過多久，負責管錢的官員開始對他的預算提出質疑：「這銅鈴也太貴了吧？一個銅鈴竟然要價五百錢？你是不是有收回扣？」
更糟的是，皇室官員要求他提供「定期進度報告」。李明只好用毛筆在竹簡上畫出一張樸實的甘特圖（Gantt Chart），但那些官員們根本看不懂。李明內心吶喊：「我懷念每日 Stand-up Meeting 的 team 了！」
「我終於理解，為什麼古代的科技發展那麼緩慢了，不是因為缺乏天才，而是因為被冗餘的官僚體系給拖累了！」李明在跟張衡喝酒時抱怨。
張衡笑著安撫他：「凡事有利必有弊。有皇室支持，我們的資源更充足，能多製造幾個感測器。但相對地，我們也要學會跟這些『不懂技術的長官們』溝通。」
李明的系統在運行的第一年，總共預警了五次大小不等的地震。這在當時，被視為「神蹟」。各地百姓開始將「地動儀」視為神物，甚至有人開始崇拜張衡，認為他有通神之能。
「地震班被視為『天譴』，是上天對君王的警示。漢朝也有『天人感應』之說。現在，我們提早預警了地震，等於打破了這種神祕主義。如果百姓不再恐懼上天，而開始信任我們這個『人造系統』，這對皇權的威信其實是一種潛在的挑戰。」李明嚴肅地分析。
張衡沉默許久，緩緩道：「確實。我當初只想著救民，卻未曾想過這背後的統治學。如果這個系統由朝廷掌控，它能安撫民心；但如果被有心人利用，謊報地震，便可能引發社會動盪。」
「正是！」李明說，「在我們那時代，這叫『虛假警報』（False Alarm）的風險。狼來了的故事，我們都很熟悉。如果系統誤報太多次，人們就會不再相信警報，那真正的災難來臨時，反而會造成更大傷亡。」
為了降低誤報率，李明花了更多的時間調整機械的靈敏度，並設計了一套「雙節點驗證機制」——也就是說，必須有兩個以上的感測站同時偵測到異常，系統才會發布警報。這等於是在他的「App」裡加入了一個簡單的「共識演算法」（Consensus Algorithm）。
然而，李明的存在本身，也對歷史造成了一些不可逆的改變。張衡受李明的啟發，不僅發明了更精良的地動儀，也開始研究李明口中所謂的「力學」「物質科學」「系統思考」。他將這些概念融入他的天文學著作《靈憲》之中，使得中國古代的科學思維朝向了更「實證主義」的方向發展。
李明不禁開始思考：「這樣一來，漢朝之後的科技發展會提早數百年發生嗎？工業革命會提前嗎？這會不會造成歷史大亂鬥？」
李明的「地震預警 App」在他穿越期間，始終沒有以「數位產品」的形式出現，沒有華麗的介面、沒有即時推送的通知訊息。他的系統由青銅器、烽火台、驛站快馬、以及一群訓練有素的烽火兵所構成。而這套系統的「API」文檔，是張衡用毛筆寫在宣紙上的《地動警報操作手冊》。
這個故事諷刺的是，即使穿越到一千八百多年前，軟體工程的核心挑戰依然沒有改變。李明在漢朝遇到的問題，與現代工程師每日面對的問題本質上一模一樣：
最終，李明在一個月圓之夜，被一股無形的力量召回現代。他回到那張熟悉的辦公桌前，螢幕上依然閃爍著 TypeScript 的 compile error。一切彷彿從未發生過。但他看向窗外，眼神裡多了一種豁達。
雖然漢朝之旅宛如一夢，但當他打開現代的地震預警 App 時，他彷彿看到了張衡微笑的輪廓——那個人，在兩千年前，就用機械與智慧，為人類生命築起了一道防線。而他，李明，只是換了一種方式，繼承了這份精神。
「技術的本質，自古至今從未改變——那就是用發明，去守護你所在意的人。」李明在部落格寫下這段文字，然後又埋首於那堆看似永無止盡的 code 之中。只是這次，他的心中多了一絲溫度。
歡迎在下方留言，分享您的想法、心得或疑問。所有留言都會透過 GitHub 帳號 進行驗證。