ИИ-инженер

Команда и роли. Назначения и участие определяются работами периода; постоянное присутствие на всех встречах не требуется.

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

Как читать гайд

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

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

Отдельные работы по этапам

Начать с однократных работ и подтверждения готовности. На Подготовке работа идёт по чек-листу условий запуска, на первой неделе PoC — по процедуре онбординга. Регулярный поток задач начинается после онбординга: простые задачи на неделе 2, целевые — на неделях 3–4, затем задачи Пилота.

Подготовка: обеспечить условия онбординга

[ ] Вместе с РП внедрения подготовить репозиторий внедрения: зафиксировать версию методологии, скопировать стартовый комплект, проверить ссылки и доступы. Проектные изменения правил оформлять по процедуре адаптации.
[ ] Пройти свою часть чек-листа готовности к PoC: обследование, исходные материалы, доступы, интеграции, модели, рабочее место инженера и условия первых задач. Полный перечень направлений задаёт, что подготовить вместе с командой.
[ ] Зафиксировать процесс задачи/HITL, Git/MR, полномочия проверяющих и первые калибровочные задачи. Договориться о взаимодействии двух ИИ-инженеров.
[ ] Приложить результаты проверок; для оставшихся работ указать исполнителей и сроки. Подготовить инженерные основания для решения о старте PoC.

По инфраструктуре проверить возможность работы агента вместе с DevOps: DEV, доступ к UAT по мере необходимости, деплой из хранилища артефактов, сброс БД и восстановление данных, зависимости и регулярные операции. Детали и развитие полного набора — в гайде инфраструктуры; для старта нужны условия первых задач.

PoC, неделя 1: выполнить онбординг

[ ] Проверить предусловия и выполнить процедуру онбординга: адаптировать каталог исходных материалов к проекту через MR литературы, получить ответы по развилкам, настроить и проверить агентов и навыки из локального агента или рабочего места на платформе.
[ ] Параллельно онбордингу создать начальную версию агента внедрения: подключить материалы и источники проекта, настроить помощь с журналами, показателями и подготовкой материалов к встречам; сохранить версию и результат пробного запуска в журнале PoC.
[ ] Пройти минимальный чек-лист онбординга: сообщение в чате → чтение задачи → feature-ветка → проверки → деплой на DEV → MR и отчёт.
[ ] Сохранить MR литературы, MR пробной задачи и результат FLOW-11 в журнале PoC. Подтвердить техническое выполнение и качество содержания по критериям завершения онбординга. Цикл замечаний, приёмка и merge в минимум первой недели не входят.

PoC, недели 2–4: подтвердить полный цикл и завершить PoC

[ ] На простых, затем целевых задачах проверить применимые кейсы по коду, аналитике, коммуникациям, тестированию, средам и мониторингу. Результаты сохранять в накопительном чек-листе журнала PoC; регулярные действия по задачам описаны ниже.
[ ] Подвести итоги по контрольным точкам фаз: доказательства, ограничения, исправления литературы и остаток работ.
[ ] Подготовить инженерную часть чек-листа готовности к Пилоту. Подтвердить готовность выбранного потока и измерений, указать участников команды продукта для постановки, диалога, ревью и приёмки. Представить результаты для решения о переходе.

Пилот: включить команду в поток и подготовить итог

[ ] К началу Пилота применить выбранный продуктовый маршрут: задачи ставит и ведёт команда, MR поступают напрямую её проверяющим. Проверить инструкции, адресатов и уведомления, канал помощи ИИ-инженера и автоматическую публикацию показателей.
[ ] К завершению Пилота подготовить инженерные результаты, ограничения и предложения к итоговому решению: подтверждение целей либо основания плана их достижения. Завершение передачи обязанностей между инженерами не является условием успеха Пилота.

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

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

Работа в потоке задач: PoC и Пилот

Ниже — работа после онбординга: недели 2–4 PoC и Пилот. Минимальный проход первой недели выполняется по чек-листу выше.

Работа и событие	PoC: ИИ-инженер ведёт калибровку	Пилот: команда продукта ведёт задачи, ИИ-инженер сопровождает
Недельное планирование: подбор и подготовка задач	Инженер обеспечивает запас задач для текущей фазы PoC: заранее выбирает их с владельцем продукта и аналитиками из бэклога либо вместе с ними готовит новые постановки. Проверяет, какие кейсы и возможности агента предстоит откалибровать	Задачи ставят аналитик, владелец продукта или другой назначенный участник команды продукта. Инженер участвует в выборе подходящей области и объясняет возможности и ограничения агента; обеспечение регулярного потока постановок остаётся у продуктовой команды
Готова постановка: запуск и рабочий диалог с агентом	Инженер передаёт подготовленную задачу агенту, ведёт диалог, получает недостающие сведения у команды и проводит цикл решения	Назначенный участник команды продукта передаёт задачу агенту и ведёт рабочий диалог. Инженер наблюдает за работой платформы и подключается по запросу или при выявленной технической проблеме
Поступил вопрос или запрос HITL	Инженер организует получение ответов: обращается к аналитику, владельцу продукта, архитектору или другому эксперту и обеспечивает продолжение задачи	Вопросы сразу поступают назначенным участникам команды продукта. Они дают ответы и принимают решения по своему процессу. Инженер устраняет ошибки маршрутизации, инструментов, контекста и поведения агентов
Появился MR или новая версия и доказательства проверок	Инженер получает каждый MR и разбирает результат. На Подготовке выбирают: инженер проверяет перед командой либо выполняет её ревью в согласованной области. Продуктовые и архитектурные решения остаются у назначенных участников клиента	MR и доказательства поступают непосредственно разработчику, тестировщику и другим назначенным проверяющим команды. Инженер изучает MR для диагностики и улучшения агента, но не является обязательной точкой ревью каждого результата
Поступили замечания или готовы исправления	Инженер ведёт обработку замечаний: проверяет их понимание агентом, организует исправления и повторное рассмотрение. Предметные противоречия разрешает с владельцами решений	Проверяющие формулируют замечания и проверяют исправления; участник команды, ведущий задачу, обеспечивает её движение по согласованному процессу. Инженер разбирает зависания, неверную обработку замечаний и повторяющиеся ошибки, улучшает агента или инструменты
Результат готов к приёмке и завершению	Инженер предъявляет результат, организует проверку калибровочного кейса и сохраняет доказательства в журнале PoC. Решения о продуктовой приёмке и интеграции принимают назначенные участники	Приёмку, решение по MR и интеграцию выполняют назначенные участники команды продукта. Инженер проверяет работу автоматизации и сбора показателей, помогает разобрать технические проблемы

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

Ритм работы и источники

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

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

Подготовка к встречам и фиксация итогов

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

Встреча из календаря	Что готовит и приносит ИИ-инженер	Что фиксирует по итогам
Рабочая встреча Подготовки или онбординга	Проверки из соответствующего чек-листа, недостающие доступы/материалы, варианты настройки и вопросы по развилкам. На онбординге — MR литературы, результаты пробных запусков и остаток до минимального прохода	Полученные решения и исходные материалы, результаты в чек-листе/журнале PoC, инженерные задачи с исполнителями и сроками; необходимые изменения литературы
Общий дейлик либо отдельные встречи по требованиям, разработке, тестированию и документации	По требованиям — ошибки понимания постановок агентами и вопросы о контексте; по разработке — сбои запусков, CI, деплоя и повторяющиеся дефекты; по тестированию — причины неудачных прогонов и неполные доказательства; по документации — пробелы литературы, предложенные изменения промптов и навыков. Прилагает ссылки на задачи, MR и журналы	Инженерные действия, гипотезы исправления, необходимые ответы команды и сроки в трекере; решения для агента — в литературе проекта. Предметные решения, продуктовые задачи и вердикты ревью фиксируют профильные участники
Недельный разбор и планирование улучшений	Проверенный эффект прошлых изменений, повторяющиеся проблемы, предложения по навыкам, инструментам и измерениям, факты обучения и передачи обязанностей. На PoC также готовит с командой следующие калибровочные задачи	Инженерные работы следующей недели с результатами, исполнителями и сроками в журнале/трекере; фактическую передачу обязанностей — в журнале передачи. На Пилоте продуктовый бэклог формирует команда
Статус внедрения	За рабочий день до встречи передаёт РП внедрения инженерные материалы для общего отчёта/презентации: подтверждённые кейсы или показатели, ограничения, проблемы, эффект улучшений, факты передачи и вопросы на решение. Иной срок может быть установлен на проекте	Принятые технические действия и сроки — в инженерных задачах со ссылкой на общую запись решений РП; изменения подхода — в литературе. Новые выводы и ограничения — в журнале этапа
Контрольная точка онбординга, завершение PoC, переход к Пилоту или итог Пилота	Доказательства по чек-листу, остаток работ и влияние ограничений; к итогу Пилота — результаты измерений и технические предложения по достижению целей	Результаты проверки в соответствующем чек-листе и журнале; дальнейшие инженерные обязательства. Решение о переходе или завершении фиксируют уполномоченные участники

Подготовка технических фактов и пояснений к статусу — инженерная обязанность даже тогда, когда инженер не включён в состав самой встречи. РП внедрения собирает из них общий отчёт/презентацию и представляет результаты; инженер не дублирует этот комплект. Повестки можно объединять в одной встрече. Итоги не переписываются в паспорт: расписание хранится там, а решения — в журнале PoC, журнале Пилота, трекере и литературе по назначению.

Инженерная работа на обоих этапах

Когда и откуда приходит сигнал	Что делает ИИ-инженер	Результат и получатель
Ежедневная проверка очередей запусков, CI, ожиданий и ошибок платформе; материалы — к ближайшему относящемуся к ним дейлику из календаря паспорта	Проверяет остановки, ошибки, повторные циклы и нарушения маршрута. Выделяет технические действия и вопросы на решение команды. Ожидание предметного ответа направляет назначенному участнику	Список технических действий и препятствий для дейлика и РП
Сбой инструмента, CI/деплоя, остановка агента, запрос помощи или лимит доработок	Диагностирует, привлекает эксперта/DevOps, проверяет гипотезу исправления. Предлагает помощь, передачу выполнения человеку или остановку; решение принимается по процессу проекта	Устранённая причина либо конкретное обращение с версиями, журналами и выполненными проверками
Ежедневное окно анализа журналов	Глазами или с помощью своего агента изучает проблемные и обычные успешные запуски. Ищет лишние циклы, потерю контекста, плохие вопросы и отчёты, пропущенные проверки, избыточные токены и задержки	Гипотезы улучшений со ссылками на запуски, даже если жалоб от команды нет
Ежедневный контроль публикации сводки; еженедельный разбор показателей	Проверяет источники, полноту и расчёты. Разбирает исходы, замечания, токены, TTM, объём, экономию и медианы; предлагает этапы наблюдения для выявленного узкого места	Актуальный журнал, ограничения данных и предложения действий для команды и РП
После недельной проверки отчёта РП клиента передал ошибки оценок и примеры с пояснениями	Разбирает причины ошибок в оценках времени работы без агентов и участия людей в задачах агента. Исправляет данные либо правила агента внедрения; повторяющиеся ошибки проверяет на нескольких примерах. Проверяет изменение на разобранных и других известных случаях	Исправленные оценки с основаниями, проверенная версия правил и перечень затронутых отчётов для обоих РП; исходные значения и история исправлений сохранены
Еженедельный разбор инженерных улучшений	Планирует изменения промптов, навыков, инструментов и литературы. С владельцами артефактов уточняет развитие требований, тестов и миграций; проверяет эффект предыдущих изменений	Инженерные задачи с результатами, исполнителями и сроками
Подготовка к статусу или контрольной точке из календаря встреч паспорта	Готовит сделанное, подтверждённые кейсы/метрики, проблемы, эффект изменений и вопросы на решение; добавляет факты передачи знаний и обязанностей	Инженерная часть отчёта со ссылками для РП внедрения; доступна РП клиента
Совместная работа и недельный разбор обучения	Объясняет действия, разбирает выполненное коллегой, дополняет инструкции, фиксирует фактическую передачу инженерных обязанностей	Записи в журнале: что освоено, что передано, где ещё нужна помощь

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

Работа над литературой и агентами

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

Сохранить пример: задача, запуск, фрагмент журнала или замечание; описать отклонение и причину либо гипотезу.
Подготовить изменение через MR литературы проекта. Указать, какое поведение ожидается и как его проверить. Нужные продуктовые и архитектурные решения получить у владельцев этих решений.
Из локального агента или рабочего места ИИ-инженера на платформе проверить промпт/навык на исходном случае и затронутых сценариях. Оценить и техническое выполнение, и качество вопросов, ответов, комментариев и отчётов.
После применения смотреть следующие запуски: исчезла ли проблема, изменились ли качество, время, токены и участие людей. Зафиксировать результат; при ухудшении пересмотреть или откатить изменение по правилам проекта.

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

Агент внедрения

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

ИИ-инженер создаёт агента внедрения на первой неделе PoC, параллельно онбордингу агентов в продукт. Агент помогает вести внедрение: использует методологию, паспорт, план, чек-листы и журналы проекта, а также доступные данные чата, трекера, Git/CI и журналов платформы.

Агент выполняет следующие работы:

Формирует todo и рекомендует ближайшие действия по правилам методологии: учитывает период, назначения и состояние проекта, прикладывает основания, отделяет пробелы и предложения. Инженер проверяет навык на приведённых в правилах сценариях; генерация правдоподобного списка без источников не считается готовностью.
Собирает выбранные показатели, оценивает трудозатраты и выделяет сомнительные значения с основаниями для проверки РП клиента.
Готовит записи в журналы и сводки выполнения плана и чек-листов: что подтверждено, какие доказательства отсутствуют, где есть задержки и вопросы на решение.
По календарю встреч готовит черновики материалов к дейликам, статусам и контрольным точкам: результаты, отклонения, открытые вопросы и предложения следующих действий со ссылками на источники.

При создании инженер задаёт источники, правила обработки данных, форматы результатов, способы и ритм запусков. Промпты и навыки хранит в литературе проекта, результаты — в артефактах внедрения в Git. Проверяет первый запуск по источникам: агент различает подтверждённый факт, оценку и отсутствие данных. Результат сохраняет в журнале PoC; проверку расчётов и помощи с ведением внедрения продолжает на неделях 2–4.

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

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

Настройка мониторинга

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

В объём работы входят:

Подключение чата, трекера, Git/CI и журналов платформы, включая ClickHouse при наличии; связи задач, запусков, MR и проверок, устранение дублей.
Правила недельных когорт, окна оценки, исходов и замечаний; расчёт выбранных показателей и контроль пропусков. Перечень показателей остаётся в коротком документе, алгоритмы — в навыке.
Оценка идеальных часов агентом или командой с согласованием РП по правилам мониторинга: предварительная при наличии, итоговая после приёмки, с историей и причинами изменений; независимая оценка участия людей по артефактам, диапазоны и основания. Время платформы и токены не включаются в человеческие часы.
Автоматическая публикация сводок и списка аномалий обеих оценок. РП клиента раз в неделю проверяет только аномалии; инженер исправляет правила по результатам разбора. Табели и регулярные запросы часов участникам не вводятся.
Настройка по описанию процесса команды и плану мониторинга; ежедневный сбор по расписанию или просьбой агенту за прошлый день/заданные даты, с догрузкой и пересборкой без дублей. Пробная сборка на PoC и FLOW-06; на Пилоте — поддержка выбранного запуска, источников и версий, проверка сопоставимости когорт.

Передача знаний и обязанностей

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

Типовой сценарий

Показать рабочий цикл. Специалист сопровождения показывает инженерную работу: настройку и диагностику агентов, разбор журналов, MR и замечаний для улучшения агента. На PoC демонстрация может включать ведение калибровочной задачи; на Пилоте постановку, рабочий диалог и ревью ведёт команда продукта. Специалист клиента наблюдает, задаёт вопросы и пробует отдельные действия.
Поработать вместе. Специалист клиента выполняет действия на реальных задачах с помощью коллеги: устраняет техническую остановку, исследует ошибочную обработку замечания, изучает журнал, меняет навык. Вместе проверяют результат и дополняют инструкции.
Передать регулярную работу. Специалист клиента берёт на себя освоенные обязанности. Оба отмечают, что именно перешло к нему и с какого момента. При необходимости обновляют адресатов уведомлений, доступы и инструкции.
Продолжать поддержку. Специалист клиента обращается за помощью в сложных случаях; вместе разбирают новые ситуации. Разовая помощь специалиста сопровождения не означает автоматического возврата обязанностей.

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

Обучение и передача могут начаться на PoC или после старта Пилота и продолжаться до его окончания. Сопровождение может сохраняться и далее. Самостоятельность клиента и завершение передачи не являются критериями успешного завершения Пилота.

Что записывать в журнал

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

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

Шаблон журнала · Пример фактической передачи · Матрица ролей