«Промпт как код» — организация промптов с той же дисциплиной, что и обычный код. Практика: 1) ВЕРСИОНИРОВАНИЕ (ключевое): — Храните промпты под контролем версий (как код). Зачем: видеть историю изменений, понимать, ЧТО изменилось между «работало» и «сломалось», откатываться к рабочей версии, сравнивать варианты. — Промпт влияет на поведение приложения так же, как код, поэтому его изменения должны быть отслеживаемыми и обратимыми, а не «поправил в проде и забыл». 2) ОТДЕЛЯЙТЕ промпты от логики: — Не разбрасывайте промпты сырыми строками по всему коду. Держите их в явном, организованном виде (отдельные файлы/константы/шаблоны), где их легко найти, прочитать, поменять, протестировать. — Плюсы: читаемость, поддержка, возможность менять промпт без правки логики и наоборот, проще тестировать промпты отдельно. 3) ШАБЛОНЫ с подстановкой (параметризация): — Продакшн-промпт обычно = ШАБЛОН + подставляемые переменные (данные пользователя, контекст из RAG, параметры). Например: «Классифицируй отзыв: {текст_отзыва}. Категории: {категории}». — Это как параметризованная функция: фиксированная структура + меняющиеся входы. — ВАЖНО (безопасность): подстановка пользовательских данных в промпт — потенциальная точка ИНЪЕКЦИИ промпта (из LLMOps): пользователь может вставить текст, пытающийся переопределить инструкции. Относитесь к подставляемым пользовательским данным как к недоверенным, разделяйте инструкции и данные, не давайте пользовательскому вводу управлять поведением. (Подробнее — в уроке про безопасность/надёжность.) 4) ДИСЦИПЛИНА ИЗМЕНЕНИЙ (как код, из LLMOps): — Меняйте промпт по ОДНОМУ изменению за раз (иначе не поймёте, что помогло/сломало). — Тестируйте ПЕРЕД выкатом (на наборе примеров — тема модуля про тестирование). — Умейте откатиться (версионирование это даёт). — Не правьте промпт вслепую прямо в проде — изменение влияет на все запросы. 5) ДОКУМЕНТИРУЙТЕ намерение: — Полезно фиксировать, ЗАЧЕМ промпт такой (какое поведение он должен давать, почему добавлены определённые инструкции). Промпты бывают неочевидны — комментарий/описание помогает поддержке. 6) ЕДИНООБРАЗИЕ и переиспользование: — Общие части (формат вывода, роль, правила) можно выносить и переиспользовать (системные промпты — следующий модуль), чтобы не дублировать и менять в одном месте. 7) Связь с оценкой (LLMOps): версионирование + тестирование = основа управляемого улучшения промптов. Изменил → протестировал на наборе → сравнил с прошлой версией → выкатил, если лучше → при проблемах откатился. Так промпты улучшаются без незаметных регрессий. Практическое правило: относитесь к промптам как к коду — версионируйте (история, откат), держите отдельно от логики (читаемость, поддержка, тестируемость), используйте шаблоны с подстановкой (но осторожно с инъекциями пользовательских данных), меняйте дисциплинированно (по одному, с тестом перед выкатом, с возможностью отката), документируйте намерение. Это превращает промпты из хаотичных строк в управляемые, поддерживаемые артефакты. Промпт определяет поведение не меньше кода, поэтому заслуживает той же инженерной дисциплины. Без неё команды застревают в «поправили промпт — что-то сломалось, непонятно что»; с ней — промпты надёжны, изменения предсказуемы и обратимы.