Vibe coding 最危險的地方，不是它太隨便。
真正危險的是，它太容易讓人產生一種錯覺：只要 AI 跑得出一版東西，工程就往前推進了。
在 demo、side project、內部小工具裡，這種錯覺有時候無傷大雅。你用自然語言描述一個畫面，agent 生出元件；你貼一段錯誤訊息，它補一個修法；你叫它整理資料結構，它改出一個看起來乾淨的 diff。速度很快，爽感也很真。
但真實專案不是這樣運作的。
真實專案裡，一段 code 不是只要能跑。它要符合原本的業務假設，要沒有偷偷改掉邊界行為，要能被測試覆蓋，要知道失敗時怎麼收斂。更麻煩的是，它通常還要跟一堆沒寫在 prompt 裡的團隊約定共存。
所以 coding agent 進入日常開發後，問題已經不是「AI 會不會寫程式」。
問題變成：你能不能把一件工作設計成可以被計畫、被執行、也被驗證的工程循環。
以前我們比較容易把 AI coding 工具想成聊天框。
你問，它答。你不滿意，就換個問法。整個互動還是以人類盯著螢幕為中心，AI 比較像一個很快、很有耐心、偶爾亂猜的同事。
現在狀況不一樣了。
AI coding 正在往 IDE、CLI、背景任務、MCP 工具鏈裡鑽。它不只是回答問題，而是開始讀專案、改檔案、呼叫工具、跑命令，甚至在你沒有逐行盯著的時候先把一版工作做完。
這件事聽起來很有效率，但它也把風險往後推了一層。
當 agent 只是幫你補一個函式，你大概還能靠肉眼和直覺接住。當 agent 可以碰 repo、跑測試、串工具、讀更多上下文時，真正需要設計的就不是 prompt，而是工作流。
也就是：它開始之前，知道什麼叫做做好嗎？它執行途中，知道哪些地方不能亂碰嗎？它做完之後，交得出足夠證據嗎？
這才是從 vibe coding 走向 agentic engineering 的分界。
不是把 prompt 寫得更華麗。
而是把「請 AI 幫我弄一下」改成一個有邊界、有檢查點、有驗收證據的循環。
Agent 很擅長放大模糊。
你給它一個模糊需求，它不一定會停下來問你。很多時候，它會把模糊理解成自由度，然後開始補洞。補得好，你會覺得它很神；補錯了，你會得到一個表面完整、其實方向偏掉的 diff。
所以 Plan 階段不是形式。
它是把風險先講清楚。
一個可以交給 agent 的任務，至少要回答幾個問題：
這些問題看起來很普通，但普通才是重點。
工程裡很多事故不是來自高深演算法，而是來自「大家以為大家知道」。AI agent 更不會知道。它只能從你給的上下文、repo 裡的線索、工具回傳的結果去推。
如果 Plan 沒寫清楚，agent 的聰明反而會變成麻煩。它可能主動重構你沒要它動的地方，可能把一個局部修復擴大成架構調整，也可能為了讓測試過，把真正該修的邏輯繞過去。
好的 Plan 不需要長。
例如：
修正登入頁在 magic link 過期時錯誤訊息不清楚的問題。只允許修改
auth模組與對應測試，不要改 session 流程。先補一個過期 token 的測試案例，再調整 UI copy 和錯誤映射。完成後跑pnpm test auth。如果需要修改 token 產生或驗證規則，停止並回報。
這段沒有什麼 prompt 技巧。
但它像一張工作單。目標、範圍、禁止事項、驗證方式、停止條件都在裡面。Agent 可以照著做，reviewer 也能照著驗。
這比「幫我改善登入錯誤處理」可靠太多。
很多人把 agent 的 Execute 想成一個黑盒子：任務丟進去，等它吐結果。
這在玩具專案裡可以。到了產品專案，這樣用很快就會累。
因為 agent 執行時最容易出問題的地方，通常不是它不會寫語法，而是它拿到太多不該用的自由度。
它可以讀整個 repo，於是把不相關的模式也套進來。它可以改很多檔案，於是順手做了「看起來合理」的整理。它可以跑命令，於是只跑最容易通過的那一個。它可以串工具，於是把權限邊界變成一句 vague 的「我需要更多上下文」。
Execute 階段要做的不是把 agent 綁死，而是讓它在正確大小的盒子裡工作。
我會把它拆成幾個很實際的控制點：
這些控制點聽起來有點煩。
但它們會省掉更多時間。你不需要在 review 時猜 agent 為什麼碰這個檔案，也不用從一大坨 diff 裡找出哪一行才是必要修改。
越接近真實產品，越不該追求「一次讓 agent 做完很多事」。
比較好的節奏是小步交付。讓 agent 先補 failing test，再修 production code；先提出 migration plan，再改 schema；先限定一個元件，再擴到相鄰頁面。它每一步都可以快，但每一步都要能被看懂。
Agent 的價值是降低單步成本，不是讓我們放棄步驟。
如果只能選一個地方投入力氣，我會選 Verify。
不是因為 Plan 和 Execute 不重要，而是因為驗證是人類責任最後落地的地方。
Agent 可以說它完成了。它也可以說測試通過了。問題是，這些句子本身沒有重量。真正有重量的是它交回來的證據。
一個可以被合併的 agent 產出，至少應該讓 reviewer 快速看見：
這不是官僚。
這是把「我覺得可以」換成「我知道哪裡被檢查過」。
尤其 agent 很會產出看似合理的局部修正。它可能讓測試變綠，卻改掉一個隱含行為；它可能補了錯誤處理，卻讓另一個入口吐出不一致的訊息；它可能為了型別通過，加了一個太寬鬆的 fallback，讓真正的資料問題被吞掉。
這些問題不一定會被單一測試抓到。
所以 Verify 不能只問「有沒有跑測試」。
要問的是：這組驗證，跟這次風險對得上嗎？
修 UI 行為，要有截圖或互動步驟。修權限，要有正反案例。修資料轉換，要有邊界輸入。改 CLI，要有實際命令輸出。改 agent 工具權限，更要能說清楚它拿到了什麼能力、哪些 secret 或敏感資料不應該出現在上下文裡。
GitHub 把 MCP server 的 secret scanning 放進討論裡，其實就是同一個方向的提醒：當 agent 能接觸更多工具和上下文時，工程問題會跟治理問題黏在一起。你不是只在驗 code，你也在驗它怎麼取得能力、怎麼留下痕跡、怎麼避免把不該流出的東西帶出去。
Verify 做得好，agent 產出就比較像工程交付。
Verify 做不好，agent 產出就只是比較有自信的猜測。
前一篇我談的是 task routing：不同任務要交給不同型態的 agent，也要設定不同權限和驗收方式。
今天這題更往裡面一層。
就算你已經選對 agent，工作也不會自動變安全。你還是要設計這次委派的內部循環：Plan 怎麼定義，Execute 怎麼控制，Verify 怎麼收斂。
這也是很多團隊導入 coding agent 後卡住的地方。
一開始大家會興奮於速度。後來踩到幾次雷，就開始懷疑工具。最後不是全開，就是全禁。這兩種反應都太粗。
比較成熟的做法，是把 agent 放回工程系統裡。
高風險任務先要求計畫。模糊任務先拆小。權限敏感的修改先讓 agent 做分析，不讓它直接改。每個 PR 都要求驗證證據。遇到未驗證假設就標出來，不要包裝成完成。
這些規則看起來很無聊。
但無聊通常表示它開始像工程了。
Vibe coding 的好處，我不想否認。
它讓很多人重新感覺到寫東西很快、很輕、很容易試。這很重要。很多產品和工具的第一版，本來就需要這種速度。
但如果要把 AI coding agent 放進長期專案，光靠靈感不夠。
我們需要的是能反覆使用的工作循環：先把意圖和邊界說清楚，再讓 agent 在受控範圍內執行，最後用測試、diff、行為檢查和人工判斷把結果收回來。
真正會用 agent 的工程師，不一定是最會下 prompt 的人。
更可能是最知道什麼東西不能省的人。
能省的是手打樣板、搜尋線索、補測試骨架、整理重複修改。
不能省的是目標、邊界、證據和責任。
AI 寫程式真正缺的不是靈感。它缺的是驗證。而驗證，剛好就是工程師還不能外包掉的那一部分。
ryanvale
iThome鐵人賽
看影片追技術