第五步：勾勒数据模型

大多数应用其实都是关于数据的：你存什么，以及各部分之间如何关联。快速勾勒一份数据模型，能让你日后免于混乱、前后不一致的代码。你不需要画数据库图——列出字段就够了。

对图书追踪器来说，主要只有一样东西——一个 Book：

Book
- id: unique string
- title: string
- author: string
- status: "to_read" | "reading" | "finished"
- rating: number 1–5 (only if finished)
- addedAt: date

哪怕这么小的一份草图，也能让决定变得明确：评分只对读完的书存在，状态是三个固定值之一，而每本书都有一个 id。当你把这个交给 AI 时，它就不再猜测字段名，而会前后一致地构建。

之所以要趁早把这个钉死，是因为字段名会渗透到处处。一旦 AI 写出读取 book.rating 的代码，这个名字就会出现在表单、列表视图、存储层，以及你日后添加的任何功能里。如果你任由它漂移——这处叫 rating、那处叫 stars、第三处又叫 score——你就会得到一些追查起来很烦人的 bug。一份六行的数据模型，是防止这种事的最便宜的保险。

一段简短、可复制粘贴的规格块，对 AI 而言往往比散文更管用。下面是同一个模型，写成你真正会发出去的提示：

Use this exact data shape for a book. Don't add fields I didn't list,
and don't rename these:

Book {
  id        — unique string, generated on creation
  title     — string, required
  author    — string, required
  status    — one of: "to_read" | "reading" | "finished"
  rating    — integer 1–5, present ONLY when status is "finished"
  addedAt   — ISO date string, set when the book is added
}

If you think a field is missing, ask me before adding it.

最后那一行——ask me before adding it（要加之前先问我）——在实打实地起作用。它把 AI 从一个猜测者变成一个协作者，并让数据模型始终归你所有。