Собери MVP с AI: задачи, контекст и контрольные точки

Навигация по видео

1. 00:00Что такое vibe coding и где он полезен▶
2. 03:22Одна задача за раз и понятный запрос▶
3. 06:31Чистый проект, проверка и откат▶
4. 08:19Контекст, отладка и просмотр изменений▶
5. 12:03Replit как среда для работы с агентом▶
6. 14:20Когда нужен агент, а когда точечный ассистент▶
7. 16:15Пять навыков: мышление, фреймворки, контрольные точки, дебаг и контекст▶
8. 26:04Алгоритм MVP: функция, проверка, исправление, контрольная точка▶
9. 28:51Практика: план SEO-анализатора▶
10. 36:46Первый запрос и план, который предлагает агент▶
11. 41:22Интерфейс проекта, файлы и новая сессия▶
12. 48:11Первая контрольная точка и проверка MVP▶
13. 51:23Поиск и исправление первого бага▶
14. 55:53Адаптивный интерфейс и новый контекст▶
15. 1:01:22Улучшение визуальной сводки SEO▶
16. 1:08:02Точечная правка по скриншоту и откат▶
17. 1:13:52Деплой и проверка опубликованного приложения▶
18. 1:17:29Данные со страницы и скетч как контекст для следующего приложения▶

Выбери главу: видео выше начнётся с нужного момента.

Vibe coding начинается с управления работой, а не с одного большого запроса

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

Передай агенту одну законченную задачу

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

Запрос для одного изменения

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

Держи контекст коротким и содержательным

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

Не принимай изменение агента вслепую

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

Собирай MVP вокруг полезного пути

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

План итераций MVP

1. Базовый сценарий: пользователь [вводит/выбирает] → сервис [обрабатывает] → пользователь видит [результат].
2. Проверка: пройди сценарий с [обычными данными] и с [ошибочным или пустым вводом].
3. Если есть ошибка: зафиксируй, что именно произошло, где видно проблему и какой результат ожидался.
4. Исправление: попроси изменить только связанную с ошибкой часть.
5. Контрольная точка: сохрани рабочую версию и запиши следующий небольшой шаг.

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

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

Дай агенту проверенные данные и визуальный ориентир

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

Контекст с данными и референсом

Задача: [что нужно создать]
Источник данных: [проверенная ссылка или приложенный файл]
Какие поля использовать: [список]
Визуальный ориентир: [скетч или описание экрана]
Обязательное поведение: [список]
Недопустимые предположения: [что нельзя выдумывать]
Проверка: [ввод → ожидаемый результат]
Сначала кратко перескажи, как понял данные и план реализации; начинай изменения после согласования.