從寫前端到打造 AI 工作流：我在公司角色的轉變
很多人以為工程師的工作，就是寫功能、修 bug、把需求做完。
我以前也這樣想。
剛進公司時，我的工作重心很明確：把前端畫面做好、把遊戲功能接起來、把需求如期完成。
但做久了之後，我慢慢發現，真正影響團隊效率的，往往不是某一個功能寫得夠不夠快，而是：
- 很多事情其實一直在重複做
- 很多溝通可以被結構化
- 很多提案其實可以被半自動生成
- 很多原本靠經驗的流程，其實可以整理成工具
而這幾年對我影響最大的，不只是技術本身，而是 AI 工具開始能真正進入工作流程。
我在公司的角色，也因此慢慢改變。
從一開始單純負責前端功能實作，到後來開始設計工具、整理流程，再到現在會主動思考：
- 哪些工作可以被 AI 輔助？
- 哪些流程可以被標準化？
- 哪些產出可以被穩定生成？
這篇文章想記錄的，就是這個轉變過程。
第一階段：功能開發者
一開始，我的角色很典型。
日常工作包括：
- 實作前端頁面
- 開發遊戲介面
- 串接 API
- 修正 bug
- 配合 PM 與設計稿完成需求
這個階段最重要的能力，是交付能力。
你要能把需求落地，能把畫面做出來，能處理實作細節，能在既有架構中穩定開發。
對前端工程師來說，這是很扎實也很必要的訓練。
但這個時期，我思考的事情多半還是：
- 這個元件怎麼切
- 這個效果怎麼做
- 這個狀態怎麼管理
- 這個 bug 出在哪裡
重點還是放在「把東西做出來」。
這沒有錯，只是影響範圍通常還停留在單一功能或單一頁面。
第二階段：開始不只寫功能，而是解決流程問題
當你開始接觸更多專案、更多合作角色之後，就會慢慢看到另一層問題。
你會發現，很多時間其實不是花在寫功能，而是花在這些事情上：
- 一直重複整理需求
- 一直重複產出提案初稿
- 一直重複對齊設計方向
- 一直重複修改命名、文案、格式
- 一直重複處理規格不完整造成的來回溝通
這時候我開始意識到：
如果我只是把功能做完，那我解決的只是表面問題。
但如果我能把這些重複流程工具化，我解決的是整個團隊的效率問題。
也就是從「任務執行者」，慢慢變成「問題解決者」。
而 AI，正是在這個階段，開始真正進入我的工作方法裡。
第三階段：把 AI 當成工作流的一部分
很多人談 AI，會停留在「拿來問問題」或「偶爾幫忙寫文案」。
但對我來說，AI 真正有價值的地方，是它能不能進入一條穩定的工作流。
也就是說，不是今天靈感來了才用一下，而是：
- 能不能讓需求輸入更簡化
- 能不能讓中間轉換更標準化
- 能不能讓輸出更穩定
- 能不能讓別人也能複製這套流程
我後來開始做的事情，就是把這些看起來很零碎的工作，整理成可以反覆使用的 AI 流程。
我實際做過的一個例子：提案生成器
這是我自己很有感的一個 AI 應用。
在遊戲或視覺提案的工作中，最常見的問題不是「沒有工具」，而是：
需求很模糊，但又希望輸出穩定。
例如有時候收到的需求可能只有一句話：
- 做一個未來科技感的 Plinko
- 想要北歐神話風格的 crash 遊戲
- 來一個少女偶像舞台感的 slot 提案
- 做一版比較金屬、比較暗黑、但不要太寫實
如果直接拿這種一句話去丟給模型，結果通常很不穩定。
因為同一句描述，可能每次生成的構圖、風格、UI 完整度、主題一致性都差很多。
所以我做的不是直接生成圖，而是先拆成幾層：
第一步：一句話需求輸入
先保留最自然的需求方式，讓輸入門檻很低。
例如：
未來科技感的 Plinko，畫面要乾淨，帶一點高級感
第二步：轉成結構化描述
把一句話需求轉成比較穩定的提案結構，例如：
- game type
- 主題設定
- 視覺關鍵字
- 色彩方向
- 材質描述
- UI 風格
- 禁止出現的元素
- 參考構圖原則
這一步很重要，因為它不是單純潤稿，而是把模糊需求轉成模型更容易理解的輸入格式。
第三步：自動組 prompt
當結構化資訊完成後，再由系統去組合成 prompt。
例如會自動補上這些內容：
- 風格描述
- 介面完整度要求
- 構圖限制
- 元件一致性要求
- 視角要求
- 不需要的元素
- 負面 prompt
這樣做的好處是，輸出的品質不再完全依賴當下怎麼寫 prompt，
而是把經驗轉成模板，讓生成品質更可控。
第四步：穩定生成提案圖
最後才進到圖像生成。
這時候 AI 圖像模型做的事情，不是「自由發揮」，而是根據已經被整理過的結構去產出結果。
因此整體穩定性會高很多。
這個流程最大的價值不是「省下一次畫圖時間」，而是：
- 降低提案前期的不確定性
- 提高產出的一致性
- 讓提案更容易快速迭代
- 讓團隊成員更容易共用同一套邏輯
我學到的關鍵：AI 最有用的不是生成，而是轉換
很多人會把 AI 的價值理解成「幫我直接產出結果」。
但我越做越覺得，AI 真正最有價值的地方，常常不是最後那一步生成，而是中間那一步「轉換」。
例如：
- 把一句模糊需求，轉成可執行規格
- 把零散想法，轉成完整 prompt
- 把設計方向，轉成固定模板
- 把經驗判斷，轉成可重複使用的規則
這種轉換層一旦建立起來，後面不管接的是圖像模型、文案模型，還是其他工具，整體品質都會更穩。
所以我後來做 AI 相關的東西，重點通常都不是「直接叫模型幫我做」，而是：
先把輸入整理好，再讓模型去做它擅長的事。
不只提案圖，AI 也開始進入其他實作流程
提案生成器只是其中一個例子。
後來我也越來越常把 AI 用在其他工作場景中，例如：
1. 規格草稿生成
有些需求在一開始只是一段口語描述。
這時候 AI 很適合先協助整理成規格草稿，例如：
- 功能目標
- 使用情境
- 流程拆解
- 欄位定義
- 邊界情況
- 驗收方向
這不代表 AI 取代規格，而是幫我更快建立第一版骨架。
2. 遊戲主題提案整理
以前做遊戲主題發想，常常會卡在「有方向但講不清楚」。
現在我會先把題材、氛圍、美術風格拆成幾個欄位，讓 AI 協助整理成一致格式，方便快速比較不同方案。
例如同樣是 slot 主題，可以很快整理出：
- 題材世界觀
- 主色方向
- 材質語言
- 情緒氛圍
- UI 關鍵詞
- 可延伸的 bonus 演出感
這樣在提案時，就不會只是憑感覺講，而是能更具體對焦。
3. 文案與命名初稿生成
像是活動名稱、功能名稱、說明文案、遊戲標題方向，AI 都很適合先跑一輪初稿。
尤其當需求量大、需要多版本比較時，速度差異非常明顯。
4. 開發輔助與程式草稿
在開發上，AI 也很適合協助：
- 快速產生 prototype
- 協助整理重構方向
- 產生工具腳本初版
- 幫忙補齊重複性高的程式碼
- 協助把口語需求翻成程式邏輯
但我自己的使用方式通常不是直接全收，而是把它當成「加速器」，再由自己做最後判斷。
角色真正的改變：從把事情做完，到設計事情怎麼被做完
回頭看，我覺得我在公司角色最大的轉變，不只是技術能力變多，而是思考方式改變了。
以前我的重點是：
- 這件事怎麼做完
後來慢慢變成：
- 這件事能不能做得更快
- 這件事能不能少重複一次
- 這件事能不能交給工具處理
- 這件事能不能整理成別人也能用的流程
而當 AI 進來之後，這個思考又更進一步。
我開始思考的是：
- 哪些輸入可以標準化
- 哪些產出可以模版化
- 哪些步驟可以自動轉換
- 哪些經驗可以被沉澱成系統
這讓我的角色從單純的前端開發者，慢慢變成一個更偏向：
流程設計者、工具建構者、AI 工作流實作者。
工程師的價值，不只是寫程式，而是放大產出能力
我現在越來越相信，工程師真正的價值不只是寫出功能，而是放大整體產出能力。
有時候你寫一個功能，幫到的是一個頁面。
但你整理出一套工具，幫到的可能是一整個團隊。
你建立一套 AI 工作流，改善的可能不只是速度，而是整個提案、溝通、產出的品質。
所以如果要我重新定義這幾年的角色轉變，我會這樣說：
- 一開始，我在做功能
- 後來，我在解決問題
- 現在，我更常在設計流程，讓問題不要一直重複出現
而 AI，正是讓這件事變得更有可能的一個關鍵工具。
結語
我以前以為工程師成長，就是技術越來越熟、功能越寫越快。
但現在我更覺得，真正的成長，是你開始不只看「怎麼做」，而是看「怎麼讓這件事被更好地完成」。
從前端開發，到流程優化，到 AI 工作流設計，
這一路的變化，其實不是突然升級，而是慢慢累積出來的。
你會開始發現，自己不再只是接需求的人，
而是開始主動思考：
- 這個流程是不是能更順
- 這個需求是不是能更清楚
- 這個產出是不是能更穩定
- 這件事是不是能被工具化、標準化、複製化
對我來說，這就是我在公司角色轉變最明顯的地方。
不只是把東西做出來，
而是開始打造一套能持續產生結果的方法。
