第五步：勾勒数据模型

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

对图书追踪器来说，主要只有一样东西——一个 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 从一个猜测者变成一个协作者，并让数据模型始终归你所有。