Задача знакомая: каждый день в девять утра получать отчёт о продажах интернет-магазина. Сколько платежей прошло вчера, на какую сумму, сколько денег вернули покупателям.
Раньше для этого нужен был разработчик: изучить API платёжной системы, написать программу, настроить сервер и рассылку. Сегодня задачу можно описать нейросети и получить готовый сценарий для n8n. Остаётся подключить сервисы и нажать «запустить».
Письмо приходит. В нём количество платежей, сумма, возвраты. Все узлы отработали без ошибок. Задачу можно закрывать.
Но что, если за день было 150 платежей, а программа получила только первые 100? Если часть заказа вернули, а автоматизация этого не учла? Если магазин считает день по Москве, а отчёт строится по UTC?
Отчёты будут приходить вовремя. Ошибку никто не заметит, пока цифры не разойдутся с бухгалтерией.
Пример с Reddit
26 октября 2026 года на Reddit появился разбор типичных ошибок, которые допускают нейросети при создании сценариев n8n. Автор заметил повторяющиеся проблемы: выдуманные компоненты, параметры от старых версий, неправильно соединённые узлы, вымышленные идентификаторы таблиц и вебхуков, а иногда один лишний символ, из-за которого вместо значения переменной передаётся просто текст.
Для этого он сделал валидатор, который проверяет сценарий до запуска. В качестве примера опубликовал автоматизацию ежедневной финансовой отчётности, которая, по его словам, проверку проходит.
Сценарий простой: по расписанию обращается к Stripe, забирает платежи за предыдущий день, считает итоги и отправляет письмо.
Важная оговорка: автор решал задачу технической корректности и не обещал проверять бизнес-логику. Это не упрёк инструменту. Но опубликованный JSON оказывается удобным учебным примером: структура в нём верна, а ошибки сидят в самих правилах расчёта.
1. Сто платежей вместо ста пятидесяти
Запрос к Stripe ограничен сотней платежей. Если операций за день больше, остальные в расчёт не попадут.
За день пришло 150 платежей по 1000 ₽, то есть 150 000 ₽. Автоматизация получила первые 100 и посчитала 100 000 ₽. Разница 50 000 ₽.
В сценарии есть предупреждение о возможной неполноте данных, и это лучше, чем ничего. Но сам отчёт всё равно содержит суммы, которые легко принять за итоговые.
Правильно: запрашивать страницы, пока API не сообщит, что данные закончились (в Stripe для этого служат поля has_more и starting_after). Если полный набор получить не удалось, отчёт должен быть явно помечен как неполный, а не выдавать частичный результат за окончательный.
Это не специфика ИИ, такую ошибку мог допустить любой разработчик. Но когда сценарий создаётся за минуты, такие детали пропускаются особенно легко.
2. Деньги не всегда нужно делить на сто
Платёжные API передают суммы в минимальных единицах валюты: 1500 центов означают 15 долларов. Поэтому в коде естественно появляется деление на 100.
Но у японской иены нет дробной части, и Stripe передаёт её суммы как есть. Деление иен на 100 даёт неверный результат. В разборе используется универсальное деление без учёта валюты.
Пока магазин работает только с валютами с двумя знаками, ошибка не видна. Как только подключается новая валюта, показатели искажаются без единого сообщения об ошибке. Код корректен, API отдаёт реальные данные, исключений нет. Неверно само допущение, зашитое в расчёт.
3. Возвраты сложнее, чем кажется
Покупатель оплатил заказ на 10 000 ₽, а потом вернул товар на 3000 ₽. Компании могут понадобиться разные цифры: первоначальная сумма платежей, сумма возвратов, чистая сумма после возвратов.
В сценарии полностью возвращённые платежи исключаются, а частичные возвраты учитываются неверно. Отчёт показывает сумму, которая не сходится с суммой после возвратов.
Есть и менее очевидный вопрос: возврат сделан сегодня по платежу, который прошёл вчера. В какой отчётный период он попадает? В день платежа или в день возврата? От ответа зависит, совпадёт ли отчёт с бухгалтерией.
А сам термин «продажи» может означать оплаченные заказы, успешные платежи, выручку за вычетом возвратов или фактические поступления на счёт. Это разные показатели. Нейросеть не угадает, какой нужен вашему бизнесу, и человек-исполнитель тоже: ему придётся додумывать. Подробное ТЗ нужно не чтобы объяснить, как писать код, а чтобы определить, какой результат считается правильным.
4. Даже «вчера» нужно определить
Границы отчётного периода в примере заданы по UTC. У московской компании операционный день сдвинут на три часа.
Платёж в 01:00 по Москве относится к новому дню для магазина, но к предыдущему по UTC. Если сверять отчёт с учётной системой в московском времени, цифры будут расходиться нерегулярно: в дни без ночных продаж всё совпадёт, в другие появятся необъяснимые отличия.
UTC сам по себе не ошибка. Ошибка в том, что правило формирования периода не соответствует требованиям бизнеса. И решить это нужно до написания программы.
Проверка кода и проверка результата — разные задачи
Валидатор видит, существуют ли компоненты, правильно ли они соединены и заполнены ли обязательные параметры. Это полезно: такие ошибки иначе всплыли бы только при запуске.
Но он не знает, что магазин может принимать иены, что бухгалтерия учитывает частичные возвраты, что день надо считать по Москве и что в отчёт должны попасть все операции, а не первая сотня.
Здесь возникает неудобный эффект. ИИ ускорил написание программ, но не избавил заказчика от необходимости понимать свои процессы. Руководитель может получить работающую автоматизацию раньше, чем сформулирует условия, и не заметить, сколько решений было принято за него.
Почему второй ИИ не гарантирует правильность
Можно попросить другую модель проверить результат, и это действительно помогает: она найдёт пропущенную пагинацию или сомнительные вычисления, особенно если дать ей документацию API и требования.
Но если обе модели исходят из того, что «продажи за вчера» это успешные платежи по UTC, вторая подтвердит правильность первой, и обе ошибутся относительно реальных требований. Модель проверяет соответствие правилам. Если правил нет, она их предполагает.
Как принимать автоматизации, созданные ИИ
Я делю приёмку на три уровня.
Уровень 1. Техническая работоспособность. Программа запускается, подключается к сервисам, получает данные, обрабатывает ошибки. Здесь помогают валидаторы, тесты и независимая проверка кода.
Уровень 2. Бизнес-логика. Готовится набор контрольных ситуаций с заранее известными результатами, и результаты автоматизации сравниваются с эталоном. Для финансового отчёта он может выглядеть так:
- 150 платежей по 1000 ₽ за день — учтены все 150, сумма 150 000 ₽.
- Платёж 10 000 ₽, частичный возврат 3000 ₽ — нетто 7000 ₽ по согласованной формуле.
- Платёж в иенах — сумма без деления на 100.
- Платёж в 00:30 по Москве — попадает в новый день, а не в предыдущий.
- Возврат сегодня по вчерашнему платежу — относится к периоду, как закреплено в правилах компании.
- Stripe вернул больше одной страницы — загружены все страницы, иначе отчёт помечен неполным.
Уровень 3. Надёжность эксплуатации. Что будет, если Stripe недоступен, истекла авторизация, запрос упал или письмо не отправилось? Система должна заметить сбой, сохранить информацию о нём и позволять безопасный повторный запуск.
Для финансовых процессов разумно какое-то время запускать новую автоматизацию параллельно с прежним способом подготовки отчёта и сверять результаты на реальных данных. Глубина проверки зависит от риска: сортировка внутренних уведомлений и расчёт выручки требуют разного контроля. Принцип один: успешный запуск не доказывает правильность.
Где теперь главная ценность
Стоимость написания кода резко упала. Сложность бизнес-процессов никуда не делась: у заказчика остаются особые правила расчёта, исключения и ограничения. Чем быстрее появляется программа, тем легче принять её внешнюю работоспособность за готовность.
Поэтому ценность смещается от механического написания кода к умению разобраться в задаче, выявить неочевидные требования, определить критичные сценарии и организовать независимую проверку.
Если вы рассматриваете автоматизацию с ИИ, начинайте не с выбора модели. Сначала опишите процесс, ожидаемый результат и ситуации, где стандартный сценарий может сломаться. Затем выберите ограниченный участок, автоматизируйте его и проведите пилот на контрольных данных. Измеряйте не только сэкономленное время, но и число ошибок, стоимость их исправления и способность системы самой замечать проблемы.
Если у вас уже есть автоматизация на n8n или похожем инструменте, пришлите её: я разберу один сценарий и подготовлю для него набор контрольных примеров по описанной выше схеме. Я занимаюсь этим в Бюро цифровых решений: помогаю понять, какие процессы стоит автоматизировать, где нужен ИИ, а где надёжнее обычный алгоритм.
Написать программу стало проще. Доказать, что она правильно решает задачу бизнеса, по-прежнему отдельная работа.
