Ассистент выполняет ровно то, что понял из запроса. Расплывчатая задача даёт правдоподобный, но чужой код, который потом дольше чинить, чем написать. Хорошая постановка похожа на хороший тикет для коллеги, который впервые видит проект.
Из чего состоит хорошая задача
- Цель. Что должно получиться и зачем. «Добавить пагинацию в список заказов, чтобы страница не грузила 10 000 строк».
- Контекст. Какие файлы, модули, типы и соглашения важны. Приложите их или назовите явно.
- Ограничения. Без новых зависимостей, не менять публичный API, совместимость с текущей версией фреймворка, стиль ошибок как в проекте.
- Критерий готовности. Какие тесты должны пройти, какие случаи обработать, как проверить руками.
- Формат ответа. Только дифф, план перед кодом, список допущений.
Пример:
Задача: курсорная пагинация для GET /orders.
Файлы: src/orders/orders.controller.ts, orders.service.ts, prisma/schema.prisma.
Ограничения: без новых пакетов, ответ { items, nextCursor }, лимит 1..100, по умолчанию 20.
Готово, когда: проходят существующие тесты и новые на пустой список,
последнюю страницу и невалидный курсор.
Сначала опиши план и допущения, код после моего ок.
Декомпозиция
Большая задача одним запросом даёт большой дифф, который трудно проверить. Лучше шагами: сначала план, потом схема данных, потом сервис с тестами, потом контроллер. Каждый шаг маленький и проверяемый, и ошибку видно сразу, а не через 600 строк.
План от ассистента полезен сам по себе: в нём видно, как он понял задачу. Неверное понимание дешевле поправить на плане, чем в коде.
Примеры и образцы
Модель хорошо копирует стиль. Покажите один существующий эндпоинт или тест как образец: «сделай по аналогии с users.controller.ts». Это работает лучше, чем абзац описания стиля.
Итерации
Первый ответ редко финальный. Рабочий цикл:
- запустить код и тесты;
- вернуть ассистенту конкретный результат: текст ошибки, упавший тест, неверный вывод;
- просить точечную правку, а не «переделай всё».
«Не работает» без подробностей заставляет модель гадать. Стектрейс и входные данные дают ей факты.
Когда начать заново
Если после нескольких попыток ассистент ходит по кругу, длинная история мешает: в ней накопились неудачные варианты, и модель за них цепляется. Помогает новый диалог с короткой сводкой: что нужно, что уже пробовали, почему не подошло.
Файлы правил проекта
Многие инструменты читают файл с инструкциями в репозитории: команды сборки и тестов, архитектура, запреты, стиль. Его подкладывают в каждый запрос, и не нужно повторять одно и то же. Хороший файл правил:
- короткий и конкретный: «тесты запускать так», «не трогать папку generated»;
- лежит в репозитории и проходит ревью, как код;
- обновляется, когда ассистент повторяет одну и ту же ошибку.
Неоднозначность решает человек
Если задачу можно понять двумя способами, модель выберет один молча и по-своему. Это всплывёт на ревью или, хуже, у пользователя. Поэтому неоднозначности снимаются до запроса: уточните у аналитика или заказчика и запишите решение прямо в постановку. Полезный приём: попросить ассистента перечислить вопросы и допущения по задаче. Список вопросов часто показывает дыры в требованиях, которые вы сами не заметили.
Свой контекст против общего
Ассистент знает общий мир: популярные библиотеки, типовые паттерны. Он не знает ваш мир: внутренние сервисы, договорённости, историю решений. Чем больше задача завязана на ваш мир, тем больше контекста нужно дать явно и тем строже проверять результат.
Чего избегать
- Секреты, персональные данные и куски чужих закрытых систем в запросе.
- Просьбы «сделай лучше» без критерия.
- Слепое доверие уверенному тону. Формулировка «точно работает» в ответе ничего не значит.
- Прямой копипаст ответа в прод без запуска.
Как это звучит на собесе
«Я формулирую задачу как тикет: цель, файлы, ограничения, критерий готовности. Большое делю на шаги и прошу план перед кодом. Возвращаю ассистенту конкретные ошибки, а если он зациклился, начинаю новый диалог со сводкой».