Короткий практический разбор: как давать нейросети задачу так, чтобы на выходе получить код, который можно скопировать, запустить и проверить без долгой переписки.

Я чаще всего вижу одну и ту же ошибку: человек просит «напиши скрипт», получает красивый фрагмент, вставляет его в редактор, а дальше начинается ремонт. Не хватает входных данных. Не указана версия Python. В JavaScript неясно, где код запускается, в браузере или в Node.js. Ошибки не обработаны, формат результата отличается от ожидаемого. Нейросеть не угадывает контекст, она достраивает его по вероятности.

Хороший запрос к ИИ для кода похож на короткое техническое задание. В нём есть среда выполнения, вход, выход, ограничения, проверка и формат ответа. Если эти шесть элементов заданы прямо, шанс получить рабочий скрипт резко растёт. Не магически, а из-за меньшего числа допущений.

Почему просьба «напиши код» почти всегда слабая

Когда вы пишете «сделай скрипт для парсинга файла», в задаче скрыто минимум 8 развилок. Какой файл: CSV, XLSX, JSON, TXT? Какая кодировка: UTF-8 или Windows-1251? Нужна ли обработка пустых строк? Куда складывать результат? Можно ли ставить внешние библиотеки? Что делать, если путь к файлу неверный? Какой размер данных: 200 строк или 2 млн строк?

Для Python разница между «используй только стандартную библиотеку» и «можно поставить pandas» меняет архитектуру решения. Для JavaScript разница между браузером и Node.js меняет доступные API. Например, fs.readFileSync работает в Node.js, но не работает в обычной странице браузера. fetch есть в современных средах, но обработка CORS зависит от того, где запускается код.

Поэтому я формулирую запрос так, будто передаю задачу младшему разработчику на 30 минут. Он должен понять, что открыть, что запустить и как убедиться, что результат правильный. Если вы только начинаете разбираться с запросами, полезно сначала освоить базовые правила промптинга для нейросетей, а затем перенести те же принципы на код: контекст, роль, ограничения, критерии качества.

Каркас запроса для кода, который можно копировать

Я использую один шаблон. Он годится для Python, JavaScript, небольших SQL-запросов и утилит для API.

Ты пишешь рабочий скрипт для [язык и версия].
Среда запуска: [операционная система, браузер/Node.js/терминал].
Задача: [одно действие, без лишних целей].
Входные данные: [формат, пример, путь, поля].
Выходные данные: [формат результата, куда вывести или сохранить].
Ограничения: [без внешних библиотек / можно такие-то библиотеки].
Обработка ошибок: [что делать при пустом файле, неверном формате, ошибке сети].
Проверка: добавь 2–3 тестовых примера или команду запуска.
Формат ответа: сначала коротко объясни запуск, затем полный код одним блоком.
Не используй псевдокод. Если данных не хватает, задай вопросы до написания кода.

В SoftChat такой каркас удобно держать как шаблон промпта для повторяемых задач. Если вы часто пишете утилиты одного типа, например обработку CSV или запросы к API, шаблон сокращает риск забыть про входные данные и проверку. В веб-чате можно вести отдельные разговоры с сохранённой историей, переключать модель для текущего диалога и использовать системный промпт или сохранённого ассистента, если нужна стабильная роль, например «строгий ревьюер Python-кода». Я не советую превращать это в бесконечную настройку: сначала дайте чёткое ТЗ, потом уже меняйте параметры ответа, если выбранная модель их поддерживает.

Что писать для Python, а что для JavaScript

Python чаще берут для файлов, таблиц, автоматизации в терминале, обработки текста, небольших интеграций. JavaScript удобен, когда код должен работать рядом с веб-страницей, в расширении, в Node.js-сервисе или в скрипте для обработки JSON. Запросы к нейросети для этих языков отличаются деталями.

Параметр запроса Python JavaScript
Среда Версия 3.11 или 3.12, терминал, ОС Браузер или Node.js 20+, это надо указать явно
Зависимости Стандартная библиотека, либо список пакетов Встроенные API, npm-пакеты, модульный формат
Вход Файл, stdin, аргументы командной строки JSON, DOM, файл, HTTP-ответ, переменные окружения
Запуск python script.py input.csv node script.js или вставка в консоль браузера
Типовые ошибки Кодировка, пути, пустые строки, большие файлы CORS, асинхронность, промисы, формат модулей
Проверка Мини-файл и ожидаемый вывод Тестовый объект JSON или мок HTTP-ответа

Для примера: если вы просите «сделай скрипт, который объединяет 3 CSV-файла», добавьте строки заголовков, пример одной строки и желаемый результат. Без этого модель может решить, что разделитель запятая, хотя в русскоязычных выгрузках часто встречается точка с запятой. Ещё она может объединить строки по позиции, хотя вам нужно объединение по полю email или id.

Пример запроса для Python

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

Напиши полный рабочий скрипт на Python 3.12.
Задача: прочитать файл orders.csv в UTF-8, посчитать сумму заказов по каждому email и сохранить результат в totals.csv.
Входной файл содержит заголовки: email, order_id, amount, status.
Считать только строки, где status равен paid.
amount может быть строкой с точкой, например 1490.50.
Если файл пустой или нет нужных колонок, выведи понятную ошибку и заверши работу с кодом 1.
Используй только стандартную библиотеку Python.
Добавь команду запуска из терминала.
В ответе дай один полный блок кода без пропусков и короткий пример входа и выхода.

Что здесь хорошо: указана версия языка, кодировка, названия колонок, фильтр, формат числа, зависимость от стандартной библиотеки, поведение при ошибке и команда запуска. Это уже похоже на задание, после которого код можно проверять, а не расшифровывать.

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

Пример запроса для JavaScript

JavaScript особенно чувствителен к среде запуска. Один и тот же фрагмент может быть верным для браузера и бесполезным для Node.js.

Напиши полный рабочий скрипт для Node.js 20.
Задача: отправить GET-запрос к API по адресу, который я передам в переменной окружения API_URL, получить JSON-массив пользователей и вывести в консоль только активных.
Активный пользователь имеет поле isActive: true.
Для каждого активного пользователя выведи строку: id, email, name.
Используй встроенный fetch, без внешних npm-пакетов.
Обработай ошибки: нет API_URL, ответ не 200, JSON не массив, нет нужных полей.
Добавь команду запуска для macOS/Linux и Windows PowerShell.
Верни полный код одним блоком и короткое пояснение, где менять параметры.

В этом запросе нет лишней философии. Зато есть 4 проверки, которые часто забывают: переменная окружения, HTTP-статус, тип JSON и структура объекта. Для небольших внутренних скриптов этого уже достаточно, чтобы не ловить молчаливые падения.

Если задача связана с текстами, а не с кодом, тот же подход к структуре запроса разбирается в статье про нейросеть для генерации текста и проверку результата. Разница в том, что у кода критерий жёстче: он либо запускается, либо нет.

Как просить ИИ не фантазировать библиотеки и методы

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

Просите так:

  • «Если нужна внешняя библиотека, сначала объясни зачем, затем предложи вариант без неё».
  • «Не используй методы, которые помечены как устаревшие в актуальной документации».
  • «Если не уверен в названии метода, явно напиши, что это надо проверить».
  • «После кода добавь список предположений, от которых зависит работа скрипта».
  • «Сделай код самодостаточным: импорты, функция main, обработка ошибок, пример запуска».

Тут помогает и обычная рабочая дисциплина. Сначала просите минимальный скрипт на 40–80 строк, затем просите улучшить обработку ошибок, потом добавляйте логирование или тесты. Не смешивайте всё в одном гигантском запросе. Для внедрения таких сценариев в командную работу пригодится разбор как встроить нейросети в рабочие процессы: там логика та же, только шире, от личных задач до регламентов.

Мини-процесс: от задачи до вставки в редактор

Путь к рабочему скрипту1. СредаВерсия языкаОС и запуск2. ДанныеФормат входаПример строк3. ВыходФайл или экранОжидаемый вид4. ОшибкиПустой вводСбой сети5ТестЗапускЧем меньше скрытых допущений, тем ближе ответ к коду, который можно вставить без ремонта.

После генерации я не вставляю код сразу в рабочее окружение. Мой короткий цикл такой: читаю импорты, проверяю опасные операции с файлами, запускаю на маленьком примере, затем на копии реальных данных. Для скриптов, которые меняют файлы, удаляют записи или отправляют запросы на запись, нужен тестовый режим. Попросите модель добавить флаг --dry-run, если операция может испортить данные.

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

Как добиваться ответа без доработки

Фраза «без доработки» в запросе сама по себе почти ничего не даёт. Лучше заменить её проверяемыми требованиями.

Плохо:

Напиши рабочий код без ошибок.

Лучше:

Код должен запускаться командой node script.js без дополнительных файлов.
Все настройки вынеси в верхние 5 строк.
Если входные данные неверны, выводи ошибку на русском и завершай работу.
Не оставляй TODO, заглушки и псевдокод.

Для Python можно добавить: «собери логику в функцию main() и поставь защиту if __name__ == "__main__"». Для JavaScript в Node.js полезно указать формат модулей: CommonJS или ES-модули. Если не указать, можно получить код с import, который не запустится в проекте без настройки package.json.

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

Где заканчивается зона доверия

Код от нейросети надо воспринимать как черновик с высоким уровнем готовности, а не как принятый релиз. Он может быть синтаксически корректным и всё равно ошибаться в бизнес-логике. Например, скрипт может считать сумму всех заказов, хотя нужны только оплаченные. Или сортировать строки как текст, из-за чего значение 100 окажется перед 20.

Для бытовых и офисных задач, вроде переименования файлов, извлечения строк из CSV, конвертации JSON или подготовки отчёта, нейросеть экономит время уже на первом черновике. Для кода, который работает с деньгами, персональными данными, удалением файлов или записью в базу, нужен ручной просмотр и тесты. Если вам интересны более широкие сценарии вне программирования, посмотрите материал про чат-боты и нейросети для повседневных задач: там хорошо видно, где автоматизация полезна без риска для данных.

В SoftChat для таких итераций помогает история диалога: можно вернуться к исходному ТЗ, увидеть, какие ограничения уже обсуждались, и не собирать контекст заново. Ещё можно отключить использование памяти в конкретном чате, если задача разовая и личные предпочтения не должны влиять на ответ. Это особенно уместно для технических запросов, где важнее строгие параметры окружения, чем привычный стиль общения.

Финальная проверка перед вставкой

Я бы действовал так. Сначала записал бы задачу в 5–7 строках обычным языком. Потом добавил бы версию языка, среду запуска, пример входа и ожидаемый выход. После этого попросил бы нейросеть вернуть полный код одним блоком, без заглушек, с командой запуска и обработкой ошибок.

Если ответ получился длинным, я не стал бы сразу просить «улучши всё». Я бы задал точечный второй запрос: «проверь, где код может упасть на пустом файле», «добавь тестовый пример», «сделай режим без записи изменений». Так диалог остаётся управляемым, а код не расползается.

Главное правило простое: просите не «код», а воспроизводимый результат. Укажите, что подаёте на вход, что хотите получить на выходе и как проверить запуск. Тогда нейросеть чаще выдаёт скрипт, который действительно можно скопировать, вставить и проверить за несколько минут, а не превращать в отдельную задачу на отладку.