Hi~ 我是 Eric。
最近我越來越強烈地感覺到一件事：
AI 開發的核心，不是「讓 AI 幫我多寫一點 Code」。
真正的核心是：
自己要能從模糊需求切出具體的 Spec，再從 Spec 切出最小可行方案，最後拆成能推進進度的 Task。
這句話聽起來很簡單，但它其實正在改變工程師的工作重心。
以前我們常常把「寫 Code」視為開發的主要動作。需求來了，開 IDE，建資料表，寫 API，接前端，測一下，改一下，再繼續往下做。
但 AI 進來之後，事情變得不太一樣。
AI 可以幫我們補樣板、產生函式、建立元件、重構區塊、補測試、整理文件。也就是說，很多原本很吃手速的工作，開始被壓縮了。
可是被壓縮掉的不是工程師的價值。
被放大的，才是工程師真正難的部分：
你到底知不知道要做什麼？
AI 不是讓需求消失，而是讓模糊需求更危險
以前需求模糊時，工程師通常會卡住。
卡住有時候很痛苦，但它也有一個好處：你會很快發現自己不知道怎麼做。
現在不一樣。
你把一句模糊需求丟給 AI，它通常不會卡住。它會很有禮貌、很有自信、很有效率地幫你生出一整包東西。
例如你說：
幫我做一個請假系統。
AI 可能馬上幫你生出資料表、API、前端頁面、權限判斷、表單驗證，甚至連假別選單都幫你補好了。
問題是，這些東西看起來像完成品，但它可能完全沒有回答真正重要的問題：
- 誰可以申請？
- 誰可以審核？
- 審核有幾關？
- 補休、病假、事假、特休的規則一樣嗎？
- 請假是否要擋課務、代課、差勤或薪資？
- 送出後能不能撤回？
- 主管代理人要怎麼處理？
- 舊系統的歷史資料要不要接？
AI 的能力越強，模糊需求就越容易被包裝成「看起來已經完成」的假象。
這就是 AI 開發最容易踩到的坑：我們不是沒有產出，而是產出了很多不一定對的東西。
第一層：從模糊需求切出 Spec
模糊需求通常長這樣：
我們想要一個可以管理校務流程的後台。
這句話不是不能開發，而是它還不能直接開發。
它還需要被切成 Spec。
Spec 不是把需求寫漂亮而已，它的目的，是把「可以自由解釋」的語句，收斂成「可以被驗收」的規格。
我會先問這幾類問題：
1. 使用者是誰
同一個功能，不同角色看到的世界完全不同。
行政人員在意的是資料填寫與流程追蹤；主管在意的是審核與例外處理；系統管理員在意的是權限、稽核與維護；一般使用者在意的是能不能快速完成事情。
如果沒有先定義角色，AI 很容易做出一個「所有人都能用，但沒有人真的好用」的畫面。
2. 成功狀態是什麼
需求不能只寫「可以管理」。
要更具體：
- 使用者可以新增、編輯、查詢與停用資料。
- 主管可以看到待審核清單，並留下核准或退回原因。
- 系統需要記錄每一次狀態變更的時間、操作者與備註。
- 當資料已進入審核流程後，部分欄位不可再修改。
這些句子才會讓 AI 有明確邊界。
3. 不做什麼
這一點很重要。
Spec 不只定義要做什麼，也要定義不做什麼。
例如第一版可以先不做：
- 複雜報表
- 批次匯入
- 多語系
- 舊資料完整搬移
- 行動 App 推播
這些不是永遠不做，而是不要讓第一版被需求膨脹拖垮。
Spec 的價值，就是讓團隊知道現在的戰場在哪裡。
第二層：從 Spec 切出最小可行方案
有了 Spec 之後，下一步不是馬上叫 AI 全部做完。
下一步是切 MVP。
MVP 不是「偷工減料版」，也不是「先做一個醜醜的版本」。
MVP 的重點是：
用最小的範圍，驗證最重要的假設。
假設我們的 Spec 是「建立一個內部簽核流程」。完整版本可能包含表單設計器、多層簽核、代理人、通知、附件、報表、歷史查詢、權限模板。
但 MVP 也許只需要：
- 申請人可以送出一張固定格式表單。
- 主管可以核准或退回。
- 系統會保留狀態歷程。
- 申請人可以查詢目前狀態。
這四件事如果跑得通，就能先驗證流程是否成立。
至於表單設計器、複雜通知、報表統計，都可以後面再切。
很多專案做不完，不是因為工程師不努力，而是因為一開始就把「第一版」切成「理想完整版」。
AI 會讓這件事更嚴重。
因為 AI 很擅長把你的願望清單全部展開，看起來什麼都可以做。這時候工程師更需要踩煞車，問一句：
哪一小塊完成後，真的能讓事情往前走？
這就是 MVP 的判斷。
第三層：從 MVP 切出能推進進度的 Task
MVP 定義完，還不能直接開工。
因為「做 MVP」本身還是太大。
你需要把它切成可以被執行、被檢查、被回報進度的 Task。
一個好的 Task 不只是待辦事項，它應該具備幾個特徵：
- 範圍清楚
- 完成條件清楚
- 可以在合理時間內完成
- 可以被測試或檢查
- 不需要靠大量猜測才能開始
例如不要只寫：
做簽核功能。
可以改成：
- 建立申請單資料模型，包含申請人、狀態、送出時間與目前審核人。
- 建立送出申請 API，送出後狀態為
PendingReview。 - 建立主管審核 API，支援
Approve與Reject，並要求填寫審核備註。 - 建立狀態歷程資料表，記錄每次狀態變更。
- 建立申請人查詢頁面，顯示目前狀態與歷程。
- 補上基本測試，確認送出、核准、退回與歷程寫入都正確。
這樣的 Task，AI 才比較能穩定執行。
更重要的是，人也比較能檢查。
AI 開發不是把任務丟出去就結束，而是要建立一個可以逐步驗收的節奏。
Task 切得越清楚，你越能看出 AI 做對了什麼、漏了什麼、誤解了什麼。
工程師的工作重心正在往上移
所以我覺得，AI 時代的工程師，不是變得比較不重要。
而是工作重心往上移了。
以前你可能花很多時間在：
- 寫重複的 CRUD
- 補 DTO
- 接 API
- 調整畫面
- 寫樣板測試
- 改命名
這些事情還是要做，但 AI 可以分擔越來越多。
於是工程師真正要負責的事情變成：
- 釐清需求
- 定義邊界
- 拆出 Spec
- 決定 MVP
- 切出 Task
- 審查 AI 的產出
- 驗證結果是否符合業務脈絡
這些能力其實比寫 Code 更難。
因為 Code 錯了，編譯器可能會告訴你；測試失敗，也會亮紅燈。
但需求切錯、Spec 寫偏、MVP 抓錯方向，通常要等到開發一大段之後才會爆。
到那時候，AI 幫你寫越快，返工也越快。
我會怎麼跟 AI 合作
如果今天我要做一個新功能，我現在比較常用這種節奏：
Step 1：先讓 AI 幫我整理問題，不急著寫 Code
我會先丟初步想法，請 AI 幫我反問：
我想做一個內部簽核功能。
請先不要寫程式碼。
請幫我整理你需要釐清的需求問題，
並依照角色、流程、資料、權限、例外情境、驗收條件分類。
這一步的目的，是把模糊需求攤開。
Step 2：請 AI 產出 Spec 草稿
等問題回答得差不多，再請 AI 整理：
請根據以上需求，整理成一份 Spec。
內容需要包含：
1. 功能目標
2. 使用者角色
3. 使用者故事
4. 流程規則
5. 資料欄位
6. 權限規則
7. Edge Cases
8. 驗收條件
這一步不是讓 AI 決定規格，而是讓 AI 幫我把規格整理成可審查的形狀。
Step 3：從 Spec 切 MVP
接著我會問：
請根據這份 Spec，幫我切出第一版 MVP。
請明確列出第一版要做、暫時不做、以及延後到第二版的項目。
這一步可以避免第一版膨脹。
Step 4：把 MVP 拆成 Task
最後才是：
請把 MVP 拆成可執行的開發 Task。
每個 Task 需要包含：
- 目的
- 修改範圍
- 完成條件
- 測試或驗收方式
- 可能風險
這時候才適合讓 AI 開始實作。
不是因為 AI 前面不能寫，而是因為前面還沒有足夠清楚的方向。
一個簡單的判斷標準
我現在會用一個很簡單的標準判斷需求是否可以進入開發：
如果我不能把它拆成可以驗收的 Task，就代表 Spec 還不夠清楚。
這個標準很實用。
因為很多時候，我們以為自己懂需求，其實只是懂那句話的表面。
直到要拆 Task，才會發現：
- 權限還沒定義
- 狀態還沒定義
- 例外情境還沒處理
- 資料來源還不確定
- 驗收方式還很模糊
- 第一版範圍其實太大
這些問題不是壞事。
它們越早浮出來，專案越安全。
AI 很適合幫我們把問題浮出來，但前提是我們要把 AI 放在正確的位置上。
它不是需求的主人。
它是協助我們加速整理、推演、實作與驗證的工作夥伴。
Eric 的碎碎唸：寫規格不是變慢，是避免高速撞牆
很多工程師一開始會抗拒寫 Spec，覺得那很像文件工作，離真正開發很遠。
但在 AI 開發裡，我反而覺得寫 Spec 是最接近開發核心的事情。
因為你寫下的每一句規格，都會變成 AI 後面產出程式碼的方向。
你模糊，AI 就發散。
你具體，AI 才能收斂。
所以未來工程師的差距，可能不只在「誰比較會寫程式」，而是在：
- 誰比較會定義問題
- 誰比較會切邊界
- 誰比較會把複雜需求拆成可驗收規格
- 誰比較會把規格切成可以推進的最小方案
- 誰比較會把方案拆成穩定執行的 Task
AI 讓寫 Code 的門檻下降，但沒有讓工程判斷的門檻下降。
反而是把工程判斷放到更前面、更核心的位置。
如果要用一句話總結這篇文章，我會這樣說：
AI 時代的工程師，不只是寫 Code 的人，而是把模糊變清楚、把清楚變可做、把可做變可驗收的人。
這才是 AI 開發真正的核心能力。