Клиент изменил сообщение: как ИИ-продавец пересматривает основание

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

Правка ранее полученной реплики — это замена основания, а не новое сообщение с уточнением. Система должна хранить постоянный идентификатор заявки и последовательность версий извлечённых полей, сравнивать версии по полям и пересматривать только зависимые действия. После согласования требуется повторное подтверждение, а не тихая подмена документа.

Клиент отправляет в чат сообщение: «Нужны две катушки кабеля, счёт на ООО „Северный ветер“, доставка на склад в понедельник». ИИ-продавец принимает заявку, готовит коммерческое предложение и передаёт его менеджеру на согласование. Через семь минут клиент правит ту же реплику: «Нужны четыре катушки, счёт на ООО „Северный ветер“, доставка на склад во вторник». Задача уже собрана, но основание под ней изменилось. Вопрос не в том, умеет ли бот читать сообщения, а в том, что он делает со своими прежними выводами, когда текст под ними переписали.

Редактирование реплики — это не новое сообщение с уточнением

Когда клиент присылает второе сообщение «ой, я ошибся, не две, а четыре», это отдельный факт в переписке. У него свой идентификатор, своя временная метка, своя позиция в истории. Бот видит новое событие и может связать его с предыдущим по смыслу. Совсем другое дело — правка исходной реплики. Клиент не добавляет ничего в диалог. Он меняет текст, который уже был получен и, возможно, уже обработан. С точки зрения человека в мессенджере это выглядит как исправление опечатки. С точки зрения системы это подмена содержимого объекта, на который уже могли опереться последующие шаги.

Разница принципиальна для логики. Новое сообщение — это приращение: к старому знанию добавляется новое, и задача решает, какое из них актуальнее по времени. Правка — это замена: старое знание объявляется недействительным, а новое занимает его место в той же точке истории. Если обрабатывать правку как приращение, в системе останутся оба количества — две и четыре катушки — и придётся угадывать, какое из них главное. Если обрабатывать как замену, нужно аккуратно отозвать всё, что было построено на старой версии, и не отозвать лишнего.

Есть и третий случай, который чаще всего путают с правкой: клиент меняет заказ новой просьбой. «Передумал, нужен не кабель, а гофра». Это уже не исправление основания, а новый запрос, и он заслуживает собственной задачи. Смешивать эти сценарии в одном обработчике — верный способ получить бота, который при любом изменении текста сбрасывает всё подряд и теряет уже согласованные договорённости.

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

Что именно ломается, если правку считать обычным сообщением

Представим условный отдел продаж, который подключил ИИ-продавца в мессенджере. Бот принимает заявки, формирует черновик предложения, отправляет его менеджеру и ждёт подтверждения. Менеджер подтверждает, бот отправляет клиенту итог. Теперь клиент правит исходную реплику с количеством. Если бот не различает правку и новое сообщение, происходит одна из трёх неприятностей.

Первая: бот создаёт вторую задачу рядом с первой. В очереди менеджера висят два предложения — на две катушки и на четыре, — и непонятно, какое отправлять. Вторая: бот молча игнорирует правку, потому что «это сообщение уже обработано», и клиент получает предложение на устаревшее количество. Третья, самая коварная: бот замечает правку, но обновляет только текст ответа, а связанные поля — сумму, срок, склад — оставляет от старой версии. В итоге в предложении четыре катушки, а сумма посчитана за две.

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

Редакция сообщения клиента: заявка с версиями основания

Чтобы правки не превращались в хаос, полезно ввести явный рабочий объект — заявку, у которой есть неизменяемый идентификатор и последовательность версий основания. Идентификатор присваивается при первом получении реплики и больше не меняется, сколько бы раз клиент её ни правил. Версия основания — это снимок того, что бот извлёк из текста на конкретный момент: количество, получатель счёта, адрес, желаемая дата. Каждая версия помечается номером и временем, а также признаком, на каком событии она построена — исходное сообщение или правка.

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

Отдельно стоит хранить журнал переходов, а не только текущее состояние. При разборе спорной ситуации — клиент утверждает, что просил четыре катушки, а в предложении две — журнал показывает, какая версия была актуальной в момент формирования документа. Это не юридическая гарантия, а рабочий след, который помогает менеджеру восстановить картину.

Сравнение версий по полям, а не по всему тексту

Наивный подход — сравнивать старый и новый текст сообщения целиком и при любом расхождении пересобирать всё. Это работает, но дорого и суетливо: клиент поправил запятую или дописал «пожалуйста» — а бот заново готовит предложение и дёргает менеджера. Полезнее сравнивать извлечённые поля. Если количество, счёт, адрес и дата совпали, а изменилась только формулировка, зависимые действия можно не трогать. Если изменилось количество — пересматривать нужно те шаги, которые от количества зависят: расчёт суммы, наличие на складе, возможно, срок.

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

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

Правка до ответа: тихий пересчёт

Самый простой и самый частый случай — клиент правит сообщение раньше, чем бот успел что-то отправить наружу. Условный пример: заявка получена в 10:02, бот извлёк «две катушки» и поставил черновик в очередь, но ещё ничего не отправил ни клиенту, ни менеджеру. В 10:05 приходит правка на «четыре катушки». Здесь пересмотр дешёвый: старая версия основания заменяется новой, зависимые расчёты пересчитываются, черновик обновляется, наружу ничего не уходит. Клиент и менеджер видят только финальный результат, как будто правки и не было.

Тонкость в том, что «до ответа» — это не только «до отправки клиенту». Черновик мог уже уйти менеджеру на согласование, и тогда правка происходит в момент, когда человек уже смотрит на цифры. Это уже не тихий пересчёт, а ситуация, где нужно решить, что показывать менеджеру. Об этом ниже. А пока важно зафиксировать: чем раньше приходит правка, тем меньше зависимых действий нужно пересматривать, и тем полезнее не отправлять ничего наружу, пока заявка не устоялась хотя бы на короткое окно.

Это окно — предмет отдельного решения. Можно держать черновик несколько минут, чтобы дать клиенту шанс исправить опечатку, а можно отправлять сразу и разбираться с правками по факту. Первый вариант снижает суету, но добавляет задержку. Второй быстрее, но требует полноценной машинерии версий. Выбор зависит от того, насколько часто клиенты правят сообщения в конкретном канале, — а это стоит измерить, а не угадать.

Правка после согласования: пересмотр, а не тихая замена

Теперь сложный случай. Менеджер согласовал предложение на две катушки, бот отправил его клиенту, а через час клиент правит исходную реплику на четыре. Здесь нельзя просто пересчитать и подменить документ: согласованный документ уже ушёл, и у него есть статус. Тихо заменить его на новый — значит создать расхождение между тем, что человек утвердил, и тем, что лежит в переписке.

Разумная логика — пересмотр с явным следом. Новая версия основания порождает новую версию предложения, старая помечается как заменённая, а менеджер получает уведомление: «Основание изменилось после согласования: количество 2 → 4. Требуется повторное подтверждение». Клиенту при этом уходит понятное сообщение о том, что предложение обновляется, а не молчаливая подмена цифр. Кто именно утверждает повторно — вопрос процесса, но факт повторного утверждения должен быть зафиксирован.

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

Когда событие правки не пришло

Всё предыдущее опирается на допущение, что система узнаёт о правке. Это допущение нужно проверять для каждого канала отдельно. В одних мессенджерах правка приходит отдельным событием с признаком «это изменение ранее отправленного сообщения». В других — правка может не приходить вовсе, или приходить без указания, какое именно сообщение изменено, или приходить только для сообщений определённой давности. Поведение каналов различается и меняется со временем, поэтому его нельзя считать одинаковым по умолчанию.

Telegram Bot API, например, описывает обновления, связанные с изменением сообщений, но конкретный набор полей и условия их появления нужно сверять с актуальной документацией, а не с памятью разработчика: что именно приходит, для каких чатов, что происходит с медиа. Общие вопросы о поведении ботов собраны в Telegram Bots FAQ — там же полезно уточнить ограничения, которые влияют на то, какие события бот вообще получит.

Практический вывод: для каждого канала нужно составить карту событий — приходит ли правка, приходит ли удаление, приходит ли признак авторства. Если правка не приходит, система должна это знать и не делать вид, что основание всегда актуально. Тогда появляется резервный механизм: сверка, если API действительно позволяет получить актуальный текст, либо явное подтверждение от клиента перед отправкой финального документа. Это не элегантно, но честно.

Доставка повторилась: одна и та же правка дважды

Мессенджеры и очереди не гарантируют доставку ровно один раз. Одно и то же событие правки может прийти дважды — из-за повтора при сбое сети, из-за переподключения, из-за того, что обработчик упал после получения, но до подтверждения. Если обрабатывать каждое событие как новое, бот дважды пересоберёт предложение, дважды дёрнет менеджера и, возможно, дважды отправит клиенту обновление.

Защита здесь стандартная, но её нужно заложить заранее: у каждого события есть идентификатор, и обработчик ведёт учёт уже обработанных. Повторное событие с тем же идентификатором распознаётся и отбрасывается. Но идентификатор события — не то же самое, что идентификатор версии основания. Две разные правки с разными идентификаторами могут привести к одинаковому содержимому, и это нормально: версия всё равно увеличится, а зависимые действия пересчитаются по правилам. Опасен именно повтор одного и того же события, а не совпадение результата.

Полезно также разделить «получение события» и «применение изменения». Событие можно принять и записать в журнал сразу, а применение — сделать идемпотентным: повторное применение той же версии не меняет ни статусов, ни отправок. Тогда даже если событие проскочит мимо фильтра, вреда не будет.

Клиент не автор цитаты

Ещё одно исключение, которое ломает наивную логику. В интеграциях с корпоративными каналами и общими учётными записями нужно отличать автора сообщения, отправителя события и полномочия представителя компании. В обычном чате Telegram другой участник не получает произвольного права менять чужое сообщение. Если система считает, что автор правки и автор исходной реплики — всегда одно лицо, она может приписать изменение не тому человеку и не тому контрагенту. В переписке с несколькими участниками это реальный риск: заказчик подтверждает количество, а правку вносит его коллега, и не факт, что у коллеги есть полномочия менять заказ.

Поэтому в рабочем объекте стоит хранить не только «кто отправил исходное сообщение», но и «кто внёс правку», и сверять это с правилами доступа. Если правку внёс участник без нужных полномочий, изменение можно принять как информацию, но не применять к согласованному предложению без подтверждения уполномоченного лица. Это не юридическая норма, а рабочее правило конкретного бизнеса, и его стоит проговорить с теми, кто отвечает за договорную работу, сверившись с применимыми документами и внутренним регламентом.

Удалённое сообщение обычный бот может не увидеть

Рядом с правкой стоит удаление, и его нельзя считать тем же самым. Клиент может удалить сообщение целиком — и тогда основание исчезает, а не заменяется. Приходит ли событие удаления в конкретном канале — вопрос отдельный, и ответ на него может быть «нет» или «не всегда». Если бот не получает событие удаления, он продолжает считать, что заявка на две катушки существует, хотя в переписке её уже нет.

Это не повод строить сложную систему слежки. Достаточно честно признать ограничение: для каналов, где удаление не приходит событием, основание может оказаться неактуальным без ведома системы. Отсюда — рекомендация подтверждать ключевые параметры перед финальной отправкой документа, а не полагаться только на историю сообщений. Подтверждение может быть коротким: «Проверьте, пожалуйста: четыре катушки, счёт на ООО „Северный ветер“, доставка во вторник». Одна такая строка снимает целый класс расхождений.

Редакция сообщения клиента на экране сотрудника

Вся эта машинерия бесполезна, если менеджер видит только «заявка обновлена». Ему нужно понять три вещи: что изменилось, на каком основании, и что от него требуется. Поэтому карточка заявки в интерфейсе сотрудника должна показывать версии явно.

Хорошая карточка не прячет старую версию. Наоборот, она показывает её рядом с новой, чтобы менеджер видел дельту: было две катушки, стало четыре. Если правка пришла после согласования, карточка не должна выглядеть как обычная заявка — на ней нужен заметный признак, что утверждённый документ устарел и требует повторного решения. Иначе менеджер отправит клиенту старое предложение, не заметив, что цифры уже другие.

Отдельно стоит продумать, что видит клиент. Молчаливая подмена цифр в уже отправленном предложении — плохая идея: клиент может не заметить, что документ изменился, и ориентироваться на старую сумму. Понятное сообщение «обновляю предложение с учётом правки» решает проблему лучше, чем тихая замена.

Как проверить, что пересмотр работает

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

К этим тестам стоит добавить проверку журнала: после каждого сценария в журнале должна быть запись о том, какая версия была актуальной, кто внёс изменение и какие зависимые действия пересмотрены. Если журнал пуст или противоречив, значит, обработчик где-то обошёл учёт версий — и это найдётся раньше, чем в реальной переписке.

Практикум: разбор одной правки по шагам

Возьмём условную заявку на монтаж стеллажей. Клиент пишет: «Нужен монтаж трёх стеллажей, объект на Лесной, 14, в среду после обеда». Бот извлекает основание: три стеллажа, адрес, среда после обеда. Черновик уходит менеджеру. Менеджер согласует. Бот отправляет клиенту смету. Через сорок минут клиент правит исходную реплику: «Нужен монтаж пяти стеллажей, объект на Лесной, 14, в среду после обеда».

Шаг первый — распознать событие. Система получает правку и понимает, что это изменение ранее полученного сообщения, а не новое. Если канал не присылает такое событие, шаг сразу переходит к резервной проверке: перед отправкой финального документа бот просит клиента подтвердить параметры.

Шаг второй — сравнить версии по полям. Количество изменилось с трёх на пять. Адрес и время не изменились. Значит, пересматривать нужно шаги, зависящие от количества: расчёт стоимости монтажа, возможно, состав бригады и срок.

Шаг третий — проверить статус зависимых действий. Смета уже согласована и отправлена. Значит, тихая замена недопустима. Система создаёт новую версию сметы, помечает старую как заменённую и ставит на карточке флаг «основание изменено после согласования».

Шаг четвёртый — уведомить и запросить решение. Менеджер получает сообщение: «Клиент изменил количество стеллажей с 3 на 5 после согласования. Требуется повторное подтверждение сметы». Клиент получает понятное сообщение об обновлении предложения.

Шаг пятый — зафиксировать результат. После повторного согласования новая смета уходит клиенту, в журнале остаётся след: версия 1 — три стеллажа, согласована; версия 2 — пять стеллажей, согласована повторно. Если позже возникнет спор, менеджер откроет журнал и увидит, что и когда менялось.

Этот разбор показывает главное: работа с правками — это последовательность небольших решений, а не один большой механизм. Распознать событие, сравнить поля, проверить статус, уведомить, зафиксировать. Каждый шаг можно проверить отдельно и улучшить, не перестраивая всё сразу.

Где заканчивается автоматический пересмотр

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

Вторая граница — правки, меняющие суть заявки, а не её параметры. Если клиент вместо кабеля просит гофру, это не правка основания, а новая потребность. Её стоит выносить в отдельную заявку, а старую закрывать с понятным статусом. Смешивание этих случаев в одном обработчике — источник путаницы в отчётности и в переписке.

Третья граница — каналы, где события правки не приходят или приходят неполно. Там автоматический пересмотр невозможен по определению, и честнее это признать, чем имитировать уверенность. Резервное подтверждение параметров перед финальной отправкой — не костыль, а разумная страховка.

Проверка на практике: редакция сообщения клиента

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

Дальше — карта событий по вашему каналу. Выясните по актуальной документации канала, приходит ли событие правки, приходит ли событие удаления, есть ли признак автора изменения. Сверьте это с тем, что реально получает ваш обработчик. Расхождение между документацией и поведением — обычное дело, и его лучше найти на тесте, чем на клиенте.

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

Смежный вопрос разобран отдельно: Изменение заказа в чате: от просьбы к принятой новой версии.