Городские и общественные бани

gorodskie-bani.ru

Сейчас сам сайт крутится на старом next-js, а ИИ-агент в app. При этом старый next-js сервис выжирает гиг оперативы.

Надо все перенести в haih-agent. По сути, выполнить программирования сайта с нуля и перетащить все старые данные.



Текущая структура сайта&#x20;

![](/images/resized/middle/cmkppub1z0002mu0z427kxsay/1789938340043-image.png)

Перенести сайт на haih-agent

Например: [https://gorodskie-bani.ru/city/kurgan/bani/banya-%E2%84%9611-1720](https://gorodskie-bani.ru/city/kurgan/bani/banya-%E2%84%9611-1720)

Проработать потерянные страницы

# Цель

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

## Проблема

Сейчас агент при рекомендации или упоминании компаний/заведений отвечает в свободной форме: пишет название текстом, добавляет URL или оформляет ссылку по своему усмотрению. Фронтенд не может надежно определить, что конкретный фрагмент ответа соответствует конкретной записи заведения в базе, поэтому невозможно стабильно показывать карточки.

## Предлагаемый контракт

Добавить в протокол ответа агента специальный кастомный тег, содержащий **только идентификатор существующего заведения**. Например:

```text
<place id="PLACE_ID" />
```

Название тега можно выбрать в соответствии с текущими соглашениями проекта (`place`, `company`, `venue` и т.п.), но формат должен быть однозначным, машинно-парсируемым и документированным.

Ключевой принцип: LLM сообщает только `id`, а все отображаемые данные карточки (название, адрес, фото, рейтинг, ссылка, режим работы и т.п.) клиент/сервер получает из актуальных данных приложения. Не передавать эти поля внутри LLM-тега.

## Backend / AI

1. Дополнить системный prompt/инструкцию агента правилом: когда он рекомендует, перечисляет или предметно упоминает конкретное заведение из доступного ему каталога, использовать кастомный тег с ID этого заведения.
2. Убедиться, что в контексте/tools агента ID заведения доступен вместе с данными, по которым модель выбирает заведение.
3. Запретить модели придумывать ID. Тег допустим только для ID, полученного из результатов поиска/каталога/tools.
4. Определить fallback: если заведение нельзя надежно сопоставить с внутренним ID, агент пишет обычный текст без кастомного тега.
5. Сохранить нормальную возможность добавлять поясняющий текст вокруг карточки: например «Для семейного посещения подойдет …» + тег карточки.

## Frontend чата

1. Распознавать кастомный тег в assistant-message и не выводить его пользователю как сырой текст.
2. По `id` загружать/получать данные заведения и рендерить существующую либо новую компактную карточку заведения непосредственно внутри сообщения.
3. Поддержать несколько карточек в одном ответе, сохраняя порядок относительно текста.
4. Карточка должна быть кликабельной и вести на страницу соответствующего заведения.
5. Не интерпретировать произвольный HTML от модели: парсер должен поддерживать только явно разрешенный формат тега/атрибутов.
6. Если ID не существует, запись удалена или загрузка карточки завершилась ошибкой — сообщение не должно ломаться. Использовать безопасный fallback (например, скрыть невалидный тег либо показать нейтральную текстовую заглушку — выбрать единообразное поведение).
7. Учесть streaming: сырой незавершенный тег не должен мигать пользователю во время генерации. Парсить компонент после получения полного тега либо буферизовать потенциальный префикс тега.

## Рекомендуемый формат рендера

Ответ модели:

```text
Если хочется классическую городскую баню, я бы рассмотрел:

<place id="abc123" />

А если важнее современный SPA-формат:

<place id="def456" />
```

В UI пользователь видит текст, карточку первого заведения, следующий текст и карточку второго заведения — без отображения служебной разметки.

## Критерии приемки

- [ ] Определен и задокументирован единый синтаксис кастомного тега заведения с обязательным `id`.
- [ ] Агент получает реальные ID заведений и использует тег при рекомендациях конкретных заведений.
- [ ] Агент не генерирует тег для неизвестного/несопоставленного заведения.
- [ ] Чат корректно преобразует тег в карточку соответствующего заведения.
- [ ] В одном сообщении корректно работают несколько карточек вперемешку с обычным Markdown-текстом.
- [ ] Служебный тег не виден пользователю, включая процесс streaming.
- [ ] Невалидный/несуществующий ID не ломает рендер сообщения.
- [ ] Карточка ведет на страницу правильного заведения.
- [ ] Обычный Markdown и существующие ссылки в сообщениях продолжают работать без регрессий.
- [ ] Добавлены тесты как минимум на: один тег, несколько тегов, невалидный ID, malformed tag, streaming/частичный тег.

## Отдельно проверить перед реализацией

Стоит посмотреть текущий pipeline рендера Markdown/streaming и решить, где лучше выполнять преобразование: до Markdown-парсера через tokenizer/AST либо как разрешенное расширение рендера. Не использовать небезопасный `dangerouslySetInnerHTML` для обработки ответа модели.

Добавить структурированный тег с ID заведения в ответах агента и рендерить по нему карточку заведения в чате.

Карточки заведений в чате через кастомный тег агента

# Задача

Сейчас AI-агент на gorodskie-bani.ru не всегда понимает, о какой именно компании идёт речь, когда пользователь пишет из карточки конкретной бани/компании.

Нужно поправить передачу контекста текущей страницы в AI-чат.

## Что сделать

- передавать в запрос к AI-агенту URL текущей страницы, откуда пишет пользователь;
- по возможности передавать его как отдельный структурированный контекст, а не как часть пользовательского текста;
- убедиться, что адрес доступен агенту при каждом сообщении диалога или в устойчивом контексте сессии;
- проверить кейсы, когда пользователь пишет с карточки конкретной компании и задаёт вопрос без явного упоминания её названия;
- убедиться, что агент использует URL для определения текущей компании и не путает её с другими объектами каталога.

## Ожидаемый результат

Если пользователь находится на странице конкретной компании и спрашивает, например, «сколько стоит вход?» или «есть ли у них бассейн?», агент должен понимать, что вопрос относится именно к компании текущей страницы.

Передавать AI-агенту адрес текущей страницы, чтобы он однозначно понимал, о какой компании спрашивает пользователь.

Поправить передачу адреса страницы, откуда пишет пользователь

Сейчас у нас есть только центр города и общий радиус поиска объектов, но к примеру Москва и Московская область и так с другими областями... По идее надо искать те, что в заданном бОльшем радиусе, но не входят в меньший радиус.&#x20;

В идеале бы вообще область очерчивать, конечно, но это уже ту мач.&#x20;

gorodskie-bani.ru

Активные задачи · 5

Проработать потерянные страницы

К городам добавить параметр радиус поиска

Карточки заведений в чате через кастомный тег агента

Поправить передачу адреса страницы, откуда пишет пользователь

Перенести сайт на haih-agent