В обсуждении появляется обычное «Спасибо, полезный пост». Через некоторое время на его месте оказывается реклама. Первую версию антиспам пропустил правильно, но новая осталась без проверки. Для администратора это отдельная задача: проверить защиту не только при отправке сообщения, но и после его изменения.
Такой сценарий описывают сами владельцы каналов. Например, автор «Мультипликатора» предупреждал читателей о комментариях, которые превращают в поддельные приглашения. Это частное наблюдение автора, а не оценка распространённости схемы. Ниже - порядок безопасного теста для компании, которая ведёт обсуждения в Telegram.
Почему первичной проверки недостаточно
В документации Telegram Bot API новая версия известного боту сообщения приходит отдельным обновлением edited_message. Для изменённого поста канала предусмотрен edited_channel_post. Получение обычных сообщений ещё не подтверждает обработку правок. При этом обновление правки может относиться и к полям, которые бот не использует: решение нельзя принимать по одному названию события.
Команде достаточно задать исполнителю три вопроса: дошла ли новая версия, проверена ли она действующим правилом и что произошло после решения? Настройки получения обновлений и работа интеграции требуют отдельной проверки. Не передавайте для этого токен бота и не отключайте рабочую доставку событий самостоятельно.
Если не поступает даже первая версия, начните с инструкции о получении сообщений ботом. Здесь разбирается следующий случай: исходный комментарий уже известен системе, а проблема появляется после редактирования.
Проверьте четыре изменения
Выберите собственную тестовую группу или согласованное место проверки. Заранее определите разрешённый текст, условное нарушение и ожидаемое действие. Вместо реального рекламного адреса используйте безвредную учебную метку, которую исполнитель согласовал для теста. Для проверки не нужны ссылки на мошенников и данные покупателей.
| Что меняем | Что ожидаем | Что проверяем |
|---|---|---|
| Нейтральный текст заменяем согласованным нарушением | Новая версия проходит отдельную оценку | Результат относится к правке, а не к прежнему тексту |
| Исправляем опечатку в полезном вопросе | Вопрос остаётся доступен для ответа | Само редактирование не считается нарушением |
| Меняем подпись к учебному изображению | Проверяется нужный тип содержимого, если он входит в подключение | Текст и подпись не подменяют друг друга в тесте |
| Повторно меняем разрешённое сообщение | Разбирается его актуальная версия | Результаты разных версий не перепутаны |
Это план испытания, а не описание уже подтверждённых функций ЭГО. Если подписи не входят в ваш сценарий, отметьте границу покрытия. Не заменяйте неработающий пример успешной проверкой обычного текста. Для команды важнее честный список поддерживаемых случаев, чем общий ответ «редактирование учитывается».
Как записать результат без лишней переписки
В рабочей карточке укажите тестовое пространство, время отправки и правки, ожидаемое решение, наблюдаемый результат и ответственного. Исполнитель сопоставляет версии доступным ему способом. Если журнал показывает только исходный текст, спросите, как подтвердить обработку изменённого. Наличие полного архива версий заранее не предполагается.
Раздельно отмечайте «получено», «проверено», «решение принято» и «действие выполнено». Например, система могла обнаружить нарушение, но операция не прошла. Это другая неисправность, чем отсутствие повторной оценки. Вывод «антиспам пропускает рекламу» пока слишком широк для исправления.
Отдельный сотрудник проверяет полезные вопросы после теста. Удаление одного условного нарушения не означает, что все правки обрабатываются верно. Поддержка должна по-прежнему видеть уточнения покупателя, исправленные адреса и изменения вопроса, которые не нарушают правил сообщества.
Предусмотрите ещё одну рабочую ситуацию: менеджер начал отвечать на первую версию, а автор уже изменил вопрос. Сотруднику нужен способ заметить актуальный контекст до отправки ответа. Это требование к процессу, а не обещание специального уведомления в кабинете. Согласуйте, кто перепроверяет текст в открытой ветке, если данные в очереди отличаются. Такой разбор помогает не опубликовать ответ на вопрос, которого пользователь больше не задаёт.
Найдите незавершённый этап теста
Выберите проверяемый материал и отметьте только подтверждённые этапы. Помощник предлагает следующий вопрос исполнителю, не подключается к Telegram и не определяет настоящий спам.
Проверка изменённого сообщения
Выберите сценарий. Отметки составляют план проверки и не подтверждают исправность защиты.
При смене сценария отметки сбрасываются. Без JavaScript пройдите этапы по порядку: получение новой версии, повторная проверка, результат действия, сохранность полезных сообщений.
Что делать с найденной ошибкой
Если новая версия не получена, передайте пример ответственному за подключение. Если получена, но не проверена, обсуждайте повторную обработку. Если решение неверное, пересматривайте правило на паре примеров: нарушение и похожее полезное уточнение. Менять одновременно доставку и правила неудобно: связь между исправлением и результатом потеряется.
После изменения повторите весь небольшой набор. Особое внимание уделите случаю, когда пользователь несколько раз правит один текст. Сотрудник должен понимать, к какой версии относится наблюдаемое решение. При ошибочных действиях согласуйте временную остановку проблемного сценария и ручной разбор; не обещайте восстановить уже удалённое сообщение.
Дальше добавьте этот набор в приёмку защиты от спама. Новый тип отправителя и изменение текста - разные признаки: тест одного не закрывает другой. Повторяйте нужные примеры после существенных изменений подключения или правил.
Покажите задачу на демонстрации
Если команде приходится вручную отслеживать правки, обсудите модерацию спама с ЭГО. Принесите обезличенный сценарий «до и после» и ожидаемое решение. Так можно согласовать нужное покрытие, действия на вашем подключении и участие сотрудника, не подменяя проверку обещанием защитить любой чат.
Состав направления и условия смотрите в тарифах «Эго Комментарии». Пилот предусмотрен кроме спецтарифов. Начать стоит с проверяемого рабочего сценария, который помогает сохранять вопросы клиентов и замечать нарушения после правок.
