Как правильно ставить задачу нейросети, чтобы она написала рабочий код?
Качество кода, который вы получаете от нейросети, на 80 % определяется тем, как вы сформулировали задачу. По данным Anthropic, 82 % провалов ИИ-агентов происходят из-за плохого описания задачи, а структурированное ТЗ поднимает успешность первой попытки с ~23 % до ~61 % (Claude Blog, 2026). При этом в Яндексе «помочь написать код» ищут около 400 раз в месяц — и почти всегда эти запросы звучат как «напиши мне скрипт» без единого уточнения. В этой статье — система постановки задач, которая работает с любой нейросетью: DeepSeek, Claude, GLM или любым агентом. Она строится на четырёх блоках: контекст, требования, ограничения, формат результата.
Почему нейросеть пишет код «не то»: главные причины
Прежде чем менять формулировки, разберёмся, почему результат расходится с ожиданиями. Семь причин, которые встречаются в 9 из 10 «неудачных» запросов:
- Нет контекста. «Напиши бота» — бота для чего? В каком мессенджере? С какой базой?
- Нет входных и выходных данных. Нейросеть выдумала формат, а не взяла ваш.
- Нет ограничений. Без ограничений модель берёт самый «популярный» стек, а не ваш.
- Одна гигантская задача. «Сделай интернет-магазин» — это 50 задач, а не одна.
- Нет примера. Один реальный пример формата входных данных стоит тысячи слов описания.
- Нет обратной связи. Вы не запустили код и не показали ошибку — диалог не развивается.
- Двусмысленные слова. «Красиво», «быстро», «нормально» — нейросеть интерпретирует их по-своему.
Правило, которое меняет всё: относитесь к нейросети как к очень способному исполнителю, который видит ваш текст впервые и не имеет права задать ни одного вопроса. Всё, что не написано, — будет придумано.
Та же мысль — на примерах формулировок:
| Плохо | Хорошо | Почему |
|---|---|---|
| «Напиши парсер» | «Распарси XML из папки /data в CSV, битые файлы пропускай с логом» | Заданы вход, выход и поведение при ошибках |
| «Исправь ошибку» | «Вот код и стектрейс: <вставьте> — исправь минимально и объясни причину» | Модель видит факты, а не пересказ |
| «Сделай быстро» | «Ограничение: один проход по данным, без копирования списков» | Метрика «быстро» переведена в код |
| «Улучши код» | «Упрости вложенность до двух уровней, поведение не менять» | Критерий улучшения измеримый |
Структура хорошего ТЗ: четыре блока
Рабочее ТЗ для кода собирается из четырёх блоков. Вот шаблон, который можно копировать:
КОНТЕКСТ: <что это за проект, какая задача решается, кто будет пользоваться>
ЗАДАЧА: <что именно нужно сделать, одним-тремя предложениями>
ТРЕБОВАНИЯ:
- входные данные: <формат, пример>
- выходные данные: <формат, пример>
- стек: <язык, версия, библиотеки>
- ограничения: <что нельзя, чего избегать>
- краевые случаи: <пустой ввод, дубли, отсутствие данных>
ФОРМАТ ОТВЕТА:
- план из 3–5 шагов, затем код
- комментарии на русском
- покажи пример вызова с реальными данными
Пример «до» и «после»:
До: «Напиши парсер цен»
После:
КОНТЕКСТ: собираю цены конкурентов для отчёта, файлы приходят раз в неделю.
ЗАДАЧА: парсер XML из папки /data в CSV.
ТРЕБОВАНИЯ: вход — XML с товарами (теги <item><name><price>), выход — CSV
с колонками name;price;date; файлы могут быть пустыми и битыми — пропускать
с записью в лог; Python 3.12, только стандартная библиотека.
ФОРМАТ: план, потом код, комментарии на русском, пример вызова.
Разница очевидна: вторая формулировка даёт исполнителю всё, чтобы не выдумывать, а третья версия кода обычно становится первой рабочей.
Как давать контекст: файлы, код, примеры
Текст — не единственный способ дать контекст. В 2026 году лучшие практики такие:
- Давайте файлы проекта целиком. Агенты (Claude Code, Cursor, AgentHere) читают репозиторий сами — не нужно копировать 50 файлов в чат.
- Вставляйте фрагменты с местом назначения. «Есть файл utils.py, функция parse_date там — вот её сигнатура». Покажите, где будет жить новый код.
- Примеры реальных данных — золото. Строка CSV, фрагмент JSON, пара строк из лога — модель строит код по факту, а не по абстракции.
- Ошибка целиком. Стек трейс без сокращений: в нём модель видит точную причину, которую вы в пересказе исказите.
Принципы работы с контекстом в более широком смысле разобраны в гайде по промпт-инжинирингу.
Итерации: как дожимать результат до рабочего
Даже с идеальным ТЗ первый результат — черновик. Дальше работает цикл:
- Запустите код. Без запуска вы не узнаете, что он делает на самом деле.
- Скормите ошибку дословно. Вставьте сообщение об ошибке целиком и добавьте: «исправь и объясни причину в одной строке».
- Уточняйте по одному пункту за раз. «Добавь обработку пустого файла», потом «вынеси парсинг в отдельную функцию» — по одной задаче на запрос.
- Фиксируйте договорённости. После каждой успешной итерации резюмируйте: «итак, текущее состояние: ...». Так модель не «забывает» решения между ответами.
- Требуйте тесты. «Напиши тест на функцию с примером пустого ввода» — тесты превращают гадание в проверку.
Эмпирическое правило: 70 % времени при работе с нейросетью уходит не на написание кода, а на проверку и отладку. Это нормально — так выглядит новая инженерия. Задача ТЗ — не «сделать сразу идеально», а «минимизировать число итераций».
Промпты-антипаттерны: чего не делать
- «Сделай как в интернете». Модель не знает, какой «как в интернете» вы видели. Покажите пример.
- «Исправь ошибку» без ошибки. Если вставить только «не работает» — будет ответ-пустышка. Нужен текст ошибки или ожидаемое vs фактическое поведение.
- «Улучши код» без метрики. «Улучши» — что улучшить: скорость, читаемость, безопасность? Метрика одна и конкретная.
- Смена темы в середине. Одна сессия — одна задача. Смена задачи = новая сессия с полным контекстом.
- «Ты ошибся» без объяснения. Скажите, в чём именно ошибка: «ты использовал os.path, а файл может быть не на диске — нужен поток ввода».
Как ставить задачи агентам (а не просто чату)
Отличие агента от чата: агент сам читает проект, правит файлы и запускает тесты — поэтому ТЗ для агента должно содержать ещё и границы полномочий:
- Что агент может менять: «только файлы в src/parser/», «только новые файлы».
- Что агент должен подтверждать: «удаление файлов — с подтверждением», «установка зависимостей — с подтверждением».
- Когда остановиться: «сделай и остановись, не рефактори весь проект».
- Что проверить перед сдачей: «прогони тесты и покажи вывод».
Без границ агент в лучшем случае перевыполнит задачу (отрефакторит половину проекта), в худшем — навредит. Полный разбор прав, веток и ревью — в гайде по настройке ИИ-агента для кода, а принципы безопасности промптов — в гайде по разработке агентов.
Чек-лист перед отправкой запроса
За пять секунд проверьте свой запрос по списку:
- Есть контекст: проект, задача, кто пользователь
- Входные и выходные данные описаны (лучше — с примером)
- Стек зафиксирован: язык, версия, библиотеки
- Ограничения явные: чего не делать
- Краевые случаи упомянуты: пустой ввод, дубли, ошибки
- Формат ответа задан: план, код, комментарии, пример
- Одна задача на один запрос
Если по любому пункту — «не знаю», сформулируйте его минимально: «просто обработай пустой файл без ошибки». Пусть даже без деталей — факт упоминания меняет поведение модели заметно.
Итог: ТЗ — это навык, а не формальность
Умение ставить задачу нейросети — главный навык разработчика 2026 года, и он тренируется точно так же, как любой другой: практикой. Через две-три недели осознанной работы вы заметите, что формулируете требования быстрее, видите пробелы в чужих ТЗ и получаете рабочий код с первой-второй итерации вместо пятой-седьмой. Нейросети не стали умнее от ваших слов — просто перестали додумывать.
В AgentHere этот навык окупается сразу: вы формулируете задачу на русском, агент-разработчик читает проект, пишет код и прогоняет тесты, а вы проверяете результат. Если нет идеи, с чего начать, — вот гайд, как собрать первого агента за один вечер.
Промпт-шаблоны для разных задач
Пять заготовок под типовые сценарии — меняйте только содержимое скобок:
Скрипт: «Напиши Python-скрипт, который <действие> из <источник> и сохраняет в <назначение>. Аргументы командной строки: <какие>. Обработай случаи: <пустой вход, битые строки>. Версия Python <номер>.»
Функция: «Напиши функцию <имя>(<вход>), которая возвращает <выход>. Поведение: <описание>. Аннотации типов, докстринг, без побочных эффектов. Пример: <вход> → <выход>.»
Исправление ошибки: «Вот код и ошибка: <код> <стектрейс>. Найди причину, исправь минимально, объясни в двух предложениях, что было не так. Не меняй остальное.»
Рефакторинг: «Упрости этот код <код> без изменения поведения. Критерии: <меньше вложенности / короче / быстрее>. Покажи только изменённые функции и список изменений.»
Обучение: «Объясни <тему> на примере этого кода <код> для человека, который знает <базовый уровень>. Порядок: сначала пример, потом правило, потом частые ошибки.»
Шаблоны экономят 80 % времени формулировки, но не заменяют главное: конкретные данные вашей задачи. Пустой шаблон без контекста — это снова «напиши парсер цен».
Как понять, что ТЗ было плохим
Симптомы обратной связи после запуска:
- ИИ «выдумал» формат. Значит, вы не дали пример входных данных — добавляйте образец всегда.
- Код делает другое, чем просили. Проверьте формулировку задачи: она должна быть одной и измеримой («сгруппировать по месяцам» — измеримо; «обработать данные» — нет).
- Каждая итерация ломает предыдущую. Вы нарушили правило «одна задача на запрос» или не фиксируете договорённости резюме.
- Ответы становятся вежливо-пустыми. Модель «плавает» от нехватки контекста и компенсирует общими словами. Дайте файлы, данные, реальную ошибку.
- Дорого. Если на задачу ушло больше токенов, чем она стоит, — ТЗ было плохим: распишите требования жёстче, чтобы отсечь перебор вариантов.
Вопросы и ответы
Один и тот же промпт даёт разные результаты — это нормально? Да, модели вероятностные. Для воспроизводимости: зафиксируйте температуру (ниже — стабильнее), дайте пример ожидаемого вывода и требуйте формат ответа. Если результат всё равно скачет — задача слишком большая, режьте на части.
Нужно ли писать ТЗ по-английски? Современные модели одинаково хорошо понимают русский, но код-идентификаторы и стек-трейсы оставляйте как есть. Английский даёт небольшой прирост качества на самых сильных моделях, но для российских моделей (GLM, DeepSeek) родной язык естественнее.
Что делать, если нейросеть отказывается решать задачу («не могу выполнить»)? Обычно это не отказ, а нехватка деталей. Уточните, что именно заблокировано: отсутствие контекста, «этичная» граница или недостаток прав агента. Для агентов проверьте границы полномочий — возможно, задача вне его прав и песочницы.
Как улучшать ТЗ со временем? Заведите файл с шаблонами (как выше) и пополняйте его после каждой успешной задачи: что сработало, какие формулировки дали рабочий код. Через месяц у вас будет личный промпт-стандарт, который сильнее любого общего гайда.
ТЗ для текстов и ТЗ для кода — одно и то же? Структура та же (контекст, задача, требования, формат), но для кода критичны примеры данных и ограничения стека, а для текстов — тон и аудитория. Общие принципы формулировок — в гайде по промпт-инжинирингу.