Часть 4. Расширение и масштабирование · Глава 12

Prompt Ops — Промпты как командный артефакт

Цели раздела

4 пункта

К концу раздела вы сможете:

Понять жизненный цикл промпта как командного артефакта (Draft → Review → Prod).
Организовать Prompt Registry, ревью и golden dataset для воспроизводимого качества.
Внедрить минимальный контур Prompt Ops Lite для команды из 1–3 человек.
Связать Prompt DoD, метрики (IP, регрессии) и CI/CD с практикой из глав 9–10.

Не обязательно сразу Git и CI: начните с общей Prompt Library и статусов Draft/Prod — полный реестр добавляйте, когда активных промптов станет больше пяти.

История внедрения (пример)

Команда из трёх QA в продуктовой компании начала с общей страницы в Notion: название задачи, текст промпта, «кто проверил». Через два месяца стало тесно: версии путались («у Маши работает, у Пети — нет»), после смены модели в Groq один шаблон на анализ логов начал выдавать лишние поля — никто не заметил неделю.

Переход: 10 активных промптов перенесли в Git (prompts/active/), к каждому — owner и статус Draft/Prod. Ревью заняло 15 минут на промпт (коллега + чек-лист из гл. 10). Golden dataset из 12 примеров на два критичных шаблона — регрессия после правок. Итог за квартал: меньше «магических» промптов в личных чатах, IP по шаблону «тест-кейсы из AC» вырос с ~50% до ~75% после уточнения Constraints.

Это синтетический, но типичный сценарий: старт с уровня 0–1 из раздела «Prompt Ops Lite» ниже, Git и CI — когда промптов и людей становится больше.

Связь с Главой 11

Связь с предыдущей главой

Если вы уже прошли Глава 11 — Встраивание в QA-процесс:

В Главе 11 — зрелость внедрения, личная библиотека шаблонов и командная Prompt Library; готовый шаблон личного Prompt Book лежит в Приложении C. Глава 12 переводит практику на командный уровень (реестр, ревью, CI). DoD из гл. 11 становится частью более широкого quality gate (контрольной точки: явные критерии «можно ли выпускать промпт / результат в работу»).

Артефакт из гл. 11	В этой главе
Prompt Book (markdown)	Становится `prompts/active/` в Prompt Registry
DoD LLM-артефакта (5 пунктов)	Расширяется до Prompt DoD, добавляются golden dataset и peer review
Параметры temperature/top_p (Приложение D)	В карточке промпта — ссылка на Приложение D
GitLab CI пример (Гл.11)	Рядом с GitHub Actions — эквивалентный pipeline для другого стека

Prompt Ops Lite: с чего начать, если вас 1–3 человека

Полноценный реестр, YAML и CI с первого дня не обязательны. Достаточно «минимально жизнеспособного» контура — иначе практика кажется недостижимой.

Уровень 0: Личный Prompt Book (Один человек)

Markdown-файл или страница в Notion/Obsidian: промпты в формате из Приложения C. Добавляйте запись, если промпт использовали ≥2 раз и результат стабильно хороший.

Уже лучше, чем «всё в голове и в истории чата».

Начинайте с уровня 0 и переходите на следующий, когда текущий уровень становится тесен — не наоборот.

Почему «Prompt Book в Notion» недостаточно

Проблема «Prompt Chaos»: промпты в личных заметках, чатах; нет воспроизводимости («у Пети работает, у Васи нет»); после обновления модели промпт «сломался» — никто не заметил; нет явного владельца и ответственности за актуальность.

Prompt Ops vs личные заметки: версионирование (системное, с change log), тестирование (regression, golden datasets), ревью (обязательный peer review), владелец (явный maintainer), метрики (количественные), rollout (controlled deployment, rollback), compliance (policy, DoD, audit trail).

Жизненный цикл промпта

Нажмите на этап — увидите критерий и владельца

Жизненный цикл: Author → Reviewer → QA Engineer → Maintainer

Структура Prompt Registry

prompt-library/Prompt Registry — корень репозитория

README.md— Описание репозитория, правила, онбординг

.github/workflows/prompt-ci.yml— CI: валидация, тесты по golden dataset

RTCCO-template
review-checklist
versioning-convention

prompt.md

metadata.yaml

golden-dataset.json

test-results/

Раскройте папку, чтобы увидеть содержимое. Версии промптов (v1.0, v2.3) хранятся в подпапках по назначению.

Пример карточки промпта в свободной форме (Markdown)

Ниже — человекочитаемый шаблон для Confluence / Notion / Markdown; поля можно перенести в YAML из подраздела про YAML frontmatter.

Markdown

# [Название промпта]

**ID:** QA-TC-003  
**Версия:** 2.1  
**Владелец / автор:** @username  
**Последнее обновление:** 2026-05-13  
**Модели:** (на чём проверено)  
**Temperature / max_tokens:** (значения)  

## Задача
Кратко: для чего промпт (например генерация REST-кейсов).

## Промпт
[полный текст по RTCCO]

## Ограничения и известные сбои
- Пример: не работает, если требований больше N токенов — нужна декомпозиция

## Качество (IP / заметки)
- Проект X, май 2026: IP ≈ 83%

Чек-лист ревью промпта перед попаданием в командный реестр

Карточка промпта (YAML frontmatter)

metadata.yaml / YAML frontmatter

Нажмите на группу, чтобы развернуть или свернуть поля

prompt_id
name
status (draft | review | test | prod | deprecated)

Обязательные поля карточки

Идентификация

prompt_id
name
status (draft | review | test | prod | deprecated)

Владение

ownership: author, maintainer, reviewers

Версионирование

versioning: current, created, modified, changelog

Метрики

usage_count
avg_quality_score
hallucination_rate
tokens
cost_per_run

Quality gates

min_quality_score
max_hallucination_rate
test_pass_rate

Контекст генерации

model
temperature
max_tokens (см. Приложение D)

Контент

content (RTCCO-структура)

Workflow ревью промпта (5 этапов)

В заголовке — этап; нажмите, чтобы открыть описание

Описание

Написал промпт, протестировал на ≥5 примерах, заполнил карточку, создал PR

Автор: написал промпт, протестировал на ≥5 примерах, заполнил карточку, создал PR.
Авто-проверки (CI): валидация формата, запуск на golden dataset, проверка на PII, lint промпта.
Peer Review: промпт решает задачу, ограничения полные, формат вывода понятен, примеры репрезентативны.
Approver (QA Lead): не дублирует существующий, соответствует Prompt Policy, одобряет мёрж.
После мёржа: промпт доступен команде, метрики собираются, owner назначен.

Testing промптов

Golden dataset — JSON: prompt_id, test_cases (id, input, expected_behavior, evaluation_criteria)

Нажмите на тип теста — увидите пояснение

Типы: Unit test (1–3 типовых кейса), Regression test (golden dataset 10–50 кейсов), Edge case test (невалидные/пустые входы), Adversarial test (устойчивость к injection), A/B test (сравнение с предыдущей версией). Golden dataset — JSON с prompt_id, test_cases (id, input, expected_behavior, evaluation_criteria).

CI/CD интеграция

GitHub Actions (пример)

Нажмите на шаг — увидите пояснение

Аналог для GitLab CI — в разделе «Интеграция в CI/CD пайплайны» (Встраивание в QA-процесс).

Пример GitHub Actions: при push/PR в prompts/** — detect changed prompts, run regression tests по golden dataset (порог 0.95), evaluate quality metrics, block if failed. Аналог для GitLab CI см. в Главе 11.

Drift Detection

Дрейф (drift) здесь — постепенное снижение качества или изменение поведения промпта после смены модели, входных данных или накопления «шума» в шаблоне; его ловят регулярным прогоном на golden dataset.