AI 人才陷阱
為什麼在應用程式現代化中，業務情境比編碼更重要
高階主管們面臨著一個持續的悖論：如何在維持所需的快速創新步伐以保持領先的同時，又能確保被全球數千萬人使用的高流量基礎架構的穩定性？這是我過去十多年來一直在應對的挑戰。隨著 AI 應用程式的興起，這種矛盾只會加劇。我在 Caliente.mx 的多項產品與平台中親身經歷了這一切，也讓我清楚看見哪些方法奏效，哪些會在規模化時導致災難性失敗。
當我看到《2026 年 Cloudflare 應用程式創新報告》指出，有 87% 的組織認為其內部人力足以支援 AI 開發時，立刻感到警覺。這樣的信心可能具有誤導性。根據我的經驗，成功導入 AI 取決於團隊的協作方式、他們所帶來的制度知識，以及基礎架構是否支援快速且安全的實驗。這也正是我與 Cloudflare 現場技術長 Trey Guinn 在《超越應用程式堆疊》(Beyond the App Stack) 節目中所探討的主題：AI 的能力遠不止於「有人手」而已。
過去幾年，我看到許多公司在導入 AI 時出現相同模式：技術令人振奮、人才履歷看似亮眼，但結果卻不如預期。這是因為真正阻礙 AI 成功落地的因素，是策略性的，而非技術性的。太多組織把 AI 視為一種二元狀態——要麼「在做 AI」，要麼就落後了。這種壓力往往引發兩種反應：一是雇用不懂業務的 AI 專家，二是在沒有明確目標或採用計畫的情況下，在內部強行推出工具。但這兩種做法都無法長久奏效。
多數公司導入 AI 的方式可分為兩種：一種是將 AI 作為基礎產品，直接內建於服務之中；另一種則是作為最佳化內部工作流程（如人資或財務）的工具集。您可能以為產品優先的做法更為複雜，但我認為在內部引入 AI 的風險更大。正是在這種情況下，工具在未經訓練的情況下被強制使用，期望不一致，團隊開始抵制。這時，採用過程就會停滯。
核心二分法：知識與新技能
若希望 AI 能真正落地生根，領導階層必須重新思考它的導入方式，更重要的是，誰才真正有能力領導這場變革。
當您從零打造一支團隊（就像我在 Caliente 所做的），就能親身體會制度性知識的價值。它並非白紙黑字寫下來的，而是存在於人們所做的取捨、他們一手打造的系統，以及透過實戰累積的直覺判斷中。
在整合 AI 時，這種情境至關重要。外部聘請的人可能帶來專業知識，但如果不瞭解產品歷史或不熟悉架構，進展就會受阻。
提升現有團隊的技能通常是更快的途徑。這些人瞭解應用程式的演進歷程、知道使用者依賴哪些功能、也清楚系統架構中哪些地方具有彈性。當您的架構支援模組化、低風險的實驗時，這些背景知識就會成為競爭優勢，而提升技能自然成為不二之選。
管理對 AI 的抗拒
每當有新工具推出，特別是像 AI 這樣被高度炒作的技術，人們自然而然會擔心：「這會取代我嗎？」當 AI 被包裝成一項獨立計畫，或交由不瞭解日常營運的外部人員主導時，這種恐懼會被放大。要化解這種不安，最好的方式是讓對話聚焦在真實問題上。在 Caliente，我們從痛點切入，找出拖慢我們速度或增加摩擦的東西，然後才問：AI 能幫助我們解決這個問題嗎？
如果答案是肯定的，那麼重點就變成了增強。我們不說「自動化 QA」，而是說「AI 輔助測試」；我們不把新專案描述為「打造 AI 應用程式」，而是談如何延伸既有的應用程式，讓它們更快、更聰明、更有用，但不破壞原本運作良好的部分。我們強化程式碼審查流程，給工程師多一雙眼睛協助審查，讓他們能專注在更高價值的工作上。
創新的必要性：缺乏彈性的代價
如果您想要利用既有的團隊進行建置，那麼您的基礎架構就必須支援這樣的選擇。在每一場關於 AI 的討論中，人們總會在某個時候忽略最基本的重點：AI 不是靠熱情或野心運作的，而是靠基礎架構支撐。
如果您仍在使用僵固的內部部署系統，即使是最好的點子，也會因為延遲、相容性問題或採購流程而陷入困境。我親身經歷過——試圖改造舊有技術堆疊來執行 GPU 密集型工作負載，不但痛苦，而且昂貴。在還沒開始實驗前，就得忙於應付硬體修復、驅動程式更新和作業系統修補程式。
人們常常忽略的是，應用程式現代化是採用 AI 的先決條件。您的基礎架構越靈活，嘗試新事物的成本就越低。您的環境建置得越快，您就能越快瞭解什麼有效、什麼無效。特別是無伺服器架構，讓我們無需前期投入就能測試多種設定；只需執行實驗、獲取資料，就能往前邁進。
這種敏捷性也會在日後帶來回報。這個領域的硬體和軟體進展迅速。如果您在內部維護一切，就會陷入不斷的升級循環。有了無伺服器或雲端原生平台，我們就能跟上這種發展步伐，而無需為了保持更新而耗費時間或預算。
對我們有效的做法是，為 AI 試驗建立一個結構化的沙箱。這意味著清楚地將實驗性工作與正式環境發布分離，為假設驗證設定較短的時間限制，並在擴大規模之前明確定義什麼樣才算「足夠好」。
我堅持的一些原則：
將實驗與核心產品隔離，避免影響正式服務
為測試週期設定時間限制，避免無限拖延
安排 AI 專案負責人與產品負責人搭配合作，確保每個想法都對應到實際的應用程式影響
AI 不是孤立的；它必須存在於您已維護的系統之中。如果操作得當，AI 實驗會加速應用程式創新，而不是拖慢創新速度。您將獲得更智慧的的功能、更好的自動化以及反應更靈敏的產品，同時不危及穩定性。
導入 AI 的三項基礎架構必要條件
我發現，要讓 AI 從應用程式開發中的試點階段走向實際應用，有三個不可或缺的前提：
可擴展的運算。概念驗證可在低功率機器上執行，但正式工作負載不行。具備可擴展的基礎架構是關鍵，尤其針對 GPU 工作負載而言更是如此。
強大的監控。AI 一旦上線，就需要完整的可見度與掌控力。包括追蹤模型漂移、偵測異常狀況，以及在潛在問題惡化前及時介入。
做到這三點，實驗才有機會持續推進。AI 是一種能力，而不是單一產品。就我自身角色所見，這整段旅程的成功關鍵，往往取決於有紀律的實驗、明確的內部教育，以及重視透明、不盲從炒作的文化。
但基礎架構本身並不能推動進步。您的團隊也需要做好準備。
真正準備好迎接 AI 的三個跡象
當我思考一個工程團隊是否已準備好在應用程式創新中擴展其 AI 應用時，我會關注以下三點：
開放的對話：如果團隊能輕鬆分享成功與失敗，並誠實地討論什麼有效、什麼無效，這就是一個好跡象。
基本瞭解：他們不一定要是專家，但至少應理解大型語言模型 (LLM) 的基本運作原理、諸如參數量與詞元等術語，以及 AI 幻覺產生的原因。這代表他們具備好奇心與深入理解意願。
邊界意識：他們清楚哪些資料可安全分享、哪些內容可重複利用，也明白法律與道德上的界線在哪。
這些不只是加分條件，而是衡量您的團隊是否已準備好建立並維持真正由 AI 驅動的應用程式創新的重要指標。
別再「為了錘子找釘子」
我在眾多團隊中觀察到的一個常見陷阱，是「解決方案優先」的心態：高層對某項 AI 工具感到興奮，便要求團隊反向推敲一個使用案例來合理化這 項投資。但以工具為起點，往往導致人們去解決根本不存在的問題，或是對業務沒有實質影響的問題。真正的進步始於解決一個真實且影響深遠的問題，並以此為依據來判斷 AI 是否應該被納入解決方案。這樣，您才能目標明確地推進工作；清楚地進行測試、學習和調整，因為您的目標很明確。
接下來，關鍵在於快速迭代，尤其是當您將 AI 引入實際應用程式時。定義一個具體的應用場景，在正式環境之外進行測試，衡量其影響，收集回饋，然後調整。如果有效，就擴大規模。如果無效，您仍然學到了寶貴的經驗，而不會過度投入資源或開發出沒有人需要的技術。
設定行為準則，而非技術障礙
限制面向公眾的 AI 工具，或許能降低短期風險，但同時也扼殺了學習空間。更好的做法是強化團隊本來就應遵循的行為準則。例如，開發人員早已習慣在程式碼中遮蓋敏感資訊；同樣的原則也應套用在 AI 審查流程中。但光靠政策無法推動進展，真正的動能來自一套技術與文化並行的系統，能支援安全實驗，同時不拖慢交付速度。
這一切都從應用程式現代化開始。正確的架構賦予團隊實驗的空間、解決真實問題的能力，以及快速行動的自由。《2026 年 Cloudflare 應用程式創新報告》印證了我在實踐中觀察到的現象：當您的系統準備就緒 時，最明智的 AI 投資就是您現有的團隊。
利用 Cloudflare 加速現代化
隨著應用程式現代化成為一項持續策略，而非一次性計畫，技術領導者需要一個能幫助團隊加快速度，同時又不損害控制力或安全性的平台。Cloudflare 的全球連通雲支援您應用程式旅程的每個階段——從重新託管舊式系統、為提升敏捷性而遷移平台，到建置全新的應用程式和 AI 服務。憑藉在統一、可程式化的平台上整合應用程式交付、安全性、可觀測性與開發工具，Cloudflare 可幫助團隊降低複雜度、加速交付，並在不增加成本的情況下釋放創新能量。
Cloudflare 就影響當今技術決策者的最新趨勢和主題發表了一系列文章，本文為其中之一。
深入探討這個主題。
閱讀《2026 年 Cloudflare 應用程式創新報告》，深入瞭解現代基礎架構如何推動 AI 成功。
作者
Lior Gross
Caliente Interactive 技術長
重點
閱讀本文後，您將能夠瞭解：
為 AI 應用程式選擇現有團隊還是新聘人員
利用 AI 實驗推動應用程式創新
業務知識在 AI 應用程式成功中的作用