Перейти к содержимому
15 июля 2026 г. · Справочник

Читаем план (и меняем его)

Эта статья описывает продукт на момент публикации. Актуальные возможности см. в разделах AI Builder и Agent Teams.

Читаем план (и меняем его)

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

Ошибка первая: штамповать одобрение не глядя

Это самая распространённая ошибка. Скелет выглядит правильно, нажимаете «одобрить», идёте дальше — я так делал неделями, пока это меня не подвело. Сборка, которая наконец сломала эту привычку, вернулась с оплатой через Stripe, подключённой к статичному сайту, которому было некуда деть состояние аккаунта, требуемое Stripe. В плане прямым текстом было написано тип продукта: статичный сайт, прямо на карточке, а я пролистал мимо, потому что список страниц выглядел нормально, а я торопился.

Последствия этой ошибки всегда одной и той же формы: всё, что идёт после плана, корректно в рамках этого плана, поэтому сбой не проявляется как ошибка — он проявляется как рабочая сборка, которая структурно неверна. Никто её не помечает, потому что ничего не сломано — статичный сайт с кнопкой оплаты просто молча делает не то, или падает в тот единственный момент, когда реальный пользователь нажимает «оплатить». Вы узнаёте об этом на этапе проверки — а это самое дорогое место, чтобы узнать.

Ошибка вторая: чрезмерная детализация ради избежания второго круга

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

Это работает наоборот, и вот почему: план всё равно будет пересмотрен снова, как только вы увидите реальные страницы, независимо от того, насколько тщательно вы подошли к делу в первый раз. А когда его пересматривают, вы не получаете список изменений — вы получаете новую карточку, которая уже учитывает вашу правку, точка, без пометок об изменениях. Так что точность, которую вы напечатали в первом раунде, всё равно не переживает нетронутой до второго раунда — вам придётся перечитать всё заново в любом случае. Два-три раунда «нет, вот так» приводят к лучшему результату быстрее по фактическим затратам времени, чем один исчерпывающий бриф — даже если писать бриф кажется более эффективным в моменте.

Правки простым языком, которые реально работают, короткие:

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

Ошибка третья: относиться к типу продукта как к необязательному полю

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

Тип продуктаЧто это значит
Статичный сайтПростой, без серверной логики.
Устанавливаемое приложениеВ стиле PWA — работает офлайн, можно добавить на главный экран, по-прежнему без серверной логики.
Сборка на фреймворкеВ стиле React/Next, более насыщенная клиентская интерактивность, но всё ещё без постоянного бэкенда.
Серверное приложениеЕдинственный из четырёх типов с реальной базой данных и системой аккаунтов за ним.

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

Люди ошибаются здесь двумя способами. Во-первых, они не сверяют собственный запрос с этим полем — если в вашем запросе есть «аккаунты», «вход», «сохранение», «дашборд с обновлением», «платежи» или «несколько пользователей редактируют одно и то же», а в карточке не указано «с серверной поддержкой», это единственная правка, которую стоит сделать перед одобрением, без исключений. Во-вторых, они путают устанавливаемое приложение с фреймворк-сборкой, потому что оба в обычном разговоре ощущаются как «приложение». Это не взаимозаменяемые вещи: устанавливаемое приложение подходит для инструмента, где всё состояние хранится на устройстве пользователя — калькулятор чаевых, таймер тренировки. Фреймворк-сборка означает больше интерактивности и структуру компонентов, но по-прежнему ничего не сохраняется на сервере между сессиями или устройствами. Ни один из них не «приложение» в смысле наличия аккаунтов и данных, которые следуют за вами между устройствами — только тип с серверной поддержкой. И избыточное резервирование под серверную поддержку «на всякий случай» для сайта-портфолио или страницы документации — тоже не безопасный выбор; понижение позже — такая же пересборка, как и повышение.

Что остаётся, если перестать делать эти три вещи

Как только вы перестаёте пролистывать строку типа продукта, писать техзадание на этапе плана и относиться к формулировкам про аккаунты/данные/платежи в своём запросе как к обсуждаемым, остаётся быстрая, узкая проверка:

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

Этот список существует именно потому, что запрос вроде «инструмент для записи в парикмахерскую» подтягивает вещи, которые вы не вводили — календарь и SMS-напоминания и список клиентов, часть из которых вы имели в виду, а часть — разрастание объёма, которое модель добавила, потому что эти функции статистически идут вместе. Уберите лишнее одной фразой здесь, а не после того, как это уже построено.

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

Одобрение — это точка обязательства. Именно тогда списываются кредиты и начинается сборка. Всё до этого — свободное размышление; всё после — прогресс, за которым можно наблюдать.
Руководство
ПоделитьсяXLinkedInFacebookRedditQuoraWhatsAppTelegramEmail
← Все статьи