Нейросеть пишет код хорошо ровно настолько, насколько точно сформулирована задача. «Напиши скрипт для работы с файлами» даёт бесполезный пример из учебника, а «прочитай CSV, отфильтруй строки с пустым email и сохрани в новый файл» — рабочий код с первого раза.
Что должно быть в запросе
Пять элементов, без которых получается угадайка.
- Язык и версия. «Python 3.11», а не «питон». Между версиями ломается синтаксис.
- Вход и выход. Что на входе (файл, строка, аргументы), что на выходе (файл, JSON, print).
- Ограничения. «Без внешних библиотек», «только стандартная библиотека», «без pandas».
- Обработка ошибок. Что делать, если файла нет, данные битые, сеть недоступна.
- Формат ответа. «Один файл», «с комментариями», «с примером вызова».
Пример: «Python 3.11, только стандартная библиотека. Прочитай CSV с колонками name,email,date, отфильтруй строки с пустым email, сохрани результат в filtered.csv с тем же заголовком. Если файла нет — понятное сообщение и выход с кодом 1. Один файл, с короткими комментариями».
Готовые промпты под типовые задачи
Новый скрипт. «Напиши скрипт на [язык]: [что делает]. Вход: [что], выход: [что]. Ограничения: [список]. Обработай ошибки [какие]. Один файл с комментариями».
Объяснить чужой код. «Объясни, что делает этот код, по шагам. Для каждой функции — назначение, вход, выход. Отметь места, где могут быть ошибки: [код]».
Найти ошибку. «Вот код и текст ошибки: [код] [ошибка]. Найди причину, объясни, почему возникает, и предложи исправление. Не переписывай весь файл — только нужное место».
Улучшить. «Отрефактори этот код: убери повторы, дай понятные имена, добавь обработку ошибок. Функциональность не меняй. Покажи, что изменил и почему».
Написать тесты. «Напиши тесты для этой функции: обычный случай, граничный, ошибочный. Используй [pytest/unittest]. Покажи, как запустить».
SQL-запрос. «Есть таблицы: [структура]. Напиши запрос, который [задача]. Используй [диалект: PostgreSQL/MySQL]. Объясни, что делает каждая часть».
Где модель ошибается
| Проблема | Что делать |
|---|---|
| Несуществующие функции и методы | Просить только стандартную библиотеку или указывать точные версии пакетов |
| Устаревший синтаксис | Всегда указывать версию языка |
| Нет обработки ошибок | Добавлять требование явно — сама не предложит |
| Код «в вакууме» | Давать реальный пример входа и ожидаемого выхода |
| Ломает рабочее при рефакторинге | Просить менять точечно, а не переписывать файл |
Отдельно про «несуществующие функции»: модель может уверенно вызвать метод, которого нет в библиотеке. Это самая частая и самая обидная ошибка — код выглядит правильно и падает при запуске. Лечится запуском, а не чтением.
Как работать с большими проектами
Не давайте весь проект целиком. Работает пошагово:
- Сначала структура. «Вот задача: [описание]. Предложи структуру файлов и функций, без кода».
- Потом по функциям. Каждая — отдельным запросом, с контекстом.
- В конце — сборка. «Вот все части, собери в один файл, проверь, что вызовы совпадают».
Так модель не теряет контекст и не выдумывает несуществующие модули. И вы видите, где именно ошибка, если она появится.
Пример: как выглядит хороший и плохой запрос
Плохо: «Напиши скрипт для обработки данных».
Что получится: учебный пример с выдуманными именами файлов, который нельзя запустить. Модель не знает ни языка, ни формата данных, ни что делать с ошибками.
Хорошо: «Python 3.11, только стандартная библиотека. На входе CSV с колонками name,email,date, около 10 000 строк. Нужно: отфильтровать строки с пустым email, привести даты к формату YYYY-MM-DD, сохранить в clean.csv с тем же заголовком. Если файл не найден — сообщение и exit 1. Один файл, короткие комментарии, пример вызова в конце».
Во втором варианте есть язык и версия, формат входа, точная операция, формат выхода, обработка ошибки и формат ответа. Именно это отличает рабочий запрос от учебного.
Как проверять код от модели
Прежде чем запускать, посмотрите три вещи.
- Импорты. Все ли библиотеки существуют и указаны в требованиях. Несуществующий импорт — самая частая ошибка.
- Функции. Если вызов выглядит незнакомо — проверьте в документации. Модель может «вспомнить» метод, которого нет.
- Граничные случаи. Пустой файл, отсутствующая колонка, битая строка — обработаны?
Запуск на маленьком тестовом файле занимает минуту и ловит 90% проблем. Чтение кода глазами — не заменяет его.
Как просить объяснение
Если код непонятен, не просите «объясни код» — получите пересказ каждой строки. Просите так: «объясни логику по шагам: что происходит с данными от входа до выхода. Что будет, если на входе окажется файл без заголовка?».
Второй вопрос важнее первого: он показывает, понимает ли модель границы собственного решения — и заодно подсказывает вам, что стоит протестировать.
Частые вопросы
Может ли нейросеть писать рабочий код?
Да, для типовых задач — с первого или второго раза. Проверять запуском обязательно: модель уверенно использует несуществующие методы.
Что делать, если код не запускается?
Дайте модели текст ошибки целиком и попросите исправить только нужное место, не переписывая всё.
Какой язык лучше указывать?
Тот, на котором проект. И обязательно версию — синтаксис между версиями отличается.
Можно ли доверять SQL-запросам?
Для чтения — почти всегда. Для UPDATE и DELETE — проверяйте дважды: ошибка в условии обойдётся дорого.
Помогает ли модель с чужим кодом?
Да, и это один из лучших сценариев: объяснение незнакомого кода по шагам экономит часы.
Нужно ли проверять код на безопасность?
Обязательно, если он работает с пользовательским вводом, файлами или базой. Модель не всегда предлагает валидацию и экранирование.
Об общих приёмах — в статье промпт-инжиниринг. О текстовых задачах — в статье промпты для текстов.
