Анатомия запроса

контекст, цель, ограничения, критерий готовности

Что это

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

Статья — основа всей главы 3. Дальше идут готовые шаблоны под конкретные задачи, и все они построены из этих четырёх частей.

Четыре части

Как выглядит в коде

Возьмём живую задачу: в Telegram-боте надо добавить ограничение на частоту команд.

Добавь в бота защиту от спама

Запрос выглядит понятным, но в нём нет ни одной из четырёх частей. Что ИИ придумает за тебя: какой фреймворк, какой лимит, где хранить счётчики, что отвечать пользователю, считать ли по командам или по сообщениям, трогать ли существующие обработчики. Шесть решений, и все не твои.

Теперь то же самое, но с четырьмя частями:

Контекст: бот на aiogram 3, файл handlers/commands.py.
Обработчики — функции с декоратором @router.message.
Данные храню в SQLite через aiosqlite, модуль db.py.

Цель: ограничить частоту команд — не больше 5 команд в минуту
от одного пользователя.

Ограничения:
- не добавляй новых зависимостей, только то, что уже в requirements.txt
- не меняй существующие обработчики, сделай отдельным middleware
- состояние держи в памяти, в базу не пиши

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

Второй запрос длиннее в десять раз и экономит час переделок.

Как понять, что контекста достаточно

Контекст — то, чего ИИ не может увидеть. Если он работает прямо в проекте (агент в терминале), файлы он прочитает сам, и контекст сокращается до «где смотреть». Если это чат без доступа к коду — контекст придётся дать словами или вставкой файла.

Минимум, который нужен почти всегда:

• язык, фреймворк и версия — aiogram 3, а не просто aiogram;
• файл или модуль, где делать;
• как в проекте уже решены похожие задачи.

Третий пункт недооценивают. Он важнее первых двух: именно он заставляет ИИ писать в стиле проекта, а не в своём.

Критерий готовности

Самая пропускаемая часть и самая полезная. Критерий — это проверяемое условие, а не пожелание.

Критерий делает две вещи. Во-первых, ИИ понимает, когда остановиться. Во-вторых, у тебя появляется способ проверить результат, не вчитываясь в код, — ты просто проверяешь условие.

Как сказать ИИ

Четыре части не обязаны быть списком. В коротких задачах они умещаются в абзац:

В utils/text.py добавь функцию, которая режет длинное сообщение
на куски по 4096 символов по границам абзацев, не разрывая слова.
Внешних библиотек не используй. Готово, когда текст из 10 000 знаков
даёт 3 куска, и склейка кусков равна исходному тексту.

Здесь всё четыре: контекст (utils/text.py), цель (функция нарезки), ограничение (без библиотек), критерий (10 000 знаков → 3 куска, склейка совпадает).

Для большой задачи те же четыре части разворачиваются в мини-ТЗ — статья 3.15.

На что смотреть

Слишком много контекста тоже вредно. Если вывалить весь проект, важное утонет. Давай то, что относится к задаче, и ссылайся на остальное одной строкой.

Ограничения формулируй через «не», а не через «только». «Используй только стандартную библиотеку» ИИ иногда читает как пожелание. «Не добавляй новых зависимостей» работает надёжнее.

Критерий, который нельзя проверить, — не критерий. Если ты сам не знаешь, как проверишь результат, задача сформулирована не до конца. Это сигнал вернуться к шагу 1 рабочего цикла, а не писать запрос дальше.

Версия фреймворка решает больше, чем кажется. aiogram 2 и aiogram 3 несовместимы, у React другой подход после хуков, Flutter меняет API между мажорными версиями. Не указал версию — получишь код для той, которой в обучении было больше.

Шпаргалка