За последний год ко мне трижды приходили с запросом «прикрутите ChatGPT, чтобы бот отвечал клиентам». После разбора задачи выяснялось, что вопросов ровно семь, ответы фиксированные, и весь функционал закрывается условной логикой за пару часов работы. Из таких историй и складывается понимание, где не нужен ИИ в бизнесе: там, где результат должен быть предсказуемым, данные уже структурированы, а логика не меняется от диалога к диалогу, обычный код обходится дешевле и работает стабильнее нейросети. Дальше на конкретных примерах из практики: какие задачи я закрываю обычным скриптом, а какие действительно требуют модели.
Когда ИИ превращается в дорогой калькулятор
Нейросеть нужна там, где на входе неструктурированный текст, а правило нельзя описать конечным списком условий: понять намерение клиента из свободного сообщения, обобщить содержание письма, сгенерировать вариант ответа под контекст переписки. Как только задача сводится к «если сумма больше X, применить ставку Y» или «взять код региона из справочника и вернуть срок доставки», модель превращается в избыточный слой между кодом и результатом: она стоит денег за каждый вызов, отвечает с разбросом и не гарантирует одинаковый результат на одинаковых входных данных. Заказчики часто путают сложную задачу с задачей для ИИ - сложность может быть в объёме данных или количестве интеграций, а не в том, что систему нужно научить понимать смысл текста.
Три признака, что перед вами задача для обычного кода, а не для модели:
- результат укладывается в конечный список вариантов;
- входные данные уже структурированы в базе или в полях формы;
- правило не меняется чаще, чем раз в квартал.
Если все три пункта совпадают, я беру код, а разговор про модель откладываю до задачи, где она правда нужна.
| Критерий | Обычный код | Решение на ИИ |
|---|---|---|
| Предсказуемость | Один и тот же вход всегда даёт один и тот же выход | Ответ может отличаться от запроса к запросу |
| Стоимость эксплуатации | Только хостинг, дальше логика бесплатна | Оплата за каждый вызов модели |
| Скорость ответа | Миллисекунды | От одной до нескольких секунд на обращение к модели |
| Что менять при правках | Конкретную строку кода | Промпт, но гарантировать новое поведение сложно |
Условный пример: бот обрабатывает 10 000 обращений в месяц. Если на каждое обращение уходит отдельный вызов модели, в месяц набегает заметная сумма, которая растёт линейно с числом обращений и никак не связана со сложностью логики. Тот же объём, обработанный деревом условий на сервере, стоит владельцу бизнеса только аренду хостинга, которая не меняется от того, пришло 100 обращений или 10 000.
На практике я делю задачи так: если её можно описать таблицей соответствий или формулой, пишу код. Если задачу нельзя формализовать без потери смысла, беру Claude API или другую модель. Проверяю это одним вопросом: смогу ли я на бумаге нарисовать блок-схему с конечным числом веток для всех входных данных. Если да, модель не нужна, даже если задача звучит внушительно на словах заказчика.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Расчёты, налоги и валюты: работа для скрипта, а не для модели
Расчёт НДС, конвертация валют, ограничение количества использований промокода: я собрал эти вещи как готовые виджеты для Tilda, потому что логика в них не меняется от запроса к запросу. Ставка НДС фиксирована в конфиге, курс валюты обновляется по расписанию через API ЦБ, лимит промокода это счётчик в базе данных, который увеличивается на единицу при каждом успешном заказе и блокирует форму после достижения потолка. Прогонять такие вычисления через языковую модель есть смысл, только если цель - потратить бюджет клиента, а не решить задачу.
function calcVat(price, rate = 22) {
const vat = price - price / (1 + rate / 100);
return Math.round(vat * 100) / 100;
}
Семь строк кода дают точный и повторяемый результат за доли миллисекунды, без сетевого запроса к внешнему сервису и без риска, что модель однажды округлит цифру не в ту сторону. У меня в библиотеке готовых виджетов для Tilda лежат именно калькулятор НДС, конвертер валют и ограничитель промокодов - все три собраны под такую логику и работают одинаково хоть на первом заказе, хоть на десятитысячном.
Формы и проверка данных - тоже без модели
Похожая история с формами на сайте: проверка формата телефона, маска для карты, обязательность поля email, ограничение на количество символов в комментарии к заказу. Это регулярные выражения и стандартные проверки на стороне браузера и сервера, а не задача для модели. Даже условная умная проверка адреса доставки на опечатки чаще решается сверкой с базой ФИАС или подсказками через DaData, чем обращением к языковой модели ради разбора одной строки.
Регулярные отчёты и документы: шаблон вместо генерации текста заново
Еженедельный отчёт о продажах собирается из данных CRM или базы заказов и раскладывается по одному и тому же шаблону: суммы, количество заказов, средний чек по категориям. Счёт или акт для бухгалтерии генерируется из docx или pdf шаблона, куда скрипт подставляет реквизиты и суммы, и результат обязан выглядеть одинаково у всех клиентов, без вольного пересказа модели. Рассылка по сегменту, например, письмо всем, кто не открывал заказ больше 30 дней, собирается фильтром по базе и той же html-версткой письма, которая менялась в последний раз полгода назад. Единственное место, где в такой цепочке действительно пригождается модель, это подбор темы письма под конкретный сегмент или черновик текста для нового шаблона, а дальше рассылка снова уходит в обычную автоматизацию по расписанию.
Интеграции с CRM, эквайрингом и доставкой
Подключение эквайринга Т‑Банка к WooCommerce - это официальный модуль и обработка вебхуков об оплате, без единой строки генерируемого текста, только приём уведомления и смена статуса заказа с «ожидает оплаты» на «оплачен». Расчёт зон доставки СДЭК на Tilda работает так же: на входе индекс или город, на выходе конкретный тариф и срок из ответа API СДЭК, без вариантов интерпретации. Точечную доработку такого скрипта на Tilda я оцениваю от 3 000 ₽, а сложную связку из эквайринга, CRM и доставки в одном заказе - от 40 000 ₽, потому что результат здесь это точный расчёт и передача статуса между системами, а не текст, который нужно стилистически подгонять под ситуацию. Модель в такой цепочке не добавляет ценности, зато добавляет точку отказа: лишний сетевой запрос, который может зависнуть или вернуть неожиданный формат ответа.
Парсинг и мониторинг цен: Python дешевле токенов модели
Сбор открытых данных с сайтов конкурентов сводится к разбору HTML-структуры и извлечению чисел, а с этим Python справляется быстрее и предсказуемее модели. Отправлять каждую страницу в LLM ради задачи «найди цену в этом куске текста» дорого и медленно: разбор через BeautifulSoup или lxml занимает миллисекунды и стоит только время сервера, а не токены за каждую из тысяч карточек товара. Устойчивость скрипта к банам держится на ротации IP, соблюдении rate-limit и правил robots.txt, а не на хитростях против конкретной системы защиты сайта. Собранные цены складываю в базу с историей изменений и настраиваю уведомление в Telegram, когда конкурент меняет цену больше чем на заданный процент - это тоже обычная логика сравнения чисел, без обращения к модели. Такие проекты по парсингу и автоматизации на Python у меня стартуют от 20 000 ₽.
Чат-боты с фиксированным сценарием против ИИ-ботов
Бот на aiogram, который присылает статус заказа по номеру, показывает график работы или собирает заявку по шагам, не нуждается в языковой модели: сценарий известен заранее и укладывается в дерево состояний с конечным набором кнопок. Модель стоит подключать, когда клиент пишет свободным текстом и вопрос не укладывается в заготовленный список ответов - тогда я собираю бота с базой знаний компании поверх Claude API. Обычный телеграм-бот на фиксированной логике обходится от 30 000 ₽, а чат-бот с базой знаний и пониманием свободного текста от 50 000 ₽: разница в цене отражает разницу в сложности и непредсказуемости задачи.
Видел обратную ситуацию у клиента: бот поддержки на модели отвечал на простые вопросы про график работы медленнее и с разной формулировкой каждый раз, при этом счёт за токены рос с каждым обращением. После замены этой части на обычное меню с кнопками время ответа упало до долей секунды, а расходы на модель сократились до вопросов, которые правда требуют понимания контекста.
Где граница между «ещё скрипт» и «уже нужна модель»
Ориентир простой: если все возможные вопросы клиента можно перечислить списком и на каждый есть один правильный ответ, это дерево состояний в коде бота. Если вопросы формулируются каждый раз по-новому и ответ зависит от контекста конкретного диалога, тут без модели, понимающей смысл текста, не обойтись.
Автоматизация процессов в n8n без ИИ-агента внутри
Перенос заявки из формы на Tilda в CRM, уведомление менеджера в Telegram при новом заказе, синхронизация остатков между складом и сайтом - три сценария, которые я закрываю цепочкой нод в n8n без единого узла с языковой моделью. Логика внутри узла HTTP Request или Function должна выполняться одинаково и в 9 утра, и в 3 ночи, без вариативности ответа и без риска, что модель интерпретирует число по-своему. ИИ-узел в такой цепочке оправдан только там, где на вход приходит реально неструктурированный текст: например, нужно определить тему обращения из свободного письма клиента и направить его нужному менеджеру. Для всего остального - разбора JSON, сверки полей, отправки уведомлений - хватает стандартных нод. Автоматизация в n8n стартует от 25 000 ₽ и окупается на первой сотне обработанных заявок, потому что раньше эти же действия делал человек руками.
У одного клиента с интернет-магазином на связке Tilda и amoCRM раньше стоял ИИ-агент, который должен был сам решать, в какую воронку отправить заявку: розница, опт или партнёрская программа. На практике признаки этих трёх сценариев легко считывались по паре полей в форме - объёму заказа и отметке «работаю как ИП» - и агент в половине случаев путал розницу с мелким оптом, потому что делал вывод из свободного комментария клиента, а не из чисел. После замены агента на простое ветвление по значению поля ошибки в распределении заявок пропали, а время обработки одной заявки сократилось с нескольких секунд ожидания ответа модели до мгновенной сортировки.
Частые вопросы
Как понять, что задачу можно закрыть без ИИ?
Если результат можно описать таблицей условий или формулой и на одинаковый вход всегда должен приходить одинаковый ответ, задача решается кодом. Если на входе живой текст без фиксированной структуры и правило нельзя перечислить конечным списком условий, тогда есть смысл смотреть в сторону модели.
Не переплачиваю ли я, если ставлю ИИ-бота вместо простого скрипта?
Переплата возникает не на разработке, а на эксплуатации: каждый ответ модели стоит денег, а логика на условиях после разработки почти бесплатна в работе. Бот с меню из пяти кнопок и статичными ответами обходится в эксплуатации в ноль рублей сверх хостинга, а тот же функционал на модели тянет счёт за токены каждый месяц, даже если содержание ответов не менялось. Если 80% вопросов клиентов повторяются, дешевле сначала закрыть их скриптом, а модель подключить только для оставшихся нетиповых обращений.
Можно ли совмещать обычный код и ИИ в одном проекте?
Да, и чаще всего так и получается: расчёт стоимости доставки, налогов или статуса заказа остаётся на обычной логике, а модель подключается там, где нужно понять свободный текст от клиента или сформулировать вариант ответа. Такой гибридный подход обычно выходит дешевле, чем прогонять весь диалог через модель.
Где хранить данные клиентов при автоматизации через CRM?
На серверах в России, а не в иностранных облачных таблицах вроде Google Sheets: это требование 152-ФЗ о локализации персональных данных, и я закладываю это в архитектуру интеграции с самого начала.