Локальный diff промптов: инструмент для проверки изменений до запуска

Промпт часто меняют незаметно: добавили одну строку, переставили ограничение, убрали пример — и модель стала отвечать иначе. В чате это легко пропустить. Через неделю никто не помнит, какая версия дала удачный результат и почему после «маленькой правки» появились выдуманные факты.

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

Что именно сравнивает инструмент

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

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

Подготовьте контрольную выборку

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

Сохраните эталон не как «идеальный текст», а как набор проверяемых признаков. У одного ответа могут быть разные удачные формулировки, но нельзя менять число, раскрывать закрытое поле или пропускать следующий шаг. Такой подход позволяет не наказывать модель за стиль и замечать действительно опасные изменения.

Запустите две версии в одинаковых условиях

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

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

Добавьте ручное решение

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

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

Безопасная структура папок

Разделите каталоги на drafts, tests и released. В drafts лежат изменяемые варианты, в tests — обезличенная выборка и результаты прогонов, в released — только версия, которую одобрил владелец процесса. Исходные рабочие документы не копируйте в тестовый набор целиком. Для контроля целостности достаточно хэша, размера и даты файла.

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

Разделяйте текстовое и смысловое изменение

Две версии могут выглядеть почти одинаково, но по-разному влиять на поведение модели. После обычного построчного diff сделайте второй проход по намерению: какое правило появилось, какое исчезло, какое поле стало обязательным. Сведите изменения в таблицу «правило → проверочный пример → результат». Если добавили запрет на догадки, нужен пример с отсутствующим фактом; если поменяли тон, нужен пример с конфликтующим требованием. Не объявляйте правку безопасной только потому, что количество строк уменьшилось. Минимальный порог выпуска — отсутствие новых ошибок в стоп-условиях и понятная причина каждого изменения.

Когда обновление можно выпустить

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

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

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

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