AI 加快開發之後，為什麼服務交付反而更重要？

過去兩年，我大部分的程式碼都是和 AI 協作完成的。從想法、原型到功能上線，所需時間比過去縮短很多。這對開發者當然是好事，不過我也逐漸注意到另一個現象：團隊出貨更快，不代表客戶會因此留下來。

原因並不複雜。開發完成只代表功能可以運作；客戶實際使用的是一整項服務。系統是否穩定、發生問題時能否及時得到處理、資料是否受到保護，以及操作過程是否順暢，都會影響客戶是否繼續使用。

AI 降低了部分開發工作的時間與成本，但服務交付的責任並沒有因此消失。

開發速度只是服務能力的一部分

過去，軟體開發需要較長的時間，也需要更多專業人力。能不能把功能做出來，本身就是一道門檻。生成式 AI 與開發工具成熟後，原型、常見功能與部分維護工作都能更快完成。

這不代表功能從此不重要，也不代表開發成本會降到零。比較準確的說法是：當不同團隊都能更快做出功能，市場評估產品的標準就不會只停留在功能清單。可靠性、支援能力與整體體驗，會更直接地影響客戶的判斷。

我自己的工作重心也跟著改變。AI 減少了部分實作時間後，我反而花更多時間檢查功能上線後的完整旅程：誰負責維運、失敗時怎麼處理、客戶如何求助，以及問題是否會進入後續改善。

用 Utility、Warranty 與 Experience 檢查服務

ITIL 4 提供了兩個很實用的概念：Utility 與 Warranty。

Utility 指服務是否符合使用目的，也就是能否滿足需要、解決問題。
Warranty 指服務是否適合實際使用，包括雙方約定的可用性、容量、連續性與資安等條件。

ITIL 4 的 Drive Stakeholder Value（DSV）則把 customer experience 與 user experience 放進服務關係與價值共創的脈絡。嚴格來說，Experience 不是和 Utility、Warranty 並列的官方「三要素」。不過在實務檢查時，我會把它們放在一起看：功能是否有用、服務是否可靠，以及使用者實際經歷了什麼。

AI 可以協助處理 Utility，例如產生程式、補齊功能或加快整合，也可以支援部分 Warranty 與 Experience 工作，例如事件分流、紀錄摘要與客服輔助。但以下問題仍要由組織先做出明確設計：

半夜服務中斷時，誰負責接手？
發生資料外洩後，第一個小時要通知誰、執行哪些處置？
客戶被自動化流程卡住時，如何轉給可以真正處理問題的人？
服務水準沒有達標時，由誰負責追蹤與改善？

AI 可以執行部分工作，卻不能替組織決定責任歸屬，也不能自行承諾服務水準。

技術逐漸普及後，差異會往體驗與營運移動

這個觀察和 Yu-kai Chou 提出的 Digital Convergence Model 相互呼應。模型討論的是技術、行為與商業模式逐漸交會後，企業如何建立差異。

當團隊使用的模型、框架與開發工具越來越接近，技術能力仍是基礎，但單靠技術不一定能形成長期差異。在 SaaS 與 B2C 產品上，我看到的情況很一致：功能往往決定客戶願不願意試用，實際體驗與交付品質則影響他是否持續使用。

這也是我後來投入 ITIL 4 的原因。我需要的不是更多描述功能的方法，而是一套能把開發、維運、支援、供應商、服務水準與持續改善連在一起的管理語言。

服務管理實際處理哪些問題

「服務管理」聽起來容易讓人聯想到文件與流程，但它真正處理的都是具體問題：

事件發生後，正確的人多久能接手？ 只有告警沒有分工，事件仍然不會被處理。
同一個問題是否反覆發生？ 每次重開機只能恢復服務，不能取代根因分析與後續改善。
SLA 是否真的被管理？ 服務水準不是簽約後存檔的數字，而是需要持續量測、回報與處理落差的承諾。
客戶旅程上的重要接觸點是否有人負責？ 如果自助流程失敗後沒有人接手，再好的前端功能也無法補救。

AI 可以幫忙分流、摘要、預測與自動化，讓這些工作更有效率。不過責任人、升級路徑、服務承諾與改善節奏，還是要由組織建立。

審查 AI 功能時，先問三個問題

下次審查 AI 功能，不妨先從以下三個問題開始：

功能失敗或判斷錯誤時，誰負責接手？
對客戶承諾的服務水準，要用什麼資料量測？
客戶在自動化流程中卡住時，如何帶著完整脈絡轉給真人？

如果這三個問題還沒有答案，即使功能已經能夠上線，服務交付仍然沒有準備完成。

我取得 ITIL 4 Master 的經過，另外整理在〈從工程師到 ITIL 4 Master：AI 時代，我為什麼開始學服務管理〉。對我而言，AI 並沒有降低服務管理的重要性；它只是讓功能更快進入真實環境，也讓原本容易被開發進度掩蓋的營運問題更早出現。

ITIL 4 × AI 實戰系列

這三篇文章分別從學習路徑、AI 開發下的服務交付，以及考試準備，整理我把 ITIL 4 帶回工作與學習現場的方法。

第 1 篇：從工程師到 ITIL 4 Master：AI 時代，我為什麼開始學服務管理
完整認證路線，以及工程師在 AI 時代補上服務管理能力的原因。
第 2 篇：AI 加快開發之後，為什麼服務交付反而更重要？（本文）
AI 讓功能開發變快之後，價值、可靠性與支援流程為什麼更重要。
第 3 篇：ITIL 4 考試準備：我怎麼用 AI 檢討錯題、完成六個進階模組
用 AI 檢討練習題、建立錯題系統，並在第一次正式考試通過六個進階模組。

資料來源與版本說明

關於作者｜About KJ Huang

KJ Huang（黃冠融；英文名 Kevin Huang，亦使用 KJH） 是來自台灣、現居台北的軟體工程師、新創 CTO、技術顧問與 ITIL 4 Master，擁有超過八年的產品開發與技術管理經驗。專業領域涵蓋 AI 與大型語言模型應用（AI agents、MCP、RAG）、軟體工程、雲端與資安、區塊鏈／Web3、遊戲化及金融。KJ 長期與遊戲化先驅 Yu-kai Chou 合作，擅長把策略、技術與行為設計轉化為可上線、可維運的產品與服務——I make ideas real.

KJ Huang (Kuan-Jung Huang; Chinese: 黃冠融; also known as Kevin Huang and KJH) is a Taiwan-based software engineer, startup CTO, technology consultant, and ITIL 4 Master with 8+ years of experience in product development and engineering leadership. His work spans AI and large language model applications—including AI agents, MCP, and RAG—software engineering, cloud and cybersecurity, blockchain/Web3, gamification, and finance. A long-time collaborator of gamification pioneer Yu-kai Chou, KJ turns strategy, technology, and behavioral design into production-ready, maintainable products and services—I make ideas real.