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