Чему вы научитесь
После урока вы сможете написать запрос, по которому другой человек или ИИ поймёт, что требуется сделать, с какими материалами работать и как определить готовность. Вы научитесь использовать примеры без слепого копирования, задавать формат ответа и исправлять неудачный результат через точную обратную связь.
Мы продолжим сайт велосипедной мастерской. На этот раз наша задача — согласовать первый экран и порядок обращения, не добавляя неподтверждённых цен и возможностей. Вы увидите, как один расплывчатый запрос превращается в несколько небольших шагов, каждый из которых можно проверить.
Что нужно знать заранее
Прочитайте урок об инструментах. Из него понадобятся понятия контекста, рабочей папки и различие между предложенным кодом и реально изменённым файлом. Также полезно иметь описание пользователя и критерии готовности из первого урока.
Для практики достаточно доступного ИИ-помощника и текстового документа. Код писать не обязательно: навык постановки задачи лучше сначала отработать на структуре и тексте страницы. Когда смысл согласован, его легче перенести в интерфейс.
Ключевые термины
Промпт — сообщение, которое задаёт помощнику направление работы. Оно не является заклинанием: качество зависит прежде всего от ясности задачи и доступных сведений, а не от особого набора «правильных» слов.
Контекст — информация, необходимая для выполнения задачи: назначение продукта, пользователь, текущие файлы, принятые решения и наблюдаемая проблема. Ограничение — условие, которое решение должно соблюдать, например запрет менять несвязанные разделы.
Формат ответа — ожидаемый способ представления результата: список вопросов, таблица, план, готовый текст или изменение файлов. Критерии приёмки — условия, по которым вы принимаете результат как выполненный.
Итерация — один цикл уточнения: запрос, результат, проверка и следующий запрос. Предположение — непроверенное объяснение или догадка. Предположения полезно обозначать явно, чтобы не принимать их за подтверждённые факты.
1. Сначала определите результат, потом формулируйте просьбу
Представьте, что вы заказываете вывеску для мастерской. Фраза «сделайте заметно» допускает десятки решений. Один исполнитель выберет яркий цвет, другой увеличит размер, третий добавит мигающий свет. Если же вы объясните, откуда вывеску видят, что на ней должно быть и какие ограничения действуют, обсуждение станет предметным.
С запросом к ИИ происходит то же самое. Начните с результата в реальном мире: посетитель должен понять, какие велосипеды обслуживает мастерская, и узнать порядок обращения. Затем определите, какой результат нужен от помощника сейчас. Это может быть только текст первого экрана, а не весь сайт целиком.
Полезно разделять цель продукта и задачу текущего шага. Цель продукта шире: помочь человеку обратиться за ремонтом. Текущий шаг уже: предложить три варианта заголовка без обещаний скорости и цены. Если смешать уровни, помощник может начать строить систему записи, хотя вы хотели обсудить формулировку.
Укажите, что не входит в работу. Например: «Не меняй остальные блоки, не добавляй форму и не придумывай отзывы». Такие границы сокращают случайные изменения. Но не превращайте запрос в длинный список запретов без положительной цели. Помощник должен понимать, какой результат нужен, а не только чего следует избегать.
Наконец, сформулируйте признак завершения. Для текста это может быть ограничение длины и наличие конкретной информации. Для интерфейса — наблюдаемое действие и состояние. «Задача завершена, когда в первом экране есть услуга, понятное действие и нет неподтверждённых обещаний» гораздо полезнее, чем «сделай максимально качественно».
2. Соберите запрос из шести понятных частей
Рабочая структура состоит из цели, текущего состояния, материалов, ограничений, результата и проверки. Это не обязательный шаблон для каждого короткого вопроса, а удобная опора для задач, где ошибка приводит к переделке. Чем выше цена ошибки, тем важнее явно описывать условия.
Цель объясняет, зачем требуется изменение. Текущее состояние описывает, что уже есть и что не устраивает. Материалы содержат подтверждённый текст, файлы или ссылки на выбранные примеры. Ограничения задают границы. Результат определяет, что помощник должен вернуть. Проверка объясняет, как оценить выполнение.
Для мастерской цель звучит так: «Помочь посетителю понять порядок обращения». Текущее состояние: «Есть список услуг, но не объяснено, нужно ли согласовывать время». Материалы: «Подтверждённый порядок: описание проблемы, согласование, визит». Ограничение: «Не обещать ответ за конкретное время». Результат: «Три коротких шага для страницы». Проверка: «Из текста нельзя сделать вывод, что сообщение автоматически бронирует время».
Необязательно писать длинный абзац на каждый пункт. Часто достаточно нескольких строк. Структура ценна тем, что помогает заметить отсутствующую информацию до отправки. Если вы не можете описать текущий процесс мастерской, помощник тоже не сможет достоверно восстановить его из названия бизнеса.
Отдельно укажите порядок работы, когда нужна осторожность. Например: «Сначала задай вопросы, затем предложи план; не изменяй файлы до согласования плана». Или: «Исправь только описанную ошибку, после перечисли затронутые файлы». Так вы управляете не только результатом, но и способом его получения.
Роль вроде «ты опытный дизайнер» может задать тон объяснения, но не заменяет факты. Она не сообщает размер экрана, аудиторию, существующие компоненты и ограничения. Лучше потратить внимание на эти сведения, чем на длинное описание воображаемого профессионального статуса помощника.
3. Передавайте контекст, который влияет на решение
Контекст похож на карту местности. Для короткой прогулки нужна ближайшая улица, а не подробная карта всей страны. Для изменения кнопки нужны её назначение, текущий код и ожидаемое поведение. Полная история проекта может только отвлечь от причины проблемы.
Сначала отделите факты от пожеланий. Факт: мастерская принимает велосипеды после согласования. Пожелание: страница должна ощущаться спокойной и аккуратной. Предположение: посетители чаще приходят с телефона. Все три вида информации полезны, но имеют разную надёжность. Если предположение влияет на важное решение, его стоит проверить или обозначить как рабочую гипотезу.
При передаче файлов объясняйте их роль. «Это текущая страница услуг» полезнее, чем просто приложенный файл без комментария. Если ошибка касается конкретного участка, укажите заголовок или действие, по которому его найти. Не обрезайте сообщение об ошибке до последнего слова: часто важны место возникновения и последовательность вызовов, которую показывает инструмент.
Перед отправкой удалите ненужные персональные сведения и секреты. Для объяснения формы достаточно вымышленных данных. Если нужно показать структуру ответа сервера, замените личные значения нейтральными, сохранив названия полей и типы данных. Тип данных — вид значения, например текст, число или логическое «да/нет».
Следите за актуальностью контекста. Если вы уже переименовали файл, старый запрос с прежним именем может привести к ошибке. После нескольких итераций полезно написать краткое резюме: что существует сейчас, что уже проверено и какая единственная проблема осталась. Это снижает вероятность возвращения к устаревшему варианту.
Когда сведений недостаточно, разрешите помощнику задавать вопросы и перечислять допущения. Важно не требовать «сделай всё без вопросов», если задача действительно зависит от неизвестного факта. Автономность полезна для обратимых технических решений, но не даёт права придумывать правила бизнеса или юридические условия.
4. Используйте примеры как объяснение, а не как приказ копировать
Пример помогает показать направление быстрее, чем длинное описание. Но изображение красивой страницы содержит много деталей, не все из которых подходят вашему проекту. Если попросить «сделай так же», помощник может перенести чужие тексты, структуру и визуальные решения без понимания задачи.
Разберите пример на свойства. Что именно вам нравится: крупный заголовок, спокойная палитра, много свободного пространства или понятный порядок блоков? Что не нужно переносить: фотографии людей, рекламные обещания, сложная навигация? Такой разбор превращает референс — образец для обсуждения — в набор конкретных ориентиров.
Можно использовать парные примеры. Покажите допустимую формулировку: «Согласуем время после обращения». Затем недопустимую: «Запишем вас мгновенно в любое время». Объясните различие: первая соответствует реальному процессу, вторая обещает неподтверждённую возможность. Это полезнее, чем просто сказать «пиши честно», потому что показывает границу на конкретном случае.
Для кода также полезны небольшие примеры входа и выхода. Если функция должна выбирать доступные услуги, покажите набор исходных значений и ожидаемый список. Не ограничивайтесь одним удобным случаем. Добавьте пустой список или отсутствующее значение, если это возможно в реальной работе. Пример не заменяет общие правила, но помогает проверить, одинаково ли вы понимаете задачу.
Избегайте противоречивых требований. «Минимум текста» и «объяснить все детали на первом экране» могут тянуть решение в разные стороны. Расставьте приоритеты: что обязательно, а чем можно пожертвовать. Например, понятность главного действия важнее декоративной краткости, а подробности процесса можно перенести в следующий блок.
5. Разбивайте работу на проверяемые итерации
Большой запрос похож на попытку одновременно изменить двигатель, тормоза и посадку велосипеда. Если после этого что-то работает хуже, причина неочевидна. Небольшие шаги позволяют связывать изменение с результатом и возвращаться к рабочему состоянию.
Для страницы мастерской можно выбрать такую последовательность: уточнить содержание, согласовать структуру, написать первый экран, собрать статическую страницу, проверить мобильную ширину, затем добавить простое поведение. Каждый шаг имеет свой результат. Не нужно обсуждать детали серверной базы, пока вы ещё не решили, нужна ли форма обращения в первой версии.
После каждого ответа сначала оцените соответствие задаче, затем красоту исполнения. Помощник мог аккуратно оформить неправильный сценарий. Например, он создал кнопку «Записаться», хотя мастерская только принимает предварительные обращения. Исправление смысла важнее подбора оттенка кнопки.
Обратную связь удобно строить из трёх частей: что получилось, что расходится с ожиданием и что нужно изменить. «Список услуг подходит. Формулировка кнопки обещает подтверждённую запись, которой нет. Замени её на действие начала обращения и сохрани остальную структуру». Такой запрос оставляет удачные части и ограничивает переделку.
Если ошибка техническая, добавьте воспроизведение: где открыли страницу, что нажали, какое значение ввели и что увидели. Не делайте вывод о причине раньше проверки. «После отправки форма исчезает» — наблюдение. «База сломана» — предположение, которое может быть неверным. Передавайте оба отдельно, если гипотеза кажется полезной.
Когда помощник предлагает исправление, попросите объяснить, какую гипотезу оно проверяет. Затем повторите исходный сценарий. Если результат не изменился, зафиксируйте это, а не накладывайте ещё несколько случайных исправлений. Последовательность наблюдений помогает постепенно сузить область поиска.
6. Проверяйте ответ и сохраняйте принятые решения
Хороший запрос повышает вероятность подходящего ответа, но не гарантирует его. ИИ может пропустить условие, неверно понять пример или уверенно назвать непроверенный факт. Поэтому итог работы оценивается по критериям, а не по длине объяснения и не по уверенности формулировок.
Составьте короткий список проверки прямо из запроса. Если вы запретили выдуманные цены, просмотрите весь текст на числа и денежные обещания. Если просили изменить только один блок, сравните файлы. Если требовали работу на телефоне, откройте нужную ширину. Каждое важное требование должно иметь соответствующую проверку.
Просите помощника отделять подтверждённое от непроверенного. В отчёте могут быть три строки: что изменено, что проверено инструментом, что осталось проверить вручную. Такой отчёт полезнее общей фразы «готово». Если браузер недоступен, нельзя объявлять визуальную проверку выполненной только на основании чтения CSS.
После принятия результата обновите описание проекта. Запишите новые решения и удалите устаревшие. Например: «Основное действие называется “Обсудить ремонт”; отправка обращения не означает резервирование времени». В следующей итерации эта запись станет контекстом и поможет избежать возвращения к ошибочной формулировке.
Не сохраняйте в библиотеку промптов только огромные универсальные шаблоны. Полезнее короткие заготовки под повторяющиеся действия: уточнение задачи, ограниченное изменение, описание ошибки и проверка готовности. Они должны помогать думать, а не скрывать отсутствие понимания за длинным текстом.
Разбор на примере
Начальный запрос звучит так: «Сделай красивый сайт мастерской, чтобы люди записывались». В нём неясно, какие услуги оказываются, как проходит запись, что уже существует и какой результат нужен прямо сейчас. Помощник может придумать календарь, цены, отзывы и гарантии, хотя ни один из этих элементов не подтверждён.
Уточнённая версия начинается с фактов: учебная мастерская ремонтирует велосипеды; посетитель должен прочитать услуги и начать разговор; время визита согласовывается вручную. Затем задаём текущую задачу: написать первый экран и три шага обращения. Добавляем ограничения: не использовать реальные контакты, не обещать сроки ответа, не изображать автоматическое бронирование.
Теперь определяем формат: один заголовок, короткое пояснение, текст основной кнопки и три пункта процесса. Критерий приёмки: читатель понимает, что после сообщения мастер сначала уточнит детали. Это уже задача, которую можно выполнить и проверить без разработки всей системы.
Предположим, ответ содержит подходящий заголовок, но кнопку «Записаться сейчас». Мы не просим переделать всё. Сообщаем, что заголовок и пояснение приняты, а название кнопки нужно изменить из-за неверного обещания. После правки проверяем весь блок ещё раз и сохраняем итоговый текст как согласованный материал для следующего этапа.
Готовые промпты для ИИ
Первый шаблон предназначен для уточнения содержания. Замените квадратные скобки конкретными сведениями, а неизвестные факты обозначьте как вопросы.
Цель продукта: [какую задачу решает посетитель].
Текущий шаг: [один результат, который нужен сейчас].
Подтверждённые сведения: [факты].
Текущие материалы: [текст или файлы].
Ограничения: [что нельзя менять, добавлять или обещать].
Формат ответа: [например, заголовок, пояснение и три шага].
Критерии готовности: [наблюдаемые условия].
Если важного факта не хватает, задай вопрос. Не заполняй пробел выдумкой.
Второй шаблон помогает сообщить об ошибке без преждевременного вывода о причине.
Ожидалось: [конкретное поведение].
Получилось: [что наблюдаю].
Шаги воспроизведения: [действия по порядку].
Среда: [браузер, устройство, способ запуска].
Сообщение об ошибке: [точный текст без секретов].
Уже проверено: [попытки и результаты].
Предложи наиболее вероятные причины и одну следующую проверку.
Не меняй несвязанные части проекта и не объявляй проверку выполненной заранее.
Третий шаблон пригодится после выполнения изменения. Его цель — сделать отчёт пригодным для самостоятельной оценки.
Сверь результат с исходными критериями: [список].
Перечисли изменённые файлы и назначение каждого изменения.
Отдельно укажи реально выполненные проверки и их результаты.
Отдельно укажи то, что требует ручной проверки.
Если обнаружено несоответствие, объясни его конкретно и предложи исправление.
Не добавляй новые функции в рамках этой проверки.
Типичные ошибки новичков
- Просить «идеальный результат» без условий. Это не объясняет аудиторию, задачу и ограничения. Опишите наблюдаемое действие пользователя и критерии, по которым будете принимать работу.
- Смешивать факты с предположениями. Помощник может принять догадку о процессе за правило бизнеса. Помечайте неизвестное и проверяйте важные сведения до реализации.
- Копировать чужой запрос целиком. В нём могут быть ненужные технологии и несовместимые требования. Используйте структуру, но переписывайте содержание под собственный проект.
- Отвечать только «не то». Такая обратная связь не показывает расхождение. Назовите удачную часть, фактическую проблему и конкретное ожидаемое изменение.
- Добавлять новые пожелания во время исправления ошибки. Это расширяет область изменений и мешает проверке причины. Сначала завершите исправление, затем оформите новую задачу отдельно.
- Не обновлять контекст после решения. Старые ограничения и названия возвращаются в ответы. Храните короткое актуальное описание проекта и принятых решений.
Практическое задание
За шестьдесят — девяносто минут подготовьте три связанных запроса для сайта мастерской. Первый должен уточнять содержание, второй — создавать текст одного блока, третий — проверять результат по критериям. Не просите создавать весь сайт в одном сообщении.
Перед отправкой первого запроса самостоятельно заполните цель, факты и ограничения. Получив ответ, отметьте все предположения помощника. Затем согласуйте текст первого экрана и трёх шагов обращения. Если ответ не подходит, выполните одну ограниченную итерацию обратной связи, сохранив удачные части.
В конце составьте таблицу: требование, проверка, результат. Например, запрет неподтверждённых сроков проверяется просмотром обещаний времени; ясность действия — пересказом сценария другим человеком. Работа готова, если каждый важный пункт имеет проверку, а итоговый текст не изображает несуществующую возможность.
Дополнительное упражнение: возьмите один ваш длинный запрос и сократите его, не потеряв цель, материалы, ограничения и критерии. Удаляйте эмоциональные усилители и повторения, но сохраняйте факты. Сравните ответы и объясните, какая информация действительно повлияла на результат.
Самопроверка
1. Почему длинный промпт не обязательно лучше короткого?
Длина сама по себе не гарантирует полезного контекста. В большом сообщении могут повторяться пожелания, противоречить друг другу ограничения и теряться главная задача. Качественный запрос содержит сведения, влияющие на решение, и ясно определяет результат. Иногда для этого достаточно нескольких точных строк, иногда нужен подробный документ.
2. Чем цель продукта отличается от задачи текущего шага?
Цель продукта описывает пользу для пользователя, например возможность понять услуги и обратиться в мастерскую. Задача шага определяет ближайший результат работы, например текст блока обращения. Разделение уровней помогает не расширять каждое изменение до разработки всей системы и позволяет проверять отдельные результаты.
3. Как правильно использовать визуальный референс?
Нужно объяснить, какие свойства примера подходят: ритм отступов, размер заголовков, настроение палитры или расположение действий. Также полезно назвать то, что переносить нельзя. Референс служит для обсуждения принципов, а не даёт разрешение копировать чужой текст, бренд и композицию без адаптации к задаче.
4. Чем наблюдение об ошибке отличается от предположения о причине?
Наблюдение описывает то, что вы действительно увидели: после нажатия появилась пустая страница. Предположение объясняет возможную причину: неверный адрес или ошибка сервера. Если передать гипотезу как факт, помощник может начать исправлять не тот участок. Поэтому сначала сообщайте воспроизводимые действия и результат, затем отдельно возможное объяснение.
5. Когда можно считать итерацию завершённой?
Когда согласованное изменение выполнено, проверено по критериям и сохранено в понятном состоянии. Отчёт должен различать выполненные и отложенные проверки. Если важная проверка недоступна, это нужно явно зафиксировать, а не заменять уверенным обещанием. Принятые решения затем добавляются в актуальное описание проекта.
Краткий итог
Хороший промпт соединяет цель, текущий контекст, материалы, ограничения, ожидаемый результат и способ проверки. Примеры помогают объяснить направление, небольшие итерации сохраняют управляемость, а точная обратная связь позволяет исправлять проблему без разрушения удачных частей.
В следующем уроке применим этот подход к первому мини-проекту: странице-визитке. У вас уже есть необходимые опоры — понятная задача, выбранные инструменты и способ проверять результат. Теперь можно переходить от согласованного текста к работающему интерфейсу.