Как сделать мобильный аудиогид для самостоятельных городских прогулок: карта, поиск мест и озвучка на базе AI

Мобильный аудиогид для самостоятельных городских прогулок лучше строить как карта-first приложение. Пользователь открывает карту, видит интересные места рядом, изучает карточку объекта, добавляет точки в маршрут, получает навигацию и слушает короткий рассказ по запросу или после прибытия.

Для надежной работы нужны четыре независимых слоя. Геосервисы передают координаты и строят путь, база знаний хранит проверенные факты, LLM собирает связный рассказ по ограниченному контексту, а TTS превращает готовый текст в аудио. Такая схема снижает риск случайных выдумок и позволяет отдельно менять поиск, языковую модель или голосовой движок.

GPS и ГЛОНАСС дают приложению данные о положении на местности, UTC служит базовым стандартом системного времени, а мобильная сеть обеспечивает получение контента и маршрутов. В городе координата может колебаться между зданиями, поэтому геотриггер прибытия должен учитывать расстояние, направление движения, время нахождения в зоне и уже прослушанные точки. AI здесь помогает искать, сокращать и озвучивать информацию, но не заменяет проверенные источники.

Как устроен мобильный аудиогид для прогулок по городу

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

Базовый цикл пользователя: найти, выбрать, дойти, послушать

Основной сценарий можно описать шестью шагами:

1. Приложение получает разрешение на геолокацию и показывает текущую позицию пользователя на карте.
2. Пользователь ищет места рядом по радиусу, категории или свободному запросу, например исторические здания, мосты, музеи или площади.
3. Карточка объекта показывает название, расстояние, краткое описание, доступные языки и происхождение фактов.
4. Пользователь добавляет точку в маршрут. Порядок остановок можно изменить вручную, а путь пересчитать.
5. Приложение показывает направление, расстояние и прогресс приближения. Для построения пути можно использовать встроенный маршрут или передать задачу внешнему навигатору.
6. Аудио запускается вручную из карточки или автоматически после подтверждения прибытия в геозону.

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

Маршрут экскурсии и навигационный путь решают разные задачи. Первый определяет смысл прогулки и порядок объектов, второй помогает физически перейти между точками. Один маршрут может включать несколько остановок, а навигация должна перестраиваться после удаления или перестановки объекта.

Почему карта должна быть главным экраном

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

Показателен аудиомаршрут по каналам Амстердама. В часовом круизе рассказ связан с конкретными объектами и видами по пути: домом Анны Франк, Рейксмузеумом, площадью Лейдсеплейн, церковью Вестеркерк и Магере-Брюг, который называют Тощим мостом. В описании маршрута фигурируют три пункта отправления, а аудиогид доступен на 19 языках. Такой формат связывает звук с реальным объектом, а не с абстрактной темой о городе.

Маршрут может немного меняться от поездки к поездке и открывать известные достопримечательности вместе со скрытыми уголками. Похожую механику геолокационного аудиогида разбирает статья о приложении Wrinkles: сервис связывает истории с местами вокруг пользователя и поддерживает hands-free формат. В его описании упоминаются 1,3 млн точек интереса в 177 странах, но эти масштабы нельзя переносить на новый проект без собственной базы и проверки покрытия.

Экран карты стоит разделить на постоянные и контекстные элементы. К постоянным относятся позиция пользователя, выбранный масштаб, состояние маршрута и компактный плеер. Контекстными остаются фильтры, карточка объекта, действия добавления и кнопка навигации. Такое разделение сохраняет ориентирование, когда пользователь открывает сведения о здании.

Карта как главный экран в приложении аудиогида

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

Поиск мест рядом на карте в приложении

Поиск рядом должен работать в трех режимах:

• По радиусу. Пользователь задает область вокруг текущей позиции, например 500 метров, и получает ограниченный список объектов.
• По категории. Фильтры включают музеи, исторические здания, храмы, мосты, площади, памятники и другие типы мест, которые есть в базе.
• По тексту. Запрос вроде «модернистская архитектура рядом» или «места, связанные с историей города» передается в поиск по метаданным и базе знаний.

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

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

Поиск можно ранжировать по простой формуле: сначала объекты в пределах выбранного радиуса, затем точки с корректными координатами и подтвержденными фактами, после них места, которые соответствуют категории или текстовому запросу. Сложный рекомендательный алгоритм для первого MVP не нужен.

Карточка объекта: что нужно узнать до добавления в маршрут

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

Поле	Зачем нужно
Название и альтернативные названия	Помогают найти объект и распознать его на местности.
Категория	Показывает, что перед пользователем: мост, музей, площадь или здание.
Расстояние и время подхода	Позволяют оценить, подходит ли точка для текущего маршрута.
Краткое описание	Дает причину добавить объект, не раскрывая весь рассказ.
Координаты и статус точки	Нужны для навигации и проверки корректности геотриггера.
Языки озвучки	Показывают, доступен ли рассказ на выбранном языке.
Происхождение фактов	Позволяет проверить информацию и дату ее последней редакторской проверки.

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

Ручное добавление точек и порядок остановок

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

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

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

Навигация к выбранному месту

После выбора точки интерфейс переходит в состояние навигации. На экране остаются:

• название текущей остановки;
• расстояние до нее;
• направление движения или линия пути;
• индикатор приближения;
• кнопка запуска аудио;
• кнопка ручного запуска следующего рассказа.

Если пользователь открывает внешний навигатор, приложение сохраняет идентификатор текущей остановки и состояние плеера. После возврата оно должно показать прежний маршрут, а не возвращать пользователя на главный экран без контекста. Такой сценарий особенно важен для первого MVP, где внешняя навигация может закрывать часть задач маршрутизации.

Как разделить поиск фактов, генерацию рассказа и озвучку

Один вызов LLM не должен одновременно искать исторические сведения, оценивать их достоверность, писать текст и синтезировать голос. У каждой операции разные ошибки и критерии качества. Поиск отвечает за релевантность, база знаний за происхождение фактов, генерация за форму рассказа, TTS за произношение и удобство прослушивания.

Слой фактов: база объектов и проверенные источники

Карточка фактов выступает источником правды для модели. В ней хранятся:

• название, альтернативные названия и варианты написания;
• координаты, адресная привязка и категория;
• даты строительства, реконструкций и значимых событий;
• архитектурные особенности и связи с людьми или организациями;
• утвержденные формулировки для спорных тем;
• ссылки на исходные материалы и дата их проверки;
• языковая версия, статус публикации и срок следующего пересмотра.

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

Поиск и RAG: как передать модели только релевантный контекст

Для нажатия на точку достаточно найти объект по идентификатору и передать его утвержденные факты. Свободный вопрос пользователя требует retrieval по базе знаний. В этом случае поиск может учитывать объект, категорию, расстояние, язык и тему запроса.

Упрощенный pipeline выглядит так:

1. Клиент отправляет координаты, выбранную точку, язык и режим рассказа.
2. Backend выбирает актуальную версию карточки объекта.
3. RAG-контур достает релевантные фрагменты и отбрасывает материалы другой тематики.
4. LLM получает ограниченный контекст, инструкцию по длине и правила обращения с неопределенностью.
5. Система сохраняет текст вместе с версией фактов и промпта.

RAG повышает управляемость ответа, но не проверяет истинность документа автоматически. Если в базу попал синтетический или устаревший текст, retrieval передаст модели именно эту ошибку. Поэтому проверять нужно и поиск, и качество самих документов.

Разбор подхода с закрытой базой регламентов в статье о Blue Voice и ведомственном RAG хорошо иллюстрирует общую идею: ссылка на первоисточник и метаданные важнее уверенного тона ответа.

Генерация связного рассказа без выдуманных деталей

LLM стоит использовать как редактора и рассказчика. Она может сократить набор фактов, расставить смысловые акценты, адаптировать стиль под прогулку и собрать короткую последовательность предложений.

В промпте нужны явные ограничения:

• использовать только переданный контекст;
• не добавлять даты, имена и причинно-следственные связи без подтверждения;
• отделять установленный факт от предположения;
• сообщать о нехватке данных вместо заполнения пробела;
• соблюдать заданную длительность рассказа;
• избегать формулировок, которые звучат как инструкция по безопасности или навигации, если это исторический фрагмент.

Полезный шаблон запроса можно хранить в виде отдельных блоков:

Контекст: подтвержденные факты об объекте
Задача: написать короткий рассказ для прогулки
Ограничения: не добавлять сведения вне контекста
Формат: текст для озвучки, одна мысль в абзаце
Если данных мало: прямо сообщить об этом

Ответ сервиса стоит возвращать вместе с использованной версией фактов и результатом проверки. Пользователь может видеть источник в карточке объекта, а редактор получает возможность быстро выяснить, почему конкретное предложение попало в аудио.

TTS и подготовка аудио

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

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

Смену языка нужно обрабатывать как отдельную версию контента. Перевод, текст для озвучки и аудиофайл могут иметь разные статусы готовности. Пример мультиязычного гида на 19 языках показывает продуктовый ориентир, но это число не нужно переносить в первый релиз без редакторских ресурсов и проверки произношения названий.

TTS не следует смешивать с audio-native LLM. В разборе GigaChat Audio 10B описана модель, которая обрабатывает аудио напрямую через Conformer-энкодер и Mixture-of-Experts декодер, без обязательной транскрипции. Для аудиогида на первом этапе обычно нужен более простой контракт: проверенный текст на входе, синтезированная речь на выходе.

Сценарии прогулки: аудио по запросу и по прибытию

Автоматические подсказки экономят внимание, но лишают контроля, если приложение запускает звук при каждом колебании координаты. Ручной и автоматический режимы должны сосуществовать, а пользователь должен в любой момент остановить, повторить или пропустить рассказ.

Режим по запросу

В ручном режиме пользователь запускает рассказ из карточки объекта, списка маршрута или компактного плеера на карте. Плеер поддерживает:

• пуск и паузу;
• повтор текущего фрагмента;
• переход к следующему блоку;
• пропуск объекта;
• возврат к карте;
• запуск рассказа о следующей остановке до прибытия.

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

Режим по прибытию

Геотриггер реагирует на приближение к точке, но не должен зависеть от одного измерения координаты. Надежнее использовать последовательность состояний:

1. Далеко. Точка видна в маршруте, автоматический запуск не готовится.
2. Приближение. Расстояние уменьшается, приложение проверяет направление и скорость движения.
3. Кандидат на прибытие. Пользователь вошел в геозону, система ждет несколько обновлений координаты.
4. Подтверждено. Условия выполнены, приложение предлагает или запускает аудио согласно настройкам.
5. Прослушано. Точка получает отметку, повторный запуск блокируется на заданный cooldown.
6. Покинуто. После выхода из зоны объект можно снова считать доступным для ручного прослушивания.

Размер геозоны и задержку подтверждения подбирают по конкретной улице. Между широким проспектом и узким двором будут разные условия приема сигнала. Настройки должны позволять выключить автоматический запуск, разрешить его только для точек текущего маршрута и ограничить одновременное воспроизведение.

Голосовые подсказки на маршруте

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

Тип сообщения	Пример	Приоритет
Навигационная команда	Поверните направо через 30 метров	Высокий
Предупреждение о точке	Через минуту впереди объект маршрута	Средний
Исторический рассказ	Краткая история здания и деталь для осмотра	Обычный

Навигационная команда может временно поставить рассказ на паузу. После нее плеер продолжает воспроизведение или показывает кнопку повтора, если пользователь мог пропустить часть сообщения. Одновременный запуск двух аудиопотоков нужно запретить на уровне состояния плеера.

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

Архитектура MVP приложения-аудиогида с картой

Первый прототип должен разделять мобильный клиент, backend, хранилище контента, сервис генерации текста и TTS. Конкретный стек зависит от требований к картам, приватности, языкам, стоимости запросов и необходимости работать без сети.

Мобильный клиент: карта, состояние маршрута и плеер

На устройстве хранятся и обновляются:

• текущая геопозиция и статус разрешения;
• список точек рядом;
• выбранный маршрут и порядок остановок;
• текущая остановка и состояние геотриггера;
• состояние плеера, язык и прослушанные фрагменты;
• кэш метаданных, текста и готового аудио;
• состояние последнего ответа backend.

При сворачивании приложения клиент должен сохранять маршрут и не терять текущий фрагмент. При кратковременной потере сети он показывает уже загруженные данные и объясняет, какие действия временно недоступны. Запрос доступа к геолокации нужно связывать с понятным сценарием, иначе отказ пользователя сломает весь основной путь.

Backend и модель данных

Минимальная модель может включать следующие сущности:

Сущность	Основные поля
Объект	Название, координаты, категория, адрес, статус публикации.
Факты	Утверждения, даты проверки, редакторский статус, ограничения формулировок.
Источник	Название материала, ссылка на исходный документ, дата обращения.
Текст	Язык, версия промпта, версия фактов, длина и статус проверки.
Аудиофайл	Язык, голос, параметры TTS, ключ кэша, длительность и статус.
Маршрут	Список объектов, порядок остановок, настройки автоматического режима.
Геотриггер	Зона прибытия, задержка подтверждения, cooldown, состояние точки.

Версионирование позволяет обновить спорную дату или аудиотекст, сохранив историю публикаций. Без версий трудно понять, какой набор фактов использовала старая запись и нужно ли заново создавать аудио.

AI-сервисы как отдельные этапы pipeline

Backend лучше связывать с тремя отдельными API:

1. Поиск контекста. Принимает объект, координаты, язык и запрос, возвращает релевантные проверенные записи.
2. Генерация текста. Получает контекст и правила формата, возвращает рассказ с метаданными версии.
3. TTS. Принимает утвержденный текст, язык и параметры голоса, возвращает аудиофайл.

Для каждого этапа нужны свои ошибки. Поиск может вернуть пустой результат, LLM может нарушить формат, TTS может быть недоступен или неправильно произнести название. Клиент должен различать эти состояния и предлагать понятное действие: выбрать другую точку, запустить сохраненный файл или прочитать краткое описание.

В логах полезно хранить входной контекст, версию промпта, идентификатор модели, результат проверки и время ответа. Повторную генерацию следует запускать после изменения контекста или параметров. Многократный вызов той же модели не исправляет неподтвержденный факт.

Что включить в первый MVP

Рациональный первый вариант ограничивается одной городской зоной и небольшим набором проверенных точек. В него входят:

• карта с текущей позицией;
• поиск мест рядом;
• карточка объекта с источником фактов;
• ручное добавление и перестановка точек;
• навигация к выбранному месту;
• запуск короткого аудио по запросу;
• один простой геотриггер прибытия;
• кэширование заранее подготовленных текстов и аудио.

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

GPS, ГЛОНАСС, UTC и ограничения городской навигации

Навигационный слой опирается на спутниковые системы вроде GPS и ГЛОНАСС. Мобильные телефоны, компьютеры и навигаторы используют UTC как базовый стандарт времени, связанный с атомным временем. Для аудиогида это важно при синхронизации геособытий, времени обновления маршрута, кэширования и журналов воспроизведения.

Почему GPS ошибается между зданиями

Плотная застройка создает несколько проблем:

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

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

Геозона прибытия и защита от повторных запусков

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

После запуска аудио точка получает отметку прослушивания. Повторное пересечение границы не запускает тот же рассказ автоматически, пока не закончится cooldown или пользователь явно не нажмет кнопку повтора. Выход из зоны и возвращение к ней должны обрабатываться отдельно, иначе колебания GPS создадут цепочку одинаковых запусков.

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

Сеть, кэш и проектируемый офлайн-сценарий

Операции приложения удобно разделить на сетевые и заранее сохраняемые:

Операция	Что можно сохранить заранее	Что требует сети
Маршрут	Список точек, координаты и последнюю построенную линию.	Новый расчет пути и обновление дорожных ограничений.
Карточка объекта	Название, описание, факты и статус проверки.	Загрузка новой версии данных.
Аудио	Готовые файлы выбранного языка.	Создание нового файла через TTS.
Поиск	Недавние результаты и локальный набор точек.	Новый запрос по большой базе и свободному тексту.

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

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

Как контролировать качество AI-рассказов об объектах

Исторический аудиогид формирует доверие через точность деталей. Ошибка в имени, дате или расположении здания заметнее, чем неудачная стилистическая фраза. Поэтому редакторский процесс должен проверять и исходную базу, и текст, который создала LLM.

Что AI может делать, а что лучше оставить редактору

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

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

Источники, версии и трассировка ответа

Для каждого рассказа нужно сохранять:

• набор фактов, который попал в контекст;
• ссылки на исходные материалы;
• дату проверки и автора редакторского изменения;
• версию промпта и языковой модели;
• результат проверки текста;
• версию TTS и параметры голоса;
• связанный аудиофайл и дату его создания.

В карточке объекта достаточно показать название источника и дату проверки. Техническую трассировку можно оставить в панели редактора, где она помогает воспроизвести ответ и быстро обновить устаревший фрагмент.

Редакторский чек-лист перед публикацией

• Каждое утверждение соответствует фактам из карточки.
• В тексте нет придуманных имен, дат, событий и архитектурных деталей.
• Рассказ укладывается в заданную длительность и делится на понятные блоки.
• Названия улиц, площадей и зданий правильно произносятся.
• Координата указывает на фактическую точку осмотра, а не на случайный адрес рядом.
• Исторический рассказ не перебивает навигационную команду.
• Язык, версия фактов и аудиофайл совпадают.
• У спорных или неполных сведений есть явная редакторская оговорка.

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

Проверка приложения перед запуском прогулок

Тестировать аудиогид нужно на улице, с реальным движением, сменой экранов и нестабильной сетью. Проверка отдельных API не показывает, сможет ли пользователь пройти маршрут без лишних решений.

Проверка сценария от карты до аудио

Основной тестовый путь выглядит так:

1. Открыть карту и выдать или отклонить разрешение на геолокацию.
2. Найти несколько мест рядом через радиус и категорию.
3. Открыть карточку, проверить расстояние, источник фактов и язык аудио.
4. Добавить точки в маршрут и изменить их порядок.
5. Запустить навигацию к выбранному месту.
6. Вернуться из внешнего навигатора и убедиться, что маршрут сохранился.
7. Запустить аудио вручную.
8. Повторить путь с автоматическим геотриггером.
9. Поставить рассказ на паузу, пропустить фрагмент и вернуться к карте.

На каждом шаге фиксируют, какое решение принимает пользователь. Если действие требует поиска нужной кнопки или повторной настройки маршрута, интерфейс стоит упростить до запуска публичной версии.

Проверка отказоустойчивости

Минимальный набор негативных сценариев включает:

• отказ в доступе к геолокации;
• слабый или пропавший мобильный сигнал;
• пустой результат поиска;
• отсутствие готового аудио;
• недоступность TTS;
• скачок GPS-координаты;
• повторный вход в одну геозону;
• несовпадение координаты с фактическим входом к зданию;
• возврат из внешней навигации;
• обновление фактов после создания старого аудиофайла.

Для каждого сбоя нужен предсказуемый результат. При недоступном TTS приложение запускает сохраненный файл или показывает текст. При отсутствии фактов оно сообщает о недостатке информации. При потере сети сохраняет уже загруженный маршрут и не удаляет прогресс прогулки.

Критерий готовности первой версии

MVP можно считать готовым, если пользователь без лишних экранов находит несколько проверенных точек, вручную собирает маршрут, понимает направление движения и получает короткое корректное аудио. Этот путь должен сохраняться при сворачивании приложения, временной потере сети и неточном GPS.

Публичный запуск не требует автоматической генерации рассказа для каждого места в городе. Надежнее начать с одной зоны, ограниченного набора объектов и прозрачного происхождения фактов. Новые языки, рекомендации и автоматические маршруты добавляют после проверки базового сценария.

Главное правило продукта формулируется коротко: карта отвечает за движение, база за факты, LLM за связность рассказа, TTS за голос. Если данных недостаточно, приложение должно сказать об этом и сохранить управление у пользователя.

Подписаться на канал