Как подойти к задаче без лишней магии
Я бы не масштабировал пилот только потому, что он красиво сработал на демо. Пилот должен пережить отпуск автора, новый тип входа и ошибку внешнего сервиса.
Ошибка, которую я бы сразу убрал: Прототип обычно держится на одном человеке, ручных обходах и памяти команды. Когда он становится процессом, выясняется, что нет владельца, логов, лимитов и правила остановки.
Что подготовить и какой результат ждать
- На выходе: Другой сотрудник может повторить сценарий, увидеть ошибку и понять, что делать, не звоня автору пилота.
- Запишите границы пилота: один канал, один тип входа, допустимые действия, владелец, набор тестов и критерии остановки.
- Сохраните исходные данные и права доступа отдельно от результата, чтобы можно было проверить, что сделал масштабируемый AI-пилот.
- Передайте инструкцию человеку, который не участвовал в сборке, и попросите обработать десять реальных случаев.
Превратите демо в повторяемый процесс
- Зафиксируйте рабочую версию
Сохраните промпты, credentials, версии таблиц, допустимые статусы и пример входа/выхода в одном changelog.
Проверьте: Понятно, какая версия сейчас используется.
Если не сработало: Перенесите настройки из личного аккаунта в общий рабочий доступ.
- Сделайте журнал ошибок
Поля: run_id, input_type, expected, actual, reason, owner, fix, date. Не удаляйте ошибочный запуск после исправления.
Проверьте: Одинаковая ошибка группируется, а не появляется как десять разных проблем.
Если не сработало: Добавьте обязательное поле reason перед закрытием инцидента.
- Проверьте исключения
Добавьте тесты на пустой вход, дубль, неверный формат, отсутствие права, таймаут и неполный ответ модели.
Проверьте: Каждая ошибка имеет retry, stop или human handoff.
Если не сработало: Не расширяйте пилот, пока исключение просто исчезает из журнала.
- Масштабируйте по одному измерению
Сначала увеличьте объём или добавьте один канал, но не делайте оба изменения одновременно. Сравните качество и стоимость с базой.
Проверьте: Можно понять, что именно изменило результат.
Если не сработало: Вернитесь к последней стабильной версии.
Паспорт пилота
Запишите workflow_id, владелец, версия промпта, входные поля, разрешённые действия, лимит в день, baseline, критерий успеха, типы исключений и срок пересмотра. Версия должна быть видна в каждом запуске.
Соберите журнал run_id, started_at, input_hash, status, error_type, retry_count, human_decision и final_result. Без этого команда спорит о впечатлениях, а не разбирает конкретный запуск.
- Пилот = ограниченный объём, один владелец и обратимое действие.
- Масштабирование начинается после выборки ошибок, а не после первой удачной недели.
Порог перехода в рабочий процесс
Перед расширением проверьте три вещи: результат стабилен на новых данных, сбой попадает владельцу за понятное время, а сотрудник может отменить действие. Если любой пункт не выполнен, оставьте пилот в shadow mode — пусть он предлагает, но не меняет рабочую систему.
Расширяю пилот на новых входах по одному
Разделите проверку на две выборки: обычные кейсы и крайние — пустое поле, дубль, просроченный документ, таймаут и конфликт данных. Для каждой записи сравните ожидаемый результат, фактический статус, число исправлений и время до решения человека. Не смешивайте новый канал и новый тип данных в одном запуске.
Переходите из shadow mode в действие только после повторной проверки на новой выборке. Сохраните дату решения, версию промпта и список разрешённых операций. Если новый вход вызывает неизвестный статус, возвращайте `needs_review`, а не расширяйте права модели на ходу.
Что должно измениться после настройки
Другой сотрудник может повторить сценарий, увидеть ошибку и понять, что делать, не звоня автору пилота.
Почему пилот работает только на демо
Расширять пилот до появления журнала ошибок.
Хранить критические настройки в личном аккаунте.
Считать ручные обходы частью нормального процесса.
Добавлять пять новых интеграций сразу.
Когда пора строить полноценный контур
Нужен специалист, если пилот затрагивает несколько команд, разные права доступа, высокую нагрузку или должен работать без автора.
Как понять, что пилот готов к расширению
Кому подходит этот способ работы с масштабируемый AI-пилот?
Пилот не масштабируется, когда он держится на одном человеке, ручных обходах и демонстрационном наборе данных. Сначала превратите его в повторяемый процесс с логами и владельцем.
С чего начать, если всё пока делается вручную?
Запишите границы пилота: один канал, один тип входа, допустимые действия, владелец, набор тестов и критерии остановки.
Как проверить, что настройка не навредит?
Передайте инструкцию человеку, который не участвовал в сборке, и попросите обработать десять реальных случаев.
Что делать при непонятном результате?
Заморозьте расширение, соберите ошибки в журнал и исправьте одну причину до добавления новых каналов.
