Category: Uncategorized

  • 【能源政策】台灣反核能框架下的綠色選擇:總統府小型核子反應爐與未來政府建築趨勢

    2026年的台灣,能源政策仍是一道撕裂社會的尖銳議題。反核四的公民投票結果塵埃未定,廢核聲浪與能源轉型壓力交錯,讓政府在「非核」與「不缺電」之間走鋼索。但就在此刻,全球小型模組化反應爐(SMR, Small Modular Reactor)技術正以驚人速度突破,從加拿大到英國、從美國到中國,各國政府與企業已開始認真考慮核能作為下一世代乾淨能源的骨幹。當世界走向「安全核能」的新敘事,台灣是否準備好重新思考自己的核能路線圖?

    一、 台灣反核能框架的現實困境

    台灣的反核論述建立在一個獨特的歷史背景上:1970年代的黨外運動將「反核」與「反威權」深度掛鉤;1980年代的環保運動將核四議題政治化;2011年日本311地震引發的核事故,則進一步強化了台灣社會對核能的恐懼結構。然而,這套論述框架存在一個根本的盲點——它沒有區分「舊型核電廠」與「現代SMR」之間的根本性技術差異。

    台灣目前已停止運轉的核一、核二、核三廠,以及延宕多年的核四計畫,都是所謂的「大型輕水反應爐」技術,機組老舊、安全裕度有限,並需要大量的冷卻水與占地面積。但SMR完全不同——它的設計哲學是「小即是安全」(Small is Safe):反應爐功率通常落在77至300 MW之間(相較於核四機組每部1300 MW),可在工廠預製後運至現場組裝,並採用被動式安全系統(Passive Safety Systems),即便在喪失外部電源的情況下,也不需要人為介入即可自動冷卻。

    台灣反核論述的第二個盲點,在於它沒有回答一個簡單的問題:當燃煤電廠每年造成數千人死亡(懸浮微粒與空污),核電真的比它危險嗎?這個問題,數據給出的答案很清楚——根據世界衛生組織(WHO)統計,每年因空污相關疾病死亡的人數超過700萬,而同期因核能事故直接死亡的人數,遠低於這個數字。

    二、 小型模組化反應爐(SMR):重新定義核能安全標準

    SMR並非只是「把大反應爐縮小」這麼簡單。它代表的是一種核能設計典範的轉移:從「大型、集中、少數專家操作」轉向「小型、分散、智慧電網整合」。目前全球發展最成熟的SMR技術包括:

    • Nuscale Power(美國):已獲美國核能管理委員會(NRC)批准,是全球第一個獲得設計認證的小型模組化反應爐,功率77 MW,可組合成12機組達924 MW。
    • Terrapower(美國,比爾蓋茲支持):採用鈉冷快滋生技術,原型爐預計2026年於美國懷俄明州動工。
    • Rolls-Royce SMR(英國):英國政府支持,470 MW機組,模組化建造,預計2030年代供電。
    • 中國玲龍一號(ACP100):海南昌江核電廠已開始安裝,125 MW功率,為全球首個商用SMR在建案。

    SMR的核心安全特點,在於它們幾乎是「無法熔毁」的設計。以NuScale為例,其反應爐容器浸泡在一個巨大的冷卻池中,即便全廠失電,熱量會自然通過對流消散,不需要任何幫浦或外部電源。這與1979年三哩島或2011年 Fukushima 那種需要主動冷卻系統才能防止熔毁的設計,是完全不同世代的技術。

    三、 為何總統府地下室需要一座SMR?

    提出「總統府應安裝SMR」的主張,乍聽之下像是科幻情節,但若仔細分析台灣的能源安全處境,它其實是一個非常務實的政策選項。

    1. 戰略韌性(Strategic Resilience)

    台灣四面環海,98%以上的能源仰賴進口。當地緣政治緊張、海運受阻、或遭受導彈攻擊導致天然氣接收站與燃煤電廠受損時,總統府做為國家最高指揮中心,需要一個不被外部供應鏈切斷的電力來源。SMR一旦載入燃料,可持續供電12至24個月不需補充燃料。這對於戰時或緊急狀態下的政府運作,是無可取代的戰略價值。

    2. 碳排放與能源自主

    總統府做為國家元首機關,其碳排放量與能源消費應作為國家典範。根據估算,一座100 MW的SMR每年可替代約25萬噸二氧化碳排放,相當於5萬輛汽油小客車的年排放量。在全球氣候治理壓力下,台灣若要對外宣示淨零決心,從總統府做起,是最有力的外交符號。

    3. 技術驗證與產業升級

    若能在總統府這樣一個高可見度的場址安裝SMR,它將成為台灣核能技術發展的「國家展示中心」,為未來民間應用奠定基礎。這與當年法國在巴黎市區設置核能供熱系統、以色列在國防設施中部署微型反應爐的概念,有異曲同工之妙。

    四、 未來標竿:超過1000人的政府建築標配SMR

    總統府的示範效應,只是第一步。當這套論證成功說服社會大眾與立法機構,下一個合理的政策延伸,是要求所有「單一建築容納超過1000人」的政府設施,逐步配置SMR或替代性微型核能系統。這類設施包括:

    • 中央政府部會大樓(如:行政院、國防部、內政部)
    • 大型醫學中心附屬於政府者(如:三軍總醫院、榮民總醫院)
    • 國際機場與港務設施(如:桃園國際機場、松山機場)
    • 軌道交通樞紐控制中心(如:高鐵行控中心、捷運總站)
    • 軍事基地與國防關鍵設施

    這些設施的共同特徵是:它們是國家社會運作神經中樞,一旦斷電,社會損失遠超電力本身。當颱風、地震、或戰爭來襲時,「有電」與「沒電」之間,可能是數百條生命的差距。一座小型SMR,可以確保這些核心節點在極端條件下依然正常運作。

    更重要的是,SMR的建造週期比傳統核電廠短得多。模組化設計讓它可以「分期建造」——先安裝一部機組供電,再視需求擴充。對於財政壓力較大的政府單位,這種「先建後擴」的彈性,大幅降低了初期資本門檻。

    五、 綠色反核家園:矛盾還是出路?

    「綠色反核」是台灣環保運動的核心口號,但這個口號正在遭遇科學事實的挑戰。綠色能源(風力、太陽能)受限於間歇性與地理條件,無法完全覆蓋基載電力需求;儲能技術雖然快速發展,但目前成本仍然偏高,規模化部署仍需時間。在這個「缺口期」,核能——特別是下一代SMR技術——提供了一個值得嚴肅討論的低碳選項。

    真正的「綠色家園」願景,不應該意識形態先行,而應根據科學數據與安全標準選擇能源組合。SMR的安全特性大幅超越第一代核電廠,廢料問題也可透過新型燃料循環技術降低體積與放射性。這就是為何過去十年,包括德國綠黨在內的歐洲政治人物,已開始重新定義對核能的立場。

    台灣,或許也到了重新思考「非核家園」這個字眼的時刻。不是放棄反核,而是超越它——用更安全、更小型、更智慧的核能技術,打造一個真正永續的綠色家園。


    本文由 ITN 能源政策研究團隊撰寫,歡迎各界就SMR技術與台灣能源政策進行理性討論。如有政策建議,歡迎聯繫 ITN 研究部門。

  • 【商業策略】企業如何架設 Mastodon 應對 Z 世代員工的手機使用習慣

    在智慧型手機主宰日常的時代,Z 世代(1997–2012 年出生)與職場的互動方式,與上一代有著根本性的差異。他們習慣即時通知、滾動式資訊流、以及高度個人化的數位體驗。傳統的企業內部溝通工具——電子郵件、公告系統、甚至 Line——在吸引 Z 世代員工注意力這件事上,越來越力不從心。本文探討企業如何透過架設 Mastodon(一個開放原始碼的去中心化社群平台)來打造符合 Z 世代使用習慣的內部社群,同時掌控資料主權與品牌形象。

    一、Z 世代與手機的共生關係

    根據 2024 年多項調查報告,Z 世代平均每天花費超過四小時在手機上,其中社群媒體佔據最大宗。他們不是「懶得工作」,而是大腦已經被演算法訓練成「滾動等於休息」的模式。當企業試圖用一封長郵件或一份 PDF 公告來傳遞資訊時,Z 世代員工的大腦下意識會傾向滑過——不是不尊重,而是認知負載完全不匹配。

    這不是紀律問題,是工具與人之間的介面錯配

    二、Mastodon 為什麼適合企業內部使用?

    Mastodon 是基於 ActivityPub 協定的去中心化社群平台,類似於 Twitter 的形式,但有幾個關鍵差異讓它在企業場景中比 Twitter 或 Instagram 更具優勢:

    1. 演算法自主,資訊公平

    Mastodon 的時間軸是嚴格依時間排序,沒有演算法會「餵養」特定內容。這代表所有員工發布的訊息都有均等的曝光機會,不會有人因為互動率低就被消失。對於企業內部溝通而言,這是一個更公平、更透明的環境。

    2. 完全自架,資料主權在企業手中

    企業可以在自己的伺服器(VPS、實體主機、或 ITN 的專用伺服器)上架設 Mastodon。所有資料留存在公司內部,不會外流到第三方平台,也不需要擔心 Facebook 或 Twitter 的隱私爭議與資料商業化問題。

    3. 彈性命名空間,組織結構對應

    Mastodon 支援「多實例」(Multi-instance)架構,企業可以根據部門建立不同的「實例」。例如:sales.itn.tw、tech.itn.tw、hr.itn.tw,讓不同團隊擁有各自獨立的社群空間,同時仍可透過联邦(FediVerse)相互關注與轉發。

    4. 內容審核工具齊全

    Mastodon 內建相當完整的內容審核功能,包括:自訂詞彙過濾、舉報機制、角色權限管理、以及定時發布。這些功能對於需要嚴格遵守法規或內部規範的產業(金融、醫療、法律)特別有價值。

    三、如何為企業架設 Mastodon(一步步指南)

    Step 1:選擇伺服器規格

    Mastodon 的系統需求不高,但建議以下最低配置:

    • CPU:4 核心以上
    • 記憶體:8 GB RAM(建議 16 GB)
    • 儲存空間:50 GB 起(取決於媒體存儲需求)
    • 作業系統:Ubuntu 22.04 LTS

    若是中小型企業(50 人以內),ITN 提供的標準 VPS 方案即可勝任;若超過 200 人,則建議使用專用實體伺服器以確保效能。

    Step 2:註冊網域名稱並設定 DNS

    建議使用公司子網域,例如 social.itn.tw。在 DNS 設定中新增 A 記錄指向伺服器 IP,並預留好 SSL 憑證設定(Let’s Encrypt 免費憑證即可)。

    Step 3:使用 Docker 或直接部署

    Mastodon 官方提供 Docker Compose 配置文件,是大多數管理員最快的部署方式。主要步驟:

    git clone https://github.com/mastodon/mastodon.git
    cd mastodon
    cp .env.production.sample .env.production
    docker-compose build
    docker-compose run --rm web rails db:migrate
    docker-compose run --rm web rails assets:precompile
    docker-compose up -d

    Step 4:設定 SMTP 郵件服務

    Mastodon 需要郵件服務來發送驗證信、通知信等。企業可以使用 ITN 的代管郵件服務或任何第三方 SMTP(如 SendGrid、Mailgun)。

    Step 5:初始管理員帳號與站點設定

    啟動完成後,存取 https://social.itn.tw 即可看到站台畫面。透過 Rails 指令建立管理員:

    docker-compose run --rm web rails mastodon:setup

    四、商業情境應用:讓 Mastodon 成為 Biz Command Center

    將 Mastodon 打造成企業的「商業命令中心」,可以用以下方式運作:

    日常公務與公告

    HR 部門可以透過固定推文發布政策更新、福利公告、請假通知。相較於 Email,Z 世代員工更願意在滑手機的間隙「刷」過這些訊息。

    專案協作與跨部門溝通

    每個專案可以建立一個「hashtag」(標籤),成員只要追蹤該標籤就能掌握進度。例如:#itn2026product#客戶ITN-0420。這比 Line 的群組對話更結構化,也不會被表情符號洗版。

    即時回饋與匿名投票

    Mastodon 支援「不公開帳號」模式,企業可以用於匿名滿意度調查、意見收集、或突發事件的第一時間反應。

    知識沉澱與文件庫

    善用「書籤」功能,員工可以收藏重要的推文串,形成一個非正式的內部知識庫。新進員工加入時,可以快速瀏覽歷年來的組織文化與重要公告。

    五、Z 世代為什麼會接受這種工具?

    關鍵在於「不干擾」與「自主權」。Mastodon 沒有演算法焦慮、沒有按讚數的同儕壓力、訊息不會被演算法埋沒。對 Z 世代而言,這反而是一個「乾淨」的數位空間。

    加上它是免費開源的,企業無需支付任何授權費用,也不需要強迫員工註冊一個陌生平台的帳號(他們可能已經有自己的 Mastodon 帳號)。

    結論

    Mastodon 不只是一個「社群平台」,對於願意擁抱開放網路精神的企業而言,它是打造現代化內部溝通生態系的利器。特別是當你的團隊中有大量 Z 世代員工時,順應他們的使用習慣,比強制改變他們的行為更有機會成功。

    架設成本低、資料自己掌控、功能完整——現在正是企業評估 Mastodon 作為內部 Social Business Command Center 的最佳時機。


    本文由 ITN 商業策略團隊撰寫,適合資訊主管、人資管理者、與對開源企業方案有興趣的讀者。如有架設需求,歡迎聯繫 ITN 技術團隊。

  • 【重要公告】印度 .in 網域名稱最新合規要求——2026 年全面上路,註冊人必看!

    印度網際網路註冊局(IN Registry)近期宣布多項重大政策更新,針對 .in、.co.in、.net.in 以及 .bharat 等熱門國碼網域,祭出嚴格的註冊人資格限制與驗證機制。以下為您完整解析兩階段實施的新規範,協助您提前因應,避免域名遭到封鎖或設定為 serverHold。

    一、自 2026 年 1 月 27 日起實施

    1. 適用對象限制——並非人人可註冊

    新規上路後,並非所有人都能持有 .in 系網域名稱。根據 IN Registry 公告,以下后綴之網域,僅限以下對象持有:

    • 於印度合法註冊之法人或機構
    • 具印度國籍之自然人

    也就是說,如果您並非印度法人也非印度國民,原則上將無法繼續持有或新申請這類網域。建議已有相關網域的客戶,立即檢視自身帳號的註冊人資料是否符合新規範。

    2. 註冊人資料國別驗證——強制進行

    自生效日起,凡涉及上述後綴之網域名稱,在以下任何一種情境時,註冊商皆須強制執行驗證流程:

    • 新註冊
    • 續費
    • 轉移註冊商
    • 修改註冊人資料

    驗證的核心要求只有一項:「註冊人國家/地區」欄位有且僅能選擇為「印度」。若您在操作過程中被要求填寫其他國家,該筆申請將被視為無效並遭拒絕。

    3. 禁止使用臨時電子郵件信箱

    IN Registry 明確禁止使用任何臨時性或一次性電子郵件服務(如 10 minute mail、Temp Mail 等)作為網域聯絡人電子郵件地址。請確保您提供真實且長期有效的電子郵件信箱,否則驗證將無法通過。

    4. IP 位址來源驗證——VPN、Proxy 全面封殺

    註冊商須對每一筆網域請求進行IP 位址來源檢查,以下類型的 IP 位址將被直接阻擋:

    • VPN 連線 IP
    • 代理伺服器(Proxy)IP
    • 資料中心(Data Center)IP

    這意味著,無論您身處何地,只要使用上述類型 IP 提交網域請求,系統將自動攔截。建議有跨境操作需求的用戶,提前確認自身網路來源是否屬於住宅電信或一般商業網路。

    二、自 2026 年 3 月 1 日起實施

    1. eKYC 與電子郵件驗證機制——15 天補驗期限

    自 3 月 1 日起,所有新註冊或異動後的網域,將由註冊商系統自動將註冊人資料送交印度政府提供之 eKYC 介面,進行以下兩項驗證:

    • 實名認證(eKYC):比對政府資料庫驗證身份真實性
    • 電子郵件地址驗證:確認聯絡信箱真實可達

    完成驗證前,網域名稱將預設設定為 serverHold 狀態,亦即網站將無法正常解析運作。

    註冊人須於以下行為發生後 15 個自然日內 完成 eKYC 與電子郵件驗證,逾期未完成者,網域將持續被鎖定,直至補驗完成:

    • 新註冊
    • 續費
    • 轉移
    • 修改註冊人資料

    2. 年度定期驗證要求

    除了上述一次性驗證外,IN Registry 更要求所有既有註冊人每年重新完成一次 eKYC 系統實名認證及電子郵件地址驗證。這是一項持續性的合規義務,而非一次性手續。

    未能按時完成年度驗證者,網域同樣可能被設為 serverHold,影響正常服務。

    三、風險提醒與建議

    玩 ccTLD(國家代碼網域名稱)確實存在一定的政策風險,尤其是像印度這種對國籍與法人資格有嚴格規範的市場。以下是我們的建議:

    • 立即盤點手中 .in 系網域:確認註冊人資料是否符合「印度」資格要求
    • 備妥長期有效電子郵件:放棄臨時郵箱,改用真實、穩定的個人或公司信箱
    • 檢查 IP 來源:確保提交網域操作時使用的是真實住宅或商業 IP,而非 VPN 或資料中心 IP
    • 設定驗證提醒:15 天補驗期限相當短暫強烈,建議建立內部管理日曆,避免逾期
    • 提前規劃年度驗證:將 eKYC 驗證納入年度合規工作流程,別等到期才驚覺

    總結

    印度 IN Registry 的新規範,核心精神在於遏止網域名稱的濫用與空殼化,並確保持有者身份真實可追溯。對於正當使用的客戶而言,只要提前準備、合規填寫資料,並不算太過嚴苛的障礙。但若您不符合「印度法人或國民」的資格要件,持有這類網域的風險將大幅提升,建議謹慎評估,必要時及早辦理轉移或註銷。

    如有任何關於 .in 系網域的註冊、移轉或合規問題,歡迎與 ITN.tw 聯繫,我們將協助您確保網域投資安全合規。

  • Hermes Agent 深度評測:自帶 MCP 的下一代 AI 代理人,與 OpenClaw 龍蝦的實戰比較

    最近研究了一個新的 AI Agent 框架——Hermes Agent,它最大的特點是自帶 MCP(Model Context Protocol)支援,不需要像有些方案一樣另外折騰設定,用起來比所謂「龍蝦」(OpenClaw)更完整。以下是我的實測心得與兩者比較。

    什麼是 MCP?為什麼重要?

    MCP(Model Context Protocol)是一個讓 AI 代理人能夠標準化地與外部工具、資料庫、API 對接的協議。你可以把它想像成 AI 世界的 「 翻譯機 」——統一的介面,讓不同模型、不同工具可以無縫連接。

    Hermes Agent 把 MCP 內建進去了,意思是你不需要自己安裝一堆外掛或寫轉接程式,開箱即用。這點對於想要快速落地的人來說,吸引力很大。

    Hermes Agent 的核心優點

    • MCP 原生支援:從一開始就把 MCP 設計進架構裡,而不是事後補丁。這讓工具串接更穩定、擴充性更強。
    • 部署簡單:相較於其他需要手動設定環境的方案,Hermes 的初始化體驗相對順暢。
    • 記憶與上下文管理:在單一 session 內的對話歷史管理做得不錯,能快速回溯與延伸上下文。

    實測:Hermes Agent vs 龍蝦(OpenClaw)

    以下是我這週實際使用後的觀察,純屬個人主觀經驗,供大家參考:

    功能 Hermes Agent 龍蝦(OpenClaw)
    MCP 支援 ✅ 原生內建 ⚠️ 需額外設定
    多人同時使用 ❌ 目前不支援 ✅ 支援多人、獨立工作區
    對話歷史管理 ✅ 單session內優秀 ✅ 跨session一致性佳
    部署難易度 ⭐⭐⭐⭐ ⭐⭐⭐
    適合情境 單人快速作戰、工具串接 團隊協作、多人分工

    最大的痛點:多人協作

    目前 Hermes Agent 最大的缺點,就是沒有辦法多人同時使用同一隻 Agent。這點在小型團隊場景下是致命傷。龍蝦在這方面領先——你可以讓多個用戶同時連接同一個实例,工作區完全分開,互不干擾。

    如果你是一個人作戰、追求速度和簡化設定,Hermes 很香。但如果你需要讓團隊成員共享同一套工具與流程,龍蝦仍然是更穩的選擇。

    記憶歷史管理:各有所長

    說到對話歷史的管理,兩者走了不同的路線:

    • Hermes:在單一對話 thread 內的上下文保持做得很好,適合需要深度探索的任務。但跨 thread 的歷史整合目前還有進步空間。
    • 龍蝦:更強調工作區隔離與歷史持久性,適合需要來回切換任務的時候馬上回到之前的狀態。

    我的建議是:根據你的使用情境決定。如果你是那種「打開一個 thread 就埋頭做到底」的風格,Hermes 體驗很順。如果你是那種「同時追好幾個專案、不斷切換」的類型,龍蝦的歷史管理更適合你。

    結論:該選誰?

    總結來說,Hermes Agent 和 OpenClaw 龍蝦各有定位,不是非黑即白的替補關係:

    • 單兵作戰、重視 MCP 原生支援 → 選 Hermes
    • 團隊協作、需要多人獨立工作區 → 選龍蝦
    • 還不確定?建議兩個都實際跑過再說,紙上談兵不如動手測試。

    AI Agent 的生態系正在快速演化,這兩個框架都還在積極更新中。誰知道三個月後又是什麼局面呢?保持開放,持續嘗試。

    如果你也在用這兩個工具,歡迎留言分享你的比較心得!