常被問到的問題
那我自己叫 AI 做就好了？
小工具或原型很適合用 AI 自己做；若系統會直接服務客戶或影響營運，還要處理需求、權限、部署、監控與維護。
前提
AI 真的會寫程式
AI 可以協助製作表單、資料整理程式或 API 串接，我在開發工作中也會使用。
真正需要評估的是：怎麼驗證結果、怎麼上線，以及發生異常時由誰處理。
差別一
需求不只是一句功能描述
以 LINE AI 客服為例，「可以回答問題」只是其中一部分。
開始製作前，至少要先確認以下事項：
- 知識庫從哪來？誰維護？價格改了誰去改？
- 答不出來的時候要怎麼辦？硬答、說不知道、還是轉真人？轉給誰？
- 要不要記住上一句？記多久？隔天客人再來，算同一段對話嗎？
- 同時十個人在問，狀態會不會互相蓋掉？
- 對話要不要留紀錄？留多久？誰能看？客人的個資怎麼處理？
- 模型呼叫要花錢，用量爆掉的時候誰擋？上限設多少？
- 客人傳一張你根本沒賣的東西的照片，機器人該說什麼？
AI 可以協助列出與實作這些項目，但答案仍取決於你的業務流程、風險承受程度與維護方式。
差別二
上線前容易漏掉的問題
以下幾項不一定出現在主要功能中，卻會直接影響系統是否穩定。
- Webhook 可能逾時或重送若收到訊息後才開始耗時處理，平台可能判定失敗並再次傳送。流程需要快速回應，並避免同一事件被重複處理。
- 模型輸出格式不一定固定即使提示詞相同，回傳內容仍可能缺少欄位或格式錯誤，因此要驗證、重試並準備備援處理。
- API 金鑰不能放在前端前端程式會被使用者下載，放在其中的金鑰可能遭到取用，造成資料或費用風險。
- 連續訊息可能同時處理多個程序同時更新同一段對話時，可能互相覆蓋狀態，需要排序、鎖定或去重。
- 第三方服務會調整規格API、權限或回傳格式變更後，既有串接可能需要更新，因此要保留錯誤紀錄與通知機制。
- 資料結構需要預留變更方式新增欄位或調整流程時，既有資料可能需要轉換；設計階段應先決定版本與遷移方式。
這些問題都能處理，重點是上線前納入設計，並在發生時留下足以判斷原因的紀錄。
差別三
程式碼只是其中一塊
程式完成後，仍要準備執行環境與日常維護方式。
部署與網域
程式要放在哪台主機、怎麼上去、憑證怎麼弄、掛掉會不會自己重啟。
金鑰與權限
各種服務的金鑰放哪、誰能看、外洩了怎麼換。
資料庫
資料如何保存、多久備份一次，以及是否定期測試還原。
監控
系統壞了誰知道、怎麼知道、去哪看紀錄查原因。
成本控制
模型、主機與第三方服務如何計費，哪些項目需要設定預算或用量上限。
交接文件
記錄系統架構、設定位置與操作方式，讓日後接手的人能繼續維護。
差別四
維護責任要先確認
系統可能遇到連線失敗、服務改版、用量增加或資料異常。無論自行製作或委託開發，都應先決定誰負責接收通知、排查與修復。
自己製作的優點是成本低、修改自由，但也需要自行保留版本、設定與處理紀錄，否則隔一段時間後很難回想當初的設計。
委託開發時則要確認合約是否包含保固或持續維護；只有明確約定責任範圍，問題發生時才知道由誰處理。
所以
什麼情況下你真的該自己做
不是每件事都該外包。
- 只有你自己使用的小工具例如整理檔案、執行一次性統計或製作試算表；即使失敗也容易重新執行。
- 目的是學習願意花時間測試、查資料並自行維護，製作過程本身就是收穫。
- 仍在驗證需求不確定流程是否會長期使用時，可先製作簡單原型，確認確實有用再投入正式開發。
適合找人協助的情況：系統會直接提供給客戶使用、故障會影響營運、需要處理敏感資料，或預計長期增加功能。這些需求除了開發，也要一併規劃測試、權限與維護。
ALL PROJECTS · 04
實際做過的系統
從客戶正式營運專案、需求原型到自有產品，查看我如何把 AI 協作轉成能使用與維護的成果。