Прежде чем писать код, спеку или промпт для агента, нужно ответить на вопрос, который почти никогда не задают вслух: из каких понятий состоит наша задача и как они связаны? Ответ на него называется страшным словом «онтология», но за ним — простая и очень практичная вещь. Разберём без философии.

Онтология — это система понятий

Онтология предметной области — это описание того, какие в ней есть понятия, какими свойствами они обладают и как связаны между собой. «Заказ состоит из позиций. У заказа есть владелец-клиент. Заказ оплачивается платежом. Отменённый заказ нельзя оплатить» — вот кусочек онтологии интернет-магазина: четыре понятия, связи между ними и одно правило.

Важно понять: онтология есть у любого проекта — вопрос лишь, записана ли она. Команда в любом случае оперирует какими-то понятиями. Если система понятий нигде не зафиксирована, она живёт в головах — у каждого своя версия. Продакт под «заказом» понимает одно, разработчик — другое, а служба поддержки — третье. Все три версии работают, пока не встретятся в одном спринте.

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

Модель не бывает «правильной» — она бывает подходящей

Первая ловушка новичка — искать «истинную» модель предметной области. Её не существует. Один и тот же мир можно описать разными системами понятий, и все они будут корректны — но по-разному эффективны для разных задач.

Пример: что такое «клиент» для магазина? Для маркетинга — профиль с историей интересов. Для платежей — плательщик с реквизитами. Для доставки — получатель с адресом. Это три разные модели одного человека, и попытка сделать одну «универсальную» даст худшую из всех: раздутое понятие, неудобное каждому.

Критерий качества модели — не истинность, а пригодность: помогает ли она решать задачи, ради которых построена, и одинаково ли её понимают все участники.

Уровни абстракции

Второй практичный инструмент — понимать, на каком уровне ты сейчас говоришь. Понятия выстраиваются в этажи:

  1. Конкретный экземпляр — заказ №4211 от Иванова на 3 400 ₽.
  2. Тип — «заказ»: у любого заказа есть номер, клиент, позиции, статус.
  3. Тип типов — «бизнес-сущности»: заказы, клиенты, платежи — всё это сущности с жизненным циклом.
  4. Методология — правила, по которым мы вообще описываем сущности (например, соглашение «у каждой сущности есть владелец и статусная модель»).

Половина запутанных споров в командах — это спор людей, находящихся на разных этажах. Один обсуждает конкретный заказ («а вот тут заказ без клиента!»), второй — тип («заказа без клиента не бывает по определению»). Умение заметить «мы на разных уровнях» экономит часы.

Есть и совсем базовые наборы понятий, к которым сводится почти любая модель. Один из известных: объект, отношение, состояние, событие, класс. Присмотрись — это же скелет любой доменной модели: сущности, связи, статусы, доменные события и типы. Классические работы по онтологиям и работы по DDD пришли к одному и тому же с разных сторон.

Зачем это продукт-инженеру в AI-эпоху

Раньше нестыковку понятий сглаживали люди: аналитик переспросит, разработчик догадается, тестировщик заметит. Агент не переспросит. Модель работает только с тем, что ей дали, и заполняет пробелы правдоподобными догадками — уверенно и молча. Если в твоей голове «заказ» один, а в промпте описан другой, агент реализует третий.

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

Коротко

  • Онтология — система понятий предметной области: понятия, свойства, связи, правила. Она есть у любого проекта; вопрос — записана или живёт в головах разными версиями.
  • Модель не бывает «истинной» — только подходящей под задачу; универсальное понятие «для всех» обычно худшее для каждого.
  • Понятия живут на уровнях абстракции (экземпляр → тип → тип типов → методология); споры «на разных этажах» — источник половины недопониманий.
  • Почти любая модель сводится к базовому набору: объект, отношение, состояние, событие, класс — это скелет и доменной модели, и будущей спеки.
  • В AI-эпоху цена незаписанных понятий выросла: агент не переспрашивает, а достраивает пробелы догадками.

Дальше — концептуальная модель — не схема базы данных: почему прыжок «сразу в таблицы» ломает проекты и что моделировать до структуры хранения.