二月 16, 2026 | 網站建置知識
AI 時代工程師的一天：從 Scrum 到 AI Flow 的工作轉型實錄
前言：工程師的角色正在改變
如果你是一位軟體工程師，你可能已經感受到了——AI 工具正在快速改變我們的工作方式。從 GitHub Copilot 到 Claude、ChatGPT，AI 不再只是一個「有趣的玩具」，而是實實在在的生產力工具。
但問題來了：當 AI 可以幫你寫 code，你一天到底在做什麼？
這篇文章，我用第一人稱視角，帶你走過一個採用「AI Flow」工作模式的工程師的完整一天。你會看到，工程師的價值不但沒有消失，反而因為 AI 的加入而更加清晰。
09:00 — 到公司，打開看板
我坐下來，打開看板。先不急著做事，先看整體狀態。
這是每天最重要的第一步。在 AI Flow 的工作模式裡，看板不只是一個任務清單，它是整個團隊的「即時狀態面板」。我快速掃了三個關鍵欄位：
- 「待我 Review」欄位：昨天下午其他人 Generate 的產出，有 3 個等我 Review
- 「我的 Self Review」欄位：昨天我自己下午 Generate 的 2 個任務，還沒做完 Self Review
- 「Spec Ready」欄位：今天有 4 個新任務已經有 Spec，可以 Generate
我心裡先排一下今天的節奏：先把昨天的尾巴收掉（Self Review），再進入今天的 Sync。
09:10 — Morning Sync（全員 10 分鐘）
站在看板前，不是報告「我昨天做了什麼」，而是看流程哪裡卡住了。
這跟傳統 Scrum 的 Daily Standup 完全不同。我們不再輪流說「昨天做了什麼、今天要做什麼、有什麼 blocker」。取而代之的是：
- PL 宣布今天的 Review 分配：「小王你負責 Review 小李昨天的兩個 Med Risk 產出，小張你 Review 小陳的。」
- PO 說今天下午要驗收什麼：「昨天通過 Review 的那個報表功能，我下午 14:30 驗收。」
- 我確認我的工作：上午 Review 2 個同事的產出 + Generate 1 個新任務。下午第二輪 Generate + 幫忙 Review。
整個 Sync 不到 10 分鐘。重點是確認「誰 Review 誰」和「有沒有東西卡住」。
09:20 — 收昨天的尾巴：Self Review
先把昨天下午自己 Generate 的 2 個產出做完 Self Review，不然它們會卡在那裡佔 WIP（Work In Progress）。
Self Review 的重點不是重新寫一遍 code，而是用 Checklist 快速驗證：
- AI 引用的 library 存在嗎？ ✅
- 邏輯正確嗎？ ✅
- 跟現有架構一致嗎？ ⚠️ 發現命名不一致
命名不一致是小問題——調整 prompt 讓 AI 重新生成那一段，2 分鐘搞定。
通過後，我把任務推到 Risk Gate：表單驗證 → Low Risk（自動化跑）。API endpoint → Med Risk（等同事 Review）。
💡 Self Review 心法：不是隨便看看，但也不用像 Code Review 那麼深。重點是攔截 AI 的明顯錯誤，不要浪費後面 Reviewer 的時間。這個步驟大約花 20-30 分鐘。
09:50 — 寫 Spec：今天最需要腦力的時段
腦袋最清醒的時候，做最需要思考的事。
我今天要為一個「訂單匯出功能」寫 Spec。PO 寫的需求是：「使用者要能匯出訂單為 CSV，可選日期範圍和狀態篩選」。
這句話人讀得懂，但 AI 需要更精確的指令。我的工作是把它轉化為 AI 可執行的技術規格：
- 定義 API endpoint、參數規格、回傳格式
- 釐清邊界條件：空資料怎麼處理？超大量資料怎麼處理？
- 指定架構約束：要用哪些現有的 service 和 pattern
- 標記風險等級：涉及資料庫查詢效能 → Med Risk；若涉及金額計算 → High Risk
- 定義驗收條件：自動測試要覆蓋正常匯出、空結果、超過 10 萬筆的效能、CSV 格式正確性
🧠 關鍵洞察：這才是我真正的核心價值。我不是在寫 code，我是在定義 AI 該做什麼、怎麼做、做到什麼程度算對。Spec 寫得越精確，等一下 AI 產出品質越高，Review 越快過。這個步驟大約花 30-40 分鐘。
10:30 — 第一輪 Generate：操作 AI 生成
Spec 寫完了，現在用 AI 生成。但這不是按一個按鈕然後去泡咖啡。
整個 Generate 流程是這樣的：
- 把 Spec 餵給 AI：把技術規格、架構約束、測試條件一起給 AI，讓它生成完整的實作
- AI 產出第一版 — 快速判斷（30 秒）：掃一眼結構，用的 pattern 對嗎？有沒有奇怪的 import？整體方向對不對？
- 不滿意 → 調整 prompt 重來：「查詢效能不行，請用 cursor-based pagination 而不是 offset」→ AI 重新生成
- 滿意 → 跑自動測試：自動化 pipeline 跑 lint + test + security scan
- 自動測試通過 → 做 Self Review：用 checklist 仔細過一遍
- Self Review 通過 → 推到 Risk Gate
整個過程我跟 AI 來回了 3 次才滿意。不是 AI 不好，是第一次的 Spec 沒有講清楚 pagination 策略。下次我會在 Spec 裡寫更明確——這就是持續改善的循環。
這個步驟含 Self Review 大約花 40-60 分鐘。
11:30 — Review 同事的 AI 產出
Generate 完我的任務，現在換我當 Reviewer。早上 Sync 分配給我 2 個 Med Risk 任務。
Review 的方式是：先看 Spec 了解他要做什麼，再看 AI 產出是否符合 Spec 的要求。
- 第一個：通過 ✅ — Spec 寫得清楚，AI 產出品質高，邏輯正確，架構一致。批准，推進到 PO Review。
- 第二個：有問題 ⚠️ — AI 用了一個不存在的 util function（幻覺）。留 comment 退回，請同事修正後重新 Generate。
⚡ Review AI 產出的關鍵差異：Review AI 產出跟 Review 人寫的 code 不一樣。AI 的 code 表面上看起來都很漂亮，所以更要專注看「邏輯對不對」和「有沒有幻覺」，而不是看 code style。
12:10 — 午餐
收工午餐。上午的成果：完成 1 個 Self Review、寫了 1 個 Spec、Generate 了 1 個任務、Review 了 2 個同事的產出。
自動化 pipeline 在背景跑著。Low Risk 的東西如果自動測試全過，會自動推到 PO Review 隊列。
13:10 — 集中 Review 時段
全團隊同時進入 Review 模式。這是 AI Flow 裡一個很重要的設計——把 Review 集中在固定時段，而不是零散地穿插在一天之中。
- 我繼續 Review 其他同事的產出（還有 1 個 Med Risk 等我看）
- 同事 Review 我上午 Generate 的產出——我坐旁邊等，有問題即時回答
- PL 在旁邊 Review High Risk 的東西（涉及 DB schema 變更，需要深度審核）
集中 Review 的好處是：有問題當面講，不用等非同步 comment 來回。一個 Med Risk Review 從「2 天來回」壓縮到「30 分鐘搞定」。
14:20 — PO 驗收
通過 Review 的產出，PO 來驗收了。我開 staging 環境，照著驗收條件逐項展示。
- PO 確認通過 → Done ✅。卡片移到 Done，從 Spec 到 Done 總共花了不到 24 小時。
- PO 對另一個功能有小調整：「篩選條件能不能加一個日期區間？」→ 不用大改，寫個小 Spec 下午 Generate 就好。
以前 Sprint Review 要準備投影片、安排 Demo 順序。現在就是打開環境直接操作給 PO 看，5 分鐘搞定一個功能。
15:00 — 第二輪 Generate
下午場。處理新任務 + PO 剛才的小調整：
- PO 的小調整：寫 mini Spec（10 分鐘）→ Generate（5 分鐘）→ Self Review（10 分鐘）。Low Risk → 自動化直接跑。
- 新的任務：接下一個 Spec Ready 的任務，重複上午的 Generate 流程
- 修正被退回的產出：如果上午 Review 有東西被退回，下午修正 Spec 重新 Generate
下午的產出會進入隔天的 Review 隊列。所以我要確保 Self Review 做好，不要讓明天的 Reviewer 浪費時間。
17:10 — 收工整理
下班前花 15 分鐘整理：
- 更新看板狀態：確認所有卡片在正確的欄位
- 下午的產出標記好 Review 資訊：讓明天的 Reviewer 知道重點看什麼
- 掃一眼明天的 Spec Ready 隊列：心裡有個底
準時下班。跟以前最大的差別是：不會有「code 寫到一半、明天要記得從哪裡繼續」的壓力。Spec 都寫好了，明天來直接 Generate 就好。
今日成果統計
| 項目 | 數量 |
|---|---|
| Spec 撰寫 | 1 個 |
| AI Generate | 3 個 |
| Review 同事產出 | 3 個 |
| Done（交付完成） | 2 個 |
跟傳統 Scrum 的對比
傳統模式：一個工程師一個 Sprint（2 週）完成 3-5 個 Story。
AI Flow 模式：一個工程師一天 Generate 2-4 個任務 + Review 2-3 個同事的產出，每天都有東西 Done。
差異不只是速度。更關鍵的是工程師角色的本質轉變：
| 面向 | 傳統模式 | AI Flow 模式 |
|---|---|---|
| 核心技能 | 寫 code | 寫 Spec + Review AI 產出 |
| 時間分配 | 80% 寫 code，20% 溝通 | 30% 寫 Spec，30% Review，20% 操作 AI，20% 溝通 |
| 交付節奏 | 2 週一個 Sprint Review | 每天都有 Done |
| 品質把關 | PR Review（非同步，慢） | Risk Gate + 集中 Review（同步，快） |
| 下班心情 | 「code 寫到一半...」 | 「Spec 寫完了，明天來 Generate」 |
結語：你的價值不是寫 Code，是定義問題
很多工程師擔心 AI 會取代自己。但從這一天的實際工作可以看出——AI 取代的是「打字」，不是「思考」。
在 AI Flow 的模式下，工程師的價值體現在：
- 寫出精確的 Spec：你對系統的理解越深，Spec 寫得越好，AI 產出越精準
- 判斷 AI 產出的品質：只有懂技術的人才能辨別 AI 的幻覺和邏輯錯誤
- 設計風險控管機制：什麼該自動化、什麼該人工審核，需要工程判斷力
- 持續改善流程：每次 Generate 的經驗都在優化下一次的 Spec 品質
工程師不會消失。但「只會寫 code 的工程師」可能真的需要轉型了。
你準備好了嗎？
