Шаг 5: Набросать модель данных

Большинство приложений на самом деле про данные: что вы храните и как части связаны между собой. Быстрый набросок модели данных избавляет вас от путаного, несогласованного кода в дальнейшем. Вам не нужна диаграмма базы данных — достаточно списка полей.

Для трекера книг есть одна главная сущность — Book:

Book
- id: уникальная строка
- title: строка
- author: строка
- status: "to_read" | "reading" | "finished"
- rating: число 1–5 (только если прочитано)
- addedAt: дата

Даже этот крошечный набросок делает решения явными: оценки существуют только для прочитанных книг, статус — одно из трёх фиксированных значений, и у каждой книги есть id. Когда вы передаёте это AI, он перестаёт угадывать имена полей и собирает согласованно.

Причина зафиксировать это пораньше в том, что имена полей просачиваются повсюду. Как только AI напишет код, читающий book.rating, это имя появится в форме, в представлении списка, в слое хранения и в любой добавленной позже функции. Если позволить ему дрейфовать — rating в одном месте, stars в другом, score в третьем — вы получите баги, которые утомительно выслеживать. Модель данных из шести строк — самая дешёвая страховка от этого.

Короткий блок спецификации, готовый к копированию, обычно работает для AI лучше, чем проза. Вот та же модель, записанная как запрос, который вы бы реально отправили:

Используй для книги именно эту форму данных. Не добавляй полей, которых
я не указал, и не переименовывай эти:

Book {
  id        — уникальная строка, генерируется при создании
  title     — строка, обязательна
  author    — строка, обязателен
  status    — одно из: "to_read" | "reading" | "finished"
  rating    — целое 1–5, присутствует ТОЛЬКО когда status = "finished"
  addedAt   — строка даты ISO, ставится при добавлении книги
}

Если думаешь, что поля не хватает, спроси меня перед добавлением.

Эта последняя строка — ask me before adding it — делает настоящую работу. Она превращает AI из угадывателя в соавтора и сохраняет модель данных вашей.