Игорь Градов
Игорь Градов
7 мин
ai

5 ловушек «тихого отказа» в автоматизации: звук р в логах есть, а работа не сделана

Три утра подряд крон (автоматический планировщик задач, «будильник для программ») отчитывался кодом 0, то есть «всё хорошо», а реальная работа не выполнялась, и разбор этого сбоя обнажил пять типовых ловушек, в которые попадает любая автоматизация с ИИ-агентами.

Почему это важно

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

Автор материала, практик, который строит личную автоматизацию на ИИ-агентах Claude Code и Codex, столкнулся с «тихим отказом»: скрипт по расписанию выдавал бодрый лог с цифрами, счётчиками и временем выполнения, но главную задачу не делал. Причина оказалась системной. Доложить об успехе для кода дешевле, чем проверить, был ли успех. На этой разнице и живёт тихий отказ: проверка отвечает одинаково, когда всё исправно и когда сломано. Разобранных форм набралось пять, и к каждой прилагается контрольный вопрос, который годится не только для лога крона, но и для статуса подрядчика в трекере.

Что понадобится

  • Терминал с доступом к cron (или любому планировщику задач)
  • Текстовый редактор для правки скриптов (nano, VS Code, любой привычный)
  • ИИ-агент, если вы генерируете скрипты через Claude Code, Codex или аналоги (YandexGPT, GigaChat для русскоязычных задач)
  • 15 минут на ревизию каждого автоматического скрипта
  • Лог-файл, куда пишет ваш крон, и доступ к нему на чтение

Пять ловушек и пять контрольных вопросов

1. Успех по умолчанию: что окажется в отчёте, если работа не сделана?

Бытовая аналогия: ребёнок на вопрос «уроки сделал?» отвечает «да» раньше, чем вопрос дозвучал. Ответ бодрый и одинаковый при любом состоянии уроков.

В утреннем скрипте автора схема была стандартной: сделать главное, собрать статистику, отчитаться. Главный шаг падал из-за протухшего токена (токен тут означает цифровой пропуск, по которому программа ходит во внешний сервис). Потом команда claude не находилась в PATH крона, потому что у крона свой, урезанный список каталогов, где он ищет программы. А статистика при этом собиралась и печатала настоящие цифры.

Настоящие цифры здесь самое обидное. Лог сломанного прогона выглядел живее исправного. Чем подробнее отчёт, тем убедительнее ложный успех.

Причина: переменная $? в оболочке хранит код возврата (число, которым программа сообщает, как всё прошло; ноль читается как «всё хорошо») последней выполненной команды. К моменту итогового отчёта последней была статистика, она отработала, и её ноль достался всему заданию. Главный шаг упал выше, и об этом никто не спросил.

Как починить:

главная_команда
RC=$?
if [ $RC -ne 0 ]; then
  echo "Главный шаг не выполнен: код $RC" >> "$LOG"
fi
# статистика, отчёт
exit $RC

Сохранённый код позволяет явно выбрать итоговый статус. Признак при чтении чужого скрипта: между главной командой и итоговым $? стоит хотя бы одна другая команда. Если стоит, код возврата уже потерян.

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

2. Проверка упрощённым входом: на каких данных это проверяли?

Аналогия: примерка обуви сидя. Сидя ботинки сидят. Жмут они на прогулке, а прогулка в проверку не входила.

Автор проверял удалённый вызов по ssh однословным запросом, получил правильный ответ. Любой запрос из нескольких слов падал: ssh склеивает аргументы в одну строку, а оболочка на той стороне режет её заново по пробелам. Однословному запросу распадаться нечему. Из пробы было убрано ровно то свойство, которое ломало рабочий сценарий.

Второй случай нагляднее. Скрипт перед отправкой сверял адресата: входит ли имя чата в заголовок открытого окна. Отрапортовал успех со строкой чат ''. Нужный чат открыт не был. Пустая строка входит в любую строку:

print("" in "Любое другое окно")  # True

Пустое искомое надо считать отдельным отказом ещё до проверки на вхождение.

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

3. Проверка не того слоя: что на самом деле измеряет этот признак?

Аналогия: проверять, дома ли подросток, по свету в его окне. Свет горит. Обычно совпадает, поэтому такой замер живёт годами.

MCP (Model Context Protocol, способ дать ИИ-агенту внешние инструменты: сервер предлагает набор функций вроде «прочитать почту» или «создать черновик письма»). Агент не нашёл у себя функцию создания черновиков Gmail и объявил, что такой возможности нет. Накануне он сам ею пользовался. В истории сессии висели уведомления о переподключении сервера: связь моргнула, инструменты потерялись. При этом сам сервер был запущен, и стандартная проверка «сервер работает?» возвращала «да».

Автоматизация звука р здесь в том, что рапорт о работоспособности сервера отвечал на вопрос «процесс запущен?», а не на вопрос «инструменты доступны агенту?». Это разные слои, и проверка одного ничего не говорит о другом.

Что делать с этим прямо сейчас, по ролям

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

Маркетологу. Автоматические отчёты о рассылках и постинге страдают тем же: «отправлено 1000 писем» не равно «1000 писем дошли с актуальным содержимым». Добавляйте в отчёт хотя бы хэш (контрольную сумму) тела письма и сверяйте с эталоном.

Предпринимателю в РФ и СНГ. Claude Code и Codex пока доступны в РФ с ограничениями. Из доступных аналогов для генерации скриптов подходят YandexGPT и GigaChat, но описанные ловушки от модели не зависят: код возврата перезаписывается в bash одинаково, какой бы ИИ-агент (программа, которая действует автономно, выполняя задачи без пошагового контроля человека) скрипт ни написал. Все пять контрольных вопросов применимы к любому стеку.

Что ввели и что получили

Автор обнаружил, что крон три дня подряд рапортовал «завершено, код 0». В логе были настоящие цифры статистики. После добавления строки RC=$? сразу после главной команды и замены финального exit 0 на exit $RC крон начал возвращать ненулевой код при сбое. Ошибка стала видна в первом же прогоне: протухший токен доступа, который раньше молча терялся между статистикой и отчётом. Второй фикс: добавление проверки if [ -z "$SEARCH_TERM" ]; then echo "Пустой запрос" && exit 1; fi перед сверкой имени чата устранило ложное срабатывание с пустой строкой.

Частые ошибки
  • Доверять подробному логу. Чем больше цифр и счётчиков в отчёте, тем убедительнее выглядит ложный успех. Длинный лог не равен правильному логу.
  • Проверять однословным вводом. Если рабочие данные содержат пробелы, кавычки, кириллицу, юникод, а тест прогнали на слове test, вы убрали из пробы именно то свойство, которое ломает рабочий сценарий.
  • Считать «сервер запущен» равным «сервер работает правильно». Процесс висит в памяти, но инструменты после переподключения потерялись. Проверяйте тот слой, который вас интересует, а не соседний.
  • Не проверять пустые значения. Пустая строка входит в любую строку. Перед любым сравнением убедитесь, что искомое не пустое.
  • Полагаться на exit 0 в конце скрипта вместо exit $RC. Явный ноль в конце скрипта маскирует любой сбой, случившийся выше.
Мнение редакции dzen.guru

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

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

Проверьте свои автоматизации

Если вы строите контент-процессы с ИИ и хотите, чтобы скрипты не врали о результатах, начните с аудита по пяти вопросам из этого гайда

Попробовать инструменты dzen.guru
Поделиться:TelegramVK
Игорь Градов
Игорь Градов

Основатель dzen.guru. Эксперт по монетизации и продвижению на Дзен. Автор курса «Старт на Дзен 2026».

Комментарии

Читайте также

ai

Liquid AI выпустила d1: нейросеть для решения задач по теории вероятности без единого токена на выходе

Почему это важно Впервые появилась модель, которая не генерирует текст, а возвращает откалиброванные вероятности по заданным вариантам ответа, и делает это без…

6 мин
ai

RSA запускает платформу для контроля AI-агентов: безопасность требует учёта 150 000 ботов на компанию

Salesforce компании парализовал один неудачный промпт (промпт, текстовая инструкция для ИИ): сотрудник попросил ИИ-агента (программу, которая сама выполняет…

7 мин
Один автор обошёл 2 500 заявок XPRIZE AI и получил $2,5 млн на фильм
ai

Один автор обошёл 2 500 заявок XPRIZE AI и получил $2,5 млн на фильм

Компания Google совместно с XPRIZE AI и Range Media Partners объявила победителя конкурса Future Vision XPRIZE: короткометражный трейлер «The Gifted»…

4 мин