Принципы продукта для небольших AI-команд: что стоит строить

Почему команды из двух человек выбирают не ту работу

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

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

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

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

Быстрый эксперимент и настоящая функция — это разные виды работы. Эксперименту нужно лишь один раз быть интересным. Функция должна выдержать месяцы использования. Кто-то должен её поддерживать, объяснять, тестировать после обновлений модели и решать, что делать, если она сломается.

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

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

Три правила, которые быстро сортируют идеи

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

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

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

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

Команда, которая использует Claude, GPT и open-source модель, может применить эти правила за несколько минут. Прогоните одну и ту же задачу на небольшой группе похожих входов и посмотрите, остаются ли ответы в понятных пределах. Сохраните достаточно деталей, чтобы любой из двоих смог потом восстановить ход результата. Потом задайте простой вопрос: если это сломается в пятницу вечером, сможет ли один человек быстро убрать это?

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

Это может звучать строго, но обычно это экономит время. Команды, которые работают с AI-продуктами, рано понимают: самая яркая идея редко оказывается той, что стоит выпускать первой. Лучше делать ставку на то, что можно повторить, проверить и вернуть назад без драмы.

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

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

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

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

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

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

Дрейф часто проявляется тихо. Claude может оставаться структурным, а GPT — становиться более творческим. Open-source модель может работать нормально, пока извлечённый контекст не становится слишком длинным. Небольшая правка промпта, которая ускоряет работу, может одновременно снизить точность. Даже маленькое изменение данных, например другой фрагмент поиска или версия документа, способно сдвинуть ответ настолько, что доверие сломается.

Пользователи принимают некоторую вариативность. Они не ждут, что каждое предложение будет звучать одинаково. Но они ожидают, что инструмент останется в понятных рамках. Если приложение пишет черновики ответов в поддержку, пользователи могут принять разную формулировку, но не разные факты. Если оно размечает тикеты, они могут принять расхождение в 5 %, но не в 25 %.

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

Как сделать работу AI проверяемой

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

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

Если основатель спросит: «Почему ассистент отправил именно такой ответ?», это должно быть видно без открытия трёх инструментов и чтения стены JSON.

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

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

Быстрое ревью лучше, чем идеальное ревью. Задайте короткий ритм — например, 20 минут два раза в неделю — и приносите реальные ошибки. Смотрите на плохой ответ, промпт, исходные данные и действие, которое последовало после. Потом решайте одно изменение: уточнить промпт, заблокировать рискованное действие, добавить проверку человеком или убрать задачу из продакшна.

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

Пошаговый тест для новых идей

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

Это особенно важно, когда команда использует несколько моделей в одном продукте. Claude может хорошо выполнять одну задачу, GPT — другую, а open-source модель может быть дешевле для рутинной работы. Если тест слишком рыхлый, продукт быстро становится хаотичным.

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

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

Сохраните доказательства в одном месте. Документ, таблица или issue вполне подойдут. Запишите вход, точный промпт или настройки инструмента, ответ и короткую заметку проверяющего. Когда потом что-то сломается, вы будете знать, что изменилось и почему команда это одобрила.

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

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

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

Простой пример с двумя людьми и тремя моделями

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

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

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

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

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

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

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

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

Ошибки, которые создают долгосрочную боль

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

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

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

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

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

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

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

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

Короткий чеклист перед тем, как тратить время на продакшн

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

Хорошие продуктовые правила специально скучные. Прежде чем встраивать что-то в продукт, проверьте пять вещей.

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

Во-вторых, проверьте, можно ли потом объяснить результат. Вам нужны промпт, версия модели, использованные инструменты, извлечённый контекст и финальный ответ в одном месте.

В-третьих, протестируйте путь отката. Если модель сломается, сможете ли вы переключиться на более простое правило, старый промпт или ручную проверку без разрыва процесса?

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

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

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

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

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

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

Следующие шаги для команды из двух человек

Команде из двух человек не нужен более длинный roadmap. Ей нужен более строгий фильтр. Выберите одну идею, которую вы обсуждаете прямо сейчас, и проверьте её по консистентности, проверяемости и обратимости. Используйте простую шкалу: pass, unclear или fail. Если вы не можете оценить идею за пять минут, значит, она всё ещё слишком туманна для продакшн-работы.

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

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

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

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

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

Некоторым командам нужен взгляд со стороны, чтобы всё это настроить без лишнего процесса ради процесса. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями над AI-продуктовыми решениями, лёгкими техническими процессами и практичными способами запускать новые системы так, чтобы откат и ревью не становились сложнее, чем нужно.