作者簡介

作者目前擔任凌群電腦資通技術處經理，現專職AI解決方案規劃與領導AI專案開發，並規劃凌群AI開發團隊之研究方向。

API接上就能上線？AI專案最常被誤解的不是技術，而是「時間」

在上一篇專欄中，我們談到Software 1.0與 Software 2.0的本質差異，理解了AI在其本質上的「機率性」後，接下來企業面臨的最大挑戰，往往不在於技術本身，而在於「專案管理」與「團隊預期」的落差。

很多企業主或PM會有這樣的疑問：「現在模型已經這麼強了，API接上去，Key複製貼上後不就結束了嗎？為什麼開發一個AI應用還需要這麼久？為什麼你們不能像以前一樣，提供一個明確的完工日期？」

蓋房子 vs. 研發新藥

為了理解為什麼傳統軟體開發流程在AI專案中經常失靈，我們可以用一個比喻來區分這兩種工作：

• 傳統軟體工程（Software 1.0）就像「蓋房子」：這是一個「確定性」極高的過程，建築師畫好藍圖，計算好結構，工人照圖施工，只要藍圖沒錯、材料沒錯，工法正確，房子一定蓋得起來；進度條是線性的，今天蓋好一樓，明天就能蓋二樓。(單純比喻，勿筆戰)
  
  
• AI應用開發（Software 2.0）就像「研發新藥」： 這是一個「實驗性」極高的過程，我們有一個理論（模型），知道這藥「可能」有效，但仍須經過不斷的臨床試驗（測試與驗證），且無法保證「下週三」一定能發明出解藥，只能保證預期的結果會是如何。

這不僅僅是理論上的比喻，更是已發生的現實，在台灣這環境，大家可能沒注意到，目前各個產業中，受AI衝擊最嚴重的其實正是資訊產業。筆者根據網路上的資料，搜尋自2023年起至 2025 年底，Amazon、Meta、IBM、微軟與 Google等科技巨頭已累計裁員超過 5萬4千名以上之軟體工程師；很特別的是，這些科技巨頭在節省了人力成本之後，卻擴大了人工智慧的投資？甚至在裁員了之後，部份職位也停止了招聘，還宣稱將由AI來取代這些停聘的職位！

為什麼？這並非資訊產業已不再需要軟體工程師，而是不再需要只會「照圖施工」的Software 1.0工程師；筆者認為這除了是給準備準備踏入或者是現役的軟體工程師一個警訊之外，也同時在向所有企業傳達一個訊息：如果你還試圖用舊有的編制、舊有的心態來迎接AI時代，則失敗是必然的。



為什麼「AI應用開發」沒有速成？

在開源社群或雲端模型供應商那裡，我們確實可以輕易「拿來」一個強大的預訓練模型，但這就像是我們從藥廠拿到了一個「廣效型藥錠」，它貌似能治百病，但對於「特殊症狀」（如：企業內部的特定業務場景）可能效果平平，又或者是無用。

要讓這個通用模型在你的企業場景落地，需要的是一個「研究團隊」，這不僅僅是開發團隊如此簡單，因為AI應用的實踐需要解決以下三個非標準化問題：

• 資料的適配性：模型學習到的是網際網路的通用資料，它並不懂每家公司的專業術語、流程或是過去十年的歷史交易紀錄，研究團隊需要像配藥師一樣，透過RAG或Fine-tuning，將企業知識加入模型中，這絕不是寫幾行Code就能完成的，而是需要反覆測試：「餵什麼資料它才聽得懂？」
  
  
• 提示工程的實驗：同一個問題，用不同的問法，AI 給出的答案可能天差地遠，然而這也不是將邏輯寫死就能解決的；團隊需要像科學家一樣設計實驗：設置對照組，測試不同的提示策略，找出最適用於該應用的「咒語」。
  
  
• 評估標準的建立：在傳統軟體中，測試通過就是 Pass，失敗就是 Fail，但在AI中，什麼叫「回答得好」？如同藝術一樣，這些都是一個主觀且模糊的標準；因此研究團隊需要建立一套自動化或半自動化的評估機制去量化AI的表現，才能決定這個版本是否可以上線。
  

從「交付功能」轉向「交付能力」

因此，如果你正準備啟動一個AI專案，請避免「速成主義」，不要預設「接上模型的API就會有奇蹟發生」。

我們需要的團隊成員，不再只是會接 API、寫 SQL 的工程師，需要的是具備「實驗精神」的研究人才，他們需耐心並懂得觀察輸出結果，懂得從AI的錯誤回答中找出規律，並持續優化。

擁有了正確的團隊心態後，下一個問題來了：既然模型是引擎，實驗是過程，那驅動這一切運轉的燃料是什麼？即是「資料」，然而在AI的理解能力中，其實我們企業資料並不如我們想像中那麼「乾淨」；下一期，我們將深入探討AI應用開發背後的隱形功臣：資料工程：AI 模型背後的「技術供應鏈」。