Автоматизация кода через ИИ работает лучше всего, когда вы просите не «написать программу», а ведёте модель по короткому инженерному маршруту: задача, варианты, проверка, адаптация.

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

Хорошая новость: без знания программирования можно получить 20–30 вариантов скрипта, сравнить их и довести до безопасной рабочей версии. Для этого не нужно становиться разработчиком. Нужно научиться описывать задачу так, чтобы языковая модель генерировала проверяемые решения, а не один «магический» ответ. Если вы только начинаете работать с текстовыми запросами, полезно сначала разобрать основы формулировки промптов для нейросетей, потому что в коде цена расплывчатого запроса выше, чем в обычном тексте.

Когда ИИ действительно помогает писать скрипты

Скрипт нужен там, где есть повторяемое действие. Не «разработать сервис на месяцы», а взять входные данные, применить правила и получить результат. Типичные задачи: переименовать 500 файлов по шаблону, собрать 12 таблиц в одну, вытащить из писем номера заказов, проверить строки на дубли, преобразовать CSV в XLSX, скачать набор страниц, разложить документы по папкам.

Ручная обработка 200–300 строк в таблице часто занимает час и больше, если нужно сверять несколько колонок. Скрипт на 30–80 строк обычно закрывает такую задачу быстрее, но только после проверки на копии данных. Для разовой операции это уже окупается, если действие повторится хотя бы 3–4 раза. Для еженедельной рутины эффект заметнее: 20 минут настройки один раз могут заменить десятки одинаковых кликов каждый месяц.

Есть граница, где новичку без разработчика лучше остановиться. Не стоит самостоятельно просить модель написать код, который удаляет данные без резервной копии, меняет финансовые документы, работает с персональными данными без понятного режима хранения или имеет доступ к платёжным операциям. Такие сценарии требуют ревью специалиста. А вот локальная сортировка файлов, расчёт по открытой таблице, подготовка черновика отчёта или пакетное переименование изображений подходят хорошо.

Почему нужно просить 20–30 вариантов, а не один

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

Я предпочитаю просить партии по 5 вариантов. После каждой партии модель получает уточнение: «сделай безопаснее», «убери внешние зависимости», «добавь проверку пустых строк», «сохрани исходные файлы». За 4–6 раундов получается 20–30 решений. Большую часть можно отбросить за 2 минуты по простым признакам: слишком много зависимостей, нет обработки ошибок, непонятно где менять путь к файлу, скрипт сразу удаляет или перезаписывает данные.

Модельный кейс: «переименование 1 200 фотографий» лучше начинать с варианта, который выводит старое и новое имя в таблицу предпросмотра, а не сразу меняет файлы. Если первые 20 строк совпали с ожиданием, только потом можно включать реальное переименование. Это не делает задачу сложнее. Наоборот, снижает риск в разы, потому что самая частая ошибка в таких задачах, неверный шаблон имени.

Рабочий промпт для генерации пачки скриптов

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

Мне нужен скрипт для автоматизации задачи.
Я не программист, поэтому объясняй простыми словами.
Задача: [что нужно сделать].
Входные данные: [файл, папка, таблица, пример строк].
Результат: [что должно получиться].
Ограничения: не удалять исходные файлы, сначала сделать режим проверки.
Среда: [Windows/macOS/Linux], язык: [Python или JavaScript].
Дай 5 разных вариантов решения.
Для каждого варианта укажи: когда подходит, риски, зависимости, как запустить.
Код пока не пиши длиннее 80 строк.

Если задача связана с текстом, таблицами или повторяемыми рабочими шагами, её удобно сначала разложить на операции. В этом помогает подход из статьи про внедрение нейросетей в рабочие процессы: не автоматизировать хаос, а описать стабильный процесс. Например, «каждую пятницу беру файл sales.csv, фильтрую строки со статусом paid, считаю сумму по регионам, сохраняю итог в report.xlsx». Это уже почти техническое задание.

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

Как сравнивать варианты без знания программирования

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

Критерий Хороший признак Тревожный признак Что спросить у модели
Безопасность Есть копия или режим предпросмотра Скрипт сразу удаляет или перезаписывает «Добавь сухой запуск без изменений файлов»
Простота запуска 1–3 команды и понятные пути Нужно ставить много пакетов «Сделай версию без внешних зависимостей»
Читаемость Есть комментарии к блокам Код выглядит как плотная стена «Разбей на функции и подпиши шаги»
Проверка результата Печатает сколько строк обработано Ничего не сообщает после запуска «Добавь итоговый отчёт в консоль»
Ошибки Пропускает проблемные строки и пишет причину Падает на первом сбое «Добавь обработку пустых значений и неверных дат»
Адаптация Настройки вынесены наверх Значения спрятаны внутри кода «Собери все параметры в начале файла»

После таблицы я обычно прошу модель: «Оцени эти 5 вариантов по критериям выше и выбери 2 самых безопасных для новичка». Затем прошу объединить сильные стороны. Так появляется не «самый умный» код, а рабочая версия: понятная, короткая, с проверками.

Алгоритм на 6 шагов: от идеи до запуска

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

  1. Опишите задачу в одном предложении. Например: «Нужно взять CSV с заказами и создать отдельный файл по каждому менеджеру».
  2. Добавьте пример входных данных. Достаточно 5–10 строк, можно с вымышленными значениями.
  3. Попросите 5 подходов без полного кода. На этом этапе вы выбираете архитектуру, а не копируете строки.
  4. Отберите 2–3 подхода и попросите код с режимом проверки.
  5. Запустите на копии файла или на тестовой папке из 5 элементов.
  6. Верните ошибку модели целиком: текст ошибки, команда запуска, структура папки, ожидаемое поведение.

Для примера: если модель пишет скрипт для файла «orders.csv» на 8 колонок, дайте ей заголовки колонок и 3 строки теста. Не нужно отправлять весь рабочий файл. Достаточно структуры. Если в данных есть персональная информация, замените имена, телефоны и адреса на вымышленные значения. Метод похож на работу с обычными текстовыми задачами, где нейросеть сначала делает черновик, а человек проверяет смысл; подробнее этот принцип разобран в материале про нейросети для генерации текста и проверку результата.

Python или JavaScript: что выбрать новичку

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

Гипотетический пример: «собрать 30 JSON-файлов в одну таблицу» можно решить на Python примерно в 40–70 строк, а на JavaScript в сопоставимом объёме. Разница для новичка будет не в числе строк, а в установке среды, понятности ошибок и наличии нужных библиотек. Поэтому в промпте я прошу модель дать два варианта: «самый простой для запуска» и «самый удобный для дальнейшей доработки».

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

Как адаптировать скрипт под свой стиль

Под «своим стилем» я понимаю не красоту кода, а предсказуемость. Скрипт должен говорить человеческим языком, где лежат файлы, что он сделал, где возникла ошибка и как откатиться. Даже если вы не читаете код свободно, можно попросить модель привести его к правилам.

Мой набор правил обычно такой: все настройки в начале файла; комментарий перед каждым крупным блоком; сначала режим проверки; итоговый отчёт после запуска; ошибки пишутся в отдельный файл; исходники не меняются без явного подтверждения. Если скрипт длиннее 120–150 строк, я прошу разбить его на функции и объяснить каждую функцию одной строкой.

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

Память SoftChat можно использовать для личных предпочтений, если вы явно их сохраняете. Например, команда «Запомни, что я работаю на Windows и предпочитаю объяснения без технического жаргона» помогает получать более подходящие ответы в будущих диалогах. Управлять такими записями можно в разделе «Память»: редактировать, ставить на паузу, удалять и отключать использование памяти в конкретном чате.

Как проверять скрипт перед реальными данными

Проверка должна идти от малого к большому. Сначала 3 строки таблицы. Потом 20 строк. Затем копия полного файла. Только после этого рабочие данные. Если скрипт меняет файлы, создайте папку «test» и положите туда 5 копий. Если результат выглядит верно, увеличьте набор до 30–50 файлов. Такая лестница занимает 10 минут, зато ловит ошибки шаблона до того, как они размножатся на весь архив.

Просите модель встроить в код счётчики: сколько файлов найдено, сколько обработано, сколько пропущено, где лежит отчёт. Для таблиц полезны проверки колонок. Скрипт должен сказать: «Не найдена колонка amount», а не падать непонятной трассировкой. Для дат нужно явно указать формат, например «ДД.ММ.ГГГГ». Для чисел, десятичный разделитель: запятая или точка.

Условный пример: «отчёт по 500 строкам продаж» может дать неверную сумму, если часть чисел записана как «1 200,50», а часть как «1200.50». Нейросеть способна предложить нормализацию формата, но она не узнает ваши правила сама. Их нужно описать: валюта, разделитель, пустые значения, строки с возвратами.

Где ИИ ошибается чаще всего

Первая частая ошибка, модель придумывает названия колонок. Вы написали «таблица заказов», а она использовала «order_id», хотя у вас колонка называется «Номер заказа». Решение простое: отправляйте реальные заголовки, без чувствительных данных.

Вторая ошибка, пропущенная среда запуска. Скрипт может быть верным, но не работать из-за версии языка, пути с кириллицей, пробела в имени папки или отсутствия библиотеки. Поэтому в запросе нужна строка: «У меня Windows, файл лежит в папке C:\Reports, я запускаю через терминал».

Третья ошибка, слишком уверенное объяснение. Модель может предложить команду, которая выглядит правдоподобно, но не подходит вашей системе. Не спорьте с ошибкой на глаз. Скопируйте полный текст сбоя и попросите: «Объясни причину простыми словами, предложи 3 исправления, начни с самого безопасного».

Четвёртая ошибка, рост сложности. После трёх уточнений код может раздуться с 60 до 250 строк. Для новичка это плохо. Просите модель каждые 2–3 итерации делать «чистую версию»: убрать лишние эксперименты, оставить рабочий путь, подписать места настройки.

Мини-воронка выбора лучшего варианта

После 20–30 вариантов не пытайтесь выбрать «идеальный». Выберите тот, который легче проверить. Мой практический фильтр выглядит так:

  • отбрасываю всё, что меняет исходники без резервной копии;
  • отбрасываю решения с непонятными внешними сервисами и лишними зависимостями;
  • оставляю версии, где настройки вынесены наверх и есть отчёт;
  • прошу модель объяснить код на уровне «что делает блок 1, блок 2, блок 3»;
  • запускаю самый простой вариант на тестовых данных.

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

Что бы я сделал на вашем месте

Я бы начал с одной рутинной задачи, которую вы уже выполняли вручную хотя бы 5 раз. Не с главной системы компании, а с безопасной операции: сортировка файлов, сбор таблиц, проверка дублей, подготовка черновика отчёта. Затем описал бы входные данные, попросил 5 подходов, выбрал 2 самых безопасных и довёл один до запуска на копии.

Дальше я сохранил бы удачный промпт как шаблон и добавил в него свои правила: «не удалять», «сначала проверка», «объяснять запуск», «писать итоговый отчёт». Через несколько таких циклов вы получите личный стиль автоматизации. Он не делает вас разработчиком за вечер. Зато позволяет уверенно разговаривать с нейросетью, получать десятки вариантов и выбирать тот, который можно проверить без паники. Для самообучения хорошо работает режим тьютора: просите объяснять каждую правку и задавать вам один контрольный вопрос после изменения кода. Такой подход близок к тому, как нейросети применяют в саморазвитии и обучении: не списывать готовый ответ, а разбирать ход решения.