❯❯ 打字的產能可以被複製，判斷的責任沒有人接！Human-in-the-Loop 的三大邊界：定目標、看風險、做取捨

📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（整條線上的那個人）

走到 Day 26，回頭看這套 Pipeline 裡的 AI 覆蓋率：轉譯規格、生成型別、建立 mock、撰寫測試、建構 UI、修正程式碼直至測試通過，甚至補齊 vibe 測試。基本上，「撰寫程式碼」這個動作，絕大部分早已自動化。

這帶來一個最根本的問題：

如果 AI 能夠承擔絕大多數的執行工作，工程師的不可替代性到底在哪？

把我們手上記錄的工作攤開看，工程師的角色並沒有消失，而是集體往開發流程的最上游移動。這些工作全壓在自動化工具永遠跨不過去的三個維度上：

第一件，定目標：商業脈絡與業務邏輯

Day 07 提到的兒童椅規則就是個典型範例：「一桌十位，兒童椅額外加位、不佔正常席」。這條業務規則不會出現在任何通用 API 套件或 open source 文件裡，它是特定情境下的實務習慣。就算 AI 的訓練資料看過幾千種座位系統，也不可能憑空猜出這項特定需求。規格如果不寫清楚，AI 是無法生出對應的邏輯。

實務上很多團隊導入 AI 踩坑，缺的從來不是資料，而是脈絡。在個人專案中更是如此：AI 執行力極強，但它永遠無法自己判定「這個系統到底要解決誰的什麼問題」。這些業務脈絡，終究得由人來定義。

第二件，看風險：邊界條件與責任歸屬

Day 15 檢討的三個案例揭露了自動化測試的盲點：當測試全數通過時，系統顯示正常，但實際環境仍可能存在隱患 -- 系統永遠不需要為運作失敗承擔責任。

不管是 R2 Path 沒測全、多租戶架構下的越權漏洞，還是 CI 流程漏跑檢查等問題，這類「測試綠燈範圍之外的風險」，AI 一概不會主動提醒你。這並不是模型不夠聰明，而是風險評估與後果承擔本來就屬於開發者的責任範疇。

所以，整體系統的安全性健檢、授權模型的梳理，以及版本變更對生產環境影響的推演，都得由工程師主導。AI 可以協助執行細節的清查，但「檢查範疇與項目」必須由人來指定。先前發現的越權問題，正是由人工發起系統性健檢並劃定檢查範圍後，才由工具協助排查出來的。

第三件，做取捨：資源限制與架構抉擇

接待台即時性需求的技術選型，是一次很典型的 Trade-off（取捨）案例。
為了呈現最新的報到狀態，技術上有兩條路：採用 SSE（Server-Sent Events）即時推送，或是採用五秒一次的輪詢（Polling）機制。SSE 在技術架構上看起來更現代，AI 也做得出來；在此前的運動科技影像專案中，某個模組便採用了 SSE 架構；婚禮專案接待台的輪詢程式碼註解中，也曾留有正式版要改用 SSE／WebSocket 的待辦標記。

但最後我的決策是：不採用 SSE，維持 5 秒輪詢，並把那條 // TODO 標籤連同 Issue #77 一起 Close 掉。

把影響因素攤開，每一點都在勸退：

1. 架構限制：
部署平台是 Serverless，原生有效支援長時間連線，強行導入只會變成昂貴的偽輪詢。

2. 維護成本：
資料庫若要支援推播，得額外掛載 Pub/Sub 服務，維護成本上升，還增加了系統依賴。

3. 真實場景：
單場婚禮現場頂多只有 1 到 3 台接待裝置，5 秒 Polling 對伺服器負擔極低，對賓客更完全無感。

我把這個評估脈絡記錄在 issue 裡，是為了防止未來重蹈覆轍，或是把「有意識的取捨」誤當成技術債。未執行不等於技術債，這兩者有本質上的不同，若未留下紀錄，後續維護時容易產生混淆。將此評估邏輯延伸至產品維度，便形成了產品化分層 roadmap（issue #36）：將各項功能的開發決策綁定於明確的業務訊號，並不是抽象的規格想像。

同樣的 SSE 技術，在運動科技影像專案是核心，在婚禮系統則是過度設計。技術本身沒有絕對優劣，價值全由場景決定，而場景的衡量只能靠工程師。

「技術可行」不等於「架構值得」。工具擅長處理可行的實現路徑，但「值不值得」卻需要綜合考量資源、場景與優先順序，這些因素超出了自動化工具的評估範疇。

確定 Human-in-the-Loop 的定位

在 Day 17 中，我曾把工程師角色比喻為監工，在旁邊盯著測試指標的修復進度。但更精準地說，我們可以參考「可信的資料、專家的腦、智慧的手」這三層架構：AI 承擔了手與部分執行層面的功能，但整體架構的方向與邊界仍需由人來掌控。

這也解開了 Day 02 與 Day 20 關於「Human-in-the-Loop 確認點該擺哪」的爭議。有些框架將確認點設置於每個頁面開發完成時，頻繁的打斷大幅降低了開發效率；而在這套流水線中，直接把確認點從「寫 Code」這一層拉掉，完全收斂到最上游的三個核心節點：

1. 定目標： 在規格定案時確認。
2. 看風險： 在劃定門禁閘門與安全性健檢時確認。
3. 做取捨： 在架構抉擇與 issue 拍板時確認。

工程師真的沒必要跟工具搶著寫 Code，應該是要把手伸進自動化做不了決策的地方。

流水線自動化的極致，並沒有取代工程師，反而將工程師從「程式碼撰寫者」轉變為「架構與業務判斷者」。當執行過程被高度自動化後，人的稀缺性反而更加凸顯，集中到了上游，體現在定義目標、評估風險與執行架構取捨上。

打字的產能可以被複製。判斷的責任沒有人接。

至此，整條軟體流水線與架構思考已全部討論完畢。最後四篇將進行整理與收尾：包含跨專案的實證對照、整體效益帳的梳理、不適用場景的邊界說明，以及 repo 的交付細節。

🎒 最小一步｜列出你目前開發流程中，絕對不交給 AI 決定的三項任務。列不出來，代表自動化與人工判斷的邊界還沒釐清。
📎 本篇證據｜issue #77（接待台即時性：維持 5 秒輪詢、結案 SSE 待辦，trade-off 與未來訊號全文入檔）・issue #36（產品化分層 roadmap：「決策掛在訊號上，不是想像上」）