vibe coding：現場人員用聊天把系統做出來
從『日本工廠用 Claude 邊聊天邊寫系統』談起：vibe coding 讓需求能直接被翻譯成可運行的原型，但真正決勝點在資料、權限、可追溯性與測試，否則很快變成新型態的 shadow IT。
我最近看到一段很短、但很有代表性的貼文：「日本工廠開始用 Claude 寫系統了。很多人原本不懂技術，現在可以邊聊天邊寫程式。」作者把這種做法稱作 vibe coding。
這個描述其實很精準：它不是在講某個新框架，而是在講一種新的「進入軟體開發」的方式。
Vibe coding 的本質：把需求翻譯成本來就會說的話
傳統的軟體開發流程，第一關就把很多人擋在門外：
- 你要會寫規格
- 你要會拆需求
- 你要理解資料結構、例外處理、狀態管理
- 你要知道怎麼跟工程師溝通，才能把需求落地
vibe coding 把這一整串門檻，先用自然語言「橋接」過去。
你不用先把自己訓練成工程師，你可以先把你在現場看到的問題講清楚：
- 哪個步驟最常出錯
- 哪個表單最常填錯
- 哪個資料要從哪裡來
- 哪個規則要怎麼算
模型會把這些話翻成一版可運行的程式雛形，甚至直接幫你把 UI、資料庫、API 的骨架先搭出來。
這就是為什麼「不懂技術的人也能開始寫系統」會變成可行。
為什麼日本工廠這個場景特別容易成立
我覺得「工廠」是 vibe coding 很容易先爆發的地方，原因很務實：
- 流程清楚、規則多、但變動有限：很多需求是既定 SOP 的數位化
- 痛點貼近現場：最知道問題的人，常常不是資訊部門，而是線上主管、品管、維修
- 小系統的 ROI 很直接：少打一張紙、少跑一趟、少對一次帳，就能立刻省時間
在這種環境裡，能把「需求」直接交給工具的人，常常比會寫漂亮架構的人更快創造價值。
但 vibe coding 最容易踩雷的點也在這裡
當你用聊天的方式寫系統，你得到的往往是「看起來能跑」的第一版。
真正的風險通常出現在第二週、第二個月：
- 例外狀況開始累積（特殊單、退料、重工、跨班）
- 權限與稽核需求上來（誰改過數字、誰核可、如何追溯）
- 跟既有系統要串接（MES/ERP/Excel/手工台帳）
如果你把 vibe coding 當成「不用工程能力也能長期維運」，很容易變成一個新型態的 shadow IT。
所以我更傾向把它定位成：加速原型與自動化的方式，而不是把工程治理整段刪掉。
我會怎麼把 vibe coding 變成可擴張的做法
如果你真的想在企業內把這件事推起來，我會把它做成一個「可治理的工作流」：
- 先定義能做的範圍：例如內部表單、報表、簡單規則引擎、自動通知；避免一開始就碰核心生產系統
- 把資料源與權限先卡住：系統最常出事的不是 UI，而是資料與權限
- 強制留下需求與變更紀錄：每次改規則、改欄位都要可追溯，否則現場會陷入「到底誰改的」
- 把測試變成流程的一部分：至少要有幾個關鍵流程的檢核案例，讓模型每次改完都跑一遍
這樣你就能保留 vibe coding 的速度，同時避免它變成後續維運的債。
最後一個觀察：未來的「懂技術」會長得不一樣
很多人把 vibe coding 理解成「人人都能寫程式」。
我覺得更精準的說法是：人人都更接近系統設計者。
你不一定需要寫出最優雅的程式碼，但你必須能把現場的規則講清楚、把資料邏輯講清楚、把例外情境講清楚。
當這三件事講得清楚，工具會幫你把程式碼補齊；講不清楚，再強的模型也只是在幫你把模糊放大。
