AI Agent 的想像很美，但企業現場很硬。真正的瓶頸往往不是模型夠不夠聰明，而是企業能否讓 Agent 安全取得資料、使用工具、呼叫 API、參與流程，並且全程可觀測、可治理、可稽核。這場演講從我的個人 Agent 實驗、AI Scrum Team 的「6+1」模式，一路談到企業級 Agent Platform，以及 Cloud First 為何正好替 Agent First 打下基礎。

Cloud First 建立數位基礎建設，Agent First 則讓數位勞動力能在其上安全工作。

1. AI Agent 的想像很美，但企業現場很硬

這幾年我在雲端大會分享的內容，大多與上雲有關。去年提報這個題目時，我還不知道 2026 年的 AI 會發展到哪裡，只覺得 AI Agent 應該會成為重要議題。到了今年上半年，從個人使用的 Agent、Coding Agent，到各家雲端業者推出的企業方案，市場真的快速升溫。

但我愈實際使用，愈確定一件事：Agent 最大的瓶頸不是模型，而是企業系統能否被安全接入。

在對話視窗裡問問題很容易；要讓 Agent 真的工作，就必須讓它接觸資料、權限、API、文件、帳號與既有流程。個人使用時，這些問題還能靠自己的信任和手動修正處理；到了團隊和企業，任何模糊的授權都可能被放大。

因此，我把 Agent 能力的放大分成三個層次：

1. 個人 Agent：看見 Agent 能持續工作的真實能力，也看見它的邊界。
2. 團隊 Agent：讓 AI 不再是用完就關掉的工具，而是參與共同流程的第七位成員。
3. 企業 Agent：當 Agent 從一個變成數百個，問題核心就轉向平台工程、治理與營運。

Agent First 不是把 AI 接到企業裡，而是把企業變成 AI Agent 可以安全工作的地方。

2. 個人 Agent：第一次覺得 AI 真的在工作

今年二月開始，我讓 Agent 真正住進自己的電腦。四十多天裡，我做了三十多個 one page、十二個 skills，也使用過四個不同的 AI agents。它會替我整理科技新聞、抓取文章全文、查資料、翻譯，甚至把我真正關心的內容做成每天開車時可以收聽的 Podcast。

第一次讓我有強烈「Aha Moment」的，是請它幫我訂武陵農場的露營位。櫻花季營位很難搶，我先讓它每三十分鐘檢查一次。第一次發現空位時，它只通知我；等我看到訊息再打開網站，名額早已被搶光。

我於是調整指令：發現空位就直接協助訂位，不要只通知。後來它真的完成了。那一刻的感受很不一樣——它不是回答了我一個問題，而是持續監控環境，等條件成立後替我完成工作。

但這個例子同時也顯示了邊界。訂位進入刷卡付款時，我曾嘗試提供卡號，Agent 拒絕接受，因為它判斷這是高風險行為。Agent 愈有能力，我們就愈不能只問「它會做什麼」，還要問「哪些事可以直接做、哪些必須先問、哪些永遠不能做」。

從 Prompt 到 Skill

使用 Agent 時，我們會透過對話反覆調整做法。當一件工作做過一兩次、流程已經穩定，下一步就可以請 Agent 把它沉澱成 skill，形成可重複執行的工作流。

Agent 的能力不只是問答，而是把 Prompt 逐步沉澱成每天都能運作的 Skill。

例如每日新聞摘要會經過抓取來源、整理全文、產生摘要、上傳 NotebookLM，再生成語音；另一個流程會進入 The Verge 的每篇文章取得全文，而不是只看標題；GitHub 編輯精選 Podcast 則會完成選題、整理與語音產出。

真正的挑戰不是成功一次，而是今天成功、明天更新後仍然能工作。模型具有不確定性，Agent Runtime 和外部網站也會變動，因此個人 Agent 很快就會碰到類似 SRE 的課題：失敗如何重試、輸出如何驗證、異常如何被發現、流程如何修復。

3. Agent Harness：能力愈強，愈需要安全紅線

一個 Agent 的表現不只由模型決定。模型、Agent Runtime、skills、工具權限、記憶與 guardrails 共同構成 Agent Harness。好的 Harness 應該讓工作流不會因為更換模型或工具就全部失效，也要讓不同執行環境維持一致的行為邊界。

我會把動作分成三層：

• 可以直接執行：整理資訊、監控公開狀態、產出分析草稿。
• 必須先詢問：登入帳號、提交表單、修改正式資料、對外發布。
• 必須拒絕：未授權金流、敏感資料外流與高風險權限操作。

治理不是把 Agent 關起來，而是讓它知道可以安全走到哪裡，以及何時必須把決定交還給人。

個人場景已經會遇到帳號、金流與個資；企業場景只會把問題放大十倍、百倍。沒有清楚邊界的 Agent，不可能因為換成更強的模型就突然變得安全。

4. AI Scrum Team：六位真人，加上一位 AI 成員

到了五月，公司開始把 Agent 機制導入開發團隊，形成 AI Scrum Team。過去常用「兩個披薩」形容一個約十到十二人的敏捷團隊；既然 AI 已經進入開發流程，我們嘗試把人的編制縮小為六人：

• PM／Product Owner 一人。
• Design／UI/UX 一人。
• RD 三人，涵蓋前端、後端與架構。
• QA 一人。

再加上一位 AI Member，成為「6+1」。

AI 不是開在瀏覽器裡、用完就關掉的工具，而是有身份、資源與工作協議的團隊成員。

這個「+1」不是一個聊天頁面。它有自己的主機、帳號、身份與存取範圍，可以持續存在於團隊流程中。Sprint Planning 時，它能整理需求背景、找相依性、補足驗收條件；Daily Scrum 時，能整理進度與阻塞；Development 階段，可以參與 code review、測試、文件和 PR 摘要；到了 Review 或 Retro，則協助沉澱決策、缺陷模式和下一輪改善。

6 月 23 日 Anthropic 發表 Claude Tag，讓團隊能在 Slack 頻道直接 @Claude 指派任務。它會在授權的 channel 中累積共同上下文、使用指定工具、非同步完成工作，再回到 thread 報告結果。這與我們設計「第七位成員」時的想法非常接近：不是問完就消失，而是留在流程裡，替團隊保存共同脈絡。

5. 它是在監督團隊，還是在幫助團隊？

Agent 進入團隊後，很快會出現一個敏感問題：它知道任務進度、branch 是否合併、誰遇到阻塞，也能整理個別工作量。那麼，它究竟是管理者派來監督團隊的工具，還是幫助大家完成 sprint goal 的成員？

這不是功能問題，而是目標設計問題。

如果 Agent 的目標是找出誰沒做事，團隊會把它視為壓力來源，最後只剩形式化配合，甚至不願意讓它進入真正重要的對話。若它的目標是補足上下文、提醒阻塞、減少重工，替團隊扛下繁瑣流程，它就更可能成為大家願意合作的隊友。

有一個團隊讓自己的 AI Member 回答「你是來監督大家，還是真正的 member？」它給出一個很誠實的判準：如果它消失，只有一個人發現，它還只是工具；如果好幾位成員都感覺團隊少了什麼，這個角色才算真的長出來。

因此，AI 成員同樣需要 onboarding：

1. 給它身份：帳號、主機、repo、API 與文件存取權。
2. 給它規範：哪些可以做、哪些要先問、哪些永遠不能做。
3. 給它上下文：產品目標、團隊慣例、Definition of Done 與架構原則。
4. 給它觀測：能追蹤做過什麼、使用哪些工具、產出什麼結果。

6. FinOps Agent：從目標清楚、價值可量化的工作開始

當每個團隊都可能有第七位成員，下一個問題自然是：企業應該先從哪一種 Agent 開始？

我認為 FinOps Agent 是很好的切入點，因為目標明確——替大家節省不必要的雲端成本。它需要理解成本、政策、標籤、預算和雲端定價，也需要底層的 Policy Engine、Tagging Engine 與成本資料。

當這些基礎能力準備好，FinOps Agent 就能在工程師提交 IaC 變更和 Pull Request 時，自動檢查預估成本與政策；遇到異常時通知工程師，需要核准時交還給人，確認無誤後才進入部署流程。

這類 Agent 不必一開始就取得所有權限，也不需要重做整個企業流程，卻能很快證明 Agent 參與團隊工作的具體價值。

7. Cloud First 其實是在替 Agent First 打底

團隊 Agent 成效不錯後，企業很快會想把它複製到更多團隊與流程。但許多 PoC 停住，並不是模型不夠聰明，而是卡在資料、權限、API、流程、治理與安全。

國泰從 Cloud Ready、Cloud Adoption 走到 Cloud First，完成百套系統上雲。過程中建立的 Landing Zone、IAM、Gateway、隔離環境、標準化流程、資安與治理機制，當時看起來都是在處理雲端管理；回頭看，這些正好也是 Agent 可以安全工作的基礎。

大型金融集團還必須同時面對監理、安全、既有系統、跨公司治理和組織共識。合規不能事後再補，身份與權限也不能等 Agent 上線後才設計。Agent 不是一個獨立 App，而是會觸碰整個企業能力的數位勞動力。

完整的 Agent Platform 至少需要八項核心能力：

• Identity：Agent 是誰？
• Knowledge：它可以看哪些知識？
• Tool／API：它可以呼叫哪些系統？
• Workflow：它如何嵌入企業流程？
• Observability：如何知道它做了什麼？
• Security：如何控管它的行為？
• Audit：如何追蹤與稽核？
• Lifecycle：如何上線、更新與退場？

企業級 Agent Platform 必須把八項核心能力整合在同一個可營運、可治理的平台上。

企業 Agent 的發展可以依序分為 Build、Scale、Governance、Optimize。先證明 Agent 能解決問題，再讓它接上 Runtime、Gateway、Apps、APIs 與 Tools；規模增加後，逐步導入 registry、identity and access、policy guardrails 與 audit trail；最後透過觀測、評估、回饋、成本與效能調校持續優化。

治理當然重要，但不要在 Build 階段就用過重規範壓住所有實驗。正確做法是先守住必要底線，再隨著規模擴大治理力道。治理者也必須理解技術，才能在創新速度與風險之間建立真正可執行的平衡。

8. 打造一個 Agent 很容易，管理五百個才是真正挑戰

一個個人 Agent 可以靠信任與手動修正；一個團隊 Agent 需要 JD、onboarding、權限和工作協議；當企業裡有五百個 Agent，就需要平台化管理身份、授權、工具目錄、知識庫、審計、觀測、成本與生命週期。

規模從個人、團隊走向企業後，真正的挑戰從打造 Agent 轉為管理 Agent。

這也是為什麼我認為平台工程在 Agent 時代會變得更重要。多年來管理雲端資源和應用系統累積的治理邏輯，可以延伸到 Agent；改變的是管理對象，從 digital infrastructure 轉成 digital workforce。AgentOps 也可以借鏡 CloudOps、DevOps、MLOps 與 FinOps 的成熟做法。

Cloud First 建立的是彈性、標準、治理、安全且可營運的數位基礎建設；Agent First 則是在這個工作場所裡，形成能安全接入企業系統、跨流程協作、被觀測也被稽核的數位勞動力。

企業今天為雲端、資料、權限、流程與治理打的底，就是明天 AI Agent 能不能真正上工的分水嶺。

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

北宋思想家、教育家、理學創辦人 張載（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 走向 Cloud First 的七年旅程，也分享我一路上最深的體會：雲端轉型其實是一場信心工程。

我們不是把系統搬到雲上就結束，而是一路從「能上雲」走到「預設用雲」。

1. 敢說走在同業前面，先回答「為什麼要上雲」

這是我第一次在 WebConf 談雲端。前一場講者才提到，當年大約六成議程都和 AI 有關；我的題目卻完全沒有 AI，反而顯得稀有。

不過既然題目敢寫「走在同業前面」，我就得先交代憑什麼。從 2020 年啟動集團七年雲端轉型計畫，到公開宣布完成百套系統上雲，外部已經留下不少紀錄；我甚至搜尋到有人只靠公開資料，把國泰上雲寫成一篇碩士論文，卻沒有訪問任何我認識的人。演講當下，我看到的最新內部數字是 123 套。國泰對外資料則以「超過百套系統上雲，正式從 Cloud Ready 進入 Cloud First」描述這個里程碑。

但數量不是我最想談的重點。金融業上雲，最常被問的是「會不會比較省錢？」我的答案一直是：不一定。架構沒有設計好，上雲一樣很貴。

真正值得換取的是速度、彈性與可靠性。信用卡活動或大型售票帶來的瞬間流量，很難靠地端設備為少數尖峰長期備妥；金融服務又不能隨便停機。雲端的彈性伸縮與託管服務，讓我們能用不同方式處理這兩個問題。上雲不是為了追流行，而是為了替金融科技建立更能快速反應的體質。

2. Cloud Ready：先把抽象的風險說成人話

2019 年，主管機關為金融業上雲打開一扇小門；國泰從 2020 年進入 Cloud Ready。那時不能突然選一個系統就搬上去，我們得先準備網路與 Landing Zone、管理治理、組織人才，以及雲原生應用的開發方式。

最常遇到的問題是：「把資料放到雲端服務商的機房，他們半夜偷看怎麼辦？」

標準答案是責任共享模型，但光講 IaaS、PaaS、SaaS，法遵、資安與風控同仁未必立刻有感。我後來改用辦公室租賃來比喻：國泰把樓層租給其他公司，不代表房東可以半夜破門翻資料；承租人也不會把機密攤在桌上，而會鎖櫃、加密並管理鑰匙。雲端同樣如此，服務商與使用者各有責任，資料所有權與保護措施也不能因為「租用」就消失。現行規範同樣要求金融機構保有資料所有權、控管儲存地，並採取加密與金鑰管理措施，可參考金管會雲端委外規範。

責任共享不是把風險全部交給雲端服務商，而是把每一層該由誰保護說清楚。

金融業的另一個現實，是技術語言一旦進入規範，差一個詞就可能多出大量溝通成本。我曾在政府文件裡看到 SaaS 被翻成「雲端化服務」，還分成「套裝型」。我當場很困惑：如果有雲端化服務，是不是也會有地端化服務？我們花了不少力氣釐清 IaaS、PaaS、SaaS 的邊界。這類事情看起來像文字問題，實際上會直接影響審查、架構與採用方式。

因此 Cloud Ready 不是單一技術專案，而是五條軌道同時推進：

1. 進行雲端安全評估與差異分析。
2. 導入 ISO 27017、CSA CCM 等雲端安全框架。
3. 透過培訓、Workshop、Onsite 輔導與 Office Hour 建立種子團隊。
4. 以 CCMA 評估系統，搭配 Cathay 6R 決定 Rehost、Re-platform、Refactor、Rewrite、Replace 或 Retain。
5. 建立 MVC 與 Landing Zone，把 VPC、IAM、CI/CD、IaC、安全機制與託管服務真正跑起來。

回頭看，這一階段最重要的產物不是一張架構圖，而是信心：讓資安知道風險如何被控制，讓開發知道雲端不是摸不到的黑盒子，也讓主管知道上雲有方法、有順序、有退路。

3. Cloud Adoption：一套能上雲，不代表一百套能上雲

2021 年起，我們進入 Cloud Adoption。單一系統成功後，問題立刻改變：大規模遷移需要成熟 SOP；雲端支出快速增加，需要 FinOps；多雲環境也讓維運、安全與治理複雜許多。2023 年主管機關改採更明確的風險基礎管理，並簡化部分申請範圍，也替金融業規模化採用雲端創造了條件，可參考金管會修法說明。

從一套到百套，真正增加的不只是資源數量，而是治理、維運與成本管理的複雜度。

我們在 2023 年底成立雲端策略發展部，扮演 CCoE 的角色，設置上雲戰情室、Sandbox，並把 DevSecOps、Policy as Code、SRE、ITSM、平台工程與 FinOps 納入共同運作。各子公司也需要對應的引導組織；金控不能只在總部喊「要上雲」，還得讓銀行、人壽、產險與證券都知道怎麼做。

Sandbox 尤其重要。新技術導入時，如果完全不允許同仁犯錯，大家就不敢碰，也不可能累積真正的操作經驗。我們需要在正式環境之外，提供一個有邊界、可觀測、出錯也能復原的練習場。治理的目的不是把所有路封死，而是讓團隊知道可以在哪裡安全試驗，以及越過哪條線之前必須停下來確認。

多公雲不是為了蒐集品牌，而是不同時期與場景的結果。早期應用系統選擇 Google Cloud，與台灣已有資料中心有關；數據團隊偏好 AWS；OA 與生產力工具則自然連到 Microsoft 365 與 Azure。最後形成混合雲加多公雲，也必須承擔跨雲治理的複雜度。

FinOps 則像管理水電。地端伺服器買下去，預算已經支出；雲端資源一開啟，水龍頭就開始流。除了巡查閒置資源、調整過度配置、管理儲存分層與跨區傳輸，也要預估未來用量，透過承諾使用取得更好的價格。優化雲端不是一味砍資源，而是把資源放在最有價值的地方。

我們也把評估、設計、審查、維運與資產盤點沉澱成 Cloud Ready Platform 與 Cathay Information Asset。當方法論被做成平台，轉型才不必每個專案重新發明一次。

4. Cloud First：生成式 AI 帶來第二波雲端需求

到了 2025 年，雲端開始從選項變成預設。Cloud First 的意思不是任何系統都不顧條件直接上雲，而是新系統先評估雲端；即使暫時留在地端，也盡量採用 cloud-native 架構與 API，替未來移動保留彈性。

生成式 AI 讓這個策略更有感。2023 年起，數據團隊開始提出 GPU 機房需求，有時一估就是一百、兩百張 H100。當時詢價，一張 GPU 約百萬元台幣；廠商評估的散熱系統租用費，一年也要兩、三千萬元。更麻煩的是，採購與建置可能花掉一年，而 GPU 三、四年就進入下一個汰換週期。

我們因此反問：能不能先在雲端按需租用，完成模型與架構的可行性驗證，再決定是否自建？團隊實際看到結果後，才逐步放下「一定要先蓋 GPU 機房」的想法。雲端在這裡提供的不是比較便宜的口號，而是先小額驗證、成功再擴大的選擇權。

企業使用生成式 AI 當然不能只有算力。身分、授權、稽核、網路隔離、DLP 與資料治理都必須一起進來。我們傾向使用三大雲提供的企業級 GenAI 服務，把 AI 納入既有 VPC 與治理框架。因為 AI 的燃料是資料，而資料與 AI 的底層又是雲；多年 Cloud Ready 與 Cloud Adoption 的累積，剛好替這一波需求打好地基。

AI 不會憑空創造企業價值：Cloud 是地基，Data 是燃料，AI 才能成為能力。

5. Smart Archie：不要讓一個 Agent 假裝什麼都會

大規模上雲後，架構設計出現三個痛點：敏捷迭代讓需求反覆改變；金融業政策與安全要求很多；多雲架構圖又缺乏一致格式。這促使我們開發 Smart Archie，讓 GenAI 協助產生架構、套用 Policy as Code，並把設計流程標準化。

Smart Archie 一開始是 Prompt-based LLM，後來加入 Knowledge Base 成為 RAG，再演進到能拆解任務的 Agent。如果把所有能力塞進同一個 Agent，Prompt 會失控、Knowledge Base 難維護，Context Window 也容易過載，所以我們最後選擇 Multi-Agent：

• Architect Agent 負責理解需求、分派任務與整合結果。
• DaC Agent 以 Diagram as Code 產生架構關係。
• Solution Agent 分析服務組合並檢核政策。
• TCO Agent 估算成本與提出資源優化建議。
• IaC Agent 把架構轉成可進入 CI/CD 的 Terraform。

Multi-Agent 的價值不是多放幾個機器人，而是把複雜任務拆成可管理、可檢查的專業分工。

Demo 裡，使用者只要補上一個新需求，系統就會重新分析方案、更新架構與成本，最後輸出 IaC。這讓架構師把時間從重複繪圖與搬資料，移回真正需要人判斷的技術決策。Smart Archie 也建構在 AWS 與 Amazon Bedrock 上，證明 Cloud First 不只是政策，而是我們自己開發產品時採取的實作路徑。

這個產品也讓我更確定，自研不代表什麼都要自己守到底。我們早期花力氣做過成本估算，後來雲端服務商推出更成熟的現成能力，接進來效果更好，我就請團隊直接採用。真正可持續的平台，應該能替換元件、吸收新的外部能力，而不是把過去寫過的每一行程式碼都當成不能放手的資產。

6. 最後的答案：轉型是一場信心工程

回顧整段旅程，我把洞察整理成 People、Process、Technology 三件事。

People：組織文化比技術更難升級。 DDT、Cloud Ready 與 CCoE 的作用，是讓雲端導入從阻力變成信心工程。大家願意相信方向，才會願意改變工作方式。

Process：標準化是規模化的前提。 Cathay 6R、SOP 與 Cloud Ready Platform，讓不同系統與團隊可以沿著相同軌道前進。沒有標準化，就無法治理百套系統。

Technology：雲與 AI 重新分配人的時間。 程式碼、架構圖與 IaC 都能由 AI 協助產出；人的價值則更集中在問題定義、洞察與判斷。

文化決定願不願意走，流程決定能不能一起走，技術則決定可以走多快。

所以我在最後仍然提醒大家，AI 時代需要兩類能力。Networking、Cloud Architecture、Cloud-Native Development、DevOps、SRE、Data & AI、Cloud Security 等 Hard Skills，是你能否提出好問題的地基；洞察與批判思考、創意、自我管理、溝通協作與領導影響力等 Soft Skills，則決定你能把 AI 的能力放大到什麼程度。

AI 取代的是技術操作，而不是專業能力。

國泰所謂「走在同業前面」，不是因為所有系統都已經在雲上，也不是因為我們沒有繞路；而是我們把每一次碰撞變成方法，把方法變成平台，再把平台變成整個組織可重複使用的能力。真正的雲端轉型，不是完成一次遷移，而是讓下一次改變來臨時，組織已經準備好。

重點聚焦於國泰金控的雲端轉型策略以及如何利用多智能體（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 工具的同時，也要培養資料篩選和批判性思維等核心能力。