前言：做出來變容易，交出去還是有門檻
最近看 AI 開發工具，我最有感的變化，是把想法做成一個能跑的小工具，已經不再那麼遙遠。
描述需求、讓 AI 產生程式、試用後來回修改，這種 Vibe Coding 的工作方式，我認為可能慢慢變成國民技能。像用 Excel 整理資料一樣，業務做報價工具、老師整理教材、小店老闆管理訂單，都能先解決自己手邊的問題。
但這也讓我反覆想：當大家都能做出程式，工程師的價值會往哪裡移動？以下是我的觀察與判斷；招聘的部分不代表整體市場統計，未來的部分則是推測。
一、招聘需求回溫的感受，伴隨更高的資深門檻
從我近期看到的需求，軟體招聘有回升的跡象，但企業期待的能力也更完整。除了寫功能，還希望工程師懂設計、資料、部署，能處理故障，知道一個決定會帶來什麼維護成本。
我的解讀是：當產出程式碼的成本下降，能判斷問題、整合系統、可靠交付的人，會更受重視。資深的意義，也更接近能處理多少不確定性，而不只是做過幾年。
這跟 Vibe Coding 的普及並不衝突。做小工具的人變多，跟能長期負責產品的人變多，是兩件不同的事。
Demo 到落地，中間還有很多工程
我對某些過度誇大的招生行銷比較保留。「幾週就能獨立接案」「一個人就是一個團隊」，很容易吸引想轉職的人，但如果只展示成功的 Demo，沒有交代後面的責任，期待就容易失真。
| 階段 | 真正開始面對的問題 |
|---|---|
| Demo 能跑 | 在預設流程和範例資料下完成展示 |
| 一個人能用 | 真實資料、錯誤處理、儲存與恢復 |
| 多人正式使用 | 認證、授權、併發、資料隔離 |
| 長期維運 | 監控、備份、升級、事故處理 |
| 團隊協作 | 可讀性、測試、審查、知識交接 |
| 規模化 | 容量、效能、成本與變更管理 |
這些問題不是等 Demo 完成才突然出現。有人要在設計時想到，有人要在上線後持續處理。AI 可以協助每個階段，但採用哪個方案、怎麼驗證，仍需要判斷。
所以「一個人就是一個團隊」有它的前提：那個人已經對產品、開發、部署、維運與資安都有涉獵，也知道何時需要別人的專業。工具放大了能力，沒有自動補齊所有經驗。
我認為這正是系統思維的價值：看得到元件的關係，知道改 A 可能影響 B，也能替接手的人留下理解與修改的空間。
二、產品機會，我更看好貼近使用者現場的應用
當介面與常見功能越來越容易做，只有表單、列表、再包一層 AI 的產品，也更容易出現相似版本。
我更看好的機會，是深入使用者工作現場的應用與客製型產品。價值不只在畫面，而在能不能接上實際流程：
- 理解場景：這個人為什麼在這一步卡住？
- 整合資料：能否接上既有的 POS、會計、LINE 或 Excel？
- 處理例外：退單、缺貨、臨時改價時怎麼辦？
- 持續交付：有人教使用者操作，也有人負責後續維護。
這些能力需要程式，也需要領域理解。競爭者可以模仿畫面，卻不容易同時複製流程知識、資料整合與交付關係。
客製化也有代價。如果每個客戶都分岔出一套程式，升級與修錯就會越來越重。我的做法會是保留共用核心，把欄位、流程規則與報表差異放在較薄的客製層；當相同需求反覆出現，再評估做成共用能力。
AI 能加快客製內容的產出，但哪些差異值得保留、哪些應該標準化，依然是產品與架構的取捨。
三、各行各業可能會需要自己的工程師
我想像未來有更多水果行、旅行社、餐廳，會開始思考自己需要什麼軟體能力。這不是說每家店都要養一個開發團隊，也可能是內部工程師搭配外部協作。以下是說明這個方向的假想場景。
水果行在意的可能是進貨批次、庫存與耗損。知道還有幾箱香蕉不夠，還要知道哪批先賣、何時出清，以及下次採購量要不要減少。
旅行社的痛點可能是行程、報價與客服資料分散。同一個行程會因日期、人數、房型而變價；做計算器之前，工程師得先弄懂成本怎麼組成、哪些規則會改。
餐廳可能需要把訂位、排班與備料接起來。明天有幾桌團體客，會同時影響食材、人力與服務安排，不能只把三張表各自做漂亮。
這些問題未必需要最新的模型，卻很需要有人理解現場。AI 可以協助整理資料、提出方案，工程師仍要跟使用者核對：這是不是實際發生的流程？例外是不是被漏掉了？
對工程師來說，選一個產業深入理解，可能是一條值得走的路。當對話從「要幾個欄位」走到「這個環節到底浪費多少時間」，才比較有機會做出值得付錢的東西。
四、未來加入團隊的，可能是人加上自己的 AI Agent
我有一個猜想：未來每個人可能都會有自己的 AI Agents，累積個人的工作方法、工具用法與可分享的經驗。加入團隊時，也帶進一套能協助執行的能力。
但個人的經驗，跟公司的資料、客戶資訊、商業機密，不能混成一包帶走。要讓這個想像落地，我覺得至少要先回答五件事：
- 權限邊界：Agent 能讀什麼、改什麼？能否單獨撤銷？
- 知識來源：建議依據哪份資料，是否有權使用？
- 可交接：個人離開後，團隊如何接續公司的流程與成果？
- 可追溯：執行了哪些工具、修改哪些資料、由誰核准？
- 責任歸屬：什麼由 Agent 自動做，什麼必須由人確認？
Agent 的價值不只在能做多少事，也在它能否被安全地納入協作。若權限、資料與責任都不清楚，增加的可能是另一個難以管理的系統。
五、開發變容易，平台防守也要跟上
我另一個擔心是：工具降低開發門檻，也可能降低產生掃描與濫用程式的門檻。做平台時，不能再把「目前沒人知道這個網址」當成防護。
尤其是 API key。一把金鑰如果出現在前端程式或公開紀錄，拿到的人可能把它當吃到飽使用，帳單卻算在平台身上。
網路隔離很重要，但要分清楚它處理哪一層問題。Kubernetes NetworkPolicy 控制選定 Pod 的網路流量，依賴支援它的網路外掛。沒有對應實作，建立政策物件也不會產生隔離效果。
Pod 被政策選中，且政策涵蓋某個方向時，該方向會進入隔離；允許流量取適用政策規則的聯集，另有節點等例外。它與主機防火牆是不同層次的防護，不能只裝其中一個就當作完成資安。
網路隔離也不能單獨解決外洩金鑰的濫用。 來源限制可以減少部分風險，但攻擊者若能走允許的路徑，仍需要應用與服務端的控制。
| 防護 | 目的 |
|---|---|
| 最小權限、分服務金鑰 | 縮小外洩後可操作的範圍 |
| Secret 管理 | 避免明文金鑰進入前端、映像與公開版控 |
| 撤銷與輪替 | 發現外洩時能停用，減少長期使用舊憑證 |
| 速率限制、硬性配額 | 在服務確實強制執行的前提下限制消耗 |
| 用量警示與稽核 | 提早發現異常，協助追查與處理 |
| NetworkPolicy、主機防火牆 | 分層限制連線與橫向移動 |
警示負責通知，不會自己停止扣款；配額也要確認是硬性阻擋，還是只有預算提醒。這些細節，才決定事故發生時能不能真的控制損失。
結論：越容易產出，越需要有人負責交付
把這五個觀點放在一起，我看到的是同一個方向：產出程式變便宜之後，判斷問題、理解領域、可靠交付、長期維護與承擔責任，會更顯得重要。
Vibe Coding 讓更多人能動手解決問題，這件事值得期待。工程師則可以把這份效率，拿來走得更深入：理解使用者、看懂系統邊界，讓做出來的東西真的有人敢用，也有人能接手。
會做 Demo 是起點。能讓一個產品長期被使用，才是我想繼續累積的能力。
Comments