Этот интерактивный маршрут поможет создать первую рабочую версию онлайн-сервиса на WordPress с помощью ИИ — даже если вы пока не умеете программировать.
В гайде 14 шагов и 4 этапа: проверка идеи, проектирование экранов, разработка и запуск. На каждом шаге есть понятные действия, готовые запросы к ИИ и критерий результата.
Как пользоваться: начните с первого шага, выполняйте действия последовательно и отмечайте завершённые шаги. Прогресс и личные заметки сохраняются в браузере, без отправки на сайт. Промпты можно копировать и скачивать.
Если идея уже есть: в первом шаге используйте специальный промпт «У меня есть идея» вместо промпта на поиск идей. Это позволяет пройти тот же маршрут, не придумывая идею заново.
Перед началом: ИИ может ошибаться. Проверяйте выводы, цены и технические рекомендации. Не вставляйте пароли, API-ключи и персональные данные третьих лиц в публичные чаты.
Шаг 1. Найдите проблему, которую хочется решить
Этап: Проверяем идею
Хорошие идеи начинаются с неудобства, которое люди испытывают регулярно.
Почему это важно
Если начать сразу с красивого сайта, можно потратить время на то, что никому не нужно.
Что нужно сделать
- Вспомните, на что вы или знакомые регулярно тратите лишнее время.
- Откройте ChatGPT и попросите помочь найти 3–5 повторяющихся проблем.
- Выберите наиболее понятные проблемы и сохраните список.
Пример из жизни
Администратор небольшой студии каждый день вручную переносит заявки из мессенджеров в таблицу.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Помоги мне найти идею небольшого полезного онлайн-сервиса. Я не разработчик, объясняй всё простыми словами.
Сначала задай по одному 8–10 коротких вопросов о моей работе, хобби и повседневных задачах: где я использую таблицы, постоянно копирую данные, переписываюсь, собираю заявки или делаю повторяющиеся действия.
Не предлагай решения, пока не узнаешь достаточно обо мне. Затем предложи 3–5 конкретных проблем, которые можно попробовать решить сервисом. Для каждой укажи, у кого она возникает и как человек справляется сейчас. Не выдавай предположения за доказанный спрос.Если у вас уже есть идея — альтернативный запрос
Вместо предыдущего запроса вставьте в чат текст ниже, заменив место для описания идеи.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
У меня уже есть идея онлайн-сервиса:
[ОПИШИТЕ ЗДЕСЬ СВОЮ ИДЕЮ]
Я новичок и не умею программировать. Не хвали идею автоматически и не начинай писать код. Сначала задай 5–7 простых вопросов, чтобы понять, для кого этот сервис, какую регулярную проблему он решает и как люди обходятся без него сегодня. Затем покажи три самых важных предположения, которые надо проверить у реальных людей. Если фактов недостаточно, скажи об этом прямо.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Подведи итог нашей беседы. Сделай простой список из 3–5 идей. Для каждой напиши: кто пользователь, в чём проблема, как её решают сейчас, почему это неудобно, что пока неизвестно.
Дай результат в виде документа «01-IDEAS.md». Если ты не можешь создать файл, выведи его содержимое, чтобы я мог скопировать в документ.Что должно получиться
Список из 3–5 проблем и возможных решений.
Как проверить готовность: Для каждой идеи понятно, кто сталкивается с проблемой и в чём неудобство.
Что передать дальше
Исходные материалы: Ваш опыт, работа, процессы
Итоговый документ: 01-IDEAS.md — список идей и проблем
Следующий шаг / инструмент: не требуется — продолжаем в том же ChatGPT-чате.
Если возникают сложности
Не обязательно придумывать инновацию. Полезный сервис может просто заменять неудобную таблицу.
Частая ошибка: Просить ИИ придумать прибыльный стартап.
Что делать, если не получается: Если сильных проблем нет — продолжайте наблюдение и вопросы.
Дополнительные пояснения
Что делаем: Ищем повторяющиеся боли, а не «красивые стартапы»: ручные операции, Excel, копирование данных, переписки, отчёты, неудобные сервисы. Если у вас уже есть свои идеи, добавьте их сюда — ChatGPT должен рассмотреть их наравне с идеями, которые появятся из найденных проблем.
Результат: 3–5 проблем и связанных продуктовых идей, которые стоит исследовать дальше.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Помоги найти повторяющиеся проблемы в моей работе и повседневных процессах, которые потенциально можно решить небольшим онлайн-сервисом.
Не предлагай решения сразу. Сначала задай мне 10–15 вопросов о:
— ручных операциях;
— таблицах;
— копировании данных;
— переписках;
— повторяющихся запросах клиентов;
— отчётах;
— неудобных инструментах;
— временных обходных решениях.
После моих ответов выдели реальные проблемы, их частоту и предполагаемую болезненность.
Если у меня уже есть готовые идеи, я могу перечислить их здесь:
[МОИ ГОТОВЫЕ ИДЕИ — можно оставить пустым]
Не считай готовые идеи автоматически подтверждёнными. Для каждой сначала определи, какую реальную проблему она предполагает, и включи её в итоговый анализ на тех же условиях, что и идеи, найденные из моих процессов.Шаг 2. Выберите одну идею
Этап: Проверяем идею
Сейчас не нужно выбирать идею на всю жизнь. Выбираем одну, которую дешевле всего проверить.
Почему это важно
Ясная формулировка поможет не распыляться на функции и случайные советы ИИ.
Что нужно сделать
- Просмотрите идеи из предыдущего шага и выберите одну.
- Попросите ИИ кратко описать пользователя, проблему и предполагаемое решение.
- Уточните, что ещё нужно выяснить, прежде чем делать сайт.
Пример из жизни
Для администраторов небольших студий — простой список заявок, чтобы не терять обращения клиентов.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Мы выбираем одну идею из списка выше. Помоги сравнить варианты по трём критериям: насколько понятна проблема, легко ли найти потенциальных пользователей и насколько дёшево проверить интерес без разработки.
Не выбирай идею за меня. Задай уточняющие вопросы и покажи преимущества и риски каждого варианта. После моего выбора сформулируй идею одним абзацем: «Для кого — какая проблема — как будет помогать сервис».Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Составь документ «02-HYPOTHESIS.md» простыми словами: 1) кому нужен сервис, 2) какая проблема возникает, 3) как люди решают её сейчас, 4) чем предполагаемое решение лучше, 5) какие три предположения ещё нужно проверить, 6) как проверить их без программирования. Не называй недоказанные предположения фактами.Что должно получиться
Одно короткое описание идеи и список того, что нужно проверить.
Как проверить готовность: Вы можете объяснить свою идею обычному человеку за 30 секунд.
Что передать дальше
Исходные материалы: 01-IDEAS.md — список идей и проблем
Итоговый документ: 02-HYPOTHESIS.md — описание выбранной идеи и того, что в ней нужно проверить
Следующий шаг / инструмент: остаёмся в этом же чате. Итог используется в Deep Research.
Если возникают сложности
Можно вернуться и выбрать другую идею, если проверка покажет, что проблема несущественная.
Частая ошибка: Выбрать идею только потому, что она нравится.
Что делать, если не получается: Если идеи равны — выбирайте ту, где дешевле проверка.
Дополнительные пояснения
Что проверяем: Кто пользователь, когда возникает проблема, как он решает её сейчас и что должно быть настолько неудобно, чтобы он захотел изменить привычный способ.
Термин: Продуктовая гипотеза должна быть проверяемой, а не абстрактной.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Я выбираю идею: [УКАЖИТЕ ИДЕЮ ИЗ ПРЕДЫДУЩЕГО СПИСКА].
На основе нашего предыдущего обсуждения опиши её как продуктовую гипотезу:
— кто пользователь;
— какая у него проблема;
— когда она возникает;
— что он делает сейчас;
— что должно быть достаточно болезненным, чтобы он захотел изменить привычный способ;
— какие предположения мы пока принимаем без доказательств.
Для каждого критичного предположения предложи самый дешёвый способ проверки до разработки.Шаг 3. Поговорите с будущими пользователями
Этап: Проверяем идею
Проверьте, действительно ли проблема существует, прежде чем создавать сервис.
Почему это важно
ИИ способен помочь с вопросами, но не может заменить реальные разговоры с людьми.
Что нужно сделать
- Найдите 3–5 людей, которые похожи на будущих пользователей.
- Спросите их о последнем реальном случае, когда возникала проблема.
- Запишите ответы и попросите ИИ найти общие закономерности.
Пример из жизни
Вы спрашиваете у пяти администраторов, когда последний раз потерялась заявка и почему это произошло.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Помоги подготовиться к 3–5 коротким разговорам с потенциальными пользователями моего сервиса. Составь 7 простых вопросов.
Меня интересуют их реальные ситуации: когда последний раз возникала проблема, что они делали, сколько времени потеряли, за что уже платят или какими инструментами пользуются. Не предлагай спрашивать «нравится ли вам идея» или «купили бы вы её». Добавь короткую инструкцию, как записывать ответы.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Вот записи моих разговоров с реальными людьми: [ВСТАВЛЮ ОТВЕТЫ].
Проанализируй их без попытки подтвердить мою идею. Что повторяется, что не подтверждается, кому проблема мешает сильнее всего? Составь понятный итог «03-INTERVIEWS.md». Если данных мало, прямо напиши об этом и предложи, с кем ещё поговорить.Что должно получиться
Заметки о разговорах и список действительно повторяющихся трудностей.
Как проверить готовность: В заметках есть реальные случаи из жизни, а не только мнения о вашей идее.
Что передать дальше
Исходные материалы: Выбранная продуктовая гипотеза
Итоговый документ: 03-INTERVIEWS.md — итоги разговоров с потенциальными пользователями
Следующий шаг / инструмент: остаёмся в том же ChatGPT-диалоге и используем интервью в Deep Research.
Если возникают сложности
Вопрос «Вы бы купили такой сервис?» почти ничего не доказывает. Лучше спросить, как человек решает задачу сейчас.
Частая ошибка: Спрашивать «купили бы вы?».
Что делать, если не получается: Если проблема не подтверждается — вернитесь к идеям.
Дополнительные пояснения
Что делаем: Проводим проблемные интервью о реальном прошлом поведении, а не просим оценить нашу будущую идею.
Почему важно: ChatGPT может подготовить вопросы и разобрать ответы, но не может заменить реального пользователя.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
На основе выбранной гипотезы подготовь сценарий проблемного интервью на 20–30 минут.
Спроси про последнюю реальную ситуацию, частоту, последствия, текущий способ решения, затраты времени/денег, прошлые попытки что-то изменить и самое болезненное место.
Не задавай вопросы «купили бы вы?» и «нравится ли идея?».Шаг 4. Посмотрите, какие решения уже существуют
Этап: Проверяем идею
Найдите конкурентов, похожие сервисы и привычные способы решения проблемы.
Почему это важно
Если люди уже используют решения или платят за них, это важная информация для проверки идеи.
Что нужно сделать
- Попросите ИИ найти конкурентов и привычные альтернативы.
- Откройте несколько найденных сайтов сами: проверьте функции, цены и обещания.
- Запишите, чего не хватает существующим решениям и для кого.
Пример из жизни
Вы нашли две CRM, одну таблицу-шаблон и жалобы людей на сложность существующих решений.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Исследуй рынок для нашей идеи с поиском актуальных источников в интернете. Пиши для человека без бизнес-образования и без навыков разработки.
Найди 3–7 решений проблемы: сервисы, таблицы, ручные способы. Для каждого укажи сайт, кому подходит, основные возможности, цену (если её удалось проверить) и заметные ограничения. Найди отзывы или жалобы, если они доступны. Отделяй подтверждённые факты от предположений. Если у тебя нет доступа к поиску, предупреди меня и предложи, что проверить вручную.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Сделай простой документ «04-MARKET-RESEARCH.md»: кто наши пользователи, какие альтернативы существуют, проверенные цены, повторяющиеся жалобы, ссылки на источники, что известно и что пока остаётся предположением. В конце предложи одну аудиторию для первого теста и объясни почему, не утверждая, что спрос уже доказан.Что должно получиться
Краткое сравнение существующих решений со ссылками на источники.
Как проверить готовность: Есть реальные ссылки, а цены и факты не взяты на веру без проверки.
Что передать дальше
Исходные материалы: 02-HYPOTHESIS.md + 03-INTERVIEWS.md
Итоговый документ: 04-MARKET-RESEARCH.md — итоги исследования рынка
Следующий шаг / инструмент: пока никуда — остаёмся в том же диалоге.
Если возникают сложности
Конкуренты — не всегда плохая новость. Полное отсутствие похожих решений тоже требует объяснения.
Частая ошибка: Искать только подтверждение своей идеи.
Что делать, если не получается: Если сегмент слабый — исследуйте другой.
Дополнительные пояснения
Что такое «Глубокое исследование»: Deep Research нужен для внешней картины рынка: сегментов, конкурентов, цен, статистики и жалоб.
Что получаем: Понимание рынка и сегмента , на котором имеет смысл запускать первый MVP.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Проведи глубокое исследование с поиском внешних источников для выбранной продуктовой гипотезы.
Цель — попытаться опровергнуть идею, а не подтвердить её.
Исследуй:
1. размер и структуру рынка;
2. сегменты пользователей;
3. статистику;
4. конкурентов и альтернативы;
5. цены;
6. жалобы пользователей;
7. неудовлетворённые потребности;
8. признаки готовности платить;
9. факторы, из-за которых идея может оказаться нежизнеспособной.
Отделяй:
— факты;
— выводы;
— гипотезы.
Для важных цифр указывай источники.
В конце предложи 3–5 интересных сегментов, но не выбирай победителя автоматически.Шаг 5. Прикиньте расходы и возможный доход
Этап: Проверяем идею
Вам не нужна сложная финансовая модель. Достаточно понять, какие цифры могут сделать идею жизнеспособной.
Почему это важно
Даже полезный сервис может быть убыточным, если привлечение пользователя стоит дороже, чем доход от него.
Что нужно сделать
- Запишите предполагаемую цену и основные ежемесячные расходы.
- Попросите ИИ составить три сценария: осторожный, средний и оптимистичный.
- Отметьте числа, которых вы не знаете, и способы узнать их на практике.
Пример из жизни
Подписка 500 ₽ в месяц, расходы на сайт 2 000 ₽ и неизвестная пока стоимость привлечения клиента.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Помоги очень просто прикинуть экономику нашего будущего сервиса. Я новичок.
Сначала спроси, какая предполагается цена, сколько стоит хостинг, есть ли комиссии и сколько денег я готов потратить на первую проверку. Потом сделай таблицу для трёх сценариев: осторожный, средний, оптимистичный. Покажи, сколько платящих клиентов примерно нужно, чтобы покрывать известные расходы.
Не придумывай стоимость рекламы, число клиентов и их поведение как факты: помечай такие цифры «предположение». Объясни все непонятные слова.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Собери «05-ECONOMICS.md». В документе должны быть: предполагаемая цена, известные расходы, три сценария, самые рискованные предположения и простые способы их проверить. Добавь итог обычным языком: «Что нужно узнать прежде, чем тратить деньги на разработку».Что должно получиться
Простая таблица с доходами, расходами и вопросами для проверки.
Как проверить готовность: Понятно, какие цифры реальные, а какие — пока только предположения.
Что передать дальше
Исходные материалы: MARKET-RESEARCH
Итоговый документ: 05-ECONOMICS.md — черновой расчёт экономики
Следующий шаг / инструмент: не требуется — тот же ChatGPT-диалог.
Если возникают сложности
Не бойтесь вопросительных знаков вместо чисел. Выдуманная точность хуже честной неопределённости.
Частая ошибка: Придумать точные CAC/LTV/retention.
Что делать, если не получается: Если не сходится — меняйте сегмент, цену или канал до кода.
Дополнительные пояснения
Ключевые термины: CAC , retention , LTV , цена, конверсия, инфраструктурные расходы.
Зачем: Не для точного прогноза, а чтобы понять порядок цифр и выявить допущения, которые могут сделать продукт невыгодным ещё до кода.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
На основе нашего исследования собери экономику продуктовой гипотезы v0.1.
Не выдумывай неизвестные показатели как факты.
Для каждого неизвестного параметра:
— пометь его как гипотезу;
— предложи диапазон;
— объясни, как проверить.
Посчитай:
1. осторожный;
2. базовый;
3. оптимистичный сценарий.
Учти:
— цену;
— стоимость привлечения платящего клиента (CAC);
— конверсию в оплату;
— возврат пользователей (retention);
— доход от одного клиента за всё время (LTV);
— инфраструктуру;
— комиссии платежей;
— бюджет первого рекламного теста.
В конце назови 3 параметра, от которых экономика зависит сильнее всего.Шаг 6. Решите, что войдёт в первую версию
Этап: Проверяем идею
Первая версия должна решать одну важную задачу, а не пытаться быть всем сразу.
Почему это важно
Чем меньше лишних функций, тем быстрее вы проверите, нужен ли продукт кому-то.
Что нужно сделать
- Опишите одно главное действие, ради которого человек придёт в сервис.
- Выберите только функции, без которых это действие невозможно.
- Отложите все необязательные идеи в список «позже».
Пример из жизни
Пользователь получает заявку, меняет её статус и видит список всех заявок. Без отчётов, сложных ролей и автоматизаций.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Помоги описать самую маленькую рабочую версию нашего сервиса. Не предлагай дополнительные функции «на будущее».
Ответь простыми словами: 1) что хочет сделать человек, 2) какие 3–5 действий он должен выполнить, 3) какие экраны нужны, 4) какие данные сохраняются, 5) что обязательно для безопасности и работы, 6) что можно отложить. Для каждого пункта объясни пользу.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Оформи решение в документ «06-MVP-SPEC.md». Укажи пользователя, одну главную задачу, сценарий использования по шагам, обязательные функции, что сознательно не делаем и как поймём, что первую версию можно показать людям. Не добавляй новых функций без моего согласия.Что должно получиться
Короткий список функций первой рабочей версии (её часто называют MVP).
Как проверить готовность: Главный сценарий понятен, а каждую функцию можно объяснить через пользу для пользователя.
Что передать дальше
Исходные материалы: Гипотеза + рынок + экономика
Итоговый документ: 06-MVP-SPEC.md — описание первой рабочей версии
Следующий шаг / инструмент: пока не переходим в другой инструмент — сначала проектируем архитектуру.
Если возникают сложности
MVP — просто самая маленькая рабочая версия сервиса, на которой можно проверить вашу идею.
Частая ошибка: Добавить в первую версию все идеи «на будущее».
Что делать, если не получается: Если функций много — требуйте обоснование каждой.
Дополнительные пояснения
Главный вопрос: Какой минимальный законченный продукт позволит проверить, что выбранный пользователь действительно решает проблему нашим способом?
Что не входит: Второстепенные отчёты, сложная кастомизация, редкие роли, автоматизации «на будущее» и всё, что не влияет на основной сценарий.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
На основе нашей гипотезы, исследования рынка и экономики сформируй MVP.
Определи:
1. главную задачу пользователя;
2. главный пользовательский сценарий;
3. необходимые сущности;
4. минимальные роли;
5. минимальный набор функций;
6. обязательные уведомления;
7. что явно НЕ входит в MVP;
8. что можно добавить только после подтверждения спроса.
Для каждой функции объясни, какую гипотезу она помогает проверить.Шаг 7. Подготовьте понятное техническое задание
Этап: Проверяем идею
Вы объясняете ИИ, как должен работать сервис. Программировать на этом шаге не нужно.
Почему это важно
Без единого плана помощники по дизайну и разработке могут по-разному понять вашу идею.
Что нужно сделать
- Попросите ИИ описать правила сервиса без сложных терминов.
- Проверьте, что понятно: кто что может делать, какие данные хранятся, нужна ли оплата.
- Сохраните единое описание продукта для следующего инструмента.
Пример из жизни
Клиент создаёт заявку → администратор получает её → заявка сохраняется → её можно найти и изменить статус.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Мы планируем сделать небольшой онлайн-сервис на WordPress. Я не программист. На основе всех наших предыдущих решений объясни, как должен работать сервис.
Опиши: какие виды пользователей есть, что каждый может видеть и делать, какие данные будут сохраняться, что происходит после каждого действия, нужны ли уведомления, оплата или внешние сервисы, как защитить пользовательские данные.
Используй стандартные возможности WordPress, где это разумно. Если какая-то часть слишком сложна для WordPress, предупреди. Не пиши код. Любой технический термин тут же объясняй одной фразой.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Подготовь полный документ «07-PRODUCT-SPEC.md» для передачи ИИ-дизайнеру и ИИ-разработчику. Объедини только уже принятые решения: идея, пользователь, проблема, функции первой версии, экраны, данные, роли, правила, безопасность, необходимые внешние сервисы, критерии готовности и открытые вопросы.
Не придумывай отсутствующие решения — отмечай «нужно уточнить». В начале добавь короткое описание продукта человеческим языком.Что должно получиться
Единый документ о продукте — «07-PRODUCT-SPEC.md».
Как проверить готовность: Другой человек сможет прочитать документ и понять, что должен делать сервис.
Что передать дальше
Исходные материалы: 06-MVP-SPEC.md + предыдущие артефакты
Итоговый документ: 07-PRODUCT-SPEC.md — полное описание продукта перед дизайном и разработкой
Следующий шаг / инструмент: в GLM 5.3 (z.ai) или Figma Make передаём PRODUCT-SPEC.md целиком.
Если возникают сложности
Слова API, webhook или права доступа не нужно изучать заранее. Пусть ИИ объясняет их по необходимости. Если оплаты нет, раздел про платежи не нужен.
Частая ошибка: Проектировать оплату, аналитику и права по ходу кода.
Что делать, если не получается: Если архитектура тяжёлая — вернитесь к MVP.
Дополнительные пояснения
Стандартные возможности WordPress: пользователи, роли, база, API WordPress, файлы, админка, задачи по расписанию, email
Своя логика продукта: уникальная бизнес-логика продукта
Внешние сервисы: AI, платежи и внешние сервисы
Подписка: тарифы, статусы, повторная попытка оплаты, отмена подписки, окончание подписки
Webhook: платёжные события и синхронизация статусов
Безопасность: роли и права доступа , nonce , sanitization
Аналитика: регистрация, активация, ключевое действие, карта, оплата, retention
Рекламный тест: аудитория, обещание, события и критерии качества
Инфраструктура: хостинг/ VPS , домен, SSL, тестовая версия / рабочая версия , backup
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Спроектируй минимальную архитектуру MVP на WordPress на основе всех решений в этом диалоге.
Раздели решение на:
1. стандартные возможности WordPress;
2. готовые плагины;
3. собственную бизнес-логику;
4. внешние сервисы.
Отдельно опиши:
— пользователей, роли и права доступа;
— сущности и связи данных;
— API WordPress;
— файлы;
— email и cron;
— админку;
— безопасность;
— логирование и backup;
— подписки и оплату;
— webhook и состояния подписки;
— аналитику событий;
— рекламную воронку;
— тестовая версия сайта и рабочая версия сайта;
— минимальную серверную инфраструктуру.
Принцип: не усложняй заранее. Всё, что не является конкурентным преимуществом, по возможности должно использовать стандартный механизм WordPress или проверенный компонент.Шаг 8. Сделайте первые макеты экранов
Этап: Показываем экраны
Покажите, как будет выглядеть сервис и куда пользователь нажмёт.
Почему это важно
Исправлять схему экранов проще и дешевле, чем переделывать работающий сайт.
Что нужно сделать
- Откройте ИИ-инструмент, который умеет создавать макеты или прототипы.
- Передайте ему документ из шага 7 и готовый запрос ниже.
- Проверьте каждый экран: понятно ли, что делает человек и куда нажимает.
Пример из жизни
Экран входа → список заявок → добавление заявки → карточка заявки.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Я прикладываю документ «07-PRODUCT-SPEC.md». Помоги создать простой и понятный прототип интерфейса. Я не дизайнер.
Сначала перечисли экраны, которые действительно нужны первой версии. Затем предложи их расположение и порядок действий пользователя. Для каждого экрана опиши заголовок, кнопки, поля, сообщения об ошибках и что происходит после нажатия. Учти телефон и компьютер. Не добавляй функций сверх документа. Если умеешь создавать макеты, сделай их.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Подготовь «08-UX-SPEC.md» — понятное описание готовых макетов: список экранов, назначение каждого, кнопки и их действия, переходы между экранами, поведение при ошибках, варианты для мобильного. Перечисли вопросы, которые остались непонятными. Этот документ пойдёт к ИИ-разработчику вместе с макетами.Что должно получиться
Набор макетов экранов и описание их поведения.
Как проверить готовность: Можно объяснить путь пользователя от входа до результата, глядя только на макеты.
Что передать дальше
Исходные материалы: 07-PRODUCT-SPEC.md — полное описание продукта перед дизайном и разработкой
Итоговый документ: 08-UX-SPEC.md + макеты
Следующий шаг / инструмент: PRODUCT-SPEC.md + UX-SPEC.md + макеты/ссылка на Figma или экспорт ключевых экранов.
Если возникают сложности
Красивые цвета сейчас вторичны. Главное — удобный и понятный порядок действий.
Частая ошибка: Начинать с визуального стиля вместо UX.
Что делать, если не получается: Если flow не сходится — исправляйте UX, не расширяйте MVP.
Дополнительные пояснения
Что проектируем: Путь пользователя , wireframes , экраны, empty / loading / error states, desktop/mobile.
Результат: Макеты и понятное описание того, как должны работать экраны. Этого должно хватить Codex, чтобы не додумывать поведение интерфейса самостоятельно.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Я прикладываю PRODUCT-SPEC.md.
Не меняй продуктовую гипотезу и границы MVP без моего подтверждения.
Сначала спроектируй UX:
1. основной путь пользователя;
2. список необходимых экранов;
3. цель пользователя на каждом экране;
4. основное действие;
5. роли и права;
6. состояния «нет данных», «загрузка» и «ошибка»;
7. mobile;
8. черновые макеты экранов.
Не добавляй функции, которых нет в MVP.Шаг 9. Проверьте макеты на живых людях
Этап: Показываем экраны
Дайте нескольким людям простую задачу и посмотрите, справятся ли они без ваших подсказок.
Почему это важно
Вам интерфейс кажется очевидным, потому что вы его придумали. Новым пользователям — не обязательно.
Что нужно сделать
- Покажите прототип 3–5 представителям вашей аудитории.
- Дайте понятное задание и не объясняйте интерфейс заранее.
- Запишите, где они ошибаются или останавливаются, затем исправьте макеты.
Пример из жизни
Попросите знакомого: «Добавь новую заявку и найди её в списке». Не показывайте, куда нажимать.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Составь простой план проверки моего прототипа на 3–5 людях. Придумай 2–3 задания из основного сценария. Объясни, какие вопросы задать после проверки, что наблюдать и почему нельзя подсказывать человеку. Сделай таблицу для записи результатов.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Вот мои заметки о проверке прототипа: [ВСТАВЛЮ ЗАМЕТКИ].
Помоги выделить проблемы, которые мешают пройти основной сценарий. Что нужно исправить до разработки, а что можно отложить? Подготовь документ «09-USABILITY.md». Если испытаний ещё не было, не выдумывай их результаты.Что должно получиться
Список найденных затруднений и улучшенные макеты.
Как проверить готовность: Основную задачу люди выполняют без постоянных подсказок.
Что передать дальше
Исходные материалы: Прототип + UX-SPEC.md
Итоговый документ: 09-USABILITY.md + исправленный UX
Следующий шаг / инструмент: PRODUCT-SPEC.md + финальный UX-SPEC.md + макеты + при необходимости 09-USABILITY.md.
Если возникают сложности
Не превращайте каждое пожелание участника в новую функцию. Исправляйте прежде всего то, что мешает выполнить задачу.
Частая ошибка: Считать любое пожелание обязательной функцией.
Что делать, если не получается: Если сценарий системно непонятен — оставайтесь в дизайне.
Дополнительные пояснения
Что проверяем: Может ли человек без подсказок пройти основной сценарий и понять интерфейс.
Почему до кода: Передвинуть экран или изменить flow в прототипе дешевле, чем переписывать готовую бизнес-логику.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Подготовь сценарий проверки прототипа на реальных пользователях прототипа. Не объясняй интерфейс участнику заранее. Определи стартовую ситуацию, задачу, что наблюдаем, какие подсказки нельзя давать и какие сигналы считать проблемой.Шаг 10. Подготовьте WordPress к сборке сервиса
Этап: Собираем сервис
На этом этапе ИИ-разработчик помогает собрать основу проекта. Вам нужно контролировать результат, а не писать код.
Почему это важно
Сначала нужен безопасный тестовый сайт и понятный план, иначе ошибки будет трудно исправлять.
Что нужно сделать
- Подготовьте тестовый WordPress на хостинге или локально; не меняйте живой сайт без резервной копии.
- Откройте ИИ-инструмент для работы с кодом и передайте ему документ о продукте и макеты.
- Попросите сначала составить план файлов и функций, не меняя ничего без проверки.
Пример из жизни
Вы сделали тестовую установку WordPress, сохранили резервную копию и попросили Codex показать план проекта.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Я новичок и создаю WordPress-сервис с помощью ИИ. Прикладываю «07-PRODUCT-SPEC.md», «08-UX-SPEC.md» и макеты.
Сначала изучи документы и составь план разработки без изменения кода. Покажи простыми словами: какие части будут стандартным WordPress, для чего понадобится собственный плагин, какие данные нужно хранить, какие есть риски и что будем делать первым. Сохрани технические подробности в «10-ARCHITECTURE.md». Не создавай лишних функций. До моего подтверждения ничего не изменяй.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
План разработки я проверил. Помоги создать минимальную основу проекта. Работай небольшими изменениями, проверяй их и после каждого изменения объясняй простыми словами, что сделано, что ещё не работает и как мне самому это проверить. Не затрагивай существующий работающий сайт без отдельного согласования.Что должно получиться
Тестовый WordPress, план устройства проекта и базовая структура файлов.
Как проверить готовность: Есть тестовая среда, резервная копия и понятный план разработки.
Что передать дальше
Исходные материалы: PRODUCT-SPEC + UX-SPEC + макеты
Итоговый документ: 10-ARCHITECTURE.md + каркас
Следующий шаг / инструмент: остаёмся в том же Codex-проекте.
Если возникают сложности
Не отправляйте пароли и платёжные ключи в переписку. Если не знаете, как установить WordPress, попросите инструкцию именно для вашего хостинга.
Частая ошибка: Попросить Codex одним запросом сделать весь продукт целиком.
Что делать, если не получается: Если есть лишняя инфраструктура — потребуйте обоснование.
Дополнительные пояснения
Термин: Кодовая база — вся структура проекта, с которой дальше работает Codex.
Результат: Понятная структура проекта и правила, по которым Codex будет добавлять функции небольшими шагами.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Изучи WordPress-проект, PRODUCT-SPEC.md и UX-SPEC.md.
ПОКА НЕ МЕНЯЙ КОД.
Сначала:
1. опиши структуру проекта;
2. предложи структуру custom plugin / application layer;
3. сопоставь сущности продукта с механизмами WordPress;
4. опиши роли и права доступа;
5. опиши REST endpoints;
6. укажи внешние зависимости;
7. перечисли места повышенного риска;
8. проверь соответствие PRODUCT-SPEC.md;
9. укажи, где использовать стандартный WordPress API.
Создай ARCHITECTURE.md.
Не начинай реализацию, пока я не подтвержу архитектуру.Шаг 11. Собирайте сервис по одной функции
Этап: Собираем сервис
Просите ИИ-разработчика делать одно небольшое изменение за раз и сразу проверяйте его.
Почему это важно
Большая команда «сделай всё» приводит к ошибкам, которые сложно найти и исправить.
Что нужно сделать
- Выберите из плана одну функцию, например «создать заявку».
- Передайте ИИ точное задание и попросите перечислить изменённые файлы.
- Откройте тестовый сайт, проверьте функцию и запишите найденные ошибки.
Пример из жизни
Сначала форма новой заявки → проверка → затем список заявок → проверка → затем статусы.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Продолжаем работу над моим WordPress-проектом. Сейчас сделай ТОЛЬКО одну функцию: [ОПИШУ ФУНКЦИЮ].
До изменений расскажи, что затронешь и как проверишь права доступа и безопасность. Затем реализуй функцию. Не меняй ничего несвязанного. После работы объясни человеческим языком, что изменилось, как это проверить на тестовом сайте и как вернуться к прошлой версии при ошибке.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Проверь только что созданную функцию. Составь мне короткий список ручных проверок: что нажать, что должно случиться, как проверить ошибку и что проверить под обычным пользователем. Перечисли оставшиеся проблемы. Не говори «готово», если проверки не были действительно выполнены.Что должно получиться
Постепенно работающий сервис, в котором основные действия проверены.
Как проверить готовность: Новая функция работает, а предыдущие не перестали работать.
Что передать дальше
Исходные материалы: ARCHITECTURE + одна функция
Итоговый документ: Рабочая функция + фиксация изменений в Git
Если возникают сложности
Сохраняйте рабочие версии перед изменениями. Система контроля версий Git помогает вернуться назад, но пользоваться ей может и ИИ-разработчик.
Частая ошибка: Запрос «сделай весь сервис».
Что делать, если не получается: Если изменение расползается — снова ограничьте задачу.
Дополнительные пояснения
Цикл: Одна функция → анализ → изменение → список изменений → тест → исправление → фиксация изменений в Git .
Почему: Большой запрос «сделай весь сервис» резко повышает риск дублирования логики и регрессий.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Реализуй следующую функцию MVP:
[ОПИШИТЕ ОДНУ ФУНКЦИЮ]
Сначала ничего не меняй и:
1. найди связанные файлы;
2. покажи затрагиваемые механизмы;
3. проверь роли и права;
4. проверь, можно ли использовать стандартный WordPress API;
5. перечисли риски регрессии.
После этого реализуй функцию.
Проверь:
— permission checks;
— sanitization;
— escaping;
— nonce там, где требуется;
— обработку ошибок;
— совместимость с существующим кодом.
Не меняй несвязанные части проекта.Шаг 12. Проверьте всё перед публикацией
Этап: Собираем сервис
Прежде чем пускать настоящих людей, проверьте, что сервис работает и не открывает чужие данные.
Почему это важно
Ошибка в доступе или оплате важнее недоделанной анимации.
Что нужно сделать
- Пройдите главный сценарий как обычный новый пользователь.
- Попросите ИИ-разработчика проверить безопасность, ошибки и восстановление из копии.
- Исправьте все серьёзные проблемы до публичного запуска.
Пример из жизни
Вы проверяете вход, создание заявки, невозможность увидеть чужую заявку, письма и восстановление из резервной копии.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Проведи итоговую проверку моего WordPress-сервиса по документам проекта. Не добавляй новые функции.
Проверь основной сценарий, регистрацию и вход (если есть), права доступа, защиту чужих данных, ошибки, мобильную версию, резервные копии, оплату и письма (только если они нужны). Раздели проблемы на «нельзя публиковать», «желательно исправить» и «можно позже». Укажи, что проверено реально, а что ещё нужно проверить вручную.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Помоги подготовить понятную инструкцию «11-DEPLOY.md»: какие файлы нужны, как сделать резервную копию, как перенести WordPress на рабочий адрес, что настроить, как проверить сайт после запуска и как откатиться назад. Пиши для новичка. Пароли и секретные ключи не включай в документ.Что должно получиться
Проверенная тестовая версия и инструкция по публикации.
Как проверить готовность: Нет известных критических ошибок, а главная задача выполняется целиком.
Что передать дальше
Исходные материалы: Рабочий MVP
Итоговый документ: 11-DEPLOY.md — инструкция по публикации продукта
Следующий шаг / инструмент: репозиторий + DEPLOY.md + секреты отдельно от Git.
Если возникают сложности
Если в сервисе нет оплаты или писем, проверять их не нужно. Доступ к чужим данным и резервные копии — важны почти всегда.
Частая ошибка: Считать, что одного плагина безопасности достаточно для защиты продукта.
Что делать, если не получается: Критичные проблемы исправляются до рабочая версия.
Дополнительные пояснения
Термин: Критерии готовности — не «вроде работает», а проверяемый набор условий готовности.
Проверяем: Права, оплату, уведомление от платёжного сервиса, аналитику, email, backup, mobile, безопасность и основной пользовательский сценарий.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Проведи release-аудит текущего MVP по PRODUCT-SPEC.md, UX-SPEC.md и ARCHITECTURE.md.
Не добавляй новые функции.
Проверь:
— главный пользовательский сценарий;
— регистрацию и авторизацию;
— роли и права доступа;
— доступ к чужим данным;
— REST permission checks;
— sanitization / escaping;
— nonce;
— ошибки и empty states;
— подписку и оплату;
— webhook;
— повторные webhook;
— отмену и окончание подписки;
— аналитику событий;
— email;
— cron;
— mobile;
— логи;
— backup;
— рабочая версия сайта-конфигурацию.
Составь список:
КРИТИЧНО / ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ.Шаг 13. Опубликуйте первую версию сайта
Этап: Запускаем
Перенесите проверенный продукт на адрес, который можно отправить будущим пользователям.
Почему это важно
Цель не просто загрузить файлы, а дать человеку возможность выполнить основную задачу.
Что нужно сделать
- Подготовьте домен и хостинг с HTTPS — защищённым соединением.
- По инструкции из предыдущего шага опубликуйте проверенную версию и сделайте резервную копию.
- Проверьте сайт в другом браузере и на телефоне, как новый пользователь.
Пример из жизни
Вы открываете https://мой-сервис.рф на телефоне, регистрируетесь как новый пользователь и создаёте первую заявку.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Вот инструкция «11-DEPLOY.md», мой хостинг — [НАЗВАНИЕ ХОСТИНГА]. Проведи меня через публикацию WordPress-сервиса пошагово, по одному действию за раз.
На каждом шаге скажи: где именно искать нужную настройку, что сделать, какой результат увидеть, как проверить и что делать при ошибке. Не проси меня размещать пароли в открытой переписке и не делай необратимых изменений без предупреждения.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Составь короткий чек-лист после публикации: сайт открывается по HTTPS, вход и регистрация (если нужны), основное действие, мобильный экран, письма и оплата (если нужны), права доступа, резервная копия. Помоги отметить фактически проверенные пункты и отдельно перечислить непроверенное.Что должно получиться
Рабочий адрес сайта, который можно безопасно показать первым людям.
Как проверить готовность: По ссылке действительно можно выполнить главное действие, без вашей помощи.
Что передать дальше
Исходные материалы: Код + DEPLOY.md
Итоговый документ: Адрес рабочей версии сайта
Следующий шаг / инструмент: URL рабочая версия + список аналитических событий + план теста из PRODUCT-SPEC.md.
Если возникают сложности
Для первого проекта обычный подходящий WordPress-хостинг часто проще в обслуживании, чем собственный сервер.
Частая ошибка: Покупать сложную инфраструктуру заранее.
Что делать, если не получается: Выбирайте самый простой достаточный вариант.
Дополнительные пояснения
Что нужно: Домен, HTTPS / SSL , PHP/MySQL, email, задачи по расписанию , backup, логи и мониторинг.
Хостинг или VPS?: Для первого MVP лучше то, что дешевле и проще поддерживать. VPS нужен, когда обычного хостинга действительно недостаточно.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Вот DEPLOY.md моего WordPress MVP.
Помоги развернуть его на [ХОСТИНГ / VPS].
Сначала составь пошаговый план:
— домен;
— HTTPS/SSL;
— PHP/MySQL;
— WordPress;
— загрузка проекта;
— база данных;
— переменные и секреты;
— cron;
— email;
— webhook;
— аналитика;
— backup;
— логи;
— финальная проверка.
Для каждого шага укажи ожидаемый результат перед переходом к следующему.Шаг 14. Позовите первых пользователей и сделайте выводы
Этап: Запускаем
Запуск — это начало проверки идеи, а не конец работы.
Почему это важно
Важнее понять, пользуются ли люди вашим решением, чем просто собрать посещения.
Что нужно сделать
- Выберите одну аудиторию и простой способ пригласить первых людей.
- Посмотрите, сколько людей совершили главное полезное действие.
- Спросите пользователей о затруднениях и решите, что проверить следующим.
Пример из жизни
30 человек пришли на сайт, 8 зарегистрировались, 3 реально создали заявку. Вы выясняете, где остальные остановились.
Готовый запрос к ИИ — начать задание
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Помоги мне запустить маленький и недорогой тест нового сервиса. Определи одну аудиторию, одно понятное обещание и одно главное действие пользователя, которое покажет пользу продукта. Предложи способы пригласить первых людей без большого бюджета. Объясни, какие числа записать и как не перепутать посещения сайта с реальным использованием.Готовый запрос к ИИ — подвести итог
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Вот реальные результаты теста: [ВСТАВЛЮ ЧИСЛА, ОТЗЫВЫ И НАБЛЮДЕНИЯ].
Помоги отделить факты от предположений. Что люди действительно делали, где возникли сложности, какие объяснения ещё не подтверждены? Предложи один самый дешёвый следующий эксперимент. Создай итог «13-RESULTS.md» и план следующей проверки.Что должно получиться
Факты о первом тесте и одно следующее решение.
Как проверить готовность: Вы опираетесь на реальные действия людей, а не на предположения.
Что передать дальше
Исходные материалы: Production + PRODUCT-SPEC + данные
Итоговый документ: 12-TEST-PLAN.md / 13-RESULTS.md / следующая гипотеза
Если возникают сложности
Не тратьте большой рекламный бюджет до проверки, что сервис понятен и реально работает.
Частая ошибка: Менять одновременно рекламу, цену, UX и продукт.
Что делать, если не получается: Возвращайтесь в тот этап, где возникла причина проблемы.
Дополнительные пояснения
Что смотрим: Визит → регистрация → активация → ключевое действие → сильный сигнал → оплата → возврат.
Цель: Понять, где проблема: трафик, позиционирование, onboarding, продукт, цена или платёжный сценарий.
Расширенный запрос для более подробной проработки (необязательно)
Используйте этот вариант, если короткого запроса выше оказалось недостаточно. Он основан на исходной подробной методике.
Пожалуйста, объясняй всё простыми словами и не используй технические термины без пояснения. Не придумывай факты, цифры или результаты, которых у нас нет. Если ты не видишь прежнюю переписку и документы, сначала попроси меня их прислать.
Я запускаю первый рыночный тест MVP.
Вот PRODUCT-SPEC.md и план теста.
Зафиксируй:
— проверяемую гипотезу;
— аудиторию;
— сообщение;
— целевую страницу;
— главное целевое действие;
— слабые конверсии;
— сильные конверсии;
— аналитические события;
— минимальный объём данных;
— условия «продолжить»;
— условия «изменить позиционирование»;
— условия «менять продукт»;
— условия «остановить тест».
Не оптимизируй только на дешёвую регистрацию.