Система понятий записана, словарь согласован — теперь их можно превратить в главный рабочий артефакт продукт-инженера: спецификацию, по которой агент строит фичу, а ты её принимаешь. Разберём, как модель понятий разворачивается в спеку и почему без неё спека — просто длинный промпт с надеждой.

Спека — это онтология с обязательствами

Посмотри, из чего состоит хорошая спецификация функциональности:

  • Сущности и их атрибуты — понятия модели: заказ, позиция, платёж.
  • Статусные модели — состояния понятий и разрешённые переходы: draft → placed → paid → shipped, «из cancelled переходов нет».
  • Команды — что можно сделать: «оформить заказ», «отменить», «оплатить» — с предусловиями («оплатить можно только placed»).
  • События — что происходит в результате: «заказ оформлен», «платёж получен» — то, на что реагируют другие части системы.
  • Инварианты — правила, которые не нарушаются никогда: «сумма позиций равна сумме заказа», «у заказа ровно один клиент».
  • Критерии приёмки — проверяемые сценарии: дано → когда → тогда.

Заметь: первые пять пунктов — это ровно элементы онтологии (объекты, состояния, события, отношения, правила), только с обязательствами: спека не просто описывает понятия, она фиксирует, что система гарантирует про них. Поэтому попытка «написать спеку» без модели понятий и проваливается: нечего разворачивать. Получается пересказ хотелок, где агенту всё равно приходится угадывать, что такое «заказ» и можно ли оплатить отменённый.

Порядок работы

Путь от проблемы до спеки выглядит так:

  1. Понятия и связи — модель домена (как строить): существительные бизнеса, кратности, границы.
  2. Состояния — у каких понятий есть жизненный цикл; нарисуй переходы, запрещённое — важнее разрешённого.
  3. Команды и события — глаголы бизнеса: что пользователи и системы делают (команды) и что происходит (события). Словарь — единый: CancelOrder и OrderCancelled, а не синонимы по настроению.
  4. Инварианты — что должно быть истинно всегда. Это самое ценное для агента: инвариант нельзя «понять по-своему».
  5. Критерии приёмки — сценарии, по которым ты примешь результат. Они же — основа тестов.

На выходе — документ на несколько страниц, где нет ни слова про фреймворки и таблицы: только домен. Техника (какая БД, какой транспорт) добавляется отдельным разделом и не смешивается с моделью — мы уже видели, что бывает при смешивании.

Почему это работает с агентом

Спека такого вида — идеальный вход для AI по трём причинам:

  • Она проверяема. Инварианты и критерии приёмки — это готовые тесты: приёмка результата превращается из «вроде похоже» в прогон сценариев.
  • Она устраняет угадывание. Агент не решает сам, можно ли оплатить отменённый заказ, — это записано. Чем меньше свободы в смысле, тем больше пользы от скорости агента: свобода остаётся там, где она уместна, — в реализации.
  • Она переживает сессии. Контекст сессии исчезает, спека остаётся. Следующая сессия (или другой агент, или ты через месяц) стартует от того же документа — три сессии дают одно решение, а не три.

Дальше эта дисциплина масштабируется: спека на команду/фичу — рабочая единица, набор спек — модель сервиса. По этому принципу устроена методология Use Case Pattern, на которой стоит весь этот сайт: спецификация живёт рядом с кодом, исполняется агентом и проверяется на каждом изменении. Здесь важно понять сам мостик: онтология → спека → код агента → приёмка по критериям.

Коротко

  • Спека = онтология с обязательствами: сущности, состояния, команды, события, инварианты + критерии приёмки. Без модели понятий спека вырождается в пересказ хотелок.
  • Порядок: понятия → состояния (запрещённое важнее разрешённого) → команды и события в едином словаре → инварианты → критерии приёмки.
  • Домен отдельно, техника отдельно — спека не про таблицы и фреймворки.
  • С агентом это работает, потому что спека проверяема (критерии = тесты), устраняет угадывание (инварианты не интерпретируются) и переживает сессии.
  • Мостик продукт-инженера: онтология → спека → код агента → приёмка. Это ядро подхода Use Case Pattern.

Дальше — онтологии и графы знаний для LLM: как записанная система понятий помогает не только строить, но и спрашивать — когда векторного поиска мало.