Как просить ИИ написать рабочий код на Python и JS

Короткий практический разбор: как давать нейросети задачу так, чтобы на выходе получить код, который можно скопировать, запустить и проверить без долгой переписки.
Я чаще всего вижу одну и ту же ошибку: человек просит «напиши скрипт», получает красивый фрагмент, вставляет его в редактор, а дальше начинается ремонт. Не хватает входных данных. Не указана версия 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 строк, затем просите улучшить обработку ошибок, потом добавляйте логирование или тесты. Не смешивайте всё в одном гигантском запросе. Для внедрения таких сценариев в командную работу пригодится разбор как встроить нейросети в рабочие процессы: там логика та же, только шире, от личных задач до регламентов.
Мини-процесс: от задачи до вставки в редактор
После генерации я не вставляю код сразу в рабочее окружение. Мой короткий цикл такой: читаю импорты, проверяю опасные операции с файлами, запускаю на маленьком примере, затем на копии реальных данных. Для скриптов, которые меняют файлы, удаляют записи или отправляют запросы на запись, нужен тестовый режим. Попросите модель добавить флаг --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 строках обычным языком. Потом добавил бы версию языка, среду запуска, пример входа и ожидаемый выход. После этого попросил бы нейросеть вернуть полный код одним блоком, без заглушек, с командой запуска и обработкой ошибок.
Если ответ получился длинным, я не стал бы сразу просить «улучши всё». Я бы задал точечный второй запрос: «проверь, где код может упасть на пустом файле», «добавь тестовый пример», «сделай режим без записи изменений». Так диалог остаётся управляемым, а код не расползается.
Главное правило простое: просите не «код», а воспроизводимый результат. Укажите, что подаёте на вход, что хотите получить на выходе и как проверить запуск. Тогда нейросеть чаще выдаёт скрипт, который действительно можно скопировать, вставить и проверить за несколько минут, а не превращать в отдельную задачу на отладку.