Transcription
Сегодня я покажу, как сделать help-центр внутри приложения. Как, наверное, многие из вас знают, я занимаюсь созданием приложения для онлайн фитнес-тренеров. Оно называется онлайн Fitness App. И, э, сегодня я хочу сделать help-центр или такой справочный центр, базу знаний прямо внутри приложения. Приложение выглядит приблизительно вот так. Здесь у меня, конечно, есть AI ассистент, который отвечает на любые вопросы, но я хочу добавить куда-нибудь вот сюда, а специальный раздел Help-центр, где будет, скажем так, э каталог всяческих статей, ответов на вопросы и так далее и тому подобное. И прямо сейчас мы вместе с вами спроектируем эту фичу и реализуем её от начала до конца.
У меня уже есть небольшие наработки в этой области. У меня уже в админке моего приложения есть раздел Help Articles, в котором есть админка, скажем так, для того, чтобы создавать эти статьи. Выглядит она приблизительно вот так вот. Здесь можно каждую статью отредактировать. У неё есть статус публикации, есть аудитория, э, которая определяет, кому доступна эта статья, всем пользователям, клиентам тренеров или тренерам. И есть категория. Вот. И, ну, вот так вот выглядит форма редактирования. Здесь немножечко, а, скажем так, технический редактор. Здесь нету никакого низвига, ничего. Пока что всё в формате markdown, но я думаю, что для начала этого будет достаточно. Дальше мы уже докрутим какой-то Rich Editor или что-то в этом роде.
Я пока не знаю точно, как будет работать эта фича и как будет выглядеть наш help-центр. Ну, думаю, что это должен быть раздел в основном меню, в которой ты заходишь, и там у тебя есть каталог статей с каким-то удобным поиском, с навигацией, с, возможно, какими-то категориями, не знаю, сейчас мы всё это спроектируем. И, конечно, к этой же базе знаний у нас будет подключен AI агент, который сможет отвечать на произвольные вопросы, которые будут задавать пользователи. И нам нужно будет в этой базе знаний э каким-то образом явно сообщить пользователям, что можно вот тут вот в чатике поспрашивать. Ну и давайте не будем затягивать, а перейдём сразу к делу.
А я открываю VS-код, стартую новую сессию чата и для этой задачи я решил попробовать GPT 5.4. Это самая последняя модель от Open AI. И посмотрим, как она справится с этой задачей. У меня здесь уже есть некоторые наработки. У меня есть миграция, которую я использовал для того, чтобы создать вот эти, скажем так, статьи в нашей базе знаний Help Articles. И мы будем использовать их в качестве контекста для LLMки, чтобы она знала, в чём вообще, собственно, суть и про что будет наша база знаний. Начнём мы, конечно же, как всегда, с плана. А вот таким образом я добавляю этот файл в контекст, переключаюсь в полноэкранный режим, чтобы нас ничто не отвлекало. Вставлю сюда курсор. Давайте чучуть сделаем побольше. И начинаю наговаривать промт.
Смотри, у меня появилась такая идея. Я хочу прямо внутри нашего приложения в левом меню для тренера и для клиента добавить новый раздел, который будет называться Help или, я не знаю, ну, допустим, help, да. Вот. И в нём должна быть э справочная информация. Я думаю, что это должна быть такая своего рода база знаний, в которой человек может навигироваться, находить часто задаваемые вопросы, смотреть информацию по конкретным разделам. В общем, что-то приблизительно должно быть похоже на базу знаний, которую даёт, например, Intercom. Я хочу, чтобы мы с тобой в отдельном Markdown файле спроектировали эту фичу. У меня уже есть некоторые наработки в приложении. У меня есть Entity Object, называется Help article. В этих статьях уже понаписано какое-то количество статей. И вот я тебе для примера прикрепил файл с миграцией, который мы использовали для того, чтобы загрузить в базу данных Firestore все эти статьи. Я хочу, чтобы ты помог мне спроектировать суперклассную, суперудобную Mobile first базу знаний. Я хочу, чтобы ты задавал мне вопросы, если что-то непонятно или нужно принять какое-либо решение. Ну и, конечно, эта база знаний, она должна учитывать, что у нас есть несколько типов пользователей. Это тренера и клиенты тренеров. И, соответственно, каждому типу пользователей будет доступен свой тип статей. Редактируются эти статьи через нашу админку. Там уже всё реализовано. Статьи хранятся в формате Markdown. Статьи должны быть на русском и английском языке, то есть разные версии для разных языков. Ну и в общем, я думаю, что можем приступать к созданию плана. Вот такой вот нехитрый промт я надиктовал. И сейчас мы попробуем запустить и посмотрим, что будет.
Ну и вот агент пару минут подумал и начал задавать мне вопросы. Как назвать раздел в меню и в интерфейсе? Это повлияет на терминологию в документе и future I18N. Я выбираю help. Дальше, какой основной UX сделать главным на первом экране раздела? Поиск плюс подборки. Большая строка поиска, популярные темы. FAQ категории, только категории. FAQ first, AI first. Ну, здесь я думаю, что мы ему скажем так. Мне нравится, как сделано в Intercom. Единственное, что у нас справа, аэ, обычно на всех страницах есть чат с AI ассистентом, а в мобильной версии он открывается по кнопочке, которую пользователь может всегда нажать в верхнем правом углу приложения. И для того, чтобы агенту было более понятно, что происходит, я сделаю ему скриншоты. Добавлю вот сюда раз. Покажу, как выглядит мобильная версия. Вот таким образом. Так, это отправляем. Как лучше моделировать ру статьи в плане? Одна статья, две локали, отдельные статьи по языкам. Независимые документы. Независимые документы. Да. Кому должен быть доступен новый раздел на первом этапе? Только coach client Client внутри App. Да. Так. И сразу вот на всякий случай тебе скриншоты, чтобы ты видел, как выглядит сейчас интерфейс в мобильной версии и в десктопной версии. Давайте я ему сразу это отправлю. Оп, агент закончил работу и давайте посмотрим, что получилось. Да, скриншоты помогли. План уже собран в отдельном файле. Что учтено в документе? Mobile first UX, текущий layout с AI справа на десктоп и кнопкой AI на mobile, отдельный раздел help для коуч и client. Roll Awe. Доступ к статьям, отдельные статьи по языкам, эволюционная миграция текущей модели Help Articles без резких breaking changes, структура экранов, маршрутов, поиска контент-модели и фаз реализации. Самое важное из выводов, в меню лучше добавлять help как отдельный раздел. В MVP главный экран должен быть поиск плюс подборки плюс FAQ плюс категории. Отлично. А не просто список статей AI не заменяет help-центр, а дополняет его. Для локализации лучше перейти к модели article K плюс локаль, где один документ равно одна локализованная статья. Отличненько. Открыты две продуктовые Открыты два продуктовых решения. Как назвать раздел в русском UI? Центр помощи или справка. Прикольно. Агент предлагает сделать сразу механизм сбора обратной связи по статьям в базе знаний. Давайте сделаем это. Да, мне нравится идея с блоком "Это помогло" в виде таких эмоджей, которые нажимаешь и записывается прямо в Help Article информация о том, что пользователю понравилась эта статья. Таким образом, мы сможем ранжировать статьи по степени удовлетворённости пользователей от прочтения. Это хорошая штука. Давай сразу это в план добавим. Щук добавил это в план обновлённый файл. Вот он. Что именно добавлено? Отдельная секция про блог "Это помогло". Emoi фидбек как часть MVP. Модель хранения агрегатов прямо в статье. Рекомендация дополнительно хранить user feedback в подколлекции для дедупликации helpfulness Score и его формула. Использование скор для аранжирования статей. Аналитические события для фидбек. Новый Backend treat WR сценарио для отправки фидбек. Обновлённый список MVP критериев и рисков. Коротко. План теперь описывает не только чтение и поиск статей, но и сбор сигнала удовлетворённости, чтобы потом использовать его для ранжирования и улучшения контента. Blog help article feedback в плане нужен для first up реакции через эмоджи. А сценарий Submit article feedback нужен для записи агрегатов.
Да, смотри, мы не делаем никакой MVP, мы делаем сразу production ready суперкрутую систему. Поэтому никаких MVP нам не нужно. Мы делаем круто, быстро и с первого раза. Вот такие у меня требования к нему. Я последнее время стараюсь быть строгим с агентами, потому что чем более напористо ты на них давишь, тем лучше они справляются. Это вот фишечка, которую я, скажем так, раскрыл. Да, зафиксировал, обновил план. Что изменил? Убрал фрейминг через MVP, перевёл документ с Production Ready подход, убрал временные компромиссы вроде сначала только каунтер. Зафиксировал, что фидбек делаем сразу правильно. агрегаты плюс feedback user ID заменил, не знаю, что это, обновил definition of данный порядок реализации. Теперь план описывает сразу целевую сильную систему, а не урезанную первую версию. Если хочешь следующим сообщением я могу ещё превратить этот план в конкретный технический бэклок покend frontend admin или сделать архитектуру. Да, это не нужно. Всё.
Так, ну давайте посмотрим, что получилось. Вот этот файл почитаем. Так. Help center, mobile first plan, контекст. Давайте немножечко зачитаю, чтобы уж, как говорится, тем, кто не любит читать, было попроще. Нужно добавить в основное приложение новый раздел Help-центр для тренеров и клиентов. Раздел должен работать как встроенная база знаний в стиле Intercom, помогать находить ответы через поиск, категории, FAQ и связанные статьи, дополнительные вводные. Раздел доступен только внутри авторизованного приложения. Есть разные аудитории, тренера, клиенты и все подряд. Статьи уже существуют в backend, как help articles. Статьи редактируются через админку. Контент находится в Markdown. Нужны отдельные версии статей для русского английского языка. Справка в десктоп уже живёт чат, а на мобайл он открывается по кнопке в header. По скриншотам видно. Ну, в общем, короче, тут написано так, что уже есть. Рассказывает, что уже есть. Help article модель, категории, роли. Fire store, repositories, vectors search, use case. AI tool, миграция seat статьями. Крут для статей в админке. Админка, список статей редактирования создания markdown content, publish, unpublish, ролик категории теги. Ограничение текущей модели. Текущая модель статьи фактически одноязычная. Для полноценного языка нужно, короче, добавить туда полевидж, я так понимаю. Продуктовая цель - сделать встроенный help-центр, который быстро отвечает на типовые вопросы без обращения в поддержку, помогает пользователю самостоятельно ориентироваться в продукте, усиливает текущий AI ассистент, а не конкурирует с ним. одинаково хорошо работает на мобилках и десктопах, учитывает роль пользователя и язык интерфейса. То есть первый экран - это не просто список статей, а комбинация крупной строки поиска, популярных тем, FAQ блоков, категорий, рекомендованных статей. Это ближе всего к Intercom подходу и лучше подходит для неизвестного вопроса. Пользователь либо ищет напрямую, либо быстро сканирует готовые entry points. Роль AI. AI остаётся отдельным, всегда доступным слоем помощи. На десктопе Help-центр открыт в основном контенте. AI справка, как сейчас справа. Mobile Help-center занимает весь экран. AI по-прежнему открывает через кнопку в header. Следствие: Help-центр не должен пытаться стать вторым чатом. Его задача - дать структурированный селф-сервис, навигацию по темам, надёжные канонические ответы. И я и поверх этого может ссылаться на статьи, открывать нужную статью, отвечать по содержимому статей. Совершенно точно. Название рабочее продуктовое название help-центр. Почему? Ну это тут неважно почему. Локализация. Всё понятно. Центр помощи. Так. Информационная архитектура. Вот начинается самое интересное. Точки входа. Значит, для тренера новый пункт в левом меню/help. Для клиента то же самое. Всё правильно. Так, дополнительный entry points. Нужны быстрые переходы в help из контекста. Пустые состояния, ошибки загрузки, онбординг, подсказки и ответы со ссылкой "открыть статью". Ну, замечательно, мы этого и хотели. Структура раздела Help Home, главная страница help-центр с поиском, блок популярные темы, блок частые вопросы, блок категории, блок. Рекомендуем начать с этого. Отлично. Так, результаты поиска с группировкой. Топ совпадений. FAQ, how to trouble shooting. Окей. Страница категории. Заголовок, описание категории, список статей, закреплённые статьи, быстрый фильтр. Article page, страница статьи, заголовок, summary, markdown content, related articles, кнопка "спросить AI по этой теме". Неплохо. Mobile first UX. С учётом текущего интерфейса на скриншоте места мало. Боковое меню уже используется как главный способ навигации. Верхний headers содержит основные actions, и ей нельзя перегрузить перегрузить дополнительные сложные навигации. Рекомендация. На Mobile Help Center должен иметь три простых уровня. Главное, результаты поиска, категория, статья. Без тяжёлых боковых колонок, дерево разделов и лишних контролов. Абсолютно поддерживаю. Mobile Screen Composition. Help Home. Первый экран. Порядок блоков сверху вниз. Search field. Чипс популярных тем. Список FAQ. Категории карточками. Последние рекомендуемые статьи. Отлично. Нас устраивает. На поиск или просмотр категории. Стики Search Bar, фильтр чипс. Все, how to trouble shooting, компактны спик со статей. Ну окей. Экран статьи, заголовок, какие-то там категории, время чтения, Markdown content, related articles и кнопка "спросить AI". Окей. Mobile rules. Один primary action на экран. Поиск всегда доступен сверху. Article list максимально компактный. Related articles после контента, а не сбоку. AI call to action не мешает чтению. Он, конечно, здесь забыл кнопку вот эту сбора фидбека, но надеюсь где-то в конце это будет.
Давайте продикто про десктоп теперь почитаем. На десктоп help-центр должен, естественно, встраиваться в текущий layout. Слева обычное app-меню, центр content help center. Справа текущая AI assistance панель. Ну, тут всё понятно. Desktop layout help home, широкая строка поиска, двухколоночная сетка категорий, подборка, helpful articles. Просмотр статьи узкая, хорошо читаемая колонка текста. Справа можно оставить и чат без изменений. Три статьи, блоки, related, ask, AI. И было ли это полезным? Вот как раз оно и началось. Хорошо. Важный принцип. Help-center не должен забирать правую колонку у AI, то есть не делать десктоп layout вида Left Navigation Help, Center article, right article, Table of Contents. Ну, всё правильно. Окей. Ролевая модель. Пользователь видит статьи своей роли и роли all. Всё логично. Тренер видит, соответственно, все статьи для тренеров и плюс все статьи для всех пользователей. Клиент видит статьи для клиентов и для всех пользователей. Логично. Запрещено. Нельзя показывать клиенту статьи про тренера, тренеру клиентские статьи, ну и так далее. Тут всё, в принципе, логично. Языковая модель. Пользователь выбрал направление, отдельные статьи по языкам. Это подходит продуктово, но требует аккуратной технической модели, чтобы не сломать текущую систему. Рекомендуемая модель хранения. Один документ, одна локализованная статья, новые поля. Вот это он тут на придумал. Article K общий стабильный ключ статьи, локаль, заголовок, контент, Summary, категория, роль, теги, опубликовано, не опубликовано, featured, не featured, sort order для того, чтобы вручную сортировать их, estimated read там сколько минут читать короче, и ключи связанных статей ну это видимо для поиска какие-то ключевые слова но пофигу окей пример article coach client management тут всё понятно я думаю Почему не просто хранить title, title в одном документе? Ну, тут, я думаю, что всё понятно, потому что у нас, э, нет такой необходимости искать сразу на двух языках, условно говоря. Ну и, в общем, тут всякие прочие. Не будем вдаваться в подробности. Query compatibility - это критично, потому что мобильные клиенты обновляются не сразу. AI, то уже используют текущую модель статьи. Админка уже работает с текущим набором полей. Безопасный production путь, нужно сразу спроектировать целевую модель, но внедрять её без breaking changes. Здесь мы сразу можем прокомментировать ему, что вот ты в документе говоришь про breaking changes, я думаю, что на это не стоит обращать внимание, потому что это не имеет значения. Мы всегда можем прямо сейчас модифицировать AI агента, чтобы он работал с новым форматом статей. А на текущем приложении статьи всё равно нигде не видны, кроме админки, ну и кроме вывода AI агента. Так что никаких breaking changes у нас не будет. Будем ээ рефакторить, переделывать структуры так, как нам нужно. Можешь так и отредактировать документ. Тюк. Так. Ну и вот агент всё поправил. Давайте я закрою сайтбар. Посмотрим. Рефакторинг текущей модели для help можно сразу переходить на целевую структуру данных. Это допустимо, потому что сейчас статьи используются ограниченно в админке, в выборе, выводе AI агента. Следовательно, можно рефакторить модель, если в той же по постановке синхронно обновляются. Ну, короче, можно рекомендуемый путь сразу вести целевую локализованную систему, провести миграцию сит статьи RU Par article Case, создать, перевести админка на новую модель там, туда-сюда. Короче, всё понятно. Важное ограничение. Нужно не тянуть две равноправные модели параллельно дольше, чем это требуется на время миграции данных. Цель не compatibility layer, а быстрый переход на чистую целевую архитектуру. Ну, спасибо, что сообщил. Ная модель для production ready статьи нужны не только title и content, но и metadata для хорошего UX. Обязательные поля для app, read experience, title, summary, content, категория, роль, локаль, publisher, желательные поля. Вот такие типа featured, статья, иконка, sort, сколько времени она занимает чтение, related article case - это похожие статьи. И search words. Зачем? нужен summary. Я думаю, что это объяснять не надо. Зачем нужен, это мы не будем читать. Категории навигации. Текущие категории подходят как басовый production ди набор, но в UI лучше показывать их как продуктовые разделы. Пример отображения. Что это фича, как сделать how to, частые вопросы FAQ, проблемы решения, troubleshooting. Дополнительно можно ввести поверх категории topic collections. Клиенты, тренировки, тра-та-та-та-та. Ну, это на теги похоже. Рекомендации: добавить топик туда-сюда. Поиск, центральная часть. Требования к поиску. Сначала фильтрация. искать только по текущей роли, текущие локали true, типы поиска Ready Search, комбинированные поиск. Ну, тут скорее нам нужен semantic search по имбедингам, ну и, возможно, по вот этим штукам тоже. Хороший э вопрос, как сделать качественный поиск. Ну, думаю, что мы до этого дойдём. Ранжирование результатов. Приоритизация. Ну, здесь пока не очень понятно, чего пустой результат. Если ничего не найдено, показывать suggested topics, показать call to action, кнопку "спросить AI". Взаимодействие с AI. Вот как раз он расписывает. Help center - это канонический контент, то есть источник правды, а AI - это просто такой слой для коммуникации, conversation layer, назовём это так. Так, UX интеграции из статьи в AI. Кнопка "спросить AI по этой теме", открывает чат, прокидывает артикл текст или prefield prompt. Из AI в статью может кинуть ссылку или список релевантных статей. Окей. Из поиска в AI. Если поиск не помог, спросите AI. Окей. Маршруты предлагаемые Road Pass. Да, меня здесь всё устраивает. Здесь меня всё устраивает. Почему не отдельный глобальный help? Потому что уже есть RLAS роу. Проще выставлять доступ, проще собирать меню и аналитику, меньше риск смешать а интерфейс тренера и клиента. Экранный состав Production Ready версии Help Home. Ну, тут мы уже это всё читали. Article list screen. Не будем сейчас сильно вдаваться в подробности. Article screen блок - это помогло. Вот это интересно. UX. Внизу статьи показывается компактный фидбек блок. В заголовок "Это помогло" три эмоджи реакции и опциональный send you state после выбора. Рекомендуемый набор реакций. Не помогло. Частично помогло. Очень помогло. Можно использовать и более нейтральные позитивные эмоджи вместо сердечек. Ну окей. Так, голосование должно занимать один этап после выбора показания состояния. Спасибо за отзыв. Повторное голосование в рамках короткого окна лучше не поощрять. На мобайл блок должен быть визуально крупным и tab friendly. Что сохраняем? Минимально нужно сохранять агрегированную статистику на уровне статьи. Ну окей. Для production ready первой версии достаточно простой нормализованной формы. Ну, тут высшая математика началась. Как использовать продукте? Helpfulness score должен влиять на ранкинг в поиске, порядок feature popular статей, выбор статей для блока. Рекомендуем появление слабых статей туда-сюда. Практическое правило ранжирования. Helpfulness score не должен полностью перебивать текстовую релевантность. Итоговый ранкинг лучше строить так: текстовая релевантность. Roll локали exact match там. Ну, короче, техническая модель. Поскольку пользователь хочет, чтобы сигнал записывался прямо в статью, базовый путь такой: агрегаты храним прямо в документе. При голосовании атомарно увеличиваем нужный счётчик. Пересчитываем helpfulness score. Так, ну и рекомендуемое расширение. Чтобы в будущем избежать спама и повторного голосования, лучше заложить второй слой данных. А, ну, условно говоря, фидбек каждого юзера складывать в отдельную коллекцию. Окей. Почему это полезно? Production ready решение. Всё круто. Рекомендации по UI компонентам. Вот он сразу спроектировал, какие будут UI компоненты. Markdown rendering requirements. Нужно поддержать в заголовке, списки там и так далее. Важно должен быть безопасным. Ну это не обязательно, потому что у нас никакого не будет произвольного HTML. Мы будем сами всё это делать. Ну не суть. Так, аналитика. Нужно собирать отдельные события. Help center opened. Help search submitted, help article opened, related open. Ну и так далее. Короче, куча всяких придумал прикольных событий. Это хорошо. Что это даст? Понятно. Контентные принципы статьи для Hcenter должны писать не как внутренний технический markdown, а как продуктовая документация. Структура статьи такая-то ся-кайта. Писать нужно короткими абзацами, с понятными заголовками, mobile first формулировками и так далее. Ну, в общем, для этого мы создадим отдельного агента Helpwriter. По-моему, кстати, он у меня уже даже есть. Надо будет немножко там только промпто ему докрутить в соответствии с новыми правилами и будет конфетка. Ну и самый прикол технический план реализации. Давайте посмотрим. Workstream number one. Product design. Подтвердить AI, утвердить road structure, утвердить data model локализации, утвердить статьи поиска feedback, описать admin changes. Дальше backend platform, ввести целевую схему локализованных статей, обновить backend под новый формат статей, реализовать тра-та-та. Ну, короче, тут целый он план. Frontend, backend, admin experience расписывает, analytic, breaking changes расписывает. Тут, короче, что понадобится. Так, окей. Всё круто. Всё круто, всё круто. Article frontend changes. Рекомендую новая фича help. Да, всё супер, мне нравится. Pattern. Окей. Почему лучше? Тратата. Admin changes. Супер, супер, супер. Так, ну хорошо. Риски. Смешение help и AI. Если сделать Help-центр слишком похожим на чат, пользователь не поймёт разницу. Контрмера. чётко разделить. Help, browse, search readi, ask clarify do. Ну, окей, слабая локализационная модель. Если быстро долепить ru article k, потом будет трудно поддерживать пары статей. Да, ничего не будет там трудным. Всё это будет AI делать. Так, лонгка текущей админки. AI search. Ну, это пофигу. Пустой центр, это мы сделаем. Накрутка фидбек - это вообще неважно. Никто у нас ничего не будет накручивать. Definition of done. Это что он так? Окей. Рекомендуем порядок реализации. Так, ну, в общем, итог какой? Документ мне нравится. Я думаю, что надо по нему начинать делать. Я думаю, что надо по нему начинать делать. И не знаю, его только попробовать на GPT 54 это сделать или на чём-то ещё. Наверное, попробуем на GPT 54. Почему нет? Открою чат на full screen, ставлю сюда курсор и наговариваю промт. Мне нравится план. Давай приступать к реализации этого плана.
Для вас это мгновение, для меня минут 20, наверное, прошло или даже, может быть, меньше. И что удивительное, случилась какая-то фигня response cleared do it to content safety filters какой-то. Потом случилась ошибка, потом нажал try again. И дальше агент там что-то очень много долго думал, изучал документацию, смотрел код, что-то там потом вот у него са контекст забился, он самаризировал. Ну, в общем, что-то делал, делал, делал. В итоге вот говорит, что всё готово. Реализован первый рабочий срез Help-center. Backend модель статей расширена локально, локалью. Article case, summary, topic, related ключами, helpfulness metric и так далее. Добавлен user feedback, агрегированная реакция через там submit help particle feedback use case. API ручку подключены dependency injection и API routing в контейнер открыто чтение опубликованных help статей для coach client и добавлен доступ к фидбек под коллекции Firestore Rules. Добавлены индексы. Ну, короче, тут всё сделано. Кратко по коду загружает, фильтрует там. Ну, в общем, мы тут не будем вчитываться, чтобы не терять время. Прогнал все тайп-чеки. Ошибок изменённых файлах не осталось. Замечание. Схема уже продакшн для русского и английского языка, но текущая сит миграция пока наполняет только английскую версию с fallback на английский. Следующий логичный шаг - наполнить ру пары статей и затем довести ranking analytics для help. Ну давайте русские статьи тоже сгенерим, ничего страшного, это 5 секунд занимает. Да, давай-ка мы сгенерим русскоязычную версию статей. Тоже что интересненького добавилось? Я уж не знаю, это новая версия GPT или это в GitHub Pilot, но теперь все вот эти размышления и всё, что он там делает, оно вот в таком прокручивающемся окошечке появляется, и оно не растягивает основную ветку чата на 100 экранов. И это довольно удобно. Прикольно сделано. Обновил сит-миграцию, добавил полноценные русскоязычные версии всех help-статей, оставил английские статьи, сделал локализованные документы, добавил для каждой статьи топик там туда-сюда проверки, короче, коротко по коду. Обе локали. Ну, в общем, ээ будем считать, что готово. Если нужно, следующим шагом могу сразу добавить related article case между статьями или подготовить отдельную миграцию. Ну давайте сразу help related article case добавим. Давай сразу добавим related article case. Конечно, почему нет? Я не против. Готово. Добавил related article прямо в сит миграцию. Примеры связей, проверка туда-сюда. Ну и, в общем, как будто бы уже можно пробовать смотреть, что получилось. 53 файла наизменялось, 3.904 строк кода добавилось. Давайте посмотрим, что получилось. Ну вот. Всё похоже на правду. Какие-то тут странные штуки оно надобавляло. Ну не суть. Давайте попробуем запустить, да, проверим. И начнём из того, что зайдём в админку, которая запущена у меня на localhost, девелоперская версия. Заходим в миграции, обновляем список миграций. Вот. На Create Articles появилась. Давайте попробуем запустить. Что-то работает. Готово. Готово. Окей. Посмотрим, что тут поменялось. Добавилась локаль, добавился топик. Аудитория здесь так и было. Featured, не featured. Окей, давайте отредактируем. Здесь у нас article K локаль появилась заголовок summary, content категория тагетория topic теги search key words, related articles, опубликовано, не опубликовано, sort order и количество минут. Сколько? Ну, круто, круто. Окей. Так, перейдём в клиентское приложение, в кабинет тренера, так называемый. Действительно, появился пункт Helpcenter. Нажимаю. О, нельзя сказать, что он не справился. Да, с дизайном есть вопросики, конечно, это сейчас докрутим, но в целом, как будто бы всё получилось. Есть небольшие косячки, конечно. Как всегда, он не понял, где где хранятся переводы для вот этой строки, но это болезнь, которая неизлечима. Вот тут он с дизайном, конечно, немножечко не рассчитал, ну, потому что он не может пока что сам смотреть. Я не подключал здесь Chrome DevTools, не скидывал ему скриншоты. Я думаю, что сейчас мы это флоапами легко доделаем. Давайте проверим, работает ли Help-центр. Попробуем позаходить по статьям, понажимать на какие-нибудь кнопочки, посмотрим, что вообще происходит. Так, ну, допустим, фильтр по топиком у нас работает. Вот я переключаюсь, оно переключается. Замечательно. Даже отжать можно. Это ли не сказка? Окей. Дальше карточки. Так, ну, попробуем теперь провалиться в карточку. Работает. Работает. Удивительно, но работает. Вот тут показываются чипы, что это featured статья. Topic general. Читать 1 минуту. Ну, дизайн, понятное дело, сейчас надо фуапом докрутить, но в целом как бы заголовок показывает. Вот тут какие-то штуки показывает. Не знаю пока ещё, что это такое. App features показывает. Ask AI about this topic показывает. Was this helpful показывает. Но правда, эмоджа почему-то не прикрутил. Ну, давайте попробуем. Работает, работает. Related articles показывает. Супер, супер. Ну, давай-ка. Кнопка ничего не делает. Ну, это не удивительно. Пока что, видимо, она в проекте, но хорошо. Ну, в общем и целом, по-моему, всё супер. Да, тут есть, конечно, косячки, что вот этот стейт не сбрасывается. Вот тут нужно дизайн докрутить, вот эти, может быть, какие-то штуковины доделать. Но в общем и целом, ну, как бы за 20 минут или сколько мы там за час, это, наверное, меньше даже. Полностью готовый help-центр. Да, сейчас нужно будет немножечко. Ну-ка, давайте поиск попробуем. Это ли не сказка? Это ли не сказка? Даже поиск работает. Наверное, это пока ещё не векторный поиск. Вот. Но фича работает. Фича работает. Чтобы эксперимент, скажем так, был окончательно полным. Давайте ещё проверим, что там насчёт русского языка. Переключим язык на русский, посмотрим. Не переключился help-центр. Магия. Магия просто какая-то магия. Пожалуйста. Как использовать AI ассистента? Как переписываться с клиентами? Как работают уведомления? Как пользоваться библиотекой упражнений. Ну это прямо супер. Это прямо супер. Да, конечно, дизайн я тут буду сейчас ещё отрабатывать, но механизм работает. Вот эта штучка не вычисляется правильно. Есть косячки, конечно, но понятное дело, что с с одного промпта, грубо говоря, оно не сделает с первого раза всё идеально. Здесь нужно будет немножечко дорабатывать напильником, как обычно. Вот. Но в целом мне нравится результат, который получился. Я думаю, что я сегодня уже не буду показывать, скажем так, вот эту дошлифовку напильником, потому что там потребуется множество итераций. Я думаю, в принципе, на этом будем вот этот ролик заканчивать. Думаю, что в следующих роликах я покажу, что уже получилось финально, когда я тут наведу марафет, доделаю дизайн и всё остальное. Но в целом на сегодня, я считаю, успешно получилось. GPT 5.4 работает замечательно, как будто бы даже не хуже, чем Opus 4.6, а стоит в три раза дешевле, по-моему, если мне память не изменяет. Ну или что-то в районе того. Ну, короче, она и самое главное, что работает довольно-таки быстро.
Можно ещё, кстати, сразу проверить, работает ли AI ассистент. Давайте-ка я попробую у него спросить. Расскажи-ка мне, как использовать AI ассистента. Тюк. Так, отличненько. Вот он, значит, сделал запрос, как использовать AI ассистента в нашу базу знаний. Ему сразу приехала вот эта статья, как использовать AI ассистента. Давайте зайдём, почитаем. И вот он мне отвечает: "Я ваш персональный помощник в онлайн Fitness App. Моя цель - избавить вас от рутины, чтобы вы могли сосредоточиться на работе с клиентами". То есть он знает, что я тренер, а не клиент. Что самое прикольное, вот основные способы, как вы можете меня использовать. Управление тренировками. Я могу создавать, изменять, удалять тренировки. Просто скажите, что нужно сделать. Работа с клиентами и документами, библиотека упражнений, всё со ссылочками. Прикольно. Ну вот тут только вёрстка, конечно, поехала. Ну, это мы всё дочиним. Дочиним. Финальная полировка, она ещё нам предстоит. Сейчас мы делаем функционал, мы делаем механизм, который будет нести ценность людям, который будет понятен, доступен и так далее. И я думаю, что вот это, э-э, вот этот Help-центр - это большой шаг вперёд к тому, чтобы наши пользователи были довольны и всегда знали, где спросить совета, где посмотреть какие-то ответы на часто задаваемые вопросы, какие-то инструкции почитать и так далее и тому подобное. Вот, я думаю, мы сделали сегодня прикольную фичу, и я доволен. Надеюсь, вам тоже было интересно. Если хотите продолжение, подписывайтесь на мой канал, ставьте лайки, пишите комментарии, спрашивайте. Я с удовольствием делюсь личным опытом. Вот. И, как говорится, чем смогу, помогу. Ну и до скорых встреч. Всем пока.