AI 編碼 Loop 教程：不寫 Prompt，改寫 Loop，AI 編碼的循環工作法

前言

為什麼你讓 AI 寫代碼，總是前半小時很爽，後半小時開始補鍋？

很多時候不是模型不行，而是我們把開發任務交給了一個「一次性 prompt」：把需求塞進去，期待 AI 一次理解、一次設計、一次實現、一次測試，還要一次性不犯錯。

真實開發不是這樣。

真實開發是循環：先對齊需求，再拆任務，再寫測試，再實現，再驗證，再審查，再記錄進度。

AI 編碼要穩定，也得把這套循環顯式做出來。

這篇教程講的不是玄學概念，而是一套普通開發者也能照做的方法：

把「寫一段 prompt 讓 AI 自由發揮」，改成「讓 AI 按一個固定循環完成任務」。讀完你能帶走一套從 0 到 1 的日常流程。

先說結論：Prompt 沒死，一次性 Prompt 該退場了

所謂「不寫 prompt」，不是以後一個字都不用輸入。

更準確的說法是：

不要再把 prompt 當成一次性許願文本，而要把它變成循環系統裏的入口參數。

以前你可能這樣寫：

幫我給訂單列表加一個導出 Excel 功能，要求支持勾選訂單、沒有勾選時給提示、數據多的時候不要卡。

這就是一次性 prompt。

它的問題是：需求、設計、實現、測試、驗收全部擠在一句話裏。

Loop Engineering 的寫法會變成：

請按「需求說明 → 澄清問題 → 拆任務 → 寫測試 → 寫代碼 → 跑驗證 → 保存進度」這個循環處理：
1. 先把需求寫成可驗收條款，不要直接寫代碼
2. 找出模糊詞，先問清楚
3. 把任務拆成 3-5 個小步驟
4. 每一步先寫測試或驗收清單
5. 實現後跑測試，並記錄結果
6. 最後留下下一次可以繼續的進度說明

這仍然有文字，但重點已經變了。

你不是在「提示 AI 怎麼想」，而是在「啓動一個工程循環」。

一個普通人也能理解的 Loop 長什麼樣

你不需要一上來就安裝複雜工具。

先把 Loop 理解成 4 個文件或 4 段記錄：

如果你願意更工程化，可以把這些內容放進項目目錄；如果你只是個人練習，也可以先放在一個 Markdown 文件裏。

重點不是文件名，而是這 4 件事必須存在：

•需求有邊界

•任務有順序

•完成有證據

•中斷後能續上

這就是一個最小 Loop。

Loop Engineering 的核心：把「我希望」改成「你應該怎樣」

一次性 prompt 常見句式是：

希望代碼質量高一點，注意邊界情況，最好寫測試。

這類話對 AI 來說很弱。它沒有退出條件，也沒有可驗證證據。

Loop 寫法要變成：

需求條款：空選提示

當用戶沒有勾選任何訂單時：
- 系統不能開始下載文件
- 系統要提示「請先選擇要導出的訂單」

驗收方式：
- 打開訂單列表
- 不勾選任何訂單
- 點擊「導出」
- 結果應該是：出現提示，並且沒有文件下載

這類寫法的好處非常直接：

•AI 寫代碼時可以對照條款

•測試可以對照驗收方式

•Review 可以逐條檢查結果

•下次續跑不用翻聊天記錄

一句話：prompt 是請求，需求條款是契約。約定既是邊界

日常開發時怎麼用：從 1 句話需求變成 1 個循環

下面是一套適合日常 AI 編碼的步驟。中等以上需求按這個走，小修小補可以簡化。

Step 1：先建任務，不急着寫代碼

先給任務起一個簡單名字。

比如：

訂單導出功能

然後讓 AI 先寫一份「任務卡」，不要直接開工。

任務卡只需要 4 塊內容：

目標：用戶可以導出自己勾選的訂單

約束：
- 沒勾選訂單時不能導出
- 數據很多時頁面不能長時間無響應
- 導出的文件要能被 Excel 正常打開

不做：
- 暫時不做後台異步導出
- 暫時不做自定義字段選擇

驗收標準：
- 勾選 1 條訂單，可以導出 1 條
- 沒勾選訂單，會出現提示
- 特殊字符不會把表格格式弄亂
- 跑完測試後才能算完成

這一步的目標不是寫漂亮文檔，而是把 AI 後續的自由發揮壓到合理範圍內。

可複製入口語：

先不要寫代碼。請把這個需求整理成任務卡：
1. 目標是什麼
2. 有哪些約束
3. 這次明確不做什麼
4. 做到什麼程度算完成
整理完後先停下來，讓我確認。

Step 2：把模糊詞變成退出條件

AI 最容易在模糊詞上自作主張。

比如：

•「大數據量」

•「不要卡」

•「兼容 Excel」

•「導出當前數據」

在一次性 prompt 裏，這些詞很危險。

Loop 裏要把它們改成可檢查的條件。

以「訂單導出」為例，可以這樣處理：

可複製入口語：

進入需求澄清：
請找出任務卡里的所有模糊詞，最多問我 3 輪。
能確定的寫入「已確認」，不能確定的寫入「待確認」。
每個結論必須能轉成測試或驗收條件。

Step 3：寫計劃，而不是讓 AI 直接開工

計劃不是「實現這個功能」這種大句子。

計劃要小到可以執行、可以回滾、可以測試。

以「訂單導出」為例，可以這樣拆：

這一步的關鍵是：任務之間要能獨立驗證。

可複製入口語：

請把任務拆成 3-5 個小任務：
1. 每個小任務說明可能改到哪裏
2. 每個小任務都寫清楚驗收口徑
3. 每個小任務儘量能單獨測試
4. 按“先驗證、再實現”的順序排
5. 不要寫“完善一下”“處理邊界情況”這種空話

Step 4：讓 AI 跑 TDD 小循環

大 Loop 裏面還有小 Loop。

每個任務都按這個順序：

寫失敗測試 → 運行確認失敗 → 寫最小實現 → 運行確認通過 → 更新任務狀態

以導出文件生成為例，循環應該是：

1. 先寫一個測試：訂單名稱裏有逗號、換行、雙引號時，導出內容仍然正確
2. 跑測試，確認失敗來自功能未實現
3. 寫導出函數
4. 再跑測試
5. 通過後進入下一個任務

你要避免這種入口語：

幫我直接實現，順便寫測試。

更好的入口語是：

從第一個小任務開始執行 TDD 小循環：
先寫失敗測試並運行，只在確認失敗後再寫實現。
每完成一個任務，更新任務清單和進度說明。

Step 5：測試不是一句「已完成」，而是一段證據

Loop 裏最重要的變化，是 AI 不能只說「已經完成」。

它要給證據。

一份合格的驗證記錄應該長這樣：

測試命令：npm test
結果：全部通過，23 個測試無失敗

覆蓋率命令：npm run test:coverage
結果：分支覆蓋率 86%，達到 80% 的最低要求

這段證據的價值很高。下次續跑時，AI 不需要猜「上次到底測沒測」，直接看驗證記錄。

可複製入口語：

進入 Verify：
1. 跑項目標準測試命令
2. 跑覆蓋率
3. 把命令和關鍵結果寫入驗證記錄
4. 不允許只說“測試通過”，必須記錄命令和關鍵結果

Step 6：用進度快照解決「上下文斷了」

日常 AI 編碼最痛的事之一，是上下文斷了。

聊天一長，AI 忘了前面做過什麼；換個會話，又要重新解釋。

你可以讓 AI 在每次中斷前寫一段「進度快照」：

任務：訂單導出功能
當前步驟：測試已通過，準備做最終驗收

已完成：
- 需求卡已確認
- 任務拆分已完成
- 導出函數已實現
- 空選提示已實現
- 自動測試已通過

未完成：
- 還沒有做人工驗收
- 還沒有檢查是否有敏感信息

下一步：
1. 對照驗收標準逐條檢查
2. 跑安全掃描
3. 決定是否合併代碼

續跑入口：
請讀取這份進度快照，從“最終驗收”繼續。

這就是 Loop 的狀態恢復能力。

你下次不用寫長 prompt，只要說：

請讀取進度快照，從上次的“下一步”繼續。

這句話不是讓 AI 猜，而是讓 AI 讀取狀態機。

Step 7：最後用放行檢查決定能不能結束

最後一步，不要問 AI「你覺得完成了嗎」。

你要讓它對照放行清單。

比如：

放行檢查：
- 需求卡里的驗收標準是否全部滿足？
- 自動測試是否全部通過？
- 有沒有新增明顯安全風險？
- 有沒有把密鑰、賬號、token 寫進代碼？
- 有沒有留下進度記錄，方便下次追溯？

結論：
- PASS：可以合併或交付
- BLOCKED：列出阻塞項，修完再檢查

這一步很重要。

沒有放行檢查，AI 很容易把「我寫完了」當成「可以合併了」。有了放行檢查，完成就變成一個明確狀態。

可複製入口語：

收尾前做放行檢查：
1. 對照驗收標準逐條確認
2. 確認測試和安全檢查通過
3. 如果不能 PASS，列出阻塞項，不要合併或交付

你每天真正需要記住的 5 句話

你不用每天背完整流程。日常使用時，記住這 5 條入口語就夠了。

1. 新任務啓動

按 Loop 流程啓動這個任務：先寫任務卡，不要直接寫實現代碼。

2. 需求澄清

找出所有模糊詞，最多問 3 輪；結論寫入「已確認」，未決項寫入「待確認」。

3. 開始實現

按任務清單執行 TDD 小循環：失敗測試 → 最小實現 → 測試通過 → 更新進度。

4. 中斷保存

把當前進度寫成快照，包含已完成、未完成、測試證據、下一步入口語。

5. 完成驗收

對照驗收標準檢查，跑測試和安全檢查，確認放行檢查 PASS 後再收尾。

這 5 句話的本質不是 prompt 模板，而是 5 個 loop 入口。

什麼任務要走完整 Loop，什麼任務不用

不是所有事情都要重流程。

判斷標準很簡單：

如果這個改動失敗後會影響用戶、數據、安全或多人協作，就不要只靠一次性 prompt。

常見坑：你以為在 Loop，其實還是 Prompt

坑 1：只有流程名，沒有進度記錄

你對 AI 說「按流程來」，但沒有任務卡、沒有進度快照、沒有驗證記錄。

這還是 prompt。

真正的 Loop 要能回答：

•當前在哪一步？

•上一步的證據是什麼？

•下一步入口是什麼？

•誰能接着跑？

坑 2：只有測試命令，沒有驗收標準

測試通過不等於需求正確。

你還要對照最開始寫下的驗收標準。比如訂單導出必須檢查：

•是否只導出勾選訂單

•空選是否不下載

•大數據量是否有進度

•Excel 是否能識別中文

坑 3：把 AI 的承諾當成強制系統

規則、提示詞、系統說明都只是 AI 行為約束。

真正強制的是：

•測試命令

•覆蓋率閾值

•安全掃描

•放行檢查

•人審

真正重要的事，要放到測試、腳本、CI 或人工審查裏。

坑 4：忘了給下次續跑留入口

很多 AI 編碼任務不是一次做完的。

好的 Loop 必須在中斷時留下這句話：

請讀取進度快照，從“下一步”繼續。

這句話比一大段背景介紹更可靠。

一個最小可複製模板

你可以直接複製下面這段，作為日常 AI 編碼的啓動口令。

按 Loop Engineering 工作流處理這個任務：

目標：
<一句話說明要做什麼>

約束：
- 不改無關文件
- 不提交密鑰
- 先寫任務卡，確認後再實現
- 每一步都要更新任務清單或進度快照

流程：
1. 寫任務卡：目標、約束、不做什麼、驗收標準
2. 找出模糊詞，先問清楚
3. 拆成 3-5 個小任務
4. 每個小任務寫清楚驗收口徑
5. 按 TDD 小循環實現：失敗測試 → 最小實現 → 測試通過
6. 跑測試、覆蓋率、安全檢查
7. 對照驗收標準逐條檢查
8. 寫進度快照，留下續跑入口
9. 做放行檢查，PASS 才能合併或交付

退出條件：
- tests PASS
- coverage 達標
- security PASS
- 放行檢查 PASS
- 進度快照可用於下次續跑

把這段保存成你自己的常用模板後，每天就不需要重新寫長 prompt。

你只需要換掉目標描述。

總結：Loop Engineering 是把 AI 編碼變成可交接系統

一句話總結：

Prompt 解決的是「這次怎麼說」，Loop 解決的是「每次怎麼做」。

日常 AI 編碼走向 Loop，不是追新概念，而是把軟件工程本來就需要的東西顯式做出來：

•用任務卡固定目標

•用任務清單驅動執行

•用測試驗證行為

•用進度快照支持續跑

•用放行檢查決定能不能交付

當這些東西都存在時，AI 不再靠記憶和猜測工作。

它是在一個可觀察、可恢復、可驗收的循環裏工作。

這就是從 prompt 走向 loop 的關鍵一步。

如果你已經在用 AI 寫代碼，可以從下一次中等需求開始試：不要先說「幫我實現」，先說「按 Loop 流程啓動這個任務」。

然後觀察一件事：你後面返工的次數，會明顯少很多。

最後這個只是 AI 編程過程中可以使用到方法論而已，是否每次或者都需要看使用場景的，這個不是必要的，但是思想理念是值得我們學習的。