沒有回饋迴路，AI coding 就會變成回合制遊戲
你交給 Claude 一件事，它做完停下來；你打開瀏覽器檢查、看到問題、再回頭告訴它。這不是代理人，這比較像你在跟一個很快的實習生輪流下棋。
Turn-based babysitting
人工檢查卡在你身上：開 dev server、看 console、點流程、檢查 layout shift、看手機版。Claude 每次都要等你回報才知道下一步。
Agentic feedback loop
把檢查寫進流程：Claude 做完就自己跑測試、開瀏覽器、檢查 console、點互動、修問題、再驗一次。你收到的是接近完成品的結果。
代理人的價值，不是第一次就完美，而是它能不能在沒人盯著時，靠回饋訊號一路逼近正確答案。
The more Claude can self-verify, the more independently it can work on long-running tasks.
Claude 已經會看機器訊號，但不一定知道你的人工標準
型別錯誤、lint、測試失敗、runtime error 都是 deterministic signals。問題是：你真正會在交付前看的東西，很多還沒有被寫進它能執行的流程。
前端驗證的最小閉環：跑、看、點、修、重驗
如果改的是 UI，不要只停在 build passed。Claude 應該像真人一樣打開頁面，確認它真的長得對、動得對。
把你的人工流程，變成 Claude 每次都會跑的 skill
寫成 skill 不是為了形式，而是把「你會怎麼驗收」變成代理人可以重複執行的工作契約。
name: frontend-verify
description: Verify frontend changes in a browser.
---
# Frontend verify
- Run a two-step verification pass in a real browser.
- Fix issues and re-verify before responding.
## Step 1
Open the URL, interact with the new element, confirm it renders and behaves as expected.
## Step 2
Run a mobile/performance audit and check Core Web Vitals.
Skill 的重點不是提醒，是授權它繼續做
如果 skill 只寫「請檢查」，Claude 還是會停下來報告。更好的寫法是：跑驗證 → 發現問題就修 → 再驗證 → 直到通過才回覆。這會把人工往返變成代理人內部的迴圈。
品味很難自動化，但可以先把標準說清楚
不是每件事都能 pass/fail。效能預算、無障礙清單、design system 規則、好壞範例，都是把「感覺怪怪的」轉成 Claude 可衡量標準的材料。
你的 workflow 成熟度
你已經有一些自動檢查，但人工驗收還沒有完全寫進流程。
合併前，再找一個沒有寫程式的 agent 審一次
第一個 agent 寫完後，會帶著自己的假設與偏見。第二個 agent 沒參與實作，反而更容易抓到「它以為自己已經完成」的盲點。
建置中的自我驗證
- 跑測試、lint、type check
- 開 browser、點互動、查 console
- 效能與手機版 audit
- 修掉問題後重新驗證
合併前的隔離審查
- 另一個 agent 讀 diff 或 PR
- 從安全、設計、可維護性不同角度看
- 把高信心問題擋在 production 前
- 看 CI，必要時回到修復迴圈
最後，把技能串成一條完整開發生命週期
真正有用的 agent workflow，不是單一神提示詞，而是一串可以互相呼叫的 skill：簡化 diff、驗證前端、設計檢查、開 PR、看 CI、修失敗。
Simplify
先清理 diff：刪掉不必要複雜度，讓下一步 review 更容易抓重點。
Verify
把 build、browser、console、mobile、performance 全部放進自我驗證迴圈。
Review
讓第二個 agent 在合併前檢查 PR，補上第一個 agent 的盲點。
把你的人工檢查變成 Claude 可以執行的流程，它就不再只是「會寫 code 的模型」，而是能自己收斂品質的工作代理人。