Собираем функцию CRM через GPT
Берём одно бизнес-правило и доводим его до работающего сценария в системе. Фиксируем, что модель сделала сама, где ошиблась и сколько времени осталось за человеком.
Зачем это бизнесу
Доработка CRM обычно упирается не в сложность кода, а в его объём: правило формулируется за пять минут, а реализация занимает дни. Если механическую часть берёт на себя модель, стоимость небольших изменений падает — и компания перестаёт откладывать полезные мелочи «до следующего этапа».
Эксперимент отвечает на практический вопрос: какую долю такой доработки реально снять с разработчика и что при этом остаётся обязательной ручной работой.
Правило, которое автоматизируем
Взяли типичное требование отдела продаж: если сделка находится в стадии «согласование» дольше пяти рабочих дней и по ней не было ни одного сообщения, ответственный получает напоминание, а руководитель видит сделку в отдельном списке.
Правило простое на словах и содержит всё, на чём обычно спотыкается генерация: рабочие дни вместо календарных, зависимость от истории сообщений, два разных получателя уведомления.
Ход эксперимента
Что модель делает хорошо
Структура получается сразу рабочей: фоновое задание по расписанию, выборка сделок, формирование уведомления. Каркас, на который у человека уходит час рутины, появляется за минуту и почти без правок.
Отдельно хорошо даются повторяющиеся куски — обработка ошибок, логирование, тесты для очевидных случаев.
Где ошибается
- Рабочие дни. Первая версия почти гарантированно считает календарные. Выходные и праздники приходится проговаривать явно.
- Границы условия. «Дольше пяти дней» — это строго больше или больше либо равно? Модель выбирает вариант сама и не сообщает об этом.
- Повторные уведомления. Без отдельного указания напоминание уходит при каждом запуске задания, а не один раз.
- Реальная схема данных. Названия полей додумываются, если их не показать целиком.
Что остаётся человеку
Постановка задачи, проверка на граничных случаях и решение о том, что делать при неоднозначности правила. Это как раз та часть, где ошибка стоит дороже всего: неверно посчитанный срок в напоминании — это не сломанный интерфейс, а потерянная сделка.
Практический вывод: механическую часть доработки можно отдать модели, но проверка граничных случаев обязательна и её нельзя сократить. Экономия появляется на объёме мелких задач, а не на одной большой.