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