第五步：勾勒資料模型

大多數應用其實都是關於資料的：你存什麼，以及各部分之間如何關聯。快速勾勒一份資料模型，能讓你日後免於混亂、前後不一致的程式碼。你不需要畫資料庫圖——列出欄位就夠了。

對圖書追蹤器來說，主要只有一樣東西——一個 Book：

Book
- id: 唯一字串
- title: 字串
- author: 字串
- status: "to_read" | "reading" | "finished"
- rating: 數字 1–5 (僅在讀完時)
- addedAt: 日期

哪怕這麼小的一份草圖，也能讓決定變得明確：評分只對讀完的書存在，狀態是三個固定值之一，而每本書都有一個 id。當你把這個交給 AI 時，它就不再猜測欄位名，而會前後一致地構建。

之所以要趁早把這個釘死，是因為欄位名會滲透到處處。一旦 AI 寫出讀取 book.rating 的程式碼，這個名字就會出現在表單、列表檢視、儲存層，以及你日後新增的任何功能裡。如果你任由它漂移——這處叫 rating、那處叫 stars、第三處又叫 score——你就會得到一些追查起來很煩人的 bug。一份六行的資料模型，是防止這種事的最便宜的保險。

一段簡短、可複製貼上的規格塊，對 AI 而言往往比散文更管用。下面是同一個模型，寫成你真正會發出去的提示：

書籍請使用這個精確的資料結構。不要新增我沒列出的欄位，
也不要重新命名這些：

Book {
  id        — 唯一字串，建立時生成
  title     — 字串，必填
  author    — 字串，必填
  status    — 取值之一: "to_read" | "reading" | "finished"
  rating    — 整數 1–5，僅當 status 為 "finished" 時存在
  addedAt   — ISO 日期字串，新增書籍時設定
}

如果你覺得缺了某個欄位，新增前先問我。

最後那一行——ask me before adding it（要加之前先問我）——在實打實地起作用。它把 AI 從一個猜測者變成一個協作者，並讓資料模型始終歸你所有。