В чём фокус
«Ошибок не найдено» и «не умею находить ошибки» снаружи выглядят одинаково: зелёная галочка в обоих случаях. Развести их можно одним способом — подсунуть заведомо плохое и посмотреть, откажет ли автоматика. С резервной копией то же самое: файл есть, а копии может не быть. Ниже два приёма, каждый на пять минут, оба без разработчика.
Почему зелёное ничего не значит
Зелёный статус говорит одно: всё запустилось и не упало. Что результат верный, он не говорит. Как это выглядит в нодах n8n, разобрано в гайде «Пять мест, где сценарий n8n падает молча». Здесь про то же самое, только шире: про любую проверку, которая докладывает «всё хорошо».
Разработчик Heinrich Neb пересчитал проверки в своих репозиториях: из 204 проверок, которые выносят суждение, только у 22 есть проверка заведомо плохим вводом. Остальные 89 % ни разу не показали, что умеют сказать «нет». Цифру он сам называет приблизительной: считал по меткам в названиях тестов. За одну неделю у него случились три сбоя:
- шаг выкладки, который должен был ловить отсутствующий инструмент, сам вызывал этот инструмент: шесть выкладок подряд упали, шесть часов ничего не выходило;
- сборщик записал семь верных строк, на безобидном предупреждении вернул код ошибки, и система записала сделанную работу в провалы;
- проверка искала в ответе «500» как признак сбоя сервера и нашла его внутри строки «4258 из 5000 очков квоты осталось».
Его правило: судить по результату, а не по тому, кто о нём докладывает. Код возврата, сводка и галочка только докладывают. Результат — это сам файл, строка, ответ.
У меня было то же самое, только мельче.
Три проверки, которые не могли покраснеть. 24.08.2026 ревью нашло в моём рабочем скрипте три проверки, которые выдавали «всё хорошо» при любом исходе: зелёное было просто вписано в них заранее. Такая проверка хуже отсутствующей. Отсутствующую хотя бы видно.
Сторож, который нашёл сам себя. 27–28.08.2026 проверка следила, чтобы в коде была нужная строка. Строку удалили, проверка осталась зелёной: эта же строка была написана в тексте самой проверки, и нашла она её там.
Закрыто для чужих, закрыто и для своих. 21.09.2026 в одном из моих ботов три проверки «чужие данные не отдаются» были зелёные. А экран профиля не открывался вообще, ни у кого. Функция, которая отказывает всем подряд, такую проверку проходит идеально.
Первый случай поймало ревью, второй нашёлся, только когда то, что проверка стережёт, сломали нарочно. Ни один из трёх не был виден по зелёному цвету.
Что понадобится
- Ваш бот или сценарий в тестовом режиме, чтобы плохой ввод не ушёл живому клиенту
- Три плохих ввода: пустой файл, номер заказа, которого нет, дата 32 августа
- Выгрузка резервной копии и пустая таблица рядом
- Десять минут на оба приёма
Приём первый: подсуньте заведомо плохое
У приёма есть название: отрицательный контроль. Проверке скармливают заведомо плохое и убеждаются, что она это отклонила, причём по правильной причине.
Пустой файл
Отправьте боту документ, в котором ничего нет. Правильный ответ: «не могу, файл пуст». «Готово» означает, что он и не заглядывал внутрь.
Чужой номер заказа
Спросите про заказ, которого нет или который принадлежит другому клиенту. Правильный ответ: «такого заказа не нахожу». Если бот рассказывает про статус, он его придумал или отдаёт чужое.
Дата 32 августа
Впишите её в заявку или форму. Правильный ответ: «такой даты нет». Если запись прошла, проверки даты нет вовсе, и следующая опечатка тоже пройдёт.
| Что подсунули | Правильный ответ | Если ответил «готово» |
|---|---|---|
| Пустой файл | «Не могу: файл пуст» | Бот не читает, что ему прислали |
| Чужой номер заказа | «Такого заказа не нахожу» | Бот не сверяет номер с базой |
| Дата 32 августа | «Такой даты нет» | Проверки даты нет, пройдёт любая опечатка |
Три попытки, три отказа — автоматизация работает. Ни одного отказа — она молчит, а молчание принимают за порядок.
В n8n плохой ввод можно подать, не дожидаясь живого клиента: закрепить данные на первой ноде и поправить их руками. По документации n8n закреплённые данные работают только в тестовых запусках, на рабочие прогоны они не влияют.
Приём второй: три числа и лишняя строка
База клиентов лежит в таблице, боте или CRM, копия «делается сама». Но файл копии и копия, из которой можно восстановиться, — разные вещи. Проверка без единой команды:
Запишите три числа по живой базе
До выгрузки: сколько строк, сумма по главной колонке, дата последней записи. С ними вы будете сверяться в конце.
Выгрузите копию
Исходную базу при этом не трогайте: сверять будете с ней.
Залейте копию в пустую таблицу рядом
И посчитайте те же три числа. Не сошлись — у вас не копия, у вас файл: данные приехали не все.
Добавьте строку с клиентом, которого не существует
Данные могут приехать, а правила нет: формулы, связи между листами, права доступа. Если копия пустила такую строку молча, защита осталась в старой базе.
Пять минут.
Когда проверяет не человек
Если вы сами перепроверяете всё, что сделал за вас ИИ, он сэкономил вам ноль времени. Бот написал, вы сели и вычитали: формально автоматизация есть, по факту одну работу поменяли на другую.
У меня проверку делает не человек. Отдельный агент со списком критериев смотрит заготовку и возвращает список претензий — до того, как я потратил деньги на генерацию. Таких агентов у меня четыре: один смотрит раскадровку до съёмки, второй слушает звук готового куска, третий проверяет финальные кадры, четвёртый — схему ролика без лица. Каждый знает ровно свой список и ничего больше. Мне остаётся решение, а не вычитка.
Список критериев и есть критерий готовности, только записанный для проверяльщика. Как его составить, разобрано в гайде «Вода в ответах нейросети: критерий приёмки». Начать можно проще: возьмите то, что перепроверяете за ботом чаще всего, и выпишите пять пунктов. Это и есть техзадание второму боту.
Чек-лист, который можно унести
ПРИЁМ 1. ЗАВЕДОМО ПЛОХОЕ
(в тестовом режиме)
Пустой файл
ответил: ______________
отказал [ ] «готово» [ ]
Чужой номер заказа
ответил: ______________
отказал [ ] «готово» [ ]
Дата 32 августа
ответил: ______________
отказал [ ] «готово» [ ]
Нормальный ввод проходит:
да [ ] нет [ ]
ПРИЁМ 2. РЕЗЕРВНАЯ КОПИЯ
база копия
Строк ______ ______
Сумма колонки ______ ______
Последняя запись ______ ______
Строка с несуществующим клиентом:
отказала [ ] пустила [ ]
ЧТО ПЕРЕПРОВЕРЯЮ ЗА БОТОМ ЧАЩЕ ВСЕГО
1. __________
2. __________
3. __________
4. __________
5. __________Чтобы не споткнуться
Функция, которая отказывает всем подряд, проходит проверку «плохое не пускаем» идеально. Рядом с каждой такой проверкой нужна парная: нормальный ввод проходит. Обе в одном прогоне.
Упасть должна именно та проверка, ради которой ломали. Если рядом покраснело ещё три по посторонней причине, вы проверили не то.
С этой настройкой прогон остаётся зелёным при пустом результате. Как это выглядит в n8n, разобрано в гайде про молчаливые падения.
Сценарий и копия меняются. Плохой ввод стоит подсовывать после каждого обновления сценария, три числа сверять после каждого изменения базы или копии.
Частые вопросы
- А если бот на пустой файл ответил «готово», но ничего не сломалось?
- Значит, он не проверял и раньше. «Ничего не сломалось» — это пока: первый пустой файл от настоящего клиента пройдёт так же молча.
- Копия в облаке делается сама, зачем её проверять?
- Сама она делает файл. Развернётся ли из него база, с теми же строками и правилами, знает только проверка. Три числа показывают разницу за пять минут, пока копия не понадобилась.
- Это только про ботов на ИИ?
- Нет, про любую автоматику: сценарий, робот сверки, скрипт. Всё, что докладывает «готово», стоит один раз попросить сказать «нет».
Источники
- Dev.to — Heinrich Neb, «AI promoted every developer to reviewer. Nobody tested the reviewer.»Опубликована 24.08.2026, сверено 14.10.2026: 204 проверки, у 22 есть отрицательный контроль, три сбоя за неделю
- docs.n8n.io — закреплённые данные (Data pinning)Закреплённые данные можно править, на рабочих прогонах они не используются. Сверено 14.10.2026