NeoTechOps 三大核心戰略目標

NeoTechOps 以「全員皆 Ops」為理念，將每一位會被新技術影響的員工都視為技術生態圈的核心成員。其戰略佈局由以下三大目標支撐：

Community（社群）：

建立部門間技術共享與交流平台，促進創新經驗的流動與知識協作，打破資訊孤島，讓最佳實踐與創新成果能夠擴散至全公司。

System（系統工具）：

打造涵蓋技術導入、體驗、評估、回饋等完整流程的數位平台，支援新技術全生命周期管理，讓工具與資源隨手可得，降低員工嘗試與採用門檻。

Methodology（方法論）：

建立組織內部的技術學習、知識傳播、制度化與知識文件化的系統化流程，讓技術內化不再倚賴個人經驗，而是成為可複製、可傳承的組織資產。

NeoTechOps 四大戰術工程

為實現上述戰略目標，NeoTechOps 透過「四大戰術工程」具體落地推動：

A. NeoSaaS 工具研發：

持續整合、整理並推廣最新技術工具，透過實務教學與學習資源推動新工具的廣泛應用，協助同仁降低學習曲線，強化技術導入的起點。

B. 系統開發：

打造各樣特定需求的專屬平台，聚合資訊收集、知識體驗、技能自評、回饋與案例管理等功能，形成完整的數位工具鏈與學習閉環。

C. 技術研究：

深入關注並剖析新興技術趨勢，包括 各種新技術的應用等，協助組織成員保持前瞻性，積極迎接新一輪技術革新。

D. 新技術聯盟（NTA）：

經營跨部門的虛擬技術社群，讓來自不同領域的成員能夠彼此交流合作，激發共創、突破部門界線，推動知識在組織內自然流動與生根。

具體成效與價值主張

透過「三大戰略 × 四大戰術」的整合推進，NeoTechOps 正逐步建構一個兼具可持續成長性與技術擴散能力的新型技術生態系統。

NeoTechOps 突破傳統「技術下放」的單向推動思維，強調全員共創與知識內化，讓 HR、業務、財會、工程師等不同角色，都能依據自身需求獲得學習、應用、共創新知的資源與支持。

這不僅消弭創新落地時的阻力與鴻溝，更激發組織持續學習、跨部門協作與共創文化，進而構築企業長遠競爭力。

本議程將深入分享 NeoTechOps 的運作架構、關鍵機制與落地成果，協助企業領導人與管理層掌握打造新時代組織創新生態圈的實踐心法，為企業數位轉型與創新升級注入持續動能。

聽眾收穫：

目前大多數的新技術應用(AI、LLM...)都是單點、單點的進行吸收和分享，提供一個新概念的方法論，並且已在國泰金控內部嘗試推廣和實際應用，可以給予其他企業的高階主管或是CTO了解到，針對目前新技術(LLM)這股快又急的浪潮，如何有效地在組織內提升同仁的能力。

聚焦 「怎麼連上現有環境並馬上看到 AI 效果」。工作坊前 30 分鐘以最小必需技術解說 MCP 架構；接下來 60 分鐘帶大家動手：

1. 以 Docker Compose 啟動事件匯流排；
2. 掛上 Filesystem-MCP 監控範例目錄、Email-MCP 監控 Gmail 測試帳號；
3. 使用內建 LLM Service 呼叫 GPT-4o，完成文件摘要、風險標記與創意建議；
4. 用 Chat UI 向 AI 提問：「幫我找出所有包含『XYZ』的合約」或「最近三天有沒有異常請款？」並即時得到多台電腦／信箱跨源答案。

大綱

1. MCP 快速總覽（10 分）

2. Docker-Compose 一鍵啟動事件匯流排

3. Filesystem-MCP 手把手

• 路徑、檔案規則、上傳驗證

4. Email-MCP 手把手

• OAuth 檔、IMAP 指令、附件過濾

5. LLM Service 綁定：OpenAI SDK 一行指令

6. AI 功能演示

• 文件摘要與重點提示
• 風險條款標記與原因說明
• Idea Mining：從簡報找創新概念

7. Chat UI：多來源 Q&A Demo

8. 擴充指引：新增 Calendar / ChatLog MCP

9. RBAC 與敏感遮罩（結尾 10 分答疑）

在企業數位轉型過程中，應用開發面臨三大挑戰：開發資源有限、跨部門協作低效、產品驗證週期過長。為解決此問題，我們提出 AI No-Code Platform，一套結合生成式 AI 與無代碼開發的企業級解決方案，旨在賦能設計師、產品經理與業務人員，快速將構想轉化為可運行的數位服務。

本平台涵蓋五大核心模組：

1. 自然語言生成應用：透過語意解析，將需求自動轉換為前後端應用架構與流程畫面。
2. AI UI/UX 導師：結合 LLM 與設計規範，協助生成設計建議、Figma 原型，提升設計品質。
3. 設計即服務：Figma 介面自動轉譯為標準化前端程式碼與後台串接，實現設計直接落地。
4. 模組化服務市集：內建報名、調查等常見場景模組，可依需求拼裝、擴充，快速實現。
5. 一站式資料後台：完成應用即具備資料儲存與視覺化分析介面，強化數據整合與管理。

平台已導入實際金融專案，將原需 數百小時開發流程壓縮至數小時內完成，顯著提升產品試錯速度與開發敏捷度。透過此平台，企業不僅可降低 IT 壓力，亦實現「開發民主化」，讓非技術部門成為創新主力，開啟企業 AI 應用的全新可能。

聽眾收穫：

隨著生成式 AI 技術日趨成熟，企業在數位轉型與創新實踐上，面臨開發資源緊縮、驗證成本高、跨部門協作困難等挑戰。本研究介紹一套以企業需求為核心、結合 AI 與 No Code 架構的 AI No-Code Platform，旨在賦能設計師、PM 與業務等非工程背景人員，快速從需求構想到應用上線。

該平台整合自然語言處理、智慧介面生成、Figma 畫面生成、自動部署等 AI 能力，具備五大核心功能模組：AI UI/UX 導師、自然語言開發介面、Figma 自動化服務、模組化服務市集、一站式後台整合，有效提升開發效率、降低人力門檻、加速數位服務落地。

初步應用顯示，從設計構想到 MVP 部署，時程可由傳統的 數百小時壓縮至數小時之內，實現真正的開發民主化。該平台已應用於金融產業多項內部專案，並持續拓展跨領域實證場景，驗證其 AI 導入對企業數位創新的實際價值。

一、背景目標

我們是金融業設計團隊，成員包含設計師、前端工程師，主要職責是設計公司所有的內部系統，像人資系統、櫃員系統等，系統數量有數百個。

團隊成立初期，靠著引進外部前端、設計資源，整合成內部系統所需的共用元件套件庫，讓團隊能夠快速應用，起初負責的系統只有十幾個時，這個模式還可以順利運行，但隨著系統的數量以及功能不斷地擴增，發現既有方法已經不合適，於是我們決定從更宏觀的視角，重新建構一套全新企業級的設計系統，支持公司更多樣態的系統與需求。

二、策略藍圖

初期，為了在有限時間內完成更多系統，團隊非常注重設計與前端開發上的效率與可行性，因此利用外部現成套件庫，快速打造出一套簡易設計系統，這個做法雖能確保開發可行，卻相對忽視了部分使用體驗，也忽略了設計系統因應未來變化的擴展性，以至於難以應用至更多系統中。

於是我們重新審視過去的策略，發現需要補足開發可行性以外的不同視角。因此參考IDEO 提出的設計思考驅動創新的模型，三個交集的圓圈：對顧客的吸引力（Desirability）、技術能力的可行性（Feasibility）、可持續的獲利（Viability），此模型強調需同時涵蓋三個要素才能創造出創新且成功的產品或服務。

於是，此次重構我們不單僅從開發者角度考慮開發可行性，也從終端使用者以及公司角度切入，訂定三個具體目標與對應策略。

公司面 ：明確工具佈局，以支持多樣化產品需求

使用者面：定義通用設計準則，以打造流暢高效體驗

開發者面：開發標準化，以開發易維護套件庫

三個策略同時並行，為設計系統打造出穩固的地基，並在這之上逐步建構出一套能夠長期運行、與時俱進的設計系統。

三、策略一：明確工具佈局

為支持更多樣的產品，架構上，採取與過去小型設計系統不同的策略。小型設計系統只需要服務少數系統，因此僅需涵蓋幾種元件，而大型設計系統，需服務更多系統

，不僅要擴增元件，還需考量怎麼讓元件可以被快速組合到多樣功能場景中。

元件就像一塊積木，需不與任何業務綁定，如此才能被彈性運用至各種場景之中。然而，實際開發一套系統，若總是從一小塊零碎的積木開始組合，會讓開發曠日費時沒有效率。因此，我們開始思索，若能想像後續要組合出的系統有什麼樣的樣態，能否在這之前，先發展出一部組合好的積木？也就是設計系統中模組、模板概念。

因此我們開始盤點公司目前與未來會涵蓋的功能場景，歸類出了流程管理類、參數設定、交易操作、分析監控、AI 輔助類等類型，有了清晰的系統樣態，就能開始界定設計系統需要的元件、模組、模板。

為了清楚劃分元件、模組、模板，我們納入業務相依性的概念，越接近功能場景的相依性越高，而元件則是業務相依性最低，而模組、模板則介於這之間，如此區分，設計系統就有了明確的工具佈局。

對公司而言，透過這些工具功能場景能快速被實踐，若有特殊功能也能夠彈性調整；對團隊而言，後續遇到未知的需求，才知道要怎麼調整或擴增設計系統。

四、策略二：定義通用設計準則

為了替使用者創造高效流暢的體驗，首先依據上述提出功能場景類型，歸納出公司系統特性：資訊數據量多、多角色協作、功能流程複雜、領域專業強，並從中總結出下列系統原則：

• 佈局靈活擴展：滿足多樣態場景
• 資訊簡單直觀：減低認知負荷
• 提示指引充足：降低學習門檻
• 結果預期明確：合理直覺使用體驗

有了系統原則，也有了明確工具，那該怎麼運用工具達成目標呢？我們參考了人因工程的認知負荷理論，歸納出設計使用指南。從接收介面，到理解，再到做出反應。我們將其分成三個階段，每個階段都有對應的指標以及方法。

視覺聚焦

空間有效利用

層級主次明確

重點元素強化

資訊有效

內容貼需求

資訊組織合理

用詞實用直觀

操作便利

動線設計流暢

功能區域聚合

操作路徑縮短

上述資訊已經可以幫助設計師組出各式各樣系統，但若專案中沒有設計師協助，就需要更具體的範例，因此團隊也準備了能讓所有人都能輕鬆理解的範例，以實際功能場景為案例，建議使用者該怎麼做，以及不建議怎麼做，幫助公司開發團隊可以更容易取用設計系統資源。

五、策略三：開發標準化

過去開發上沒有統一標準化做法，導致元件庫程式寫法與邏輯上有許多不一至，這使外部單位取用不易，更常發生改 A 元件壞 B 元件的情況，為改善上述情況，需定義出明確規範，並且讓團隊嚴謹執行，以確保在快速迭代的過程中，前端程式品質的穩定。

開發標準化、嚴謹治理執行方法：

開發流程圖：清晰流程節點，明確的任務與目標

元件相依表：梳理元件連動關係

品質控管表：提升程式品質與協作效率

此外，這次重構新增了過去開發完全沒有的概念 ：設計令牌 (Design Token)，目的是為了集中化管理樣式，建立設計通用語言。透過將常用的樣式參數，如顏色、字型、間距等，建立對應的 Token，當設計系統中的各個工具需要樣式參數時，不像過去一樣直接寫參數數值，而是標注 Token，透過此方式，未來若設計系統需要統一調整某種樣式，例如更換顏色主題或是字型大小，就可以透過調整或切換 Token 數值，不用各別去調整每個工具。這個方式能夠以最有效率的模式，控管整個設計系統的參數，是控管設計系統重要的基礎建設。

語意化 Token 優點：

參數集中化管理：將散落的樣式收攏成統一的規範

因應快速變化與發展 ：把未知的需求變成可組合的參數

建立設計通用語言：成爲設計師與前端工程師溝通的橋樑

讓跨系統一至：確保不同系統樣式與體驗的品質

聽眾收穫：

讓聽眾理解設計系統不只是元件的堆疊，而是從實務中不斷演化出的設計思維與具體實踐方法，從目標制定就需考量到多個面向，並且運用多維的策略，才能建構出能持續發展的架構。希望藉由這個分享，能夠幫助正在打造設計系統的團隊，能從我們的經驗中，獲得實用的方法與思考角度。

從 AI 與系統整合設計、AI 工具鏈串接，到 AI 開發工具的實戰應用，本場演講將分享在銀行業內部打造 AI 平台的實務經驗。透過具體案例，我們將探討如何在高度合規與安全要求的金融環境中，引入生成式 AI、模型部署框架與自動化開發流程，讓 AI 能夠真正落地，並融入產品規劃與 DevOps 流程之中。希望能為有志於企業內部推動 AI 工程化的技術人員，帶來可借鏡的實作策略與反思。

聽眾收穫：

希望能透過互相交流一起成長

演講摘要

展示如何運用 n8n 低代碼平台結合 Google Gemini AI，打造一個具備上下文記憶、場景感知的 LINE chatbot。透過Supabase 實現對話歷史管理，讓 AI 能根據使用者所在地點（如 7-11）智能推薦最適合的信用卡，實現真正的個人化金融服務。

技術架構亮點

• n8n 工作流編排**：視覺化設計複雜的對話邏輯
• Gemini AI 整合**：提供智能推薦與自然語言理解
• Supabase 記憶系統**：維持對話上下文與用戶偏好
• LINE Messaging API**：無縫的用戶體驗
• 環境變數管理**：安全的 API 金鑰處理

實戰經驗分享

1. Prompt Engineering 策略：如何設計 30 字內精準回覆的提示詞
2. 對話記憶設計：歷史對話的儲存與檢索最佳化
3. 錯誤處理機制：Webhook 失敗重試與異常狀況處理
4. 效能優化：Wait 節點的使用時機與資料庫查詢優化

聽眾收穫：　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-

技術層面

• 掌握 n8n 在 AI 應用開發中的實際運用技巧
• 學會整合多個 API 服務構建完整的對話系統
• 了解如何設計具備記憶功能的 AI Agent 架構
• 獲得 Prompt Engineering 的實戰經驗

業務價值

• 理解如何將 AI 技術應用於金融服務場景
• 學習低代碼平台在企業數位轉型中的角色
• 掌握個人化推薦系統的設計思維
• 了解對話式 AI 在客戶服務中的應用潛力

開發實務

• 獲得完整的專案架構設計參考
• 學習環境變數與安全性的最佳實踐
• 了解如何處理即時通訊平台的技術挑戰
• 掌握 AI 應用的測試與部署策略

為何現在需要這場演講

隨著生成式 AI 普及，企業急需了解如何快速將 AI 能力整合到現有業務流程中。這個專案展示了：

1. 低門檻 AI 應用開發：無需深度機器學習背景也能構建智能系統
2. 實用的商業場景：金融推薦服務具有廣泛的應用價值
3. 完整的技術棧整合：從前端到後端到 AI 的全棧解決方案
4. 可複製的架構模式：聽眾可直接應用到自己的專案中

這場演講將幫助開發者理解如何在 AI 時代快速構建有價值的應用，實現「Building the Future Together」的大會主題。

傳統 RAG 依賴向量檢索，一旦對話跨越多主題或時間跨度，記憶裂縫難以避免。GraphRAG 透過 Neo4j 或 AWS Neptune 將實體、事件、情緒寫成有向圖，檢索時可根據語意距離與圖拓撲同時過濾資訊。本議程以客戶諮詢為例，演示如何用子圖檢索維持上下文一致性，並對比向量檢索在核心度量（關聯度、人稱一致、背景衝突）上的差異，提供選型與落地參考。

大綱

1. 傳統 RAG 弱點

• 長對話碎片化
• 高維空間距離扭曲

2. GraphRAG 設計要素

• 節點類型：人、事、時、地、情緒
• 邊類型與權重

3. 資料注入管線

• ETL → KG → Index

4. 子圖檢索

• 圖拓撲 + 向量混合查詢
• 新聞級／長篇對話示例

5. Demo：對比場景

• 向量檢索 vs. GraphRAG 返回內容

6. 維運與擴充

• 異動同步、版本控制

7. 選型建議與落地挑戰

聽眾收穫：

• 迅速理解傳統向量檢索的侷限與 GraphRAG 的核心優勢。
• 看到真實對話 Demo，直接比較兩種 RAG 的輸出差異。
• 學會圖資料增量同步與索引優化的關鍵技巧。
• 獲得選型與落地評估清單，幫助團隊判斷何時導入 GraphRAG。

在數位轉型浪潮下，微服務架構成為金融業提升效率、敏捷性與擴展性的關鍵。然而，國泰中台廣泛使用微服務來提升服務敏捷性與效率，但同時也面臨資安漏洞、加密安全與AI模型治理的挑戰。如何有效地管理這些複雜的組成元素，確保系統安全、符合法規，成為當前金融業的重要課題。本次演講將分享國泰中台微服務如何導入SBOM、CBOM與AIBOM這三個關鍵概念。

1. SBOM (軟體組件清單)：掌握微服務中開源或第三方軟體元件，當軟體漏洞發生時，可快速識別並修補。
2. CBOM (加密資產清單)：記錄微服務加密演算法、密鑰管理工具、TLS憑證、簽章方法等資訊，以便應對量子電腦時代潛在的加密風險，並確保符合法規要求。
3. AIBOM (AI資產清單)：呈現AI模型之來源、訓練資料集、權重、算法、模型風險評估、倫理風險等資訊，幫助企業落實 AI治理與責任。

在國泰中台微服務架構下，SBOM、CBOM與AIBOM不再只是技術名詞，而是提升系統安全、強化合規管理、建立客戶信任的關鍵工具。透過導入這三個工具，國泰中台能更有效地掌握微服務的組成，降低潛在風險，並在快速發展的金融科技領域保持競爭優勢。

聽眾收穫：

這場轉變，對我而言，不只是從技術人走向管理者的角色轉換，更是一場針對「組織系統」與「人心動力」的再設計。

我希望帶給聽眾一個核心信念：沒有什麼是不可能的，只是我們經常忽略了除了時間與人力之外的第三種資源——能力資源。

能力不是一個人強就夠，而是要思考如何「適才適所」，建立可持續的制度與培育流程，讓團隊具備完成任務所需的能力。這不僅關乎招募，更關乎養成。你不是在填補職位空缺，而是在打造能力的供應鏈。

在面對挑戰時，我學會跳脫框架去問自己：如果我真的要達成這個目標，我可以做些什麼？我能創造什麼條件？

當然，這一路沒有銀彈，也沒有萬用公式。很多解法都來自「且戰且走」，與當下時空背景交織而成的學習歷程。我的經驗不是標準解，但我誠實分享每一個當下的選擇與試錯，希望在你遇到類似情境時，能成為你值得參考的一份思考資源。

隨著生成式 AI（GenAI）的快速發展，在金融業也開始積極導入GenAI在各個產品與應用，玉山銀行在這部分也積極投入，而在GenAI導入後，其隨後的安全防護與架構也隨之需要建立，涵蓋從地端的個資保護、顧客輸入的Prompt過濾、及雲端LLM模型回覆的保護，並將其模組化建立後讓其各產品可以立即串接與保護。在這場演講中，將分享玉山銀行在導入生成式 AI（GenAI）安全防護的實戰經驗與架構設計思維，內容涵蓋從理論到實作的完整流程，藉此應對在導入 GenAI 技術時，能夠兼顧創新與安全防護。

🛡️ 背景與動機

• 與Google GenAI合作案中，探討其在GenAI可能面臨的攻擊與挑戰。包括 Prompt Injection、資料洩漏、模型濫用、回覆非業務相關等問題，並介紹如何建立一套完整的風險辨識與防護思維。

🛡️ GenAI安全防護SafeGuards 架構設計

• 介紹我們在玉山銀行所設計的 SafeGuards 架構，這是一套針對 GenAI 應用所打造的安全防護機制，涵蓋輸入驗證、回應過濾、角色權限控管、Prompting Protection客製化防禦等模組，確保 AI 回應符合金融業合規與資安要求。

🛡️實戰 Guardrails 攻擊防護實測

• 導入 Guardrails 技術時的實測結果，包含如何模擬攻擊場景、驗證防護效果，以及如何透過策略設定與模型微調，有效阻擋 Prompt Injection、越權存取等攻擊手法。

🛡️第三方檢驗

• 為了確保架構的客觀性與安全性，我們也導入第三方資安檢測機制，包含紅隊演練與模型行為測試，並分享在這些檢驗過程中所獲得的洞察與改進方向。

🛡️成效與未來展望

• 模型優化與穩定性
• 下一階段的防禦功能與服務擴展

這場演講適合對 GenAI 技術導入、資安防護、雲端架構與實務操作有興趣的技術人員、架構師與資安專家。希望透過這次分享，能夠提供大家在導入 GenAI 技術時更全面的安全思維與實戰參考。

聽眾收穫：

當聽眾參與這場演講後，將能夠獲得以下幾項實質收穫：

🔐 建立 GenAI 安全防護的完整觀念

聽眾將深入了解生成式 AI 在企業應用中可能面臨的安全風險，並掌握如何從理論層面建構一套有效的防護思維，為日後導入 GenAI 技術奠定穩固的資安基礎。

🧩 掌握 SafeGuards 架構設計與實作細節        

透過實際案例與架構解析，聽眾將學會如何設計一套可落地的 GenAI 安全防護機制，涵蓋輸入驗證、回應過濾、權限控管等模組，並了解各模組在實務中的應用方式。

🛡️ 交流 Guardrails 攻擊防護

隨著金融科技快速演進，玉山行動銀行、網路銀行系統積極推動容器化架構轉型，以因應業務規模快速擴充的需求。此次分享將聚焦於容器化技術在行網銀系統上的實踐經驗，涵蓋從單體服務架構向微服務架構的演進、容器平台架構設計，以及如何透過自動化部署與彈性擴展機制，有效提升系統的可用性與擴展效率。

報告中將剖析遇到的主要技術挑戰，如滾動式更新、版本管理以及安全合規性問題，並分享團隊在制定設計原則與優化流程上的具體做法。此外，也會探討推動團隊技術能力提升，藉以應對持續快速變化的金融服務需求。

最後，將呈現容器化導入後的效益及未來發展方向，期望對同樣面臨數位轉型與雲端落地挑戰的金融從業者提供實務參考與啟示。

投稿大綱

背景與動機

• 玉山銀行行網銀系統現況
• 容器化轉型的必要性與目標

容器化架構設計

• 容器平台架構

快速擴展實踐

• 彈性資源調度與擴容
• 高可用性設計與監控方案

技術挑戰與解決方案

• 資源限制與相依性管理
• 版本控制與滾動更新機制
• 安全性與合規性考量

團隊管理與協作

• 技術選型與設計規範制定
• 團隊技術能力培育

成效與未來展望

• 容器化導入後的效能提升與穩定性
• 下一階段技術與服務方向

聽眾收穫：

1. 理解容器化架構在金融系統中的實務應用
2. 掌握快速擴展與高可用架構設計要點
3. 學習克服容器化過程中常見技術挑戰
4. 了解未來可能的趨勢及持續優化方向

演講摘要

展示如何運用 n8n 低代碼平台結合 Google Gemini AI，打造一個具備上下文記憶、場景感知的 LINE chatbot。透過Supabase 實現對話歷史管理，讓 AI 能根據使用者所在地點（如 7-11）智能推薦最適合的信用卡，實現真正的個人化金融服務。

技術架構亮點

• n8n 工作流編排**：視覺化設計複雜的對話邏輯
• Gemini AI 整合**：提供智能推薦與自然語言理解
• Supabase 記憶系統**：維持對話上下文與用戶偏好
• LINE Messaging API**：無縫的用戶體驗
• 環境變數管理**：安全的 API 金鑰處理

實戰經驗分享

1. Prompt Engineering 策略：如何設計 30 字內精準回覆的提示詞
2. 對話記憶設計：歷史對話的儲存與檢索最佳化
3. 錯誤處理機制：Webhook 失敗重試與異常狀況處理
4. 效能優化：Wait 節點的使用時機與資料庫查詢優化

本議程將帶您從傳統 VM 架構出發，沿著 OCP（私有雲容器）、GCP（公有雲 Serverless）直到 AI Agent 架構，系統性回顧企業在微服務架構轉型路上的痛點與演進歷程。

內容聚焦於三個核心面向：

1. 架構自由度與顆粒度如何演變（DDD → IAM → MicroAgent）
2. 不同時代的隱藏維運成本與選擇陷阱（VM 成本高、GCP 權限碎片化、AI Agent 的 token 成本）
3. AI 時代的切分新思維：從「功能導向」轉為「任務導向與行為驅動」

本場分享將融合講者在玉山銀行、國泰世華與海外雲原生金融專案中的真實經驗，重現一線架構師在選擇技術與轉型架構時的思辨與抉擇。適合架構師、後端工程師、DevOps 與數位轉型負責人參與。

聽眾收穫：

這場分享將帶你快速掌握微服務從 VM、OCP、GCP 到 AI Agent 架構的演進脈絡，深入剖析每個階段的轉型動因與痛點。從 AIM 三構面（優勢、切分、維運）切入，說明微服務如何從功能導向轉向任務驅動的智能 Agent 架構，並分享企業實戰案例（如金融業導入容器與 AI 技術的經驗）。無論你是正在導入微服務、AI 架構，或關注企業數位轉型的從業者，這場分享將提供清晰的思維框架與實務參考。

銀行導入生成式 AI 需同時滿足客戶體驗、資安與監理要求。本議程拆解 Prompt Injection、幻覺、敏感資料洩漏、計費濫用四大風險，提出「前置語義模式 → 執行期 Policy Engine → 事後 Audit Trail」的三層 Guardrail 架構。進一步分享 Prompt Hardening 範式（含前綴模板、上下文封裝、反射型驗證），並展示如何透過 Rule-based Filter、情緒分析器與行為沙箱，在不改模型權重的前提下，讓合規與體驗兼得。

大綱

1. 金融場景風險地圖

• 監理規範、資安法規、PII 群組

2. Guardrail 三層設計

• 啟動前：語義模式限制
• 執行期：Policy as Code、沙箱
• 事後：可追溯 Audit Trail

3. Prompt Hardening 實務

• System Prompt 前綴
• Context Packer／Delimiter
• Output Self-Check

4. 外部合規系統串接

• DLP、SIEM、IAM

5. 示範流程

• 敏感詞觸發 → 即時遮罩 → 日誌回寫

6. 常見誤區與調整建議

• 「萬用防火牆」迷思
• False Positive / Negative 平衡

7. Roadmap 與組織落地

• 角色分工
• 文化與流程建立

聽眾收穫：

• 取得一份可直接引用的「三層 Guardrail」設計框架圖。
• 學會 Prompt Hardening 三件套：前綴模板、Context Packer、Self-Check。
• 理解如何將 Guardrail 與 DLP／SIEM／IAM 等既有資安系統整合。

對象：後端工程師、技術主管、AI導入評估者

一、開場與轉型背景

今天要分享的是：「AI開發工具實戰與流程改造」，這不是純理論，也不是單一技術，而是從 一個真實後端系統 mySpringbootmall 專案出發，帶大家思考：

我們如何從傳統 Java MVC 系統，導入 AI 模型與智能功能？

工具怎麼選？流程怎麼改？部署怎麼穩？

有哪些坑要避？哪些流程值得複製？

這些問題不是 AI 工程師一個人能解決，而是需要你我這些系統架構設計者與實作者共同參與的流程升級。

二、mySpringbootmall 專案架構回顧

我們以 Spring Boot 建立了 mySpringbootmall 空殼專案，典型分層如下：

controller/

service/

dao/

model/

dto/

rowmapper/

util/

constant/

這是熟悉的 Java 後端開發模式，非常適合構建：

電商平台

訂單系統

資料管理 API

然而，當產品經理說：「我們要做個推薦商品功能」、「我們要加上智慧分類」……該怎麼辦？

答案就是：把 AI 功能以服務的方式導入，不打破原本架構，逐步演進。

三、從傳統架構到 AI 導入

傳統模式：Service → DAO → DB

AI 模式：Service → AI Model → 預測結果 → 回前端或入資料庫

實戰案例：推薦商品功能

我們新增一個 RecommendationServiceImpl，呼叫訓練好的 ONNX 模型：

OrtEnvironment env = OrtEnvironment.getEnvironment();

OrtSession session = env.createSession("recommendation_model.onnx", opts);

OnnxTensor inputTensor = OnnxTensor.createTensor(env, new long[][]{{userId}});

Map<String, OnnxTensor> inputs = Map.of("user_id", inputTensor);

OrtSession.Result results = session.run(inputs);

這樣就可以將模型推論的結果（如推薦商品 ID）傳回給 Controller。 使用的工具鏈：

四、AI 導入流程改造實戰

傳統流程（沒有 AI）：

需求 → Java 開發 → Controller/Service/DAO → 上線 → 回報

導入 AI 後流程（AI 模式）：

需求 → AI 團隊訓練模型（PyTorch） 

→ 匯出 .onnx 

→ Java 團隊整合至 Service 層（ONNX Runtime） 

→ 模型更新也能互替換

實務流程重點：

AI 與後端職責分離（清楚定義資料格式）

模型用 ONNX 載入，不綁定 Python

保持 Controller-Service 結構不變，易維護

可延伸為微服務部署，或支援 A/B 測試

五、流程導入常見錯誤與應對

六、結語與 Q&A

我們今天從一個空的 Spring Boot 專案開始，完整走過了：

如何改造開發流程支援 AI

如何選擇適合的工具（ONNX、ONNX Runtime）

如何讓 Java 工程師與 AI 工程師分工合作

如何保持原有架構清晰可維護

未來的系統不是寫得快，而是寫得能與 AI 共存、能不斷演進。

聽眾收穫：

使技術主管對於使用導入AI模式能有更清楚的概念，後端工程師明白自己的角色應做哪些事情與該如何與AI工程師合作，進而達到專案永續與成功的結果。

一、前言

我們所屬金融產業的的設計團隊，負責金融產業數百套系統的重構與迭代，涵蓋人資、櫃員、授信、交易、審核等上百套系統，且使用者橫跨 20 至 60 歲，來自各單位、職級、角色與業務領域，操作習慣與需求差異極大。

同時，設計需兼顧法遵規範、資安要求與系統穩定性，並與 PM、工程、業務、法遵等多方單位協作，不僅重視單一系統的使用者體驗，也需兼顧跨系統操作的體驗一致性、效能、後續的維運成本、合規性等，在這樣複雜、多變、資源有限的條件下，設計不僅是介面優化，更是一場跨角色、跨領域的整合與溝通實踐。

二、專案溝通與協作五大挑戰

(1) 設計不能犯錯：高壓合規下的微調之道

→在金融產業，設計出錯的代價不只是體驗下降，而是後續的開發調整成本、潛在的資安風險。

(2) 1 個需求，5 種解讀：多部門協作下的翻譯修羅場

→設計師、工程師、PM、業務單位、法遵、稽核等部門各有自己的語言與優先順序，有時甚至是跨部門之間對同一流程圖各持立場，如何主動引導、釐清真實根因，推進專案前進達成共識。

(3) 從混亂到有序：高密度流程的資訊架構與設計實作

→金融系統功能眾多，牽一髮而動全身，不能只靠畫面好看，而要讓資訊分類、流程邏輯一眼就懂。

(4) 改動＝冒犯：設計如何對抗習慣與情緒

→舊系統用了十幾年，從 25 歲的新進人員到 60 歲的資深主管，早就建立起自己的操作慣性。核心目標是站在使用者視角，讓「被動改變」變成「主動信任」。

(5) 在技術舊骨架上：設計如何在限制中保有價值

→面對無法重構的舊系統，只能兼顧技術限制與操作體驗，在每次迭代中多爭取一點「能見度與價值感」。

三、跨域協作 - 七項實戰思維

(1) 在合規中設計體驗

→遵循法規與資安規則，協助流程與介面設計在不違規的情況下，維持清楚、順暢的操作體驗。

(2) 在多方限制中找平衡解

→同時考量使用者需求、技術限制與維運成本，提出實用且具執行力的折衷解法。

(3) 用觀察釐清真實需求

→從使用者行為與語言中辨識痛點，以訪談與測試驗證設計假設，避免只憑直覺推進。

(4) 預設誤解，運用中立引導對齊語意

→多角色協作中，我們預設誤解的存在，因此更需要刻意確認語意交集，當立場分歧時，不偏袒任一方，而是成為拆解語言落差的中立引導者，聚焦問題本質，讓對話持續、專案前行。

(5) 以分類與最大化概念整合複雜流程

→透過分類方式模組化的方式，整合並涵蓋所有流程，在有限資源下有效對齊專案目標與執行步驟，提升協作效率與設計效益。

(6) 讓「進行中」變得可視化

→即便不是最終交付，也用低保真畫面或流程圖協助團隊討論與校準，讓對齊變得具體而可操作。

(7) 即時共享，提升執行效率

→每一次的決策與異動都需即時向所有成員同步，並清楚界定後續行動項目與責任歸屬。同時，所有資料應集中管理、清楚歸檔，放在所有人都能存取的位置，確保資訊一致性與溝通順暢，避免因資訊斷層導致執行偏差或重工。

四、案例分享

我們將介紹 2 個金融產品的專案，來說明如何透過上述的「七項實戰思維」來應對我們所面臨的「五大挑戰」。

聽眾收穫：

在高度講求合規與精準的金融產業中，設計不只是介面優化，更是一場橫跨業務、技術與法遵等多方角色的協作實踐。面對數百套內部系統、需求混亂、資源有限的情境，設計師如何在「資深員工 vs 新進員工」、「流程定義模糊」和「系統架構難動」的限制下推進改版？

本場分享將透過真實案例，揭示多角色溝通背後的誤解與挑戰，並整理七項實務原則，說明我們如何透過觀察、對話與方法，協助團隊釐清問題、推動共識、穩步前行，讓體驗優化真正落地。

目標聽眾：

• 想增加數位產品溝通能力者
• 想了解跨部門溝通者
• 對 UX 在企業中的角色與價值感到好奇者
• 有興趣理解「金融產業系統設計」者