Как собрать ДнД мастера на нейросети, который не ломает механику игры

Разработчик браузерной текстовой RPG, где ведущим работает языковая модель, описал четыре конкретные проблемы на стыке вероятностного ИИ и жёсткой игровой арифметики. Игрок пишет действие своими словами, нейросеть отвечает рассказом, а параллельно движок на коде ведёт лист персонажа: здоровье, деньги, характеристики, инвентарь, броски d20. Ниже разбираем, как это устроено и что из этого опыта пригодится тем, кто хочет собрать собственного ДнД мастера на нейросети или просто лучше понять, где модели нужна жёсткая рамка.

Что понадобится

• Языковая модель с поддержкой JSON-ответов. Подойдут модели, доступные через OpenRouter (агрегатор, который даёт единый доступ к десяткам моделей по API). В России можно попробовать YandexGPT или GigaChat, если они поддерживают структурированный вывод.
• Серверная часть. В оригинале используется Node.js 24 с Express и встроенной базой данных node:sqlite. Для экспериментов хватит любого бэкенда, умеющего отправлять HTTP-запросы к API модели.
• Базовое понимание промпт-инжиниринга (промпт-инжиниринг, умение формулировать задания для модели так, чтобы она отвечала в нужном формате и стиле).
• Время: от пары вечеров на прототип до нескольких недель на отлаженный продукт.

Как собрать ДнД мастера на нейросети: пошаговая инструкция

1. Отдайте механику коду, а модели оставьте только рассказ. Не просите модель «ответь и обнови лист персонажа целиком». Она забудет предметы, раздаст мечи с бонусом +100 и через десяток ходов потеряет счёт деньгам. Вместо этого модель возвращает строгий JSON, где кроме текста рассказа есть только изменения: сколько здоровья отнять, какой предмет добавить, какой факт запомнить. Применяет изменения движок, и он же проверяет границы: броня не режет урон больше чем вдвое, характеристики не уходят в бесконечность.

{
  "check": { "stat": "ХАР", "dc": 12, "why": "уговорить дракона", "ok": true },
  "narration": "Дракон открывает один глаз…",
  "hp": -3,
  "add": [{ "name": "Чужой сапог", "icon": "👢", "slot": "feet", "def": 1 }],
  "fact": "Гоша назвал дракона папой"
}

1. Сохраняйте ключевые факты в отдельную хронику. Поле fact из JSON уходит в короткий список событий, который подмешивается в промпт следующих ходов. Так нейросеть-мастер помнит, что двадцать ходов назад герой назвал дракона папой, а вся история целиком в контекст (окно внимания модели, сколько текста она «видит» за раз) не тащится.

2. Бросайте кубик заранее, до запроса к модели. Наивный подход: сначала модель решает, нужна ли проверка, потом игрок бросает кубик, потом второй запрос за рассказом. Это двойная цена и двойная задержка. Вместо этого сервер кидает d20 до запроса и кладёт результат прямо в промпт:

КУБИК: выпало 14, с бонусом Харизмы итог 16.

Системный промпт (системный промпт, скрытая от пользователя инструкция, задающая поведение модели) объясняет правило: если проверка нужна, первым полем ответа идёт check с характеристикой, сложностью и результатом, а рассказ пишется с учётом исхода. Если проверка не нужна, поле check отсутствует, кубик не упоминается.

1. Прячьте исход от игрока до нажатия кнопки. Сервер хранит ответ «запечатанным». Игроку показывается только «нужна проверка Харизмы, сложность 12» и анимация кубика. Поле ok (успех или провал) вырезается. Игрок нажимает «Бросить», рассказ открывается без нового запроса к модели.

2. Страхуйте арифметику модели кодом. Модели иногда пишут «успех» при итоге ниже сложности. Перебрасывать нельзя, рассказ уже написан. Поэтому сервер подвигает сложность так, чтобы честный результат совпал с текстом. Критические 1 и 20 не корректируются: это неприкосновенные значения в настольных RPG.

3. Явно укажите тип каждого числового поля: изменение или итоговое значение. Тестировщики обнаружили баг: стоило мастеру прибавить герою максимум здоровья, как дальше он удваивался. Причина: в промпте было написано «hp, money, stats это изменения», а про max_hp ни слова. Модель видела «Здоровье 10/20», решала прибавить крепости и писала max_hp: 20 как итог. Движок честно складывал: 20, 40, 80. Решение двухслойное:

4. В промпте max_hp добавлен в список изменений с правилом «меняй редко и не больше чем на четверть».

5. В коде стоит страховка: число больше допустимого шага считается итоговым и превращается в разницу, а сам шаг ограничен плюс-минус 25%.

6. Настройте стиль мастера через позицию блока в промпте. Стили «Классика», «Угар», «Хам», «Эпос», «Документалка» поначалу звучали одинаково: блок стиля стоял в середине длинного системного промпта, и модель его просто теряла. Три правки, которые помогли:

7. Перенести блок стиля в самый конец системного промпта.

8. Продублировать одной строкой прямо перед действием игрока: (Стиль ведущего: Хам.).
9. Дать каждому стилю свой лимит объёма ответа.

Строка-напоминание оказалась самым дешёвым и самым действенным приёмом: десяток токенов (токен, минимальная единица текста для модели, примерно 3/4 русского слова), а разница в поведении модели заметна сразу.

Что делать с этим прямо сейчас по ролям?

Авторам Дзена и копирайтерам. Принцип «модель придумывает, код проверяет» работает и для контента: пусть нейросеть генерирует черновик, а жёсткая рамка (чек-лист фактов, лимит длины, обязательные поля) применяется снаружи. Это и есть продуктивный промпт-инжиниринг.

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

Предпринимателям в РФ и СНГ. Полностью повторить этот стек можно и с российскими моделями. YandexGPT и GigaChat умеют отвечать в формате JSON. Главное правило то же: не доверяйте модели то, что умеет обычный код.

Разделение ответственности между моделью и кодом, пожалуй, самый практичный урок из этого проекта: нейросеть-мастер для ДнД работает ровно до тех пор, пока ей не дают считать деньги.