Архитектура фронтенда для экранов с поддержкой ИИ, которые не подводят

Где такие экраны ломаются

Команды часто делают первый экран с ИИ как обычную форму с «умным» текстовым полем. Это обычно первая ошибка.

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

Проблемы начинаются, когда UI скрывает, что изменилось. Если пользователь просит переписать и старый вариант исчезает, вместе с ним уходит доверие. Люди хотят сравнить новый текст с последней утверждённой версией, увидеть отредактированные строки и решить, действительно ли ревизия помогла.

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

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

Обычные точки отказа просты:

• Новый черновик заменяет утверждённый контент до подтверждения
• Экран показывает финальный текст, но скрывает изменения
• Повторная генерация создаёт новую версию без ярлыка или истории
• Разные состояния загрузки выглядят одинаково
• Интерфейс даёт править контент, который через секунду перезапишется

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

Состояния, которые нужны с первого дня

Многие AI‑экраны проваливаются, потому что воспринимают вывод как единый кусок текста. Реальная работа не происходит так. Люди пишут промпт, проверяют черновик, просят правки, ждут новую версию и затем утверждают её. UI должен явно показывать этот путь.

Начните с пяти состояний и показывайте каждое рядом с самим содержимым, а не спрятанным в боковой панели.

• Draft: модель сгенерировала текст, но ему ещё не доверяют
• Waiting: система работает или ждёт человека
• Approved: кто‑то принял эту версию для реального использования
• Correcting: человек попросил правки, и черновик пересматривают
• Failed: выполнение сломалось, вышло время ожидания или пришёл мусор

Метка должна отвечать на два вопроса сразу: «Что это?» и «Что будет дальше?». Маленькая заметка вроде «Черновик — требуется проверка» работает лучше, чем расплывчатая иконка "Pending".

Кнопки должны меняться в зависимости от состояния. Черновик может показывать «Утвердить», «Запросить правки» и «Отредактировать вручную». В состоянии ожидания следует ограничивать действия, чтобы люди не запускали дублирующие операции. Утверждённый контент по умолчанию должен блокировать рискованные правки, если пользователь специально не откроет его. Для неудачных запусков нужен понятный путь повтора и сохранённый последний ввод, чтобы никто не начинал с нуля.

Ограничения тоже важны. В состоянии correcting пусть пользователь отправляет короткую заметку, а не сбрасывает всю задачу. В approved держите контент только для чтения по умолчанию. В waiting отключайте разрушительные действия, если нет явной кнопки отмены.

Небольшая метка рядом с текстом, правильные кнопки и понятный следующий владелец внушают больше доверия, чем хитрый промпт.

Держите исходный текст, черновик и утверждённый контент раздельно

Если исходный текст, вывод модели и финальная копия живут в одном поле, экран быстро превращается в беспорядок. Люди перестают доверять, потому что не понимают, что они написали, что модель изменила и что команда приняла.

Относитесь к ним как к трём отдельным записям, а не как к трём видам одного и того же текста.

• Source — исходный ввод пользователя. Оставляйте его нетронутым.
• Draft — предложение модели. Оно может меняться много раз.
• Approved — версия, принятую человеком. Сохраняйте её как отдельную версию.

Исходник важнее, чем команды думают. Когда кто‑то спрашивает: «Почему модель сказала это?», вам нужен точный материал, с которого начался поток. Если вы его перезапишете, последующие исправления станут угадыванием.

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

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

Быстрое сравнение тоже важно. Пользователи должны видеть старый и новый текст за секунды, а не рыться в вкладках и модальных окнах. Простая бок‑о‑бок проверка или компактный diff часто достаточно. Когда люди могут быстро сравнить source, draft и approved, они принимают лучшие решения и утверждают быстрее.

Без этого разделения мелкие ошибки UI превращаются в вопросы аудита, падение доверия и рост запросов в поддержку. С разделением экран ведёт себя как аккуратный редактор, а не как игровой автомат.

Подтверждение должно быть отдельным шагом

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

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

• Утвердить: принять этот черновик и применить его
• Редактировать: сохранить черновик, но открыть его для правок сначала
• Отклонить: не использовать этот черновик

Метки сами по себе не достаточно. Экран также должен сказать, что сделает утверждение. «Утверждение отправит этот ответ клиенту» или «Утверждение заменит текущее описание товара» обычно достаточно. Одно короткое предложение уменьшает сомнения и предотвращает случайные клики.

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

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

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

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

Как должен работать цикл правок

Хороший цикл правок узкий. Если неправильно одно предложение, экран не должен регенерировать весь ответ и рисковать сломать то, что пользователю уже нравится.

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

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

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

Утверждённые части должны оставаться заблокированными, если пользователь сознательно их не разблокирует. Как только кто‑то утвердил заголовок, резюме или поле с ценой, система должна рассматривать это как стабильный текст, а не как материал для следующего прохода ИИ. Эта граница важна.

После каждой ревизии пользователю обычно нужны только три действия:

• Принять новый черновик и заменить только выбранную часть
• Повторить попытку и попросить ещё одну версию той же части
• Остановиться и оставить текущий контент как есть

Этот последний вариант важен. Иногда первый черновик оказывается достаточным, или пользователь предпочитает править вручную. Экран должен делать остановку нормальной, а не выглядеть как сбой.

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

Простой пример: переписать ответ в поддержку

Агент поддержки получает сообщение от клиента с вопросом, почему возврат ещё не пришёл. Агент нажимает «Создать черновик ответа», и ИИ пишет вариант. Этот ответ должен появиться в блоке черновика рядом с перепиской, а не в живой ветке. Клиент ничего не видит, и агент может без давления проверить текст.

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

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

Система должна пересмотреть только отмеченное предложение. Она не должна переписывать всё сообщение и рисковать изменить утверждённые части. Именно здесь многие AI‑экраны проваливаются. Полная регенерация часто меняет тон, удаляет полезные детали или добавляет новую ошибку. Если продукт хранит source, draft и approved отдельно, изменение остаётся маленьким и легко проверяемым.

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

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

Ошибки, которые команды совершают в начале

Команды обычно ломают эти экраны, считая вывод ИИ обычными данными приложения. Это не так. Черновик, правка пользователя и утверждённый результат каждый требуют своего места в UI и в хранилище.

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

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

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

Чёткие статусы работают лучше, чем одно универсальное состояние загрузки:

• генерируется новый черновик
• ждёт подтверждения пользователя
• сохраняется утверждённый контент
• повтор не удался, предыдущая версия сохранена

Часто неправильно реализуют и подтверждение. UI спрашивает «Утвердить это?», но не объясняет причину. Люди колеблются, если не знают, что изменилось или зачем нужен человек. Короткая заметка помогает: «Черновик изменил сумму возврата» гораздо лучше, чем расплывчатое предупреждение.

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

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

Быстрая проверка перед релизом

Экран, который смешивает черновики ИИ и правки людей, может выглядеть нормально на демо и всё же провалиться в реальной работе. Последний прогон перед выпуском должен фокусироваться на ясности и восстановлении состояния. Если кто‑то сомневается даже на момент, он может утвердить неправильный текст или стереть хорошую правку.

Проводите эти проверки в реальном продукте, а не в макете.

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

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

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

История версий не обязана быть сложной. Трёх‑пяти последних ревизий достаточно для большинства экранов. Покажите время, действие и пометку draft или approved. Это уже сильно облегчает ситуацию, когда спрашивают: «Кто это изменил?».

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

Что делать дальше

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

Прежде чем кодить раскладку, нарисуйте состояния на бумаге или в простом мокапе. Большинство команд прыгают к компонентам слишком рано и потом латает поведение. В AI‑ассистируемых экранах карта состояний важнее первого визуального дизайна.

Держите набросок простым. Вам нужны ответы на несколько вопросов:

• Что видит пользователь до начала генерации?
• Где живёт черновик?
• Как пользователь подтверждает или отклоняет его?
• Что происходит после правки или повтора?
• Когда контент становится утверждённым?

Затем протестируйте поток на «грязных» вводах, а не на отшлифованных промптах. Попросите кого‑то сделать реальные правки, отклонить слабые черновики и повторить с короткими инструкциями вроде «сделай теплее» или «сократи вдвое». Именно там цикл правок либо становится понятным, либо распадается.

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

Отслеживайте несколько метрик с самого начала. Вам не нужна сложная аналитика. Три показателя обычно дают правду:

• процент утверждений (approval rate)
• число повторов перед утверждением (retry count before approval)
• правки вручную после утверждения

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

Если хотите внешний обзор, Oleg at oleg.is работает с командами над потоками AI‑продуктов и дизайном состояний. Свежий взгляд часто быстро находит настоящую проблему: не качество модели, а экран, который воспринимает черновик, подтверждение и правку как одно и то же.