Спецификации продукта для гибридных человек‑ИИ рабочих процессов, которые остаются понятными

Почему это ломается без письменной спецификации

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

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

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

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

Пограничные случаи показывают разрыв особенно явно. Представьте, что ИИ составляет ответы клиентам. Один клиент просит возврат, но не даёт деталей. Другой звучит разгневанным. Третий просит что‑то вне политики компании. Если никто не записал, кто решает в каждом случае, ИИ предполагает, рецензент импровизирует, а менеджер позже даёт другое решение. В результате у команды три версии одной и той же политики.

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

Без письменной спецификации рабочий процесс не остаётся стабильным. Он превращается в подсказки, сообщения в чатах и личные привычки.

Что нужно поместить в спецификацию на одной странице

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

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

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

Выходу нужны правила, а не догадки. Определите формат, длину и ограничения простыми словами. Если ИИ должен вернуть JSON‑объект, короткое резюме или черновик менее 120 слов — скажите это. Если он не должен обещать юридические гарантии, менять цену или давать медицинские советы, запишите это.

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

Для низкой уверенности нужен свой путь. Не прячьте это правило в подсказке, где его никто не увидит позже. Опишите, что считается неопределённостью, кому отправляется кейс и что происходит дальше. Например: если ИИ не может классифицировать запрос на возврат с достаточной уверенностью, ему следует пометить кейс для ручной проверки, указать причину и остановиться до отправки ответа.

Одной страницы достаточно, если на ней отвечены пять вопросов: Что за задача? Что ИИ может читать? Что он должен выдавать? Кто отвечает за решение? Куда попадает неопределённая работа? Если что‑то из этого отсутствует, люди заполнят пробел по памяти, а память меняется быстро.

Как пошагово составить поток

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

Опишите процесс в порядке выполнения. Делайте каждый шаг коротким и конкретным. Используйте простые глаголы: «получить запрос», «проверить поля», «составить черновик», «утвердить», «отправить». Если шаг звучит расплывчато, значит команда, вероятно, полагается на память, а не на правило.

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

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

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

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

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

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

Кто решает и кто проверяет

Спецификация становится бесполезной, когда все могут редактировать результат, но никто им не владеет. Выберите одну роль, которая отвечает за итоговый результат. Не за подсказку, не за настройки модели и не за черновик — за результат.

Во многих рабочих процессах владелец — тот, кто отвечает за ошибки. Если ИИ отправил клиенту ответ с неправильной политикой возврата, один именованный человек должен нести ответственность. В маленькой команде это может быть руководитель поддержки, в продуктовой — product manager.

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

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

Временные рамки важнее, чем команды думают. Если ИИ сделал черновик в 10:00, а юридическая проверка должна быть «потом», люди начнут обходить проверку. Укажите время на каждую передачу: 30 минут для ответа поддержки, 4 часа для изменения страницы с ценами или 1 рабочий день для обновления политики.

Также укажите лицо, имеющее право на релиз. Ревьюер может утвердить формулировку, но не всегда это даёт право публиковать. Человек, который может нажать «отправить» или выпустить в продакшн, должен быть прописан в спецификации. Эта деталь предотвращает много обвинений позже.

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

Такая фраза решает две задачи: она защищает команду при падении уверенности и выносит правила принятия решений из подсказок и коридорных разговоров.

Что делать, когда уверенность падает

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

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

Напишите правила остановки так, чтобы никто не гадал:

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

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

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

Храните небольшую библиотеку реальных примеров. Сохраните несколько кейсов, где ИИ остановился, несколько, где человек исправил ошибку, и несколько, где эскалация была правильным решением, хотя ответ выглядел корректно. Команды учатся быстрее так, потому что тренируют и спецификацию, и ревьюеров на реальных пограничных случаях, а не на памяти и мнениях.

Простой пример из реальной команды

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

Обычный кейс проходит простую цепочку. Клиент просит возврат, и ИИ составляет черновик ответа, опираясь на ID заказа, статус оплаты и политику возвратов. Агент поддержки проверяет данные аккаунта, подтверждает реальность заказа и исправляет всё, что черновик упустил или интерпретировал неверно. После этой проверки рутиные случаи отправляются. Супервайзер вмешивается только при дополнительном риске: большая сумма, флаг о споре по платежу или исключение из политики.

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

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

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

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

Ошибки, которые делают спецификацию бесполезной

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

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

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

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

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

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

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

Быстрая проверка перед началом работы

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

Прочитайте каждый шаг и проверьте наличие именованной роли. «Руководитель поддержки утверждает возвраты свыше $200» — ясно. «Человек проверяет пограничные случаи» — не ясно. Смешанные человек‑и‑ИИ процессы разваливаются, когда владение остаётся расплывчатым, особенно в маленьких командах, где один человек может выполнять две роли за день.

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

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

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

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

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

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

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

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

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

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

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

Если команда постоянно спотыкается о владение, шаги проверки или правила запасного варианта, внешнее мнение может помочь. Oleg Sotnikov на oleg.is работает как Fractional CTO и стартап‑советник, и с такими операционными деталями он помогает командам.

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