前陣子，我們替一位客戶完成了一套企業系統。
這不是拿來參加比賽的概念作品，也不是為了展示技術而做的 Demo，而是一套準備真正進入企業現場、承接日常工作與營運流程的系統。
從一開始的需求訪談、使用者角色、操作流程，到後面的資料結構、權限設計、系統架構與第三方服務整合，我們和客戶來回討論了很多次。畫面上看起來只是一個按鈕，背後可能牽涉不同部門、不同狀態與不同責任；使用者看見的是一張報表，我們必須先確認每一個數字從哪裡來、什麼時間計算，以及發生異常時該相信哪一份資料。
系統完成後，客戶邀請他的客戶一起觀看。
展示過程很順利。操作直覺、流程清楚，該出現的資訊都出現在適當的位置。就在大家看完時，其中一位第一次接觸這套系統的人，看著畫面，很自然地說了一句：
「喔，這很像 AI 做的。」
那句話的語氣，不太像稱讚。
它比較像是在說：現在 AI 幾下就能做出系統，這個東西似乎也沒有想像中困難。
如果是幾年前，我可能會立刻解釋：這不是隨便產生的，我們做了多少需求分析、寫了多少程式、花了多少時間測試。但那一刻，我沒有急著反駁。
因為某種程度上，他說對了一半。
我們確實使用 AI，而且每天都在用
SourceKode 並不排斥 AI。相反地，我們大量使用 AI。
AI 可以協助整理訪談內容、分析需求缺口、產生部分程式碼、補齊測試案例、檢查潛在錯誤、撰寫技術文件，也能在除錯時幫助工程師快速縮小問題範圍。
過去需要工程師花數小時處理的重複工作，現在可能在幾分鐘內完成。以前必須先搜尋大量文件、比對不同寫法，現在 AI 能先整理出方向，再由工程師驗證。
既然有工具可以提升效率、降低重複勞動，甚至減少部分人為疏漏，我們沒有理由不用。
所以，當有人問：「你們的系統是不是有用 AI？」我們的答案很直接：
有，而且我們希望比一般團隊用得更好。
但「有使用 AI」和「把整套企業系統交給 AI 自己決定」，是兩件完全不同的事情。
就像建築師會使用電腦繪圖，醫師會使用影像分析，會計師會使用財務軟體。工具提升了工作效率，卻沒有取代專業人員對結果的判斷與責任。
真正該問的不是「有沒有用 AI」，而是：
AI 參與了哪些工作？最終又是誰在為系統的結果負責？
AI 讓「做出來」變簡單，但企業要的不是做出來而已
現在，只要給 AI 一段清楚的描述，就可能快速產生登入頁、會員列表、訂單管理、儀表板、聊天室，甚至是一個看起來相當完整的後台。
這是技術進步，而且是一件好事。
更多人能把想法做成原型，創業者不必一開始就投入龐大成本，內部團隊也能更快驗證流程。以前需要數週才能看到的畫面，現在可能一天內就能操作。
因此，今天有人看到一套系統後覺得「這個 AI 也能做」，並不奇怪。
如果判斷標準只是：
- 頁面是否打得開；
- 按鈕是否能按；
- 資料是否能新增、修改、刪除；
- 報表是否能顯示；
- 畫面是否像一套完整產品。
那麼 AI 確實可以完成很大一部分。
但這些只能證明「功能被做出來」，不能證明「企業可以放心使用」。
一套展示系統，通常只需要走過預期中的正確流程；一套正式企業系統，必須處理的是現實世界裡所有不照劇本發生的事情。
真正困難的，通常都藏在畫面後面
客戶看到的是一個「送出訂單」按鈕。
開發團隊必須思考的是：使用者連按兩次會不會產生兩張訂單？網路中斷後重新送出，會不會重複扣款？資料已經寫入一半時伺服器突然失敗，系統要如何復原？
客戶看到的是「付款成功」。
我們必須處理的是：金流公司回覆成功，但系統尚未建立訂單時怎麼辦？回傳通知延遲了十分鐘，要以哪一個狀態為準？使用者關掉頁面後，系統如何主動確認最終交易結果？
客戶看到的是「會員點數增加 100 點」。
我們必須確認：同一筆消費是否可能被重複計點？退款後點數如何扣回？點數已被使用，但原訂單後來取消，帳務與會員權益要如何平衡？
客戶看到的是「不同員工看到不同功能」。
我們必須設計：店員、主管、總公司、財務與系統管理員各自能看什麼、能改什麼；權限變更何時生效；員工離職後如何立即停權；敏感操作是否留下稽核紀錄。
這些內容不會讓介面看起來更華麗，甚至使用者永遠不會注意到。
但一套系統能不能真正投入營運，關鍵往往就在這些看不見的地方。
星期六晚上七點，沒有人在乎程式是誰寫的
想像一個實際情境。
星期六晚上七點，餐廳客滿，門口還有十幾組客人在等位。櫃檯正在結帳，廚房持續出餐，外送平台不斷進單，會員系統正在累積點數，信用卡、行動支付與現金交易同時發生。
突然，收銀人員發現一位客人的信用卡已經扣款成功，但 POS 裡沒有訂單；廚房也沒有收到餐點內容。客人拿著銀行通知說自己已經付款，現場人員卻不知道該不該重新建立訂單、能不能再次刷卡，以及原本那筆交易最後會不會又出現。
這時候，企業老闆不會問：
- 這段程式是工程師手寫的嗎？
- 有沒有使用 ChatGPT？
- 是 Claude 還是其他 AI 產生的？
- 這個畫面用了哪一套前端框架？
他只會問一句：
「現在怎麼辦？」
而專業開發公司的價值，就出現在這一刻。
系統是否能辨識這筆交易的唯一編號？是否能主動向金流查詢最終狀態？重送訂單時是否會避免重複扣款？現場人員是否有清楚的異常處理流程？管理者能否從後台查看完整紀錄？工程團隊是否能透過監控立即找到問題？
這些不是多寫幾行程式就自然具備的能力，而是需求理解、流程設計、架構經驗、例外處理與營運思維共同形成的結果。
企業真正害怕的不是 Bug，而是無法掌控的風險
任何系統都可能出現 Bug。成熟團隊和不成熟團隊的差異，不是前者永遠不出錯，而是前者會預先設計如何降低錯誤發生的機率，並在錯誤發生後限制影響範圍、快速找到原因、恢復服務。
企業真正擔心的，通常是以下問題：
- 系統出錯時，有沒有人第一時間知道？
- 錯誤影響一筆資料，還是會擴散到全部客戶？
- 資料能不能回復到正確狀態？
- 服務中斷後，多久可以恢復營運？
- 問題修正後，是否能避免再次發生？
- 公司成長後，原本的架構是否需要全部重做？
例如會員點數因為錯誤規則而多發了一百萬點。真正的問題不只是「把 Bug 修掉」，而是要知道哪些會員受到影響、哪些點數已經被使用、哪些交易需要回滾，以及如何避免傷害正常會員的權益。
又例如系統更新後，部分門市無法登入。專業團隊不只要修復新版本，還必須具備版本回退、分階段部署、監控告警與緊急處理能力，讓企業不必等工程師慢慢研究完，才有辦法繼續營業。
AI 可以協助分析錯誤，也能提供修正建議，但它不會替企業承擔停業、客訴、資料損失與品牌信任受損的後果。
企業系統的價值，來自一連串看似保守的決定
很多專業工作，在結果正常時看起來都很簡單。
一座橋每天都能通行，人們不會特別注意結構計算；一家餐廳每天都能順利結帳，使用者也不會知道系統避免了多少次重複交易。
企業系統也是如此。
真正專業的設計，常常體現在一連串不顯眼的決定裡：
- 資料表如何設計，避免未來擴充時互相牽制；
- 交易如何保持一致，不會只成功一半；
- 重要操作如何留下紀錄，發生問題時能追查；
- 第三方服務失敗時，系統如何降級而不是全面停止；
- 備份是否真的能還原，而不只是「有設定備份」；
- 敏感資料如何加密、遮蔽與限制存取；
- 不同環境如何隔離，避免測試資料污染正式營運；
- 系統如何監控，讓團隊在客戶回報前先發現異常。
這些工作不容易放進一張漂亮的展示圖片裡，也很難讓第一次看到系統的人立即感受到。
可是企業願意付費委託專業團隊，往往就是因為這些事情。
我們賣的不是程式碼，而是理解企業之後做出的判斷
很多人把開發公司理解成「把需求寫成程式的人」。
但如果客戶說什麼，團隊就直接照著做什麼，那只是代工，不是真正的系統顧問與開發夥伴。
企業提出的需求，常常是表面解法，而不一定是真正問題。
客戶可能說：「我要增加一個匯出 Excel 的按鈕。」深入了解後，真正問題也許是主管每天無法掌握跨門市數據；最好的解法可能不是再多一份 Excel，而是建立即時儀表板、統一資料定義，並讓異常數字能被追蹤。
客戶可能說：「我要做一個 App。」但進一步分析後，真正需要的也許是一套整合會員、訂單、通知與內部流程的系統，而 App 只是最後一個使用入口。
客戶可能說：「這個功能照競爭對手做就好。」但不同公司的組織、流程、權限與商業模式不同，直接複製介面，往往會把別人的解法硬套到自己的問題上。
SourceKode 的價值，不只是把規格轉成程式碼，而是在開發前先協助釐清：
- 這個需求真正想解決什麼？
- 哪些角色會使用？
- 資料從哪裡來，又會流向哪裡？
- 例外狀況發生時，誰有權做決定？
- 未來公司成長後，這套設計是否仍然適用？
- 哪些功能現在不應該做，以免增加不必要的成本？
AI 可以提供很多答案，但前提是有人能提出正確問題，並判斷答案是否適合這家企業。
AI 不會讓專業開發公司消失，只會重新定義它的價值
AI 一定會淘汰部分過去仰賴重複工作而存在的開發模式。
只會照規格建立基本頁面、只會重複撰寫相似程式、只把交付程式碼當作專案完成的團隊，未來確實會面臨更大的壓力。
因為這些工作，AI 會做得越來越快，也越來越便宜。
但這不代表企業不再需要開發公司。
恰恰相反，當產生程式碼變得容易，企業會更難判斷哪些系統只是看起來能用，哪些系統真的能承擔營運。
因此，未來真正有價值的團隊，必須具備更完整的能力：
- 理解商業模式與實際營運流程；
- 把模糊需求轉化為可執行的系統設計；
- 規劃資料架構、權限與系統整合；
- 預測異常情境並設計復原機制；
- 控制技術債與長期維護成本；
- 在企業成長時持續調整系統；
- 出現問題時願意面對並處理，而不是把責任推給工具。
AI 會讓程式碼的生產成本下降，但也會讓經驗、判斷與責任變得更珍貴。
未來最昂貴的，不是程式碼，而是企業願意把營運交給你的信任。
我們不否認 AI，而是要比任何人更懂得駕馭 AI
面對「這很像 AI 做的」這句話，最沒有意義的反應，是急著證明每一行程式都是人手寫的。
手寫不等於品質，使用 AI 也不等於粗糙。
真正該被檢驗的是：
- 這套系統有沒有解決企業問題？
- 流程是否符合實際營運？
- 資料與權限是否安全？
- 發生異常時是否能處理？
- 系統能否持續維護與擴充？
- 交付之後，是否有人願意長期負責？
我們使用 AI，不是為了把專案更草率地做完，而是為了把重複工作更快完成，將更多時間投入那些真正需要理解、判斷與溝通的地方。
AI 幫助工程師快速建立基礎，我們就能花更多時間檢查架構；AI 協助補齊測試，我們就能投入更多精力模擬營運例外；AI 幫忙整理需求，我們就能更早發現部門之間的認知差異。
工具應該放大專業，而不是取代專業。
回到那一句：「喔，這很像 AI 做的。」
現在回想起來，我其實很感謝那位客戶的客戶。
因為他說出了未來很多企業都會有的疑問：既然 AI 已經可以做系統，為什麼還需要花錢找開發公司？
我們的答案不是「AI 做不到」。
AI 當然做得到很多事情，而且它的能力還會繼續快速成長。
我們的答案是：
企業需要的從來不只是能產生程式碼的工具，而是能理解營運、管理風險、整合流程，並對最終結果負責的合作夥伴。
一套系統真正的價值，不是在展示當下看起來有多少功能，而是在三個月後、一年後、五年後，企業仍然可以依靠它運作。
當公司增加新部門、新門市、新品牌或新的商業模式時，系統能不能繼續成長；當金流、物流、會員或其他服務發生異常時，系統能不能維持核心營運；當真的發生問題時，有沒有人知道該從哪裡找原因，並把事情處理完。
這些，才是 SourceKode 希望交付的內容。
SourceKode 想成為的，不是替你寫程式的人
我們不希望只在客戶提出功能時出現，也不希望交付後就結束關係。
我們想做的是，先理解企業現在如何運作、未來想走向哪裡，再建立真正適合的系統。
有時候結果是一套管理後台，有時候是一個單一內部系統，有時候需要整合既有 ERP、POS、會員、金流或第三方服務，也可能最終透過網站或雙平台 App 呈現。
載體不是最重要的。
最重要的是整套系統能不能讓企業減少重複工作、降低錯誤、掌握資料、提升效率，並為未來的 AI 應用保留可整合的基礎。
我們會使用 AI 加速開發，但不會用「AI 做的」當成品質的藉口。
我們會利用現成技術降低成本，但不會把不適合的模板硬套進企業流程。
我們會追求交付速度，但不會為了畫面快速完成，就忽略資料、安全、權限與維運。
因為對企業而言，系統不是一個作品。
它是每天正在運轉的生意。
結語：AI 可以把系統做得更快，專業讓企業敢一直用下去
AI 正在重寫軟體開發的規則。
未來，會寫程式的人會更多，做出原型的速度會更快，系統的表面功能也會越來越容易被複製。
但企業不會因此不需要專業。
相反地，當所有人都能快速做出看起來相似的系統，真正的差異會回到更根本的地方：
誰真正理解企業？
誰能預見風險？
誰能設計長期可維護的架構？
誰能在出問題時處理到底？
誰願意和企業一起面對未來的變化？
所以，下一次有人再說：「這很像 AI 做的。」
我們不需要急著否認。
我們可以很坦然地回答：
「沒錯，我們確實使用 AI。因為我們希望把系統做得更快、更完整。但真正讓這套系統可以投入企業營運的，不是 AI 本身，而是我們對流程、架構、風險與責任的理解。」
AI 可以幫助我們完成更多程式碼。
SourceKode 的工作，是讓企業放心把生意交給這套系統。