AI 編程 · 工程效率

AI Coding Workflow：如何減少 AI 反覆修改程式碼？

發布於 2026.08.08 約 10 分鐘閱讀

Plan → Scoped Edit → Verify / Cursor Rules / 小步 diff / 驗收清單 / 死循環排查

用 Cursor、Claude Code 或 Copilot Workspace 寫功能時，你是否經歷過這樣的夜晚：AI 改了 A 檔案，測試掛了；修 B 檔案，A 又壞了；你說「再試一次」，它把昨天能跑的程式碼也改沒了。這不是模型「不夠聰明」，而是缺少可重複的 AI Coding Workflow——沒有把「規劃、改動範圍、驗收」拆成獨立階段，Agent 就會在同一個錯誤假設上無限打轉。

本文給出一套在 2026 年團隊裡實測有效的流程：先 Plan 再動刀，每輪只改一小塊，改完必須 Verify 才進入下一步。配合 Cursor Rules 與 Git 小提交，我們把「同一 bug 改 8 輪」壓到 2 輪以內。若你同時在搭雲端 Mac 上的 MCP Server 或選型 GitHub AI Agent 開源專案，這套工作流同樣適用。

為什麼 AI 會陷入「改不完」的循環？

Agent 模式的本質是：在不確定的環境裡試錯。當你只說「修一下登入 bug」，模型不知道你指的是 OAuth 回調、Session 過期還是前端路由——它會猜一個最像的答案，改完跑測試，失敗後再猜另一個方向。每一輪都推翻上一輪的部分假設，diff 越來越大，上下文裡堆滿互相矛盾的修改記錄，最終進入「越改越亂」的狀態。

三個根因

目標模糊——沒有寫清「成功長什麼樣」，AI 只能用測試報錯反推，而報錯資訊往往指向症狀而非根因
範圍失控——一次任務跨 10+ 檔案，改 auth 時順手 refactor 了 utils，引入新回歸
缺少驗收門禁——沒有「通過才繼續」的硬規則，失敗時預設策略是「再生成一版」而非「回滾並重定範圍」

經驗法則：如果你連續三輪都在說「不對，再改一下」，問題不在模型，而在任務沒有重新 Plan。

三階段工作流：Plan → Scoped Edit → Verify

把每次 AI 協作拆成三個不可跳過的階段，比換更強的模型更有效：

AI Coding Workflow 三階段：Plan、Scoped Edit、Verify — 先定範圍再動刀，Verify 不過就回到 Plan，而不是在同一 diff 上疊加補丁。

Plan（規劃）——用 Plan 模式或純對話，列出要改的檔案、不動什麼、驗收命令（如 npm test -- auth）。產出一段可貼上的「任務規格」，~~不要直接讓 Agent 開改~~ 應先確認規格
Scoped Edit（受限改動）——明確寫「只改 src/auth/login.ts，禁止動其他檔案」。每輪目標：1–3 個檔案、<200 行淨變更
Verify（驗收）——跑測試、lint、手動冒煙。通過 → 提交並進入下一任務；失敗 → 帶著完整錯誤日誌回到 Plan，而不是說「再試一次」

階段	推薦工具/模式	產出物	常見錯誤
Plan	Cursor Plan / 對話-only	任務規格 + 檔案清單	規格太長仍含糊
Scoped Edit	Agent + `@file` 引用	小 diff PR	順手 refactor 無關程式碼
Verify	終端 / CI / `Cmd`+測試快捷鍵	綠測試 + commit	跳過測試直接下一任務

提示詞結構：一次說明目標、邊界與驗收

可複製模板（把括號換成你的專案）：

text

## 目標
（一句話：使用者點擊登入後 3 秒內進入 dashboard）

## 範圍
- 只改：src/auth/login.ts, src/auth/session.ts
- 禁止改：路由、樣式、其他模組

## 驗收
- npm test -- --grep "login"
- 手動：錯誤密碼顯示「帳號或密碼錯誤」，不洩露使用者是否存在

## 上下文
- 當前錯誤：（貼上完整 stack trace）
- 相關約定：Session 存 Redis，見 docs/auth.md

這種結構對應 Anthropic 的 Claude Code 最佳實踐裡強調的「明確邊界」——模型不需要猜你的意圖，回歸面也可控。

Rules / Skills：把專案約束寫進倉庫

每次對話重複「我們用 pnpm、不用 class 元件、測試放 __tests__」會浪費 token，也讓 AI 時而遵守、時而忘記。把約定寫進 .cursor/rules 或專案級 AGENTS.md：

Rules（規則）: 持久約束：命名風格、禁止模式、提交前必須跑哪些命令。Cursor 會在每次 Agent 呼叫時自動注入。
Skills（技能）: 可複用的任務劇本，例如「新增 API 端點」分步清單。減少 AI 每次從零摸索專案結構。
User Rules vs Project Rules: 個人偏好（如「回覆用中文」）放 User；團隊共識（如「不改 backend 除非明確要求」）放 Project，避免協作時各說各話。

參考 Cursor Skills 文件，把高頻流程固化後，反覆修改同一類錯誤的次數會明顯下降。

小步 diff 與 Git 紀律

AI 擅長一次生成大塊程式碼，但人類審查大 diff 的能力有限。建議：

每輪 Agent 任務對應一個 commit——message 寫清「Plan 摘要」，方便 git revert
改亂了就 reset——不要在大 diff 上繼續 patch；git checkout -- . 回到綠測試點，用更小的範圍重開任務
用分支做實驗——尤其在雲端 Mac 或 CI 環境試 Agent 時，git worktree 或獨立分支隔離「AI 亂改」風險

上下文管理：別讓 Agent 淹沒在檔案海裡

把整個 monorepo 丟給 Agent，等於讓它在雜訊裡找訊號。更有效的方式：

用 @filename 精確引用 3–5 個相關檔案，而不是「掃描整個專案」
大重構拆成多個 Plan：先介面、再實作、再測試，每步 Verify
長對話到 15 輪以上時，開新對話並貼上「任務規格 + 當前狀態」，比帶著歷史包袱繼續改更乾淨

深入了解：Plan 模式和 Agent 模式何時切換？

需求不清晰、涉及架構取捨時用 Plan；規格已寫好、檔案清單明確時用 Agent。在 Cursor 裡可主動 SwitchMode 到 Plan——很多死循環是因為在 Agent 裡邊想邊改，應退回 Plan 重定範圍。

四種常見死循環與破局法

現象	根因	破局
修 A 壞 B，修 B 壞 A	範圍太大、缺少單元測試隔離	縮小到單檔案；補 mock；分兩個 Plan
同一錯誤改五遍仍失敗	錯誤日誌不完整，AI 在猜	貼上完整 stderr；指定「先讀 X 再改」
程式碼風格每次都不一樣	Rules 未配置	加 .cursor/rules；引用現有檔案作範例
「完成了」但功能不對	驗收標準未寫入提示詞	Plan 階段寫清手動驗收步驟

若你正在用 Agent 編排複雜流水線（例如批次文件處理或 MCP 工具鏈），把「路由 → 執行 → 校驗」分層的設計思路，與我們在 PDF 批次識別流水線裡講的分流架構是同一類模式：先判斷再動手，避免所有任務走最慢、最易出錯的路徑。

常見問題

是不是模型越強越少反覆？——強模型減少「語法級」錯誤，但範圍失控導致的回歸與模型檔位無關，Workflow 才是主因
團隊怎麼統一？——把 Rules、PR 模板、驗收清單放進倉庫；Code Review 時檢查「是否小步提交」
可以完全交給 Agent 嗎？——可以自動化執行，但 Plan 和 Verify 仍建議人工門禁，尤其是支付、鑑權、資料遷移
和 TDD 怎麼配合？——先讓 AI 寫失敗測試（Plan），再實作（Scoped Edit），綠了再 refactor——天然契合三階段

回到標題：減少 AI 反覆修改程式碼，靠的不是「多試幾次」，而是 Plan → Scoped Edit → Verify 的紀律、清晰的提示詞、倉庫裡的 Rules，以及敢於 git revert 的勇氣。把流程固定下來之後，你會把時間花在「定義問題」上，而不是「第 N 輪補丁」上。