Превращаем транскрипты 300+ эпизодов в весёлую игру с помощью ИИ
👋 Каждую неделю я отвечаю на вопросы читателей о создании продуктов, росте и построении карьеры. Подробнее: Lenny's Podcast | Lennybot | How I AI | Мои любимые курсы по ИИ/PM, курс публичных выступлений и ИИ-помощник для подготовки к собеседованиям
P.S. Оформи подписку Insider — и получишь бесплатный год доступа к Lovable, Manus, Replit, Gamma, n8n, Canva, ElevenLabs, Amp, Factory, Devin, Bolt, Wispr Flow, Linear, PostHog, Framer, Railway, Granola, Warp, Perplexity, Magic Patterns, Mobbin, ChatPRD и Stripe Atlas по ссылке. Да, это серьёзно.
Несколько месяцев назад я по наитию опубликовал все транскрипты подкаста в соцсетях — и, чёрт возьми, ты нашёл им такое невероятно творческое применение: советы по воспитанию через призму PM-мышления, скрипты для пользовательских исследований, антимемы, инфографика к каждому эпизоду, Twitter-бот «Учись у Lenny» — и ещё не менее 50 потрясающих проектов.
Но любимым проектом из всех оказался проект Ben Shih, нетехнического продуктового дизайнера из Miro, который создал LennyRPG. Я попросил Ben'а поделиться историей этого безумно весёлого проекта в духе видеоигр — как он его построил и чему научился.
Чтобы расцвела ещё тысяча цветов — сегодня я публикую весь архив своего рассылки (и транскрипты подкаста) в виде Markdown-файлов, удобных для ИИ. Плюс MCP-сервер и удобный репозиторий на GitHub. Платные подписчики получают все данные (около 350 постов и 300 транскриптов), бесплатные — часть. Забирай здесь: LennysData.com.
Думаю, никто раньше такого не делал — и мне не терпится дать тебе повод поиграть с самыми свежими инструментами ИИ.
Вот мой вызов тебе: построй что-нибудь и расскажи мне об этом. Выберу лучший проект и подарю победителю бесплатную годовую подписку на рассылку. Просто оставь ссылку на проект в комментариях ниже. Если ты уже что-то сделал — влей новые данные и тоже присылай. Победителя объявлю 15 апреля. Вот данные. Поехали.
Ben — дизайнер и продуктовый строитель, который любит создавать небольшие, весёлые и осмысленные продукты, делающие мир немного лучше. Сейчас он — growth-дизайнер в Miro. Больше его работ — на его сайте или LinkedIn.
Отдельное спасибо Tal Raviv, Claire Vo и Este Lopez за помощь в бета-тестировании и улучшении LennysData.com (который я с гордостью «агентно инженерил» с помощью Codex и Claude Code 👌).
Пару месяцев назад Lenny сделал кое-что особенное. Он структурировал и открыл транскрипты всех более чем 300 эпизодов подкаста. Как человек, который слушает подкаст уже несколько лет, я не мог перестать думать о том, что с этим можно построить.
Brian Balfour много говорит о том, чтобы строить в нужный момент: поймай правильное время — и найдёшь настоящее окно возможностей. Это ощущалось именно так.
Первой мыслью было сделать приложение для практики собеседований с гостями подкаста. Но чем больше я об этом думал, тем меньше горел идеей. Инструменты для практики собеседований по своей природе вызывают стресс — а это последнее, что я хотел создавать. Я хотел сделать что-то весёлое.
А что, если превратить подкаст Lenny в маленькую ролевую игру (RPG)? Игру, где ты исследуешь пиксельный мир, встречаешь гостей подкаста, соревнуешься с ними в знании продукта — и даже ловишь их как покемонов, когда побеждаешь. Так родился LennyRPG.
Когда я создаю приложения с ИИ, я обычно следую очень простому процессу:
Сам процесс мало отличается от дочатгэптовской эпохи. Но теперь я действительно слежу за тем, чтобы тратить достаточно времени на первые два шага — ИИ должен получить весь контекст того, что я хочу. По моему опыту, качество проработки идеи и PRD определяет 80% того, насколько гладко пройдёт весь остальной процесс.
Вот основные инструменты и технологии, которые я использовал в процессе разработки:
А теперь давай разберём по шагам, как я применял этот процесс при создании RPG-игры. Я поделюсь точными промптами, инструментами и решениями на каждом этапе — чтобы ты мог применить тот же рабочий процесс в своих проектах.
Суть идеи была проста: превратить подкаст Lenny в RPG в духе Pokémon, где игроки встречают гостей подкаста прямо в диком поле и сражаются с ними через вопросы о продукте.
Для многих приложений достаточно текста и чёткой идеи, чтобы начать. Но для визуально насыщенных продуктов вроде этой игры время, потраченное на визуализацию, помогает чётко почувствовать, как игра должна выглядеть и ощущаться. Это сильно влияет на дальнейшую работу с ИИ по созданию UI и взаимодействий.
Для этой игры я набросал несколько скриншотов Pokémon в доску Miro и прямо там собрал черновую концепцию. Ничего сложного — в основном текст и блоки поверх скриншотов. Но этого хватило, чтобы показать, как я представляю карту, экран боя и как примерно могут выглядеть персонажи.
Цель была не в том, чтобы точно спроектировать игру, а дать ИИ что-то конкретное для чтения и рассуждения. Как только суть идеи была примерно визуализирована, ИИ смог читать изображения вместе с текстом — и это привело к значительно более сильному PRD на следующем шаге.
В рамках визуализации я также создал несколько тестовых аватаров в ChatGPT, чтобы проверить процесс генерации контента. Это помогло разобраться, какой промпт-инжиниринг нужен для аватаров в стабильном пиксельном стиле.
Процесс был очень простым. Я перетащил в ChatGPT изображения RPG-персонажей, в стиле которых хотел работать, затем добавил фото Lenny — и попросил сгенерировать похожий аватар.
Когда результат меня устроил, я попросил ChatGPT подробно описать тон, стиль и дизайн — чтобы потом использовать это описание как промпт.
Промпт, который я использовал:
Изучи и детально обдумай стиль, дизайн, цвета, пропорции и общий вид, затем верни только отполированный промпт для генерации изображения, который создаст похожего персонажа анфас по фотографии предоставленного человека — с прозрачным фоном и без лишних элементов.
По моему опыту, PRD — самый важный документ, если хочешь, чтобы ИИ точно воплотил твою идею. Как хорошее техзадание для человека-коллеги, PRD даёт ИИ базовое понимание цели приложения, описания проблемы и сути идеи. Когда ИИ упирается в тупик или контекстное окно заканчивается, можно отослать его обратно к PRD — восстановить ориентацию. На каком бы этапе ты ни находился, PRD гарантирует, что всё, что генерирует ИИ, остаётся верным тому, что ты на самом деле строишь. Вот почему я всегда вкладываю время в этот этап.
При этом написание PRD иногда сводит с ума. Поэтому вместо того чтобы писать PRD самому с нуля, я дал ИИ меня проинтервьюировать. Я вставил суть идеи вместе с визуалами в ChatGPT и попросил задавать мне вопросы — чтобы отвечать на них по одному.
Промпт, который я использовал:
Задай мне вопросы, чтобы составить краткий PRD для следующей браузерной игры: хочу создать мини-игру, которая берёт все эпизоды подкаста Lenny's Podcast, генерирует по ним вопросы и оформляет всё в виде RPG в духе Pokémon со схожей визуальной подачей. Я представляю это так: например, ты встречаешь Elena в дикой природе, можешь соревноваться с ней в знании продукта — получаешь 5 вопросов, и при неправильном ответе теряешь HP (очки жизни) и т. д. Можно случайным образом выбрать 50 гостей подкаста и бросать им вызов. Весь стиль и дизайн игры должны быть выдержаны в духе классического Pokémon RPG.
По промпту ChatGPT вернул 17 вопросов. Я перенёс их в Miro для лучшей визуализации и воспользовался Wispr Flow, чтобы быстро надиктовать ответы голосом.
Ответы на эти вопросы также заставили меня обдумать пробелы и допущения в идее — и при этом дали ИИ гораздо больше контекста, чем одностраничное описание.
Ответив на все вопросы ИИ, я связал ответы вместе со всеми артефактами в Miro и попросил ИИ сгенерировать развёрнутый PRD.
Когда PRD был готов, я перенёс его в Cursor как Markdown-файл — чтобы приступить к работе над POC.
Для непосредственной разработки мой стек состоит из трёх инструментов: Claude Code, Codex и Cursor Composer.
Claude Code — мой ведущий инженер. Он помогает составить план реализации, продумать архитектуру, обосновать продуктовые и дизайнерские ограничения. Я также нахожу его отличным инструментом для поиска решений и опенсорсных библиотек. Codex в основном нужен для выполнения задач из плана реализации: он очень хорошо следует инструкциям и имеет более щедрый лимит токенов. Composer — преимущественно для мелких задач: форматирование документов, JSON-файлов или написание простых скриптов.
Взяв PRD как входные данные, я сначала попросил Claude Code поискать опенсорсные проекты, которые могут помочь двигаться быстрее. Это я делаю всегда на ранних этапах. Очень часто люди уже построили что-то похожее и выложили в опенсорс на GitHub — это может сильно ускорить запуск.
Одной из первых библиотек, на которую я вышел, была RPG-JS. Благодаря ей что-то рабочее удалось запустить примерно за пять минут. Я быстро выстроил основной игровой поток: карта мира с базовым движением игрока, зоны встреч и простые UI-элементы.
Но очень быстро начались сложности.
Сложность №1: упираемся в пределы RPG-JS и меняем курс
После нескольких итераций стало ясно, что RPG-JS — не та основа. Фреймворк сильно заточен под инвентарные системы и боевые механики, основанные на оружии. Это работало против меня, поскольку мои сражения строились на логике квиза. Чем больше я пытался его изогнуть, тем сложнее ИИ становилось рассуждать о системе.
Обсудив это с Claude Code, я решил прекратить борьбу и сменить курс. Новым фреймворком стал Phaser — 2D-игровой движок для создания HTML5-игр под десктоп и мобильные.
Сложность №2: запустить карту в Phaser
После перехода на Phaser всё стало намного гибче с точки зрения сцен, карт и игровой логики. Однако из-за большей кастомизации даже настройка базовой карты потребовала куда больше работы.
К счастью, с помощью Claude Code я нашёл статью на Medium с опенсорсным, многоразовым шаблоном карты — это значительно ускорило работу и позволило снова сосредоточиться на самой игре.
Сложность №3: полировка деталей в Phaser
Phaser — мощная, но сложная библиотека с огромным набором возможностей. Claude Code потратил немало времени, чтобы разобраться в её устройстве, и пришлось пройти через множество итераций, чтобы добиться нужных деталей. Такие вещи, как подключение правильных шрифтов, корректное позиционирование UI-элементов и редактирование всего в открытом канвасе Phaser, требовали постоянных переговоров.
Для таких сложных задач полезный приём — попросить Claude Code создать простой Markdown-файл, куда он будет записывать всё, что пробует, и сможет возвращаться к нему, отмечая, что работает, а что нет.
Это очень помогает Claude Code и ИИ в целом лучше понимать кодовую базу и фреймворк. Особенно полезно по мере роста проекта — когда даже мелочи вроде смены шрифта могут стать сложной задачей для ИИ.
Преодолев все эти трудности, игра наконец достигла играбельного состояния. Стартовый экран, карта и экран боя работали сквозным потоком от начала до конца.
Как только POC был готов, я показал его коллегам в офисе. На этом этапе я не искал отполированных отзывов или подробных отчётов об ошибках. Мне в первую очередь хотелось видеть реакцию людей, когда они открывают игру впервые. Сразу ли им понятно, что делать? Ощущается ли основной игровой цикл логичным? И главное — игра кажется весёлой или воспринимается как работа?
Такое лёгкое, неформальное тестирование убедило меня, что основная идея работает и стоит инвестировать больше времени, чтобы превратить POC во что-то более цельное.
Убедившись, что базовая версия работает корректно и получив отличную обратную связь от коллег, я начал следовать плану и наращивать POC до полноценной игры.
Но процесс оказался менее прямолинейным, чем ожидалось — главным образом из-за огромного количества эпизодов подкаста, которые нужно было обработать. Масштабирование рабочего POC до полной игры оказалось прежде всего задачей по выстраиванию систематического подхода вместо ручного труда.
Вот основные инструменты и решения, которые помогли мне до этого дойти:
Файл транскриптов от Lenny содержал только сырой текст. Чтобы использовать его в игре, сначала нужно было обогатить данные — добавить название эпизода, URL и обложку подкаста.
Для этого я загрузил RSS-ленту подкаста через Cursor Composer и привязал к каждому транскрипту недостающие метаданные. Это дало мне значительно более полный датасет, который игра действительно могла использовать.
Затем с помощью Claude Code я попросил его создать простой CLI-инструмент, который систематически генерирует вопросы для квиза по каждому эпизоду через OpenAI API. Вместо того чтобы делать это по эпизоду за раз, инструмент обработал всё в один прогон.
Шаг был таким же простым, как набрать промпт: «Создай CLI-инструмент, который умеет последовательно читать все транскрипты из папки /transcript и для каждого генерировать 5 вопросов согласно требованиям и JSON-формату: {твои требования и JSON-формат}»
На выполнение ушло около 20 минут, а результатом стал структурированный JSON-файл, который можно было напрямую подключить к игре.
Одной из самых сложных частей создания игры было последовательное создание более 250 RPG-аватаров. Для каждого нужна была фотография гостя. Делать это вручную, по одной ища и скачивая фотографии гостей, заняло бы целую вечность.
К счастью, каждый эпизод Lenny уже содержит обложку с аватаром гостя. Я снова запустил Cursor Composer для работы с RSS-лентой, вытащил URL изображений, скачал их локально и использовал как входные данные для генерации аватаров.
Это решило проблему поиска источников, но породило другую: как убедиться, что каждый аватар выдержан в едином качестве и стиле?
Здесь я использовал OpenAI Playground, чтобы многократно тестировать и уточнять промпт, а также проверять, какие модели лучше справляются с задачей. Я продолжал корректировать его, пока каждый сгенерированный аватар не стал следовать одному и тому же стилю и выглядеть частью одной игры.
Когда промпт устоялся, я снова попросил Claude Code написать ещё один CLI-инструмент, который систематически генерирует все RPG-аватары из обложек эпизодов. Это превратило очень болезненную ручную задачу в процесс одного клика.
Разумеется, каждый результат мне приходилось проверять вручную — убеждаясь, что размеры и стиль совпадают с тем, как гости выглядят на обложке подкаста. Это был один из самых интересных этапов, потому что встретилось несколько забавных крайних случаев. Например, я не знал, что у Adam Grenier на оригинальной обложке подкаста действительно есть кроличьи уши — я чуть не удалил их. Или встречались эпизоды с двумя людьми на обложке, как у Jake Knapp и John Zeratsky, — для них пришлось просить ИИ генерировать отдельное изображение для каждого.
Звук — огромная часть любой игры. Многие успешные приложения с геймификацией, вроде Duolingo, вкладывают огромные усилия в звуковой дизайн, потому что он делает всё более живым.
При этом подбор подходящей фоновой музыки и её интеграция в игру обычно отнимают много времени. Поэтому я обратился к Claude Code и просто написал: «Найди мне фоновую музыку для каждой фазы игры, с управлением громкостью».
К моему удивлению, ему удалось найти OpenGameArt.org — опенсорсную библиотеку звуков для игр — и корректно встроить её в игру. Когда я писал промпт, я рассчитывал добавить фоновую музыку только для карты мира, но Claude Code автоматически добавил музыку и для экрана боя, и для экранов победы и поражения. Мне всё равно пришлось подстраивать тайминг и громкость, но большая часть тяжёлой работы была сделана автоматически. Это и правда ощущалось как магия.
Определение игровых механик было самой интересной частью процесса: я хотел, чтобы игра была весёлой и ненапряжной, но при этом достаточно соревновательной — чтобы игроки ощущали прогресс и ставки. В прошлом я изучал теорию игр, но в этом проекте всё сводилось к здравому смыслу, плейтестингу и итерациям.
Я начал с очень простого набора правил: у каждого соперника три вопроса. Каждый правильный ответ даёт XP (очки опыта). Если ответить правильно на все три — это засчитывается как идеальная победа.
Чтобы было интереснее, я добавил небольшие вариации. Иногда один из трёх вопросов становится бонусным — он даёт дополнительный XP и небольшой прирост HP. Это вносит элемент случайности, не нарушая баланс.
Прохождение этапов основано на порогах XP. Как только набираешь нужное количество очков, открывается новая карта с новой порцией гостей. Побеждённые соперники исчезают и попадают в коллекцию, так что фармить одних и тех же снова не получится.
Большую часть этой логики я проработал самостоятельно, а затем попросил ИИ проверить, нет ли очевидных ошибок или крайних случаев. ИИ выступил как санитарный контроль для цифр и потоков, но окончательные решения по балансу, темпу и уровню стресса я принимал вручную.
Последний элемент игры — таблица лидеров. Это соревновательная составляющая, где игроки видят свой рейтинг и соревнуются друг с другом.
Я понимал, что для этого нужна база данных, поэтому начал с настройки Supabase MCP в Claude Code. Это означало, что вместо ручной настройки таблиц, API и соединений мне достаточно было описать Claude Code, что я хочу таблицу лидеров, синхронизированную с Supabase.
Как только я это сделал, он запустил Supabase MCP, который вызвал инструменты вроде create_project и apply_migration для автоматической настройки проекта и таблиц — включая структуру базы данных и соединение между игрой и Supabase. Это значительно ускорило весь процесс и убрало много рутинной работы по настройке, которая обычно занимает намного больше времени.
В результате получилась рабочая таблица лидеров, синхронизирующая прогресс игроков в реальном времени, — и мне почти не пришлось трогать бэкендный код.
Перед выпуском я сосредоточился на финальной полировке — чтобы приложение было стабильным, удобным и достаточно презентабельным для публичного запуска. На этом этапе основной игровой процесс уже работал, поэтому цель была не в добавлении новых функций, а в устранении трений и очевидных проблем.
Для этого шага я скачал навык ревью из маркетплейса Awesome Skills в Claude Code и использовал его для всестороннего ревью всей кодовой базы.
Это особенно помогло выловить то, что я обычно упускаю: проблемы с состоянием между сценами, отсутствующая обработка ошибок и мелкие логические баги, проявляющиеся только после нескольких раундов игры. Я не принял слепо всё, что было предложено, но получил основательный чеклист для прохождения перед выпуском.
Я прошёл по игре сквозным путём и записал все несоответствия в UI и UX в Markdown-файл: проблемы с отступами, переполнение текста, неясные подписи, проблемы выравнивания и нарушения визуальной иерархии.
Когда всё было записано, я передал список ИИ — он исправлял пункты по одному. Это сработало на удивление хорошо, особенно когда проблемы были чётко описаны. Также это сделало процесс значительно более систематичным по сравнению с хаотичными правками во время случайных кликов по приложению.
По части SEO я попросил Claude Code разобраться с базовым минимумом: заголовок страницы, мета-описание, превью для соцсетей и базовая настройка индексации.
Поскольку это была игра, а не контентный сайт, я не уходил в глубокую SEO-оптимизацию. Главная цель — убедиться, что сайт индексируется, доступен для расшаривания и хорошо выглядит, когда люди публикуют ссылку в соцсетях.
Когда игра была успешно задеплоена на Vercel, я написал Lenny в общем Slack, чтобы получить быструю проверку здравомыслия. Честно говоря, я даже не ожидал прямого ответа, зная, насколько он занят — но к моему удивлению получил от него очень тёплый и воодушевляющий отклик.
Это стало последним толчком, которого мне не хватало, чтобы просто выпустить игру.
Видеть, как игру расшаривают публично, а потом получить дополнительный импульс видимости, когда Lenny поделился ею в X — это было нереально. Отклики, которые последовали — от людей, которые играли в игру, делились скриншотами и реагировали на идею, — вышли далеко за пределы того, что я ожидал от небольшого побочного проекта, сделанного за несколько часов.
Это был один из тех моментов, которые напоминают мне, почему я люблю создавать продукты. 💛
Я создавал LennyRPG прежде всего потому, что хотел сделать что-то весёлое — и строить, и играть. Но по пути я вынес несколько полезных уроков для своих будущих ИИ-проектов — и, возможно, для твоих тоже.
С ИИ создание само по себе перестало быть узким местом. Теперь почти любой может запустить приложение. Вот тут-то и начинает иметь значение креативность — важнее исполнения. Вместо вопроса «Что возможно?» я обнаружил, что куда интереснее задавать вопросы вроде «Что было бы весёлым?», «Что звучит немного абсурдно?» или «Что я бы никогда не попытался сделать без ИИ?»
Я давно хотел создать игру, но время и технические затраты всегда казались слишком большими. ИИ не просто ускорил процесс — он достаточно снизил порог, чтобы эта идея наконец стала стоящей попытки.
Паттерн, к которому я постоянно возвращаюсь: использую ИИ, когда застреваю — не только когда нужны ответы, но и когда нужна ясность.
Не знаешь, как написать толковый PRD — попроси ИИ проинтервьюировать тебя.
Не уверен, имеет ли смысл технический стек — попроси ИИ вместе с тобой обдумать компромиссы.
Что-то ощущается как скучная ручная работа — остановись и спроси, может ли ИИ взять на себя первый проход: будь то поиск музыки, исследование опенсорсных библиотек или обработка больших датасетов.
Главное открытие для меня — воспринимать ИИ не как инструмент исполнения, а как соавтора, который помогает структурировать мышление. Когда мышление выстроено — всё остальное движется намного быстрее.
То, что ИИ может быстро что-то сгенерировать, не означает, что результат автоматически окажется хорошим.
Многое из того, что генерирует ИИ, работает технически, но ощущается неловко, непонятно или раздражающе. Если бы я выпустил первую версию всего, что произвёл ИИ, игра работала бы — но не была бы весёлой.
Всё равно нужно думать о:
Хороший UX по-прежнему требует намерения, вкуса и суждения. ИИ может помочь двигаться быстрее, но не заменяет глубокого осмысления того, как реальные люди переживают твой продукт. Это всё ещё на тебе.
—
Попробуй сам! Сыграй: www.lennyrpg.fun
Огромное спасибо Lenny за то, что в первую очередь сделал транскрипты публично доступными — и за поддержку, когда я поделился результатом.
Отдельный респект тройке лидеров таблицы: Gribs, Baptiste и RK — спасибо, что вложили время в покорение верхних строчек. 🏆
Будь ты продактом, дизайнером или разработчиком — или просто любопытным насчёт создания с ИИ — надеюсь, этот разбор подтолкнёт тебя попробовать что-то чуть более амбициозное. Порог для создания отполированного, готового к продакшену ПО никогда не был ниже.
А теперь иди и проверь свои знания о продукте — и попробуй собрать их всех. 🎮
Спасибо, Ben! Больше работ Ben'а — на его сайте или LinkedIn.
Если рассылка тебе ценна — поделись ею с другом и подпишись, если ещё не. Доступны групповые скидки, подарочные варианты и бонусы за рефералы.
Искренне твой,