Начните с одного события: например, сообщения о том, что заказ готов к выдаче. Чтобы подключить SMS к сайту или приложению с помощью ИИ, опишите условие отправки, поручите модели подготовить серверную интеграцию и проверьте её без реальной рассылки. Затем проведите контрольный тест на своём номере. Такой порядок подходит малому бизнесу в Беларуси, который собирает сайт через вайбкодинг или дорабатывает собственный сервис. Ниже — как составить задание для ИИ, защитить доступ к SMS-сервису и проверить, что приложение не отправляет сообщения повторно.
С какого SMS-сценария начать разработку?
Выберите событие, которое приложение уже умеет определять. Если в заказе есть статус «Готов к выдаче», к его изменению проще привязать уведомление, чем поручать ИИ самостоятельно решать, когда пора писать покупателю. У события должна быть понятная граница: сотрудник сменил статус, система проверила условия, затем отправила сообщение.
Для первого запуска зафиксируйте сценарий коротким списком. Его сможет проверить и предприниматель, и разработчик:
- Событие: заказ впервые перешёл в статус «Готов к выдаче».
- Условие: для этого события система ещё не отправляла SMS.
- Текст: заранее согласованный шаблон с номером заказа.
- Результат: сотрудник видит, принял ли сервис запрос.
Здесь легко пропустить деталь: повторное сохранение заказа не должно запускать ещё одно SMS. Кнопка «Сохранить» и переход в новый статус — разные события. Запишите это условие в задании до того, как модель начнёт писать код.
Не подключайте сразу все уведомления магазина. Один рабочий сценарий даст основу, на которой можно проверить ошибки и только потом добавить другие события.
Как поставить задачу ChatGPT или Claude?
Передайте модели описание проекта, условие отправки и требования к проверке. Одной просьбы «добавь SMS через API» недостаточно: модель сама выберет место вызова, способ обработки ошибок и поведение при повторном запросе. Эти решения затрагивают реальные отправки и расходы.
В качестве основы подойдёт такое задание:
«Добавь серверную отправку SMS после первого перехода заказа в статус “Готов к выдаче”. Используй документацию выбранного провайдера. Перед изменениями покажи план и список файлов. Реквизиты доступа получай из настроек окружения, не включай их в код браузера. Для локальной проверки сделай тестовый режим без обращения к провайдеру. Предусмотри защиту от повторной отправки по одному событию. Отдельно обработай отказ сервиса и ситуацию, когда ответ не пришёл. Напиши тесты и перечисли вопросы, которые документация не проясняет».
Если проект уже существует, попросите модель сначала найти обработчик нужного события. Иначе рядом с рабочей логикой может появиться второй механизм отправки. Проверьте предложенный план: где возникает событие, какой серверный модуль вызывает API и где приложение показывает результат.
Модели нужен актуальный контракт API: какие поля передавать и как читать ответ. Детали подключения можно сверить в статье на rocketsms.by, а затем приложить нужный фрагмент документации к задаче. Не разрешайте ИИ угадывать параметры по похожим сервисам.
Не вставляйте рабочий пароль в переписку с моделью. Для подготовки кода достаточно названий настроек и условных значений. Настоящие реквизиты добавляют в окружение сервера отдельно.
Как устроить интеграцию, чтобы её можно было поддерживать?
Разделите бизнес-событие и обращение к SMS-провайдеру. Обработчик заказа сообщает, что пора отправить уведомление, а отдельный серверный модуль формирует запрос и разбирает ответ. Тогда изменение текста сообщения не потребует правок во всей системе заказов.
Для HTTP API проверьте метод запроса и формат тела по документации. JSON в ответе не означает, что сервис принимает JSON на входе. В исходном примере подключения запрос использует поля формы, а ответ приходит в JSON. Если ИИ перепутает эти форматы, внешне аккуратный код не выполнит задачу.
У браузера не должно быть прямого доступа к реквизитам SMS-сервиса. Посетитель нажимает кнопку на сайте, сервер проверяет допустимость действия и только затем обращается к провайдеру. Само наличие кнопки ничего не разрешает: проверка нужна на сервере.
Задайте ограничение времени ожидания ответа. При этом тайм-аут означает, что приложение не дождалось результата; он не доказывает, что провайдер отклонил запрос. Автоматическая повторная отправка в такой ситуации создаёт риск дубля. Для первого запуска оставьте отдельный статус «Результат неизвестен» и предусмотрите проверку по доступным средствам провайдера.
Попросите ИИ сделать защиту от дублей на уровне события. Простая блокировка кнопки не спасает, если два запроса пришли одновременно или сервер повторно обработал задачу. Разработчику нужно проверить, что право на отправку одного уведомления нельзя получить дважды.
Такое подключение можно выделить в отдельную задачу по доработке сайта после вайбкодинга. В её объём входят серверный модуль, настройки окружения, тесты и инструкция по запуску. Это понятнее для оценки работы, чем формулировка «довести SMS до ума».
Как проверить SMS-интеграцию до запуска?
Сначала замените реальный вызов API тестовой функцией, которая возвращает заранее заданные ответы. Так можно проверить поведение приложения без отправки сообщений. Попросите модель показать, каким способом включается этот режим и как убедиться, что рабочий сервер его не использует.
- Проверьте успешный ответ: приложение принимает идентификатор сообщения и не помечает его как подтверждённую доставку.
- Проверьте отказ: сотрудник видит понятный результат, а сервер не запускает бесконечные повторы.
- Проверьте тайм-аут: приложение показывает неопределённый результат и не отправляет дубль автоматически.
- Повторите одно событие: обычное сохранение заказа не создаёт новое уведомление.
- Запустите параллельную обработку события: система допускает только одну отправку.
После этих проверок проведите реальную отправку на свой номер. Сопоставьте событие в приложении с ответом провайдера и проверьте текст на телефоне. Получение идентификатора в API и фактическое получение SMS — разные результаты, поэтому в интерфейсе им нужны разные названия.
Попросите ИИ перечислить команды проверки и показать фактический вывод тестов. Фраза модели «всё работает» не заменяет запуск. Если у неё нет доступа к окружению, она должна прямо перечислить, что осталось проверить человеку.
До запуска также определите способ отключить отправку без изменения кода. Например, отдельная настройка позволяет остановить уведомления, пока сотрудник разбирается с ошибкой. Проверьте её на тестовом событии: заказ меняет статус, но запрос к провайдеру не уходит.
Типичные ошибки при подключении SMS через ИИ
- Реквизиты попали в клиентский код. Причина — модель выбрала прямой запрос из браузера. Перенесите обращение к API на сервер; если секрет уже стал доступен посторонним, замените его.
- Интерфейс показывает «Доставлено» сразу после ответа API. Разделите принятие запроса и подтверждение доставки, если провайдер предоставляет такой статус.
- Каждый сетевой сбой вызывает повтор. Выделите неопределённый результат отдельно и согласуйте правила повторов с возможностями API.
- ИИ добавил отправку в несколько обработчиков. Оставьте одну точку запуска и проверьте повторное сохранение заказа.
- Тест прошёл только по успешному сценарию. Добавьте отказ сервиса, тайм-аут и одновременные запросы до реального запуска.
Начните сейчас: за две минуты запишите одной строкой, какое событие на вашем сайте должно вызвать первое SMS, например: «Заказ впервые получил статус “Готов к выдаче”».
