Как вести журнал работы с ИИ и превращать удачные тесты в процесс

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

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

Решите, что вообще стоит записывать

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

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

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

Сохраните семь вещей после запуска

1. Задача и пользователь результата. Что решалось и кто применяет итог.
2. Тип входа. Не сам закрытый файл, а безопасное описание: обезличенная таблица, утверждённый FAQ, тестовый код, публичный документ.
3. Инструмент и режим. Модель, версия или рабочее окружение, если они известны.
4. Инструкция. Шаблон запроса и ключевые ограничения, без секретов и личных данных.
5. Проверка. Какие факты, тесты, форматы и границы были сверены человеком.
6. Результат. Принят, исправлен, отклонён или передан на эскалацию.
7. Урок. Одна короткая причина успеха или сбоя, которую можно превратить в правило.

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

Не храните в журнале то, что опасно хранить

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

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

Превратите ошибки в тесты

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

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

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

Смотрите на результат раз в неделю

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

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

Если модель меняется, не переписывайте весь журнал. Добавьте новую запись с тем же набором тестов и сравните результат. Карточки GPT-5 и DeepSeek V4 могут помочь зафиксировать кандидатов для пилота, но журнал нужен именно для оценки на вашей задаче, а не для рейтинга по названию.

Пример короткой записи

Задача: черновик ответа на вопрос о доставке.
Вход: обезличенное сообщение и актуальный FAQ.
Ограничение: не называть срок, если не указан город.
Проверка: оператор сверил факты и тон.
Итог: принят после замены одной формулировки.
Урок: добавить в шаблон отдельный вопрос о городе.

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

Разделите журнал и библиотеку шаблонов

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

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

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

Чек-лист

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

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