讓工程師回歸思考：用 AI 自動化重複性開發工作

AI 不只會寫程式碼，它更適合被當成一個「專門負責重複工作的數位實習生」：你給規則、給範例，它按規則批次產出，工程師退一步變成「設計規則的人」，而不是每天埋在細節裡。 這篇文章不再只列舉 AI 能做什麼，而是從 「工作型態」和「角色分工」 的角度，去想：什麼任務應該交給 AI？
什麼決定一定要保留在人手上？
團隊怎麼重排開發流程，讓 AI 真正變成「工作系統的一部份」，而不是一時興起的玩具？

先看現場：一個被割裂的一天

想像一個後端工程師的一天時間線：

1. 109:30 打開 IDE，準備思考新功能的資料流
2. 209:45 被訊息叫去改一個欄位名稱
3. 310:10 另一個客服回報報表錯字，要改 SQL
4. 410:40 PM 問：「這個 API 多加一個欄位會不會影響前端？」
5. 511:20 新人問：「這個專案通常怎麼寫驗證？」
6. 6下午再加上幾個「幫忙看一下 log」、「這段 code 什麼意思」，一天就結束了。

這些事情重要嗎？重要。但它們有一個共通點：高度重複、規則明確、可被範本化。這正是 AI 最擅長的區域。與其問「AI 能不能取代工程師」，不如問：我們能不能讓 AI 先取代這些「打斷專注、卻又不可不做的例行工作」，讓工程師把整塊的腦力留給真正需要設計與判斷的部分？

把工作分三類：哪一些該交給 AI？

我們先不急著談工具，而是把開發工作分成三種層級：

1.規則型工作（Rule-based）

1. 1Example：CRUD、欄位驗證、DTO 轉換、API 文件樣板、相似報表。
2. 2特徵：步驟可描述、很多次都是「只換欄位名稱」。
3. 3優先交給 AI 自動化，甚至可以做到「一改規則就改一片程式碼」。

2.判斷型工作（Judgement-based）

1. 1Example：架構選擇、安全策略、權限設計、例外情境處理。
2. 2特徵：牽涉風險與責任、需要理解商業背景、未來擴充性。
3. 3AI 只能當顧問，提出選項；最後決策仍然是工程師＋團隊。

3.創造型工作（Creative / Strategic）

1. 1Example：選擇要不要做這個功能、用戶體驗設計、如何拆產品版本。
2. 2這是最該留給人類的部分。

當你開始用這個分類去看待工作時，就會發現：很多工程師今天在做的，都是第 1 類，偶爾才碰到 2、3 類。而 AI 正好可以幫你把第 1 類大量削減。

實際操作：把 AI 當「規則執行機」

以「規則」為中心，而不是以「工具」為中心

錯誤思路是：「我們來試試看某某 AI 工具能做什麼。」比較健康的做法是：

1. 先寫出一份「我們團隊的標準規則」，例如：

1. 1REST API 命名方式
2. 2常用的響應格式（code / message / data）
3. 3錯誤處理統一回傳結構
4. 4欄位驗證規範

2. 接著再把這些規則丟給 AI，讓它在產程式碼時自動套用。

這樣 AI 產出的結果就不是「某個陌生工程師的寫法」，而是「你家規格的自動化版本」。

讓 AI 負責「橫向展開」

舉例：你決定會員多一個新欄位 birthday。

傳統流程：

1. 1DB migration 加欄位
2. 2Model / Entity 更新
3. 3API Request / Response DTO 更新
4. 4後台表單新增欄位
5. 5驗證規則增加
6. 6文件更新

如果每一層都人工改，是典型的重複性開發。導入 AI 後可以改成：

7. 1你只在一個「規格檔」中宣告：新欄位名稱、型別、是否必填、顯示文字等。
8. 2要 AI 根據這份規格：產出／更新上述所有程式碼與文件（或至少提供 patch）。

工程師的工作，從「自己一個一個改」，變成「檢查 AI 展開後有沒有哪一層被漏掉」。

從個人到團隊：三種導入模式

模式 A：工程師個人自救

1. 1適用：公司保守、流程還沒跟上，但你自己想省力。
2. 2作法：自己在本機用 AI 工具（ChatGPT、Copilot 等）、幫忙產程式碼骨架、寫小工具、自動生成文件。
3. 3特色：不改公司流程，但能先幫自己省事。缺點是成果較偏「個人風格」，難以擴散成團隊標準。

模式 B：團隊級樣版化

1. 1適用：小團隊、溝通成本低。
2. 2作法：一起整理出「我們要的 code style + 專案範例」，做成 prompt 範本，大家用同一套跟 AI 溝通。
3. 3系統化整合（長期目標）。

然後再請它「依你使用的測試框架」產出初版測試程式碼，例如：

1. 1適用：公司願意投資，想做成內部平台。
2. 2作法：讓 AI 串進既有的 Scaffold 工具、後端管理系統產碼器、CI 流程。例如：新增一張 DB schema，就自動產 admin 後台、API、文件。
3. 3這時 AI 不再是「旁邊的一個聊天視窗」，而是「開發平台的一部分」。

真實風險：自動化也可能自動放大錯誤

AI 幫你加速的，同時也會把錯誤加速放大。幾個務必要意識到的點：

錯誤樣板被複製到整個系統

1. 1一開始規則沒設好、或範例本身就有問題。
2. 2AI 產出的一整排程式碼都會帶著同樣的 bug 或安全洞。

工程師失去對細節的敏感度

1. 1如果所有細節都丟給 AI，久了有可能變成只會按按鈕、看不出隱藏的風險。
2. 2解法是：讓工程師輪流「人工寫一部分」，保持肌肉記憶。重要模組（登入、金流、權限）要求人工親自實作或詳細 review。

機密資料外洩風險

1. 1把完整 DB schema、客戶資料、金流錯誤 log 全丟到外部雲端 AI，是很危險的。
2. 2保底作法：匿名化、遮蔽敏感資訊、或把 AI 限制在公司私有環境。

最關鍵的轉念：工程師不是被 AI 威脅，而是升級成「流程設計師」

當你開始真正把重複性工作交給 AI，你會發現工程師角色慢慢轉變：從「自己動手寫每一行 code」→ 變成「設計規則、設計範本、設計檢查點的人」。這種轉變會帶來幾個好處：

心理上不再是永遠被需求追著跑，而是有時間想：

1. 1有沒有更好的拆分方式？
2. 2有沒有可以重用的模組？

對公司來說：

1. 1工程師不只是「寫程式的人」，也是「開發流程的設計者」。
2. 2這種人很難被替代，反而會更有話語權。

結語：AI 自動化的真正目的，是把「注意力」還給工程師

我們不是為了炫技才導入 AI，而是為了回答一個很簡單的問題：工程師的注意力，應該花在哪裡？如果你也覺得現在的自己，花太多時間在做機械式修改、回覆重複問題、補一堆樣板，那就可以開始想:

1. 1先列出這一週你做過的工作，畫三欄：規則型／判斷型／創造型。
2. 2然後問自己：哪兩樣「規則型工作」是最適合先交給 AI 的？如果這兩樣工作都被自動化，我多出來的時間，想用來思考什麼？

AI 只是剛好出現，幫你把這一步走得更快一點而已。
👉 https://www.lohaslife.cc/contact/