以前考大學聯考（對，就是二十多年前那個年代 😅），為了讓作文拿高分，我做過一件現在想起來還滿中二、但當年自以為很聰明的事： 硬背名言。 而且不是隨便背，是直接上強度——

北宋思想家、教育家、理學創辦人 張載（1020–1077） 的經典名句——「橫渠四句」。

當時的心態很單純：

這四句好帥啊！ 有天地、有人民、有往聖、有後世，格局直接拉滿 🚀 改作文的老師看到，應該會默默點頭：「嗯，這考生不簡單。」

至於內容在講什麼？

老實說，那時候完全沒多想，只覺得——

背起來就對了。

結果人生很妙。

昨天在聽一場 AI 主題的分享，講者突然提到「生民」這兩個字，

我腦袋像被某個古老的快取命中一樣，

完全沒經過大腦審核，橫渠四句直接脫口而出（人體自然吐 Token 🤖）。

更神奇的是，

在後續跟 AI 來回互動、拆解、對話的過程中，我才突然發現——

這四句話，竟然跟我們現在天天在講的東西高度重疊：

• 使命（Mission）
• 賦能（Empowerment）
• 知識管理（KM）
• 創新
• 永續

你以為這是什麼新世代管理學、科技公司願景牆上的口號，

結果一回頭才發現——

一千年前的人早就寫完了。

突然覺得很好笑，也很敬畏。

當年只是為了作文加分背的名言，

現在卻在 AI、組織、未來議題裡重新發光。

原來有些思想，

不是老了，

只是提早出生了。

為天地立心

為生民立命

為往聖繼絕學

為萬世開太平

這四句便是北宋張載（橫渠先生）震古鑠今的「橫渠四句」。 如果說上一句「為天地立心」是在談人類存在的「價值」，那麼這完整的四句，其實勾勒出了一位領導者（無論是古代的士大夫，還是現代的管理者）從內在修為到外在功業的完整路徑。

在現代管理與組織領導的情境下，這四句可以轉化為極具實踐意義的領導哲學：

1. 為天地立心（Define the Vision）→ 談到使命
   • 原意：為客觀的天地確立精神價值。
   • 領導解讀：「建立願景與文化」 團隊和組織如果只有KPI（數據），那就是冰冷的機器。領導者的首要職責，是為團隊注入靈魂——定義我們「為什麼而戰」（Why），在 AI 衝擊與環境變動中，確立組織不可動搖的核心價值觀。
2. 為生民立命（Empower the People） → 談到賦能
   • 原意：為百姓尋求安身立命之處。
   • 領導解讀：「照顧團隊與人才發展」 這不僅是給予薪酬（生存），更是讓同仁在工作中找到成就感與職涯方向（立命）。 特別是在考核或組織變革期間，如何讓優秀的人才看到未來，讓迷惘的同仁找到位置，是管理者最「慈悲」也最「務實」的責任，如利用四象界 (擅長的事 vs 喜歡的事)、C.O.A.C.H教練式領導。
3. 為往聖繼絕學（Manage Knowledge & Innovation） → 談到KM與創新
   • 原意：傳承並發揚聖賢斷絕的學問。
   • 領導解讀：「傳承經驗與迭代創新」 在技術快速更迭（如 AI、新系統導入）的時代，我們很容易喜新厭舊。但真正的管理者懂得「承先啟後」——將資深同仁的隱性經驗（Old Wisdom）與新技術（New Tech）結合。不讓核心的專業斷層，就是「繼絕學」，AI時代最不缺產出，AI承包答案下最缺乏對產出負責的把關者、負責者。
4. 為萬世開太平（Build for Sustainability） → 談到永續
   • 原意：為後世開創長久的太平基業。
   • 領導解讀：「建立可持續的制度」 不追求短期的亮眼數字，而是致力於建立一套長久運作的機制、穩健的系統架構，或是培養出能接班的梯隊。做那些「即使我不在這個位子上了，組織依然能健康運轉」的事。

這四句其實對應了領導者的四個維度：

• 高度（立心）：格局與方向。
• 溫度（立命）：對人的關懷。
• 深度（繼絕學）：專業的傳承。
• 廣度（開太平）：長遠的影響。 在 AI 逐漸「承包答案」的當下，這四件事恰恰是 AI 最難取代，而人類領導者最無可推卸的責任。

這場演講分享集團七年雲端轉型三部曲：從建立合規地基的 Cloud Ready，到實現百套系統上雲的 Cloud Adoption，邁向 2025 年結合 AI 的 Cloud First 策略。國泰採多雲混合架構以獲取敏捷與高可用性，並展示自研 AI 工具 Smart Archie，利用 Multi-Agent 自動生成合規架構與程式碼。轉型核心在於文化建立與標準化治理，藉由雲端算力與 GenAI 加速金融創新。

1. 核心動機：Why Cloud？

雖然對新創而言上雲是常態，但對受高度監管的金融業而言，這是一個漫長的決策過程。

• 上雲的驅動力：並非單純為了省錢，而是為了換取「速度」與「可靠性」。
• 關鍵優勢：
  1. 擴充性：應對如演唱會搶票般的瞬間高流量。
  2. 高可用性：雲端天然高可用架構能滿足金融業對穩定的要求。

2. 國泰雲端轉型三部曲 (2020-2027)

國泰的轉型分為三個戰略階段：

第一階段：Cloud Ready (2020-2021) — 打地基

此階段始於 2019 年金管會發佈上雲規範，重點在於建立合規性、組織運作與方法論。

• 挑戰：金融業面臨資安合規、組織文化斷層、以及如何決定系統上雲順序的挑戰。
• 合規與資安：面對「資料放在別人雲端是否安全」的質疑，以「責任共用模型」說明。
• 方法論 (Cathay 6R)：國泰根據 AWS 的 7R 與Gartner 5R，改良出適合自身的「Cathay 6R」系統遷移策略，評估上雲價值、技術成本與風險程度。

第二階段：Cloud Adoption (2021-2025) — 大規模上雲

目標是從單一系統擴展至百套系統上雲（目前已達約 120-130 套）。

• 混合雲與多公有雲策略：
  • Google Cloud：用於應用程式開發（因早期在台灣有資料中心）。
  • AWS：用於數據與 AI 平台。
  • Azure：用於辦公室自動化（OA）與 M365。
• CCoE 與 FinOps：成立雲端卓越中心 (CCoE) 統籌治理。講者強調雲端資源像水電，必須建立 FinOps 機制「關緊水龍頭」，避免閒置資源浪費，否則成本會非常高昂。
• 自研平台：開發了獲得 Stevie Awards 的 Cloud Ready Platform 與資訊資產平台，協助子公司加速轉型。

第三階段：Cloud First & AI (2025+) — 擁抱雲與 AI

進入此階段，雲端成為新專案的首選方案 (Cloud by Default)。

• AI 與雲端的結合：AI 的燃料是大數據，目前好用的 AI 服務都在雲端上 (AI的基礎設施)。
• GPU 算力決策：講者舉例，數據團隊原本想自建 GPU 機房，但 H100 等顯卡成本極高（單張百萬台幣）且散熱建置維護昂貴。相比之下，雲端租用 GPU（如每小時 1 美金）更具成本效益且彈性，最終說服團隊採用雲端算力。
• 企業級 AI 安全：不使用一般AI SaaS，而是採用三大公有雲提供的企業級 GenAI SaaS 服務（如 Azure OpenAI, AWS Bedrock 等），確保資料在 VPC 內受控，解決資安疑慮。

3. 創新工具：Smart Archie (Multi-Agent 架構師團隊)

為了解決多雲環境下架構設計複雜、合規審查繁瑣的問題，國泰開發了基於 Multi-Agent（多智慧體）的 AI 工具「Smart Archie」。

• 運作原理：利用 LLM 與 RAG 技術，透過多個專職 Agent 協作：
  • Architect Agent：負責溝通協調與分派任務。
  • DaC Agent：繪製雲端架構圖 (Diagram as Code)。
  • Solution Agent：進行技術分析與方案建議。
  • TCO Agent：即時估算成本。
  • IaC Agent：生成基礎設施程式碼 (Terraform)。
• 實際效益：能透過自然語言對話自動生成符合國泰標準與資安規範的雲端架構圖，並直接產出部署程式碼與成本估算，大幅降低溝通與設計成本。

4. 洞察與啟示 (Insights)

轉型過程中的 PPT (People, Process, Tech) 挑戰：

• 文化是最大挑戰：技術升級容易，但「人」的觀念與信心建立最難 (People)。
• 標準化是規模化前提：必須建立標準流程與治理機制才能支撐大規模運作 (Process)。
• AI 時代的能力需求：雖然 AI 可取代技術操作（Hard Skills），但個人的洞察力、批判性思考與溝通協作能力（Soft Skills）將是放大個人價值的關鍵。

總結

國泰金控如何從法規開放初期的探索，發展至多雲混合架構的成熟治理，再到利用 AI Agent 優化架構設計的完整路徑。其核心邏輯在於：上雲不只是技術更換，而是為了獲取業務發展的速度與彈性，並透過標準化與自動化工具解決規模化後的管理難題。

重點聚焦於國泰金控的雲端轉型策略以及如何利用多智能體（Multi-Agent）技術解決雲端架構設計的挑戰，實現自動化交付。

一、 雲端優先思維 (Cloud First)

演講首先介紹國泰金控的雲端化升級目標，旨在讓各子公司能以更高速度和彈性探索 AI 應用的可能性，將 「Cloud First」 提升為推動持續創新的企業文化。 國泰集團的七年雲端轉型計畫始於 2020 年，分為三個階段：

1. Cloud Ready (2020)： 啟動集團上雲計畫，確定上雲方向和遷移計畫。
2. Cloud Adoption (2021-2025)： 目標是五年內讓 100 套系統上雲，預計在今年 (2025) 達成此目標。
3. Cloud First (目前階段)： 透過雲端優先加速 IT 現代化。雲端優先的思維是 “Cloud by default”，即未來在規劃新系統或新業務時，預設優先考量雲端解決方案。目標包括解決技術債、實現永續發展、加速業務創新，以及導入零信任（zero trust）等現代化資安治理。

二、 雲端架構設計的真實挑戰

在推動大規模上雲的過程中，國泰金控面臨雲端架構師資源稀缺的挑戰。主要有三大痛點：

1. 敏捷開發 (Agile)： 產品迭代速度快，雲端服務更新頻繁，導致架構設計需要不斷溝通、討論與重新設計。
2. 合規審查 (Compliance)： 作為金融業，架構設計必須符合資安、法規要求，審查流程繁瑣且需耗費人工時間來確保合規性。
3. 跨雲治理 (Governance)： 國泰金控使用多雲環境（如 AWS、GCP、Azure），不同雲服務特性差異大，導致雲端架構標準化和治理難度增加。

三、 Multi-Agent 解決方案：Smart Archie

為了解決上述挑戰，國泰金控利用生成式 AI (GenAI) 發展了 Smart Archie 產品，希望能透過 AI 協助實現雲端架構的標準化與自動化。 團隊從單純使用提示工程（Prompt Engineering）、導入 RAG（檢索增強生成），最終選擇了 Multi-Agent 架構，因為單一 Agent 存在提示詞失控、知識庫結構混亂以及 Context Window 限制等問題。Multi-Agent 策略的優勢在於能實現任務拆解、專業分工，並提高系統的穩定性。

Smart Archie 採用 4+1 的 Multi-Agent 架構：

• Architect Agent (核心指揮官)： 負責分析需求、決策、任務分配與調度。
• DaC Agent (Diagram as Code)： 負責自動生成雲端架構圖。
• Solution Agent： 依據需求場景，輸出完整的雲端服務組合、技術介紹與替代方案，並確保架構合規性。
• TCO Agent (Total Cost of Ownership)： 進行粗略的成本預估，提供資源優化建議並輸出成本預估報告。
• IaC Agent (Infrastructure as Code)： 將最終架構轉換為 Terraform 程式碼，方便部署到雲端環境並無縫整合至 CI/CD 流程。 該平台的基礎架構是依循 Cloud First 策略，建構在 AWS 環境上，並使用 AWS Bedrock 原生 AI 服務。

四、 實作與未來藍圖

Smart Archie 的 Demo 展示了從輸入需求到自動生成可部署的多雲架構圖、服務方案、成本估算，到最終輸出 IaC 程式碼的一鍵式流程，將過去需數小時甚至數天的設計流程縮短至數分鐘，大幅提高了工作效率。

在 AI 協作開發方面，團隊鼓勵使用 Vibe Coding 的雙核心策略：

1. 情境工程 (Context Engineering)： 透過提供完整的上下文、使用行業術語和提示重構，確保 AI 精準理解需求。
2. PDCA 開發流程 (Plan, Do, Check, Act)： 運用這個管理理論來處理 AI 程式碼的不確定性和品質問題，讓 AI 先進行規劃，再執行實作。

未來，Smart Archie 將整合進國泰的 Cloud Ready Platform 中，發展為 AI 驅動的智能雲端治理閉環，涵蓋四個階段：需求規劃與架構評估、成本規劃與治理審核、實作部署與自動化、持續運營與優化。最終目標是讓 Smart Archie 作為 AI 雲端架構師，與 Smart IaC（AI 平台工程師）、Smart Advisor 等組成 AI 輔助基礎平台，提供一站式雲端轉型服務。

整體而言，這場演講展示了國泰金控如何應對金融業在雲端轉型中遇到的專業人才與效率挑戰，並以 Multi-Agent 技術作為核心，打造出高度自動化、合規且敏捷的雲端架構設計平台。

Vibe Coding於2025爆紅，推崇動口寫程式；極端做法缺測試與需求管理，難符金融業法遵與資安。建議循四階段導入：0安全沙盒原型、1IDE輔助、2低風險工具、3受管主幹量產，並以Model Gateway、Prompt標籤、CI/CD Gate等Paved Road治理確保產碼可追溯稽核。效益評估宜聚焦DORA交付指標與技術債，勿僅看程式碼行數。此路徑兼顧速度、合規與品質的全面落地。

1. Vibe Coding 是什麼？為何在 2025 年成為話題？

「Vibe Coding」在今年（尤其 3、4 月）迅速竄紅，成為開發圈的流行語，但討論已帶動大家重新思考 AI 與軟體工程的關係。

其原始、極端版本（最常被引用的是 Andrej Karpathy 的描述）主張：不寫文件、不寫測試、不嚴格定義需求；開發者與 AI 工具互動，持續「催」到程式碼能跑為止——重點是速度與互動感，不是傳統工程嚴謹度。

「像微服務一樣，是一組原則；有些很好，有些不一定要跟」。企業要取其精華，而非教條式照單全收。

2. 為何原汁原味的 Vibe Coding 不適合金融業？

金融機構面對高度監管、資安與營運韌性要求，「能跑就好」的極端 Vibe Coding 版本根本無法過關：它缺乏測試、註釋與正式需求管理，與企業級軟體開發要求背道而馳。

在金融與法遵環境下，我們必須能對程式碼負法律責任；若交付源於未經審查的 Vibe Code，一旦出包，很難在稽核或法院上解釋其行為，帶來巨大成本與風險。

以 公文系統 為例：成熟套裝不只是資料表與 UI，而是內建合規流程；若自己「Vibe」一套 公文系統，稽核成本往往遠高於直接採購。

此外，金融核心系統高度互連，任何需串多方系統的既有應用都不是 Vibe Coding 的理想目標。

3. 轉念：把 Vibe Coding 當成「AI 原生軟體工程」的工具箱

我們逐漸把焦點從「要不要 Vibe Coding」移到「哪些 Vibe 原則可支援 AI 原生軟體工程（AI Native Software Engineering）」；也就是：把 AI 當成協作夥伴，提升速度、互動品質與開發者體驗，但讓產品最終仍走進企業治理的正軌。

3.1 適用場景一覽

4. 從「玩玩看」到「可上線」：企業級落地管線設計（先 Vibe，再上軌道）

我們若要把 Vibe 產出的原始碼帶入企業主幹，必須設計一道多關卡、可稽核的軟體供應鏈。

4.1 基本守門：程式碼審查是底線

在企業環境、尤其需承擔法律責任時，所有程式碼都必須經審查。

4.2 AI 協助審查規則

AI 現已可產生審查規則，再交由規則引擎逐行檢查；相較一年前準確度已有改善。

4.3 與 CI/CD 管線整合

讓 Vibe 工具輸出的程式碼先進原始碼庫，再跑自動安全掃描、文件生成、測試與合規檢查，是由「概念車」進化為「量產車」的必要步驟。

4.4 適用範圍：新且獨立、風險低的應用程式優先

完整採用 Vibe 流程最適合安全性不那麼關鍵、且未大量耦合既有系統的新獨立應用。

4.5 用平台工程「鋪好的道路」（Paved Road）讓大家 Vibe 得安心

所謂「鋪好的道路」就是：開發者不用每次都重頭處理資安、密鑰、審查、環境佈署這些雜事；平台團隊先把安全預設、最佳實務、管線、範本都準備好。開發者只要選模板、貼需求、讓 AI 幫忙產碼，再把程式碼推進已治理的 CI/CD 流程，就能安心迭代。這是把 Vibe Coding 變成可治理工程的關鍵 Glue。

Paved Road 九大模組

三層開發體驗

1. Vibe 層（自由揮灑）：IDE、對話式產碼、快速原型；輸出都打上「未審」旗標。對應前文 Prototype/Throwaway。
2. 治理管線層（自動清洗）：程式碼進 Repo 後自跑安全、規則、測試、文件化。
3. 企業主幹層（受控交付）：只有通過 Gate、且屬新且獨立 / 低風險應用才可進主幹與部署。

開發者旅程（Dev Journey）示意

1. 選擇「金融 Vibe App」模板 → 自帶假資料與 SDK。
2. 在 Cursor / Windsurf 類 IDE 跟模型互動，快速生出 MVP。
3. Push 到 Git；Hook 自動打 AI 產碼標籤。
4. Pipeline 跑規則檢查 + 測試 + Doc。
5. 風險分級判定：若屬低風險獨立 App，可自動佈署測試環境；高風險需人工核准。

小心得：平台工程不是要限制大家，而是減少「每個團隊自己煩惱同一堆合規細節」的時間。讓工程師把腦力放在業務創新，這才是 Vibe 的真正價值。

5. 舊系統現代化：何時用 AI、何時別叫它 Vibe？

程式碼現代化與語言平移（例如 Cobol→Java）是 AI 的好場景，但這不是 Vibe Coding；這類專案對品質要求極高。

在語言 / 框架轉換上，規則引擎通常比純 AI 生成更一致可靠；AI 可輔助生成規則。

市面已有針對主流語言轉換的工具（如 IBM Cobol→Java、GitHub Java↔Java、.NET↔.NET、AWS Java refactor），可列為轉型工具箱的一環。

若缺少對應工具，利用通用型 AI 做初版轉換仍可能達約七成正確度，雖不完美，但在評估或啟動階段仍有價值。

5.1 上下文工程（Context Engineering）挑戰

LLM 難以一次吃下整個大型應用；需挑重點提供最小充分上下文，避免雜訊反而降低品質。

提供格式樣板、測試案例、良好範例，可顯著提升 AI 轉換成果。

6. 衡量 ROI：不要只算「產出幾行程式碼」

大多數組織缺乏現行生產力基線，因此要證明 AI / Vibe 帶來提升並不容易。

尤其不要用「產生程式碼總量」這種活動指標；自動生成本來就快，沒意義。

真正該追的是業務價值：應用是否讓客戶更滿意。

6.1 建議採用 DORA 指標族群

DevOps Research & Assessment (DORA) 指標能客觀觀察交付績效：變更交付時間、部署頻率、變更失敗率、平均恢復時間、可靠度/可用性目標。

6.2 長期價值與技術債

每天省下的小時間不一定立刻換成更多功能；開發者可能把時間投資在測試、文件、學習，這些好處常在隔年才反映到較少錯誤與較低技術債。

7. 工具觀察：選擇與風險

我們討論了幾個市場上常被提起的工具，我補上金融業評估重點：

8. 金融業導入成熟度路線圖

以下為我依風險分級設計的四階段導入藍圖，協助從「概念試玩」漸進到「受治理的 AI 原生工程」：

階段 0：安全沙盒試驗

• 目標：熟悉 Vibe 互動體驗、模型能力上限。
• 範圍：假資料、無客資、無連線的本地環境；允許產生一次性程式碼與原型。對應上表的 Prototype / Disposable / Debug 場景。
• 治理：僅限測試網段；產出自動打上「非生產」標籤；禁止密鑰。參考原型、拋棄式、內部小工具適用情境。

階段 1：IDE 輔助與認知卸載

• 目標：改善開發者流暢度、縮短排錯時間。
• 範圍：IDE 內嵌 AI 助手、自動 build fail 分析、錯誤建議。
• 治理：記錄提示與回覆供稽核；敏感輸入遮罩。

階段 2：意圖導向小型內部應用

• 目標：用 AI 拆需求、產生骨架程式碼，快速交付低風險、單系統的內部 CRUD 類工具。
• 治理：程式碼審查必須、基本自動測試；使用 CI/CD Gate。

階段 3：受控進主幹 / 新獨立應用量產

• 目標：讓部分 Vibe 產碼經自動化審查管線後併入企業主幹；鎖定風險低、耦合少的新系統。
• 治理：AI 規則審查 + 安全掃描 + 文件生成整合於 CI/CD。

9. 治理清單（Checklist）

以下列出金融業在規畫 Vibe / AI 原生工程時應納入的治理控制點，對照上方階段性導入：

程式碼來源標籤與可追溯性

• 標註 AI 生成片段；必要時保留 Prompt 與 Model 版本，供稽核查詢。理由：未審查 Vibe Code 無法在法庭與稽核前説明。

功能風險分級

• 高法遵負載（如總帳、交易、AML）不得直接採 Vibe 建置；公文系統 自建稽核成本高。

系統耦合度評估

• 多系統串接者暫不採；先鎖定獨立應用。

強制程式碼審查 Gate

• 所有進主幹的 AI 產碼須人工審查。

自動化審查與管線化

• 使用 AI 產生規則 + 規則引擎逐行檢查；納入 CI/CD Pipeline。

10. 成效衡量儀表板（Metrics Dashboard）

若要在內部推廣，可建立「Vibe / AI 原生工程」專屬儀表板，至少追蹤下列指標：

交付績效 – DORA 指標族群（Lead Time、Deployment Frequency、Change Failure Rate、MTTR、Reliability/Availability）。

活動 vs 成果 – 不採計「生成程式碼行數」；改看實際業務價值。

長期品質 – 技術債、缺陷率變化；對應「省下時間→投資品質」的延遲效益。

11. 與金融監理、資安、合規單位對話建議

當我們要跟風險/稽核/法遵同仁推動這件事，溝通語言很重要：

1. 不是要把核心銀行系統交給 AI 寫——相反，我們用 AI 來快速驗證需求、產生工具、增強測試。這點可引用「原型」「自包含低風險應用」等建議。
2. 所有進主幹程式碼仍需審查與管線化，並可引入 AI 規則檢查。
3. 風險分級導入：新且獨立、低安全性應用先行，避免牽動大量耦合。

12. 結語：讓「Vibe」成為受治理的創新加速器

綜合來看，目前的Vibe Coding 或許不是百分之百適合金融等高度監管產業；但它所帶動的 AI 原生工程思維——快速建立互動原型、以 AI 助攻排錯與開發流程、把自包含低風險應用先自動化交付——若再疊上嚴格的程式碼審查、測試、文件與 CI/CD 管控，就能在不違背法遵的前提下釋放開發效率與創新速度。

我相信，真正成熟的做法不是問「要不要 Vibe Coding」，而是問：「我們要如何把 AI 導入工程流程，讓團隊在風險可控下更快迭代？」目前這個答案正在形成，也需要大家一起實驗、交流，讓這股『Vibe』變成可量產、可稽核的工程能力。

Vibe Coding快但常陷「能跑不能用」。解法：雙軌開發，Demo留Sandbox，正式版走平台化流程；用成熟度門檻，測試、IaC、SLO、DR逐級到位。引入Policy as Code與FinOps Guardrails提前檢核，Service Catalog與Golden Path優化DevEx。搭配成熟度評分、事故分享與成本透明，實現又快又穩，為企業帶來持續價值與競爭優勢。

解法總覽：從「秀技術」到「交付價值」

• 雙軌開發模型（Dual-Track）

• Exploration 軌：保留 Vibe Coding 的高速實驗優勢，限定在 Sandbox or Feature Branch，不連接正式環境。

• Delivery 軌：以 Platform Engineering 提供「鋪好路 (Paved Road)」——標準化模板、CI/CD、測試框架、觀測性與安全閘門。

兩條軌道以 pull request 或 feature toggle 交會，讓 demo 可逐步升級為 Production-Ready。

• 里程碑化成熟度模型（M0-M3）

• 雲端治理與法遵 Shift-Left

  • Policy as Code（如 OPA/Gatekeeper）在 Merge 時即檢查稽核條件。

  • 自動化 Threat Modeling & SBOM，確保開源依賴可追溯。

  • FinOps Guardrails：開發階段預設低規格 + 自動停機，避免「Demo 用完忘了關」。

• 平台化 DevEx（Developer Experience）

  • Service Catalog：一鍵產生符合企業標準的微服務骨架。

  • Golden Paths：文件＋範例程式＋範本 GitHub Actions，降低學習曲線。

  • 內部社群 & Gemba Walk(現場走訪)：持續收集痛點，迭代平台功能與 CLI 工具。

從 Demo 到上線：實務時間表範例

要訣：讓「快」只在 學習回饋循環，而不是在 跳過必要軟體工程。

行動清單（Checklist）

1. 建立 Vibe Sandbox 專案範本，預設不可連接正式環境 VPC。
2. 將 CI/CD Gate 與 Policy as Code 整合；Fail Fast。
3. 推行 Maturity Scorecard，每週評估專案位階與缺口。
4. 成立 Platform Guild (平台工程社群)，定期分享真實 incident case，提升工程自覺。
5. 對管理層透明化 Cycle Time、MTTR、單位功能成本，證明「鋪路」投資回報。

結語

Vibe Coding 最大的價值在於 速度 與 創意激盪；而企業最重視的卻是 可靠交付。透過雙軌模型、成熟度門檻、Platform Engineering 與 Shift-Left 治理，我們可以把看似相衝的兩個世界—「一周出Demo」與「穩定維運五年」—縫合在一起，真正做到 又快又穩、既能跑又能用。

我們將探討生成式AI與雲原生技術的融合，如何推動IT現代化。介紹生成式AI在雲端架構設計中的應用，特別是利用AI自動生成架構圖，提升設計效率與一致性。接著，透過以程式碼生成雲端架構圖，實現自動化設計與版本控制，透過AI自動生成符合政策規範的雲端架構圖，並實際展示上述技術的應用。最後，展望未來生成式AI與雲端服務的發展方向，包括環境實作測試、自動生成IaC程式碼等進階功能。聽眾將收穫對生成式AI架構設計中的前沿技術應用的理解，探索如何通過自動化工具提升架構設計效率，並洞察生成式AI與雲端平台結合的未來發展方向。

• 核心理念

  • IT 現代化是一段不斷演進的旅程：從早期的單機系統與單體架構，走過網際網路、行動通訊的隨時連線，一路發展到今日以雲端運算與人工智慧為核心的數位生態。每一階段都推動組織在效率、敏捷與創新上的持續躍升，體現「科技驅動業務」的深層價值。

  • 系統上雲的核心效益並非「省錢」，而是IT 現代化與Time to market。

    • 敏捷與創新
      • 雲端提供 自助式資源與快速實驗環境：如人壽官網Search Engine服務僅花 2 天就能 PoC，遠快於地端要花半年的流程。
      • 這種速度優勢直接帶動新產品迭代與上市時程。
    • 可觀測性與自動化資安
      • 雲原生監控、集中式日誌與政策即程式（Policy-as-Code）提升合規效率，降低營運風險。
    • 機房資源活化
      • 部分 UAT 環境遷至雲端後，釋放出昂貴的本地機房空間，可轉作 GPU 叢集或高敏感核心系統，提高資產利用率。

    • 長期競爭力

      • IT 現代化帶來人才吸引、跨雲備援、全球佈點等無形價值；即使帳面成本與地端持平或略高，仍能提供業務基礎設施的未來彈性。

• 國泰金控的雲端轉型旅程

  • 國泰金控於2020年啟動了為期七年的集團雲端轉型計畫。

  • 階段目標

    • 2020年（Cloud Ready）：著重於基礎設施、管理治理、人才與應用系統的雲端準備。
    • 2021-2025年（Cloud Adoption）：目標是讓集團內100套系統上雲，預計今年可達成。
    • 2025年後（Cloud Modernization）：未來新的系統和商業模式將優先考量雲端部署，直接採用SaaS服務或雲原生架構，雲端加速IT現代化。

  • 雲端策略：採用混合雲且多雲架構，同時佈署於AWS、GCP與Azure。

  • 技術選擇：鼓勵採用容器化（Containerization）和無伺服器（Serverless）等雲原生技術。這種架構能帶來：

    • 比市場快半步，更快的市場響應和發布速度。
    • 更好的資源彈性。
    • 潛在的成本節省（成本取決於雲端架構設計，直接將虛擬機搬上雲可能反而更貴）。
    • 天然高可用

  • 遷移方法：國泰金控採用目標架構遷移法，即先行設計目標雲端架構（微服務化、無伺服器），而非單純地將現有系統直接搬遷上雲（”lift-and-shift”）。國泰金控也定義了自身的Cathay 6R遷移概念。

• 生成式AI在IT現代化中的應用

  • 雲端GPU算力應用：為因應AI發展對H100/H200等GPU資源的需求，國泰金控利用雲端提供按用量付費（PPU）或無伺服器模式（SaaS-like API）的GPU算力，成本效益高且具備彈性。例如，在雲端運行Gemma 3 27B模型可達到每秒26個字元的生成速度。

  • AI輔助雲端架構圖生成：為解決架構師稀缺問題，利用AI工具根據問卷或自然語言描述自動生成標準化的雲端架構圖，並可透過對話方式解釋設計理念和元件功能。

  • AI驅動的系統現代化與重構（AI Coding）

    • 背景：面對舊有單體架構（如JSP）重構為雲原生微服務的挑戰。

    • AI實踐

      • AI能分析現有系統，識別其單體架構、傳統技術棧、有狀態特性、資料庫（如MySQL）和部署方式。

      • AI能自動生成詳細的重構策略報告，包括：

        • 轉型為無狀態架構（如使用Redis管理會話）。
        • 前後端分離、微服務拆解（如驗證授權、帳戶、交易、支付服務）。
        • 容器化配置（Dockerfiles, Kubernetes）。
        • 資料庫遷移（如MySQL到PostgreSQL，包含索引與資料轉換建議）。
        • 建構CI/CD流程。
        • 監控、日誌、資安設計（加密、API設計、環境變數）。
        • 成本估算和成功指標（SLA）。
        • 提供雲原生模式的參考資料。

      • 效率顯著提升：一份過去需耗時三天撰寫的重構報告，AI能在半小時內完成，且品質更優。

      • 實例：引述日本樂天案例，運用AI在7小時內重構了1250萬行程式碼，準確率達99.9%。

    • 應用場景考量：AI輔助開發在架構分析與設計方面表現突出，但在前端UI/App開發等需要即時視覺回饋的場景可能較不適用。此外，AI生成的複雜程式碼對初級工程師而言可能難以理解和修改。

• 未來展望

  • AI輔助開發（AI Coding）自2023年以來日益普及，並在特定場景中展現了其有效性。
  • 技術發展迅速，不斷有新的工具與應用場景出現。

雲端技術應用提供巨量數據資料儲存並支撐即時處理、分析的彈性。隨著金融三業委外上雲辦法頒布，金融業正式迎接大規模上雲潮，對金融產業的作業流程與技術推進上背後代表哪些意義？解決哪些過往痛點？並有效支持相關業務創新？

以下是這場演講的重點總結：

• 雲端是AI發展的基石：在AI時代，資料形態多樣化且大數據運用快速發展，企業需要更快速有效的方式應對數據分析需求及時處理效率。雲端作為底層基礎，支撐巨量資料的即時處理與分析彈性。

• 金融業上雲已成趨勢：國際大型金融業都開始往雲端遷移，將應用系統甚至核心系統搬上雲端，看重雲端的彈性及成本控制等效益。

• 國泰金控的雲端轉型領先地位：國泰金控早在2020年啟動七年集團雲端轉型計畫，目標在2025年將有100套系統上雲，是台灣金融業發展雲端最快的企業之一，並且成為首家數據上雲的金控業者。

• 法規鬆綁與雲端自律規範的重要性

  今年政府在法規上鬆綁，發布雲端自律規範及金融機構使用雲端服務實務手冊，對於整個金融業推動雲端佈局是一大進步。

  • 雲端自律規範的背景：為了滿足金融業數位轉型的需求，提升金融服務的敏捷性與彈性，並在一定的規範、安全及合規要求下使用雲端運算資源。制定參考了新加坡、美國、日本、香港等地的上雲法規與最佳實踐。
  • 金融機構使用雲端服務實務手冊的益處：為金融業上雲提供全面的指引與最佳實務，涵蓋降低風險（資安風險、隱私、營運中斷）、加密與金鑰管理、身份辨識、稽核軌跡、雲端架構安全指引、符合國際規範（如ISO 27017）、提升營運效率（雲端環境設計、部署監控管理）以及雲端人才職能與培訓。
  • 這兩項文件的發布如同金融業上雲的「參考書」，有助於降低上雲風險，提升營運效率與資訊安全。

• 雲端自律規範對國泰金控的影響

  • 過去上雲可能因系統重大性、是否為消金業務、境內外等議題需要報備或報准，流程耗時且不確定性高。
  • 過去選擇雲端供應商或代理商缺乏標準與依據，雙方責任劃分不明確。
  • 雲端服務實務手冊中明確了責任共享模型，區分了SaaS等不同雲端服務的使用者與供應商責任。
  • 提供了雲端服務策略發展、風險評估、架構管理、人才培訓、資安控管、維運、查核等各面向的詳細指引與標準化評估流程，有助於將系統搬上雲端，加速創新。
  • 過去對於資料加密等議題缺乏共識，現在雲端服務實務手冊直接列出相關技術與服務名稱，加速溝通與執行。
  • 主管機關與業界達成共識，有助於後續雲端創新的快速推進。

• 國泰金控的雲端發展策略與目標

  • 最重視資安與合規。
  • 注重上雲的組織發展與人才培育。
  • 採用「Cathay 6R」方法論，目標是消滅虛擬機，鼓勵使用容器化、PaaS、SaaS等更現代化的雲端服務。
  • 最終目標是實現 IT 現代化，包括償還技術債、加速業務創新、增加營運彈性與持續性。
  • 透過上雲建立符合資安與合規要求的雲端平台，堆疊數據，建立資料流水線與數據平台，為未來的 AI 應用打下堅實的基礎。雲端儲存的穩定性非常高，且三大CSP提供的AI相關服務有助於資料流、網路傳輸與資料保護的控管。

雲端運算在金融業數位轉型和AI發展中的關鍵作用，並以國泰金控為例，分享了其領先的雲端轉型經驗與策略，同時也說明了近期法規鬆綁與雲端自律規範對整個產業的積極影響。

這場演講分享關於其雲端轉型歷程以及利用 AI 輔助雲端架構設計的經驗。詳細介紹了我們的上雲計畫，並重點介紹 雲端架構圖智能生成 Smart Archie 這個 AI 工具，用於自動生成和修改雲端架構圖。

以下是演講的重點總結：

• 國泰金控的上雲計畫：該計畫自 2020 年開始，為期七年。目標是在五年內將集團 100 套系統上雲，目前已完成 82 套，預計今年將達成目標。上雲的目的是為了加速 IT 現代化、提升系統的彈性和高可用性，並縮短新功能的上市時間 (time to market)。我們強調上雲並非單純遷移虛擬機，而是透過分散式架構和雲端服務來實現 IT 現代化。
• 雲端架構設計的挑戰：傳統地端架構設計相對單純，但雲端架構設計需要考量眾多雲端服務及其組合，使得雲端架構師成為稀缺人才。為了應對這個挑戰，我們開始探索利用 AI 技術輔助架構圖的生成。
• AI 輔助架構設計的實驗 (Smart Archie)：我們進行了一項實驗，旨在利用生成式 AI 自動繪製雲端架構圖，並進一步從架構圖反向生成基礎設施即代碼 (IaC)。
• 實驗過程與工具：使用 Python 語言定義的 diagrams (Diagram as Code) 和 PlantUML 等工具來呈現架構圖。AI 模型需要輸入上雲的需求、資安規範 (policy) 等資訊。
• 實驗結果與改進：最初直接將需求丟給 AI 模型，編譯成功率 為 0%。透過逐步加入 Chain of Thought (COT)、架構圖範例 (ICON) 和反思機制，最終實現了 100% 的架構圖生成成功率和 98% 的需求滿足度。然而，生成時間也會隨之增加。
• Smart Archie 的功能展示：展示了 Smart Archie 的操作介面，使用者可以透過填寫問卷輸入系統需求，工具會自動生成雲端架構圖。使用者還可以透過自然語言與 Smart Archie 互動，修改架構圖、詢問設計理念等。Smart Archie 具備護欄機制，避免回答與架構無關的問題。最終可以將架構圖下載保存。
• Smart Archie 的價值與未來發展：Smart Archie 對於 Junior 架構師尤其有用，可以幫助他們理解複雜的雲端架構。未來的目標是從架構圖自動生成 IaC 的程式碼，進一步加速雲端部署。
• 人機協作的重要性：即使有了 AI 工具的輔助，人類架構師的全局觀和整合能力仍然至關重要。AI 生成的架構需要人類進行審核和完善。

這場演講展示我們在雲端轉型方面的努力和創新，特別是在利用 AI 技術提升雲端架構設計效率方面的探索和成果。我們開發的 Smart Archie 工具展現了 AI 在解決實際 IT 問題方面的潛力，並為金融業的雲端轉型提供了有價值的經驗。

這場演講主要聚焦在 NotebookLM 這項工具的基本介紹與其在學習上的應用。分享使用 NotebookLM 的經驗，並提到它在讀書會、會議記錄、協同筆記以及撰寫論文等方面都非常有幫助。

以下是演講的重點總結：

• NotebookLM 基本介紹：NotebookLM 是一個 Google 推出的工具，介面簡單易用，可以上傳多種格式的檔案（如 PDF、Text、Markdown、MP3、MP4）、Google 文件、Google 簡報，也能連結 YouTube 影片和網站內容。上傳資料後，使用者可以透過提問與 NotebookLM 進行互動，從而快速獲取資訊。

• 個人化資料流 (Data Pipeline)： NotebookLM 在建立個人化的資料流方面表現良好，能夠方便地導入多種資料來源，並能及時更新 Google Drive 上的文件。使用 Google 文件和簡報作為資料來源尤其方便，因為可以直接看到預覽內容，且更新來源檔案時，平台內的資料也會同步更新。分享在 Google 文件中使用 Markdown 語法的技巧，以及將分頁模式改為不分頁模式的建議。

• NotebookLM 在學習上的應用案例

  • 讀書會 (Knowledge Base)：分享使用 NotebookLM 作為讀書會知識庫的經驗，相較於 ChatGPT，NotebookLM 更能根據上傳的讀書會資料產生更精確的回答，例如關於「架構量子」、「微服務」和「領域驅動設計」之間關係的問題。讀書會後，還可以利用 NotebookLM 的 podcast 功能將討論內容轉化為音訊，方便複習，甚至可以搭配自動翻譯和字幕生成 YouTube 影片。
  • 會議小秘書 (Meeting Minutes)：透過上傳會議錄音檔，NotebookLM 可以自動生成會議記錄、建立目錄並整理出時間軸，方便使用者快速掌握會議重點。其生成的會議記錄品質甚至優於一般員工的手寫記錄。
  • 協同筆記 (Collaborative Note-taking)：實習生們在上課時使用 NotebookLM 進行協同筆記，上傳錄音檔和個人筆記後，NotebookLM 能產生系統化的內容。雖然目前 NotebookLM 的筆記功能無法放大，但學生們發現可以直接與 NotebookLM 互動提問，不必像過去一樣排隊等待助教。NotebookLM 還能根據上課內容產生學習指南和模擬考題。收集的筆記同樣可以轉換為 podcast 方便通勤時收聽。
  • 論文寫作 (Thesis Writing)：有在國外念研究所的學生利用 NotebookLM 整理論文，發現它可以快速查詢引用來源和頁碼，提高整理效率. 透過提問功能，學生能更快理解論文中難懂的概念，並能模擬與教授討論的場景。NotebookLM 的建議問題功能甚至能提供撰寫論文的新角度。講者特別提醒，提問時加入「來源」這個關鍵字，能確保 NotebookLM 從上傳的資料中生成答案，提高準確性，減少模型幻覺。

• 資料篩選與可遷移技能 (Data Filtering and Transferable Skills)：在 AI 時代，擁有篩選大量資訊、判斷資料好壞的能力非常重要。針對學生，即使 AI 工具很強大，學習「可遷移技能」（soft skills）仍然至關重要。在技能基金會的定義，包含溝通力、學習力、解決問題的能力等。在眾多可遷移技能中，影響力、洞察力、溝通能力和思維能力是生成式 AI 較難取代的。最後，批判性思維能力很重要，也就是提問的能力，在當前大量使用 AI 工具的時代尤為重要。以《論語》為例，說明提問和思考的重要性。

本次演講方式介紹了 NotebookLM 在提升學習效率方面的潛力，並提醒聽眾在善用 AI 工具的同時，也要培養資料篩選和批判性思維等核心能力。

在國泰金控推動大規模上雲的這幾年，我最大的感受是：架構師永遠不夠用。 當各子公司同時啟動 Cloud Ready 專案，動輒上百張雲端架構圖要在短時間內產出，還得符合內部 Cathay 6R 方法論與金融業合規條款──這幾乎是不可能的任務。於是，我們動手打造了 Smart Archie，一個結合 LLM 與 Diagram-as-Code 的「雲端架構生成助手」。

1. 為什麼需要 Smart Archie？

1. 產能失衡：上雲專案暴增，但資深架構師有限。
2. 格式混亂：每位架構師偏好的繪圖工具與圖例不同，導致跨部門溝通成本高。
3. 缺乏沿革：許多專案只保留最終架構圖，需求演進與修訂過程難以追溯。

關鍵思考 與其持續「人海戰術」畫圖，不如把「畫圖」本身視為可以被自動化的程式碼生成流程。

2. 技術選型：Diagram-as-Code 的二分法

我們最終採 雙軌並行：以 Diagrams 為主要產線，PlantUML 作為備援。

3. Prompt Engineering：從 0% 到 100% 編譯率

1. Naïve Prompt → 0 % 可編譯
2. 加入 Chain-of-Thought → 還是 0 %
3. 加入 RAG（Icon 檢索） → 8 %
4. Few-Shot 範例 → 83 %
5. Few-Shot + RAG → 100 %
6. 再疊上 Auto-Refinement → 需求符合度 98 %，平均 2 分鐘內完成微調。

心得 CoT 有助於 LLM 思考流程，但 範例（Few-Shot）與即時知識檢索（RAG） 才是提高穩定度的關鍵；Auto-Refinement 則讓模型學會「自我補救」，大幅降低人工回補。

4. Smart Archie 的三大核心能力

1. 架構圖初版生成
   • 讀取上雲問卷與政策，30 秒內輸出符合公司守則的雲端架構圖（Diagrams/PlantUML）。
2. 自然語言微調
   • 像對同事講話一樣：「把資料庫換成 Amazon RDS PostgreSQL 高可用版」，即可自動修版並記錄版本差異。
3. 版本沿革追蹤
   • 每一次修訂都被 Git 追蹤，方便審計與跨組織溝通。

5. 成效與展望

• 時間成本：一張典型三層式架構圖，從過去人工 3 ~ 4 小時，縮減至 < 2 分鐘。
• 品質一致性：所有圖例符合內部政策，不再需要人工比對。
• 未來整合：Smart Archie 已透過 Cloud Ready Platform 與「知識解惑」「IaC 生成」等模組串聯，形成一站式雲治理工作流。

6. 結語

Smart Archie 的誕生證明了：當我們用「程式碼」思維重塑「繪圖」流程，LLM 就能成為雲端架構師的最佳拍檔。在 AI 與雲端浪潮交會的此刻，唯有不斷解構問題、迭代實驗，才能讓工具真正落地、放大人類專業的槓桿。