Agent 在跑，但誰在決定方向？——Panel Q&A 給我的碎片反思
這是 C Talk+ X TKUG #17 | AI-Native Frontend - 從 Prompt 到 Production 的工程實踐 活動心得的第三篇。前兩篇分別記錄了 Recca Chao 的分享——如何從「寫程式的人」升級成「設計流水線的人」，以及 Marvin Lin 的 Agent 實踐——Agents 時代基本功反而更重要。如果你還沒讀過，建議先從那兩篇開始，這篇的脈絡會更清楚。
Panel 的 Q&A 段落通常是我最喜歡的部分。不是因為答案一定比演講更精彩，而是因為問題本身往往比答案更誠實——那是一整個場子的工程師，消化完前面的分享之後，心底真正想搞懂的事。
這場也不例外。
第一個問題，也是最難的問題
「如果 Agent 跑起來了，你要怎麼在中途繼續調整方向、輸入新需求，而不是每次都從頭來？」
講者的答案是樂觀的——他認為未來的 Agent 服務自然會提供這種持續溝通的介面，就像過去從網頁版、CLI 版一路演化，工具會跟上。
但我聽到這裡心裡有個小聲音：等工具跟上的那段時間，你要怎麼辦？
身為前端工程師，這個問題特別有感。我們已經很習慣「事件驅動」的思考方式——使用者做了什麼，系統怎麼回應，狀態如何流動。但 Agent 的運作邏輯更像一個跑在後台的長時間任務，它不等你，它自己往前走。你的介入，某種程度上更像是「插斷」，而不是「控制」。
這個認知調整，對我來說比學會用哪個工具更難。
多個 Agent，各自拿到不同的驗證規格
Panel 裡有一段讓我很清醒。
講者說：如果你找了一個助理幫你按規格寫 code，你自己 review，再請另一個助理按另一套規格來 review——那麼多 Agent 協作做的事，其實跟管理真實的人沒什麼不同。
差別在於，每個 Agent 拿到的「驗證規格」不一定一樣。有人負責確認畫面有沒有跟設計稿一致、有人負責確認資料量大的時候會不會跑太慢、有人負責確認 code base 的邏輯有沒有照舊的規則走。不是一個 AI 全包，而是把驗證這件事也拆開來平行跑。
這讓我想到以前帶 junior 的時候：你不可能只給一個人「幫我寫個功能」，你要給他設計稿、給他 API 文件、給他邊界條件，然後你自己再跑一次 edge case 確認沒有漏掉。
換成 Agent，邏輯一樣，只是規模可以更大、同時可以更多。
驗證不只是跑測試，也是截圖比對
有個現場問題問到前端驗證的具體做法，講者的回答很接地氣：截圖比對、UI 一致性確認、資料量壓力測試，這些都是有效的驗證機制，而且是 Agent 可以自動跑的。
這對我來說是一個小提醒。
以前我覺得「讓 AI 寫前端」最麻煩的就是驗證——寫 code 快，但你怎麼知道它生出來的畫面是對的？現在我意識到，驗證機制本身也可以設計進去，不是等 code 生完再手動確認，而是讓驗證這件事也變成 Harness 的一部分。
只是建這些驗證機制，本身就需要大量的前期設計。這筆時間帳，要先想清楚。前期不想清楚，後期就會一直手動補。
沒人說「認知投降」，但那條暗線貫穿整場
整個 panel 過程中，沒有人直接提到「認知投降」這個詞，但那個概念像一條暗線貫穿整場。
講者講到：讓 Agent 做事，但任務結構、邊界、驗證標準，這些核心的東西還是要自己想清楚。你是 manager，不是旁觀者。
這呼應了 Anthropic 研究裡的結論：分數最高的族群，不是把任務全丟給 AI、也不是完全不用 AI，而是「先讓 AI 生，再確保自己完全理解每一行」——generation then comprehension。
前端工程師很容易掉進這個坑，因為我們的工作有很多是「視覺確認」——畫面看起來對了，就感覺沒問題。但 AI 生的 code 裡可能有不合理的狀態管理、可能有效能問題、可能有邊界條件沒處理——那些東西，截圖是看不出來的。
如果我連 AI 幫我寫的 component 都沒搞懂，只是確認「畫面長對了」就送出去，那我就是在認知投降。而且，我還會很有自信。
這才是最危險的地方。
「最好也最壞的時代」，對我來說是什麼意思
說實話，聽完這場 panel，我的心情很複雜。
工具是真的好玩。Agent 跑在後台、多個助理同時 review、截圖自動比對——這些對一個前端工程師來說，聽起來像夢想。我自己也確實想試，想建一套屬於自己的 workflow，想讓 side project 跑得更快。
但我也很清楚：Marvin 那 28 個 task 背後，是多少個沒睡好的夜晚。
工具讓你能做更多，但你的體力還是你原來的那個體力。
現在最容易犯的錯，不是技術選錯，而是看到太多可能性、想做太多事，然後什麼都做不深、也什麼都撐不久。
Panel 最後那個問題的答案，我自己補了一層
Panel 最後有人問：要怎麼提升自己在 AI 時代的技能？
講者給的答案很直接：多做、多看別人怎麼寫文件、多嘗試，然後調整。不要太緊張某個問題，有時候換個新模型，問題自然就消失了。
但我聽到更重要的一層在後面：工程師真正要提升的，是設計能力，不是打字能力。
以前大家期待工程師「能寫 code、不要出錯」。未來期待的是「你知道要做什麼，然後能讓 AI 去跑」。前者是執行層，後者是設計層。
前端工程師的優勢是我們本來就很習慣「看畫面想邏輯」，這個直覺在設計 Harness、設計驗證流程的時候仍然用得上。但我也需要誠實面對：有些系統設計的東西，我確實不夠熟。
與其什麼都追，不如先把一個 workflow 建完、建透，然後從那個經驗裡長出真正的理解。
這也是 panel 整場給我最深的感受：不是讓 AI 替你想，是讓 AI 替你跑，你來決定跑什麼。
決定跑什麼，這件事沒有捷徑。