從擺盤的人，變成開火的人：一個前端工程師的爐臺練習

2026 年 10 月 3 日，掘金上出現了一篇將近半小時才能讀完的長文。作者「花旗蛻變」是個前端工程師，團隊後端只有兩個人，日常忙不過來，他決定從自己熟悉的表單頁面出發，用 NestJS 加上 AI 的輔助，把一個業務從需求一路做到可運行的系統，前端後端一手包。

這件事擺在廚房裡看，其實很好懂。過去他像個負責擺盤的人：菜端上來，他講究盤子怎麼擺、醬汁怎麼拉線、客人第一眼看到什麼。直到有一天他發現，會擺盤的人越來越多，甚至機器都學會了；真正稀缺的，是那個能為整桌菜負責的人。食材放在哪、什麼時候下鍋、火候出錯了誰來救，這些才是桌子的骨幹。

從最熟悉的那道菜開始練

他沒有一頭栽進陌生的領域。起點是一個表單專案 mjoptim-form：後臺配置表單、H5 頁面填寫提交、付費、資料管理與核銷。動態欄位、連動規則、校驗提示、檔案上傳，這些都是前端天天摸的活，像一個洗碗洗了三年的人，對水槽邊的一切瞭若指掌。

但把這條線往後延伸，就自然撞上了爐臺。表單填完送出去，資料存去哪？金額從哪裡算？有人不經過頁面直接構造請求塞資料進來怎麼辦？這就像你一直以為自己會做菜，直到第一次要自己開大火、自己顧一鍋高湯，才發現備料臺上學到的本事，只回答了問題的一半。

專案分三個應用：admin 管理後臺、web 的 H5 頁面、server 的 NestJS 後端。前端照舊用 Vue 3，管理端 Element Plus，H5 用 Vant；後端是 NestJS、Prisma 和 PostgreSQL。等於同一個人，備料臺和爐臺都站了。

文中一個很有意思的部分，是作者自己整理的「翻譯表」：前端的舊經驗，對應到後端的新概念。TypeScript 的型別宣告，對上後端執行時的資料校驗；頁面的模組拆分，對上 Module、Controller、Service 的職責區分；前端路由和按鈕權限控制，對上服務端的 Guard 與 JWT。

這張表讀起來，像一個會用瓦斯爐的人第一次學炭火。爐具有得比，手感要重學。型別宣告得再漂亮，也擋不住網路上飛來的髒請求，就像菜刀磨得再利，也得有人守著砧板確認進來的魚是新鮮的。瀏覽器裡的權限控制，說到底像把辣椒罐收到小孩搆不到的櫃子上；服務端的驗證才是鎖上廚房的門。

這種從舊手感長新本事的過程，其實和被臨時換了一把鍋鏟做菜的滋味很像：工具換了，火候的道理還在身上。

文章反覆強調一件事：怎麼判斷 AI 生成的程式碼是否滿足業務要求。這是整篇分享裡最誠實的一段。AI 能很快炒出一盤看起來有模有樣的菜，但鹹淡合不合這家店的口味、客人會不會過敏、成本算不算得過來，仍然要那個對整桌菜負責的人來把關。

作者也說明，文中的程式碼經過節選和簡化，省略了日誌、配置與部分業務分支，重點在思路。這種交代方式很像食譜上寫「鹽適量」：不是藏步，而是每家的爐火不同，照抄沒有意義，你得自己站到鍋前。

文章的最後沒有英雄式的結語。它就是一個工程師把自己從表單頁面走到後端系統的過程攤開，給同樣想嘗試的人一張參考地圖。

放在餐桌上想，這件事的滋味是這樣的：一個家裡，總不能永遠只有人擺桌、有人洗碗，卻沒人敢開火。當煮的人手忙不過來，那個最熟悉這桌人口味的人願意走進廚房，從自己最有把握的那道菜練起，配菜讓機器切，鹽自己放。第一頓飯也許普通，但爐子從此是熱的。

想跟著做的人，可以照他的路徑：挑一個你最熟的業務，前端往後延伸，讓舊經驗替你翻譯新概念。剩下的，就是站上爐臺那一刻的事了。