Хорошая задача для ИИ-агента говорит, для кого предназначено приложение, какую проблему оно решает и по каким конкретным случаям ты поймёшь, что оно работает. Если твои первые попытки с Claude Code или Codex разочаровали, причина чаще не в инструменте, а в задаче, где эти три вещи остались открытыми.
Агент заполняет пробелы предположениями. Чем больше пробелов, тем больше предположений и тем дальше результат от того, что ты себе представлял. В этой статье разберём, как построить задачу, как разбить её на части и как это выглядит на примере списка контактов.
Почему короткая задача редко даёт то, что ты хочешь
Типичная первая попытка звучит примерно так: «Сделай мне приложение для моих контактов». Агент что-то выдаёт. Может быть, список с именами и телефонами, может быть, форму с двадцатью полями, а может быть, страницу входа, которая тебе вообще не была нужна. Технически это не ошибка. Просто это не подходит к твоей работе.
В чём проблема: ты знаешь, кто будет пользоваться приложением, сколько там контактов и что должно происходить после разговора. Агент этого не знает. Он угадывает. А поскольку ты заранее не определил, как измерять успех, у тебя остаётся только ощущение: как-то не так. Дальше следует новая попытка, снова размытая, снова наугад.
Задача с понятной аудиторией, понятной проблемой и проверяемыми случаями разрывает этот круг. Ты можешь сверить любой результат со своими случаями и точно сказать, чего не хватает.
Три составные части хорошей задачи
Аудитория: для кого приложение?
Опиши человека, который будет работать с приложением, и его ситуацию. «Для небольшой фирмы» уже начало. Лучше так: «Для сотрудника отдела продаж небольшой фирмы, который ведёт потенциальных клиентов с выставок и из входящих запросов и в понедельник хочет знать, кому нужно перезвонить». Из этой фразы агент может вывести, что управление должно быть простым, что важны даты и что никому не нужна админка на сто пользователей.
Проблема: что должно стать лучше?
Называй проблему, а не решение. «Хочу таблицу с фильтрами» описывает решение. «Повторные контакты забываются, потому что разбросаны по заметкам и письмам» описывает проблему. Когда агент знает проблему, он может принимать разумные решения, которые ты явно не прописал. А ты потом сможешь проверить, действительно ли решение справляется с проблемой.
Сценарии приёмки: как понять, что всё работает?
Сценарии приёмки (Akzeptanzfälle) это короткие конкретные ситуации с ожидаемым результатом. Проверенная форма: исходная ситуация, действие, ожидаемый результат. Например: «Есть контакт с датой follow-up на вчера. Когда я открываю список, этот контакт отмечен как просроченный».
У таких сценариев два преимущества. Агент точнее понимает, что имеется в виду. А у тебя появляется чек-лист, который можно пройти после каждого изменения, вместо того чтобы полагаться на впечатление. Позже сценарии приёмки можно превратить в автоматические тесты. Тогда одна команда проверяет, всё ли по-прежнему в порядке.
Думай и о сценариях ошибок: что будет, если обязательное поле осталось пустым, если в адресе почты нет @, если список пуст? Именно эти случаи забывают с первого раза, и именно там возникают ошибки, которые потом отнимают у тебя время.
Как разбить задачу на шаги
Даже хорошая задача слишком велика, если описывает всё приложение сразу. Агент тогда выдаёт много кода за один заход, и если что-то не так, непонятно, где искать. Лучше разделить работу на небольшие шаги, каждый из которых можно проверить отдельно.
Как действовать:
- Запиши цель всего приложения в двух-трёх предложениях: аудитория и проблема.
- Собери всё, что приложение должно уметь, в свободный список.
- Расставь пункты так, чтобы каждый опирался на предыдущий. Сначала показывать, потом сохранять, потом изменять, потом подключать.
- Для каждого шага сформулируй от двух до четырёх сценариев приёмки, среди них хотя бы один сценарий ошибки.
- Давай агенту только один шаг за раз и проверяй сценарии, прежде чем двигаться дальше.
- Записывай, что внёс агент и что ты изменил сам.
Последний пункт кажется второстепенным. Но он помогает потом объяснить, как появилось твоё приложение, и быстрее понять, откуда взялась ошибка.
Хороший шаг настолько мал, что результат можно проверить за несколько минут. Если на проверку одного шага уходит полчаса, он был слишком большим.
Пример: задача для списка контактов
Так могла бы выглядеть задача для первого этапа приложения для контактов и follow-up:
Аудитория: сотрудник отдела продаж небольшой фирмы. Он ведёт
потенциальных клиентов и хочет видеть, с кем связаться следующим.
Проблема: follow-up забываются, потому что контакты и следующие шаги
записаны в разных местах.
Этот шаг: список контактов и карточка контакта с примерными данными.
Пока без сохранения, без редактирования, без входа в систему.
Сценарии приёмки:
1. Есть пять примерных контактов. Когда я открываю приложение,
я вижу все пять с именем, фирмой и статусом.
2. Когда я нажимаю на контакт, открывается карточка
со всеми данными и датой следующего follow-up.
3. Когда я нажимаю в карточке «Назад», я снова
вижу список.
4. Контактов нет. Когда я открываю приложение, я вижу
надпись «Контактов пока нет» вместо пустого экрана.
Обрати внимание, что задача явно исключает. «Пока без сохранения, без входа» не даёт агенту встроить функции, которые ты на этом шаге всё равно не сможешь проверить.
Следующие шаги
Только когда все четыре сценария выполняются, идёт следующая задача. Порядок может быть таким:
- Сохранение контактов и проверка ввода: новый контакт без имени отклоняется с понятным сообщением.
- Смена статуса: контакт переходит из «новый» в «связались», и список сразу показывает новый статус.
- Фильтр: когда я фильтрую по «просрочено», я вижу только контакты, у которых дата follow-up в прошлом.
- Интерфейс к сервису: если сервис не отвечает или сообщает об ошибке, приложение показывает уведомление, а не падает.
Каждый из этих шагов снова получает свои сценарии приёмки. Так приложение растёт небольшими контролируемыми частями.
Как понять, что задачи пока недостаточно
Перед отправкой пройдись по этим вопросам:
- Указано ли, кто пользуется приложением и в какой ситуации?
- Описана ли проблема, а не просто желаемая функция?
- Есть ли хотя бы два конкретных сценария приёмки с ожидаемым результатом?
- Есть ли среди них хотя бы один сценарий ошибки, например пустой ввод или пустой список?
- Указано ли, что на этом шаге строить явно не нужно?
- Можешь ли ты проверить результат за несколько минут?
Если на какой-то вопрос ответ «нет», дополни задачу, прежде чем отправлять. Это займёт пару минут и избавит от нескольких кругов доработок.
А если результат всё равно не подходит, сверь его со своими сценариями приёмки. Скажи агенту точно, какой сценарий не выполняется и что происходит вместо этого. «Сценарий 3 не проходит: после нажатия «Назад» карточка остаётся открытой» это обратная связь, с которой агент может работать. «Не работает» уже нет.
Как курс Vibe Coding Foundation отрабатывает этот подход
На курсе Vibe Coding Foundation ты шаг за шагом строишь именно такое приложение для контактов и follow-up с помощью Claude Code или Codex. Формулировка задачи там отдельная миссия: в миссии 1 ты описываешь, для кого предназначено приложение и что оно должно уметь. Плановое время на неё два часа. Умение разбить рабочую задачу на проверяемые шаги и описать их как сценарии приёмки входит в четыре компетенции, которые подтверждает программа.
На этом строятся следующие миссии: список контактов с карточкой, проверка ввода со сменой статусов и фильтрами, симулированный интерфейс с пустыми ответами, ошибками и задержками. У каждой миссии есть цель, критерии в виде тестов и подсказки трёх уровней на случай, если ты застрял. На твоём компьютере одна команда проверяет критерии, так что ты быстро видишь, привела ли твоя задача к нужному результату. Параллельно ты ведёшь ИИ-журнал, где записываешь, что внёс ИИ и что ты изменил сам.
Все миссии с их целями собраны в обзоре курса (на немецком). Если хочешь посмотреть, как выглядит начало: миссия 0 по настройке инструментов доступна для свободного чтения. Как устроен курс в целом, объясняет раздел Как проходит курс на главной странице. В конце тебя ждёт письменный экзамен по проекту. Как он оценивается, показывает рубрика экзамена.