讓反饋迴圈保持緊湊

你越快能看到一個改動是否有效，你和 AI 就越快收斂到正確的東西上。一個緩慢的迴圈——你要等上幾分鐘才知道有沒有搞壞什麼——會悄無聲息地把每一個錯誤成倍放大。

• 讓"跑起來"變成一條命令。npm run dev、make test，無論是什麼，把它記在你的上下文檔案裡，這樣 AI 也能跑它。
• **依靠快速的測試。**哪怕只有少數幾個單元測試，都能給 AI 一種驗證自己工作的方法，而不用你盯著。
• **使用 linter 和格式化工具。**它們能瞬間抓住一整類錯誤，並把風格之爭擋在你的審查之外。
• **把錯誤回傳給 AI。**當出問題時，把真實的錯誤資訊貼回去。具體的反饋產出具體的修復；"它不工作"只會產出猜測。

AI 工作空間的各個部件構成一個相連的迴圈——智慧體編輯倉庫，編輯器和語言伺服器報告問題，終端執行程式碼，而每一個結果都流回智慧體：

        ┌──────────────────────────────────────────────┐
        │                                               │
        ▼                                               │
   ┌─────────┐     編輯       ┌──────────┐    執行   ┌──────────┐
   │  代理   │ ─────────────▶ │  編輯器  │ ────────▶ │   終端   │
   └─────────┘                └────┬─────┘           └────┬─────┘
        ▲                          │                      │
        │                          ▼                      ▼
        │                    ┌──────────┐           ┌──────────┐
        │                    │   LSP    │           │   REPO   │
        │                    │  (錯誤)  │           │  (提交)  │
        │                    └────┬─────┘           └────┬─────┘
        │                         │                      │
        └─────────────────────────┴──────────────────────┘
                          反饋迴流

這個想法最深的版本，是讓 AI 自己把迴圈閉合。與其由你來執行命令、讀取失敗、再轉述回去，不如給智慧體許可權，讓它在每次改動後執行測試和型別檢查器，並對自己看到的東西做出反應。迴圈於是變成：編輯、執行、讀取失敗、修復、再執行——全程沒有你卡在中間。你的角色從信使轉為導演：你設定目標和護欄，然後看著迴圈轉起來。當 AI 能夠編輯、執行、看到失敗、並自行修復時，你就建好了一個能幹真正活兒的迴圈，而你穩坐導演椅。