構建迴圈

下面就是你將一遍又一遍執行的迴圈。它故意做得很小。

1. 把功能切成小的縱向步驟。 每一步都應是你能在幾分鐘內構建、執行、並看到它運作的東西。
2. 挑一個步驟。 就一個。眼下其他都先不管。
3. 為那一個步驟寫提示。 對什麼要改、什麼要保持不變都要說具體。
4. 審查改動。 讀一讀 AI 寫了什麼。你不需要看懂每一行，但要掃一眼有沒有明顯錯的地方。
5. 執行應用。 真的去點那個按鈕、載入那個頁面、請求那個端點。確認這一步奏效。
6. 提交。 在版本控制裡用一句簡短的資訊存一個檢查點。
7. 重複第 2 步，換下一個步驟——直到功能完成。

把這個迴圈畫成一個環就是下面這樣——你繞著它一圈圈轉，每圈一個小步驟，直到功能完成：

        ┌──────────────────────────────────────────┐
        │                                           │
        ▼                                           │
   ┌─────────┐    ┌─────────┐    ┌──────────┐       │
   │  切片   │───▶│  挑選   │───▶│   提示   │       │
   │  功能   │    │ 一步驟  │    │ 該步驟   │       │
   └─────────┘    └─────────┘    └────┬─────┘       │
   (一次,                             │             │
    最開始)                           ▼             │
                                 ┌──────────┐       │
                                 │   審查   │       │
                                 │ 該 diff  │       │
                                 └────┬─────┘       │
                                      ▼             │
                                 ┌──────────┐       │
                                 │   執行   │       │
                                 │  該應用  │       │
                                 └────┬─────┘       │
                          可用?       │             │
          壞了 ◀──────────────────────┤             │
          撤銷並重新提示              │ 是          │
                                      ▼             │
                                 ┌──────────┐       │
                                 │   提交   │───────┘
                                 │ 檢查點   │  下一步驟
                                 └──────────┘

整個要點在於，你永遠離一個可執行的應用不遠。如果第 4 步產出了壞掉的東西，你只有一個小改動要撤銷，而不是一團纏成結的亂麻。

跳過第 4 到第 6 步的人，會有大約二十分鐘覺得自己更快。然後他們撞上一個找不到的 bug，因為他們應用上一個已知可用的版本，在一百個改動之前。這個迴圈之所以讓人覺得慢，恰恰是因為它從不讓你積累那種債務。