构建循环

下面就是你将一遍又一遍运行的循环。它故意做得很小。

1. 把功能切成小的纵向步骤。 每一步都应是你能在几分钟内构建、运行、并看到它运作的东西。
2. 挑一个步骤。 就一个。眼下其他都先不管。
3. 为那一个步骤写提示。 对什么要改、什么要保持不变都要说具体。
4. 审查改动。 读一读 AI 写了什么。你不需要看懂每一行，但要扫一眼有没有明显错的地方。
5. 运行应用。 真的去点那个按钮、加载那个页面、请求那个端点。确认这一步奏效。
6. 提交。 在版本控制里用一句简短的信息存一个检查点。
7. 重复第 2 步，换下一个步骤——直到功能完成。

把这个循环画成一个环就是下面这样——你绕着它一圈圈转，每圈一个小步骤，直到功能完成：

        ┌──────────────────────────────────────────┐
        │                                           │
        ▼                                           │
   ┌─────────┐    ┌─────────┐    ┌──────────┐       │
   │  切片   │───▶│  挑选   │───▶│   提示   │       │
   │  功能   │    │ 一步骤  │    │ 该步骤   │       │
   └─────────┘    └─────────┘    └────┬─────┘       │
   (一次,                             │             │
    最开始)                           ▼             │
                                 ┌──────────┐       │
                                 │   审查   │       │
                                 │ 该 diff  │       │
                                 └────┬─────┘       │
                                      ▼             │
                                 ┌──────────┐       │
                                 │   运行   │       │
                                 │  该应用  │       │
                                 └────┬─────┘       │
                          可用?       │             │
          坏了 ◀──────────────────────┤             │
          撤销并重新提示              │ 是          │
                                      ▼             │
                                 ┌──────────┐       │
                                 │   提交   │───────┘
                                 │ 检查点   │  下一步骤
                                 └──────────┘

整个要点在于，你永远离一个可运行的应用不远。如果第 4 步产出了坏掉的东西，你只有一个小改动要撤销，而不是一团缠成结的乱麻。

跳过第 4 到第 6 步的人，会有大约二十分钟觉得自己更快。然后他们撞上一个找不到的 bug，因为他们应用上一个已知可用的版本，在一百个改动之前。这个循环之所以让人觉得慢，恰恰是因为它从不让你积累那种债务。