Нейросети, умеющие писать код, полезны для небольших рабочих задач. Показываю, как задать условия, проверить исключения и не запускать сырой скрипт на данных.
М
Марина
Контент-маркетолог LibraChat
8 мин чтения
Нейросети, умеющие писать код, могут снять с тебя черновую работу: предложить скрипт, объяснить чужую функцию, подсказать тест. Но готовый на вид фрагмент ещё не решает твою задачу. Я покажу, как дать нейросети достаточно условий и принять результат так, чтобы не обнаружить ошибку уже после обработки рабочей таблицы.
У меня была будничная просьба: посчитать итог по заказам из CSV. На учебных 12 строках скрипт выглядел убедительно. Потом я заметила строку с возвратом: сумма шла в общую выручку, хотя в нашем отчёте её нужно было вычесть. Ошибку нашла я, не красивый вывод программы. С тех пор начинаю с описания правила расчёта, а не с просьбы «напиши код».
Где нейросети, умеющие писать код, меня подвели
Проблема возникла не из-за сложного языка программирования. Я не объяснила, что означает отрицательная строка и как обрабатывать пустую ячейку. Модель получила расплывчатую задачу и дополнила её привычными предположениями. Если пользователь потом запускает код на настоящих данных, предположения становятся ошибками в отчёте.
Для иллюстрации возьмём обезличенный файл с колонками `order_id`, `amount`, `status`. В нём обычные оплаты, отмены и возвраты. Запрос «посчитай продажи» оставляет открытыми минимум четыре вопроса: считать ли отмены, знак возврата, пустые суммы и повторяющийся номер заказа. На одном тестовом файле можно не встретить ни одного спорного случая.
Я переписала задачу как маленький договор о результате. Никаких секретов, адресов клиентов или выгрузки из CRM в примере нет. Для рабочей компании вопрос доступа к данным решается по её правилам; учебного набора достаточно, чтобы сначала проверить ход решения.
Вход: CSV в кодировке UTF-8 с тремя названными колонками. Сумма хранится числом; пустая ячейка считается ошибкой входа.
Правило: оплаченный заказ добавляет сумму, возврат вычитает, отмена не меняет итог. Повтор `order_id` нужно показать отдельным предупреждением.
Выход: итог, число обработанных строк и список строк, которые не удалось разобрать. Программа не должна молча пропускать их.
Граница: исходный файл остаётся нетронутым; результат пишется в новый файл только после явной проверки.
Такой список можно прочитать и без умения писать Python. Именно это важно: человек, который знает бизнес-правило, способен увидеть неверную трактовку до запуска скрипта.
Сначала запрос, потом код
LibraChat помогает с кодом в обычном диалоге. Я бы попросила его построить решение на маленьком вымышленном наборе и отдельно перечислить неопределённости. Ниже предлагаемый запрос, а не цитата из фактически полученного ответа сервиса:
«Нужен пример Python-скрипта для CSV с колонками `order_id`, `amount`, `status`. Статусы: `paid`, `refund`, `cancelled`. `paid` прибавляет сумму, `refund` вычитает, `cancelled` не влияет. Не меняй исходный файл. Перед кодом перечисли вопросы, без которых расчёт может быть неверным. После кода предложи тесты для пустой суммы, повторного `order_id` и неизвестного статуса. Объясни, какие места мне проверить вручную».
Слова «перед кодом перечисли вопросы» меняют разговор. Если в учёте возврат хранится отрицательным числом, а код вычитает его ещё раз, получится плюс. Я сама однажды не уточнила знак. Поэтому ответ на вопрос о формате входа важнее любой элегантной функции.
Большой промпт не нужен. Полезнее назвать цель, вход, правила и критерии приёмки. Когда модель пишет код, попроси её пояснить каждое предположение, которого нет в твоём описании. Предположения и станут первой очередью для проверки.
Что нейросети, умеющие писать код, должны показать перед запуском
Я проверяю логику вычисления ещё до разговора о синтаксисе. Код может выполняться и всё равно считать не то. У меня есть короткий маршрут проверки, который подходит и для скрипта на десять строк, и для более длинного черновика. Он не заменяет разбор опытным разработчиком, если речь идёт о рабочей системе или чужих данных.
Этап · Что попросить или сделать · Как понять, что пора идти дальше
Требования — Повторить правило расчёта своими словами — Нет новых допущений о статусах и суммах
Чтение кода — Найти место обработки возврата и пустой суммы — Путь каждого случая виден, ошибка не скрыта
Тесты — Прогнать маленький набор с заранее известным итогом — Получен ожидаемый итог и понятны предупреждения
Безопасность — Посмотреть, какие файлы код читает и пишет — Исходник не перезаписывается, лишних действий нет
Приёмка — Сравнить итог с ручным расчётом — Расхождения разобраны до настоящей выгрузки
В руководстве GitHub по проверке сгенерированного кода отдельно советуют оценивать соответствие требованиям и архитектуре, запускать тесты и статический анализ. Для читателя без среды разработки это можно перевести в практический минимум: сначала тестовый файл, затем ожидаемый итог на бумаге, затем чтение операций с файлами. Если скрипт предлагает системную команду, сетевой запрос или установку непонятного пакета, работу стоит остановить до проверки специалистом.
Вот порядок, который я использую для учебной таблицы:
Сама считаю итог для трёх строк: оплата, возврат, отмена. Это контрольное число известно до запуска.
Добавляю пустую сумму и неизвестный статус. Скрипт должен сообщить о проблеме, а не выдать видимость полного отчёта.
Проверяю повторный номер заказа. Если правило обработки дублей неизвестно, результат не принимаю.
Смотрю, куда будет записан результат. Команда на удаление или перезапись входного файла требует отдельного решения.
Лишь после этого передаю код разработчику или запускаю в разрешённой рабочей среде на копии данных.
Пять шагов кажутся длиннее одной кнопки. Зато они отвечают на вопрос, на который сама нейросеть не может ответить за твою организацию: что в этой таблице считать правильным результатом.
Когда лучше попросить объяснение, а не новый скрипт
Иногда задача в другом. Ты получил от коллеги функцию и не понимаешь, почему она удаляет строки без статуса. Просьба «перепиши красивее» способна скрыть причину. Я сначала прошу разобрать код по веткам: какой вход попадает в каждую ветку и что получается на выходе. Затем проверяю разбор на двух-трёх искусственных строках.
Отдельно сохраняю версию задания, с которой начиналась работа. Если после третьего уточнения в чате изменилось правило возврата, прежний тест уже не доказывает правильность нового кода. Мне удобно вести короткую заметку: «версия 1 — возвраты положительными суммами, версия 2 — отрицательными». Рядом записываю, какой контрольный пример использовался. Тогда следующему человеку не приходится угадывать, почему проверка вчера прошла, а сегодня дала другое число.
Для командной задачи эта привычка ещё полезнее. Один коллега знает структуру CSV, другой отвечает за отчёт. Я прошу их согласовать один пример строки и ожидаемый итог до генерации. Если они расходятся, проблема пока в постановке задачи. Исправление промпта здесь не поможет: нейросеть просто выберет одну трактовку за нас и оформит её убедительно.
Для новичка полезен формат «строка кода — смысл — риск», а не лекция о всём языке. Если нейросеть объяснила оператор, но не показала, как он влияет на конкретный файл, я уточняю именно этот шаг. Заодно видно, где мне не хватает знаний: в синтаксисе, в структуре данных или в правиле отчёта.
Есть и обратный случай: ты хорошо знаешь код, но плохо понимаешь требование заказчика. Тут модель может помочь составить список вопросов к задаче. Исполняемый фрагмент пока рано просить. Любая неясность в словах «активный клиент», «закрытый заказ», «последний период» превращается в ветку программы. Я предпочитаю получить ответ от владельца процесса до написания этой ветки.
Где остановиться и позвать человека
Я не поручаю нейросети окончательно решать вопросы доступа, безопасности и корректности финансового отчёта. Сгенерированный код требует человеческой проверки. Рекомендации OWASP об обработке вывода ИИ отдельно предупреждают: текст модели нельзя без проверки превращать в команды или другие исполняемые инструкции. Это касается и скрипта, который выглядит аккуратно.
Условия безопасности зависят от среды. Нельзя вставлять в открытый запрос рабочие токены, пароли, внутренние адреса или персональные данные ради «точного примера». Я убираю эти детали из учебного файла, а для настоящей интеграции использую согласованный процесс команды. Если такого процесса нет, статья не даёт повода его обойти.
Если нужен только черновик, открой чат LibraChat и опиши обезличенный вход, правило и ожидаемый выход. Условия доступа и варианты тарифа можно посмотреть на странице тарифов; про смежные сценарии есть материал «Нейросеть для программиста». Скопируй предложенный запрос выше и замени названия колонок своими учебными полями.
Моя проверка в конце остаётся прежней: могу ли я заранее назвать правильный ответ для маленького набора? Если нет, запускать большой скрипт рано. Сначала уточни правило у человека, который отвечает за данные. Потом возвращайся к коду.
