«Промпт военных лет»: как писать команды для ИИ, когда цена ошибки слишком высока

Принцип «Приказ — Рапорт»

«Промпт военных лет»: как дать нейросети приказ, который будет выполнен без сбоев

В мирное время промпт — это диалог. В критических задачах — это 작전ная карта. Разбираем, как перевести общение с моделью в режим боевой готовности: структура, ограничения, верификация.

Сигнал / Шум Жёсткие рамки Самопроверка

Диалог — это роскошь. Приказ — необходимость

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

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

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

Схема структуры «боевого» промпта: роль, контекст, жесткие ограничения, формат, верификация

Пять столбов боевого промпта

1. Роль: Офицер штаба

Не «ты умный ассистент», а «Ты — старший аналитик ГРУ по радиореконnaissance. Твоя задача — извлечь координаты из шума». Роль задаёт лексикон, логику и уровень ответственности.

2. Контекст: Обстановка на секторе

Входные данные: что известно, что неизвестно, какие источники достоверны. «Исходник: перехват 14:00–14:15, частота 4.5 МГц, помехи 40%. Цель: позывные». Модель не должна гадать.

3. Ограничения: Минное поле

Чего делать НЕЛЬЗЯ строже, чем чего делать нужно. «Не придумывать позывные. Не интерполировать пропуски. Не использовать внешние знания. Если данных нет — верни NULL». Это броня от галлюцинаций.

4. Формат: Бланк рапорта

Жёсткая схема вывода: JSON Schema, Markdown-таблица, фиксированный список полей. «Вывод ТОЛЬКО валидный JSON по схеме Report_v3. Никакого поясняющего текста». Парсер не простит лишнюю запятую.

5. Верификация: Контрольный выстрел

Встроенная проверка: «Посчитай контрольную сумму ID. Если сумма нечётная — верни ERROR». Или: «Сравни результат с эталоном в теге . Расхождение > 5% — отказ». Модель проверяет себя сама.

Мирный промпт

«Напиши письмо клиенту про задержку»

Напиши вежливое письмо клиенту, что заказ задержится на пару дней. Извинись и предложи скидку. Сделай красиво и эмпатично.

Модель решит, какая скидка уместна
Тон может быть слишком неформальным
Нет гарантии структуры для CRM

Боевой промпт

FM-7: Client_Notification_Delay_v1

ROLE: Senior_Account_Manager
CONTEXT: Order_#4421 delayed 3 days (logistics). Client: VIP, contract #A99.
CONSTRAINTS: Discount=5% max. No «sorry», use «acknowledge». Tone: professional, solution-oriented. No markdown.
FORMAT: JSON {subject, body_text, discount_pct, next_update_date}
VERIFY: Check JSON valid. discount_pct <= 5. next_update_date = today+3.
EXECUTE.

Скидка жестко ограничена политикой
Тон задан терминами, не ощущением
Результат парсится без regex и молитв

Шаблон «Полевой устав» (скопируй и адаптируй)

# === FIELD MANUAL PROMPT TEMPLATE ===
# MISSION: [Краткое название задачи, напр. LEGAL_CONTRACT_REVIEW]

ROLE: [Точная специализация: Senior_Legal_Counsel / DevOps_Lead / Intel_Analyst]
AUTHORITY: [Уровень полномочий: FINAL_DECISION / DRAFT_ONLY / ADVISORY]

SITREP (CONTEXT):
  INPUT_SOURCE: [Файл / Текст / API / DB]
  RELIABILITY: [HIGH / MEDIUM / LOW / MIXED]
  KEY_ENTITIES: [Список критических сущностей: стороны договора, переменные окружения]
  BLIND_SPOTS: [Чего точно НЕТ в данных]

RULES_OF_ENGAGEMENT (CONSTRAINTS):
  FORBIDDEN: [Hallucination, Assumption, External_Knowledge, Markdown_If_Not_Asked]
  BOUNDARIES: [Scope: только раздел 4.2 / Только функция parse() / Только 2023 год]
  STYLE: [Tone: Dry_Technical / Persuasive_Legal / Minimal_Code]

OUTPUT_SPEC (FORMAT):
  SCHEMA: [JSON_Schema_Name / Markdown_Table_Columns / Plain_Text_Template]
  VALIDATION: [Regex / Checksum / Required_Fields_List]
  ENCODING: [UTF-8 / Base64 / Raw_Bytes]

SELF_CHECK (VERIFICATION):
  1. LOGIC_TEST: [Пример: IF risk_score > 8 THEN flag=CRITICAL]
  2. COMPLETENESS: [All required fields present?]
  3. CONSISTENCY: [Cross-ref dates/IDs with SITREP]
  4. FAIL_ACTION: RETURN {status: «ERROR», reason: «…»}

EXECUTE_IMMEDIATELY.

Ловушки «мирного» мышления

Ловушка «Додумает»

Надежда, что модель «поймёт контекст сама». В бою контекст — это только то, что записано в приказе. Всё остальное — вражеская дезинформация.

Ловушка «Мягкость»

Фразы «постарайся», «желательно», «если возможно». В боевых промптах только бинарная логика: ОБЯЗАТЕЛЬНО / ЗАПРЕЩЕНО / ОПЦИОНАЛНО (с дефолтом).

Ловушка «Универсальность»

Один промпт на всё. Боевой промпт заточен под одну операцию: ревью кода, извлечение сущностей, генерация SQL. Универсальность = пониженная точность.

Ловушка «Черный ящик»

Отсутствие этапа VERIFY. Если нет встроенной проверки — результат не пригоден для автоматического конвейера. Человек в цикле — это резерв, не основной режим.

Когда включать «боевой режим»

1
Автоматизация без человека в цикле.
Пайплайны, cron-задачи, вебхуки.
2
Высокая стоимость ошибки.
Финансы, юриспруденция, медицина, инфраструктура.
3
Нестабильный входной сигнал.
OCR, ASR, пользовательский ввод, парсинг чужих API.
4
Строгий контракт интеграции.
Схема БД, OpenAPI spec, формат обмена с 1С.

Правило 80/20

80% времени — разработка промпта, 20% — запуск

Мирный подход: 5 минут на промпт, часы на правку результата. Военный подход: час на проектирование FM, минуты на бесконечные прогоны с нулевым дефектом.

Инвестируй в устав, а не в правки

Главный вывод

Нейросеть не читает мысли. Она исполняет инструкции.

«Промпт военных лет» — это не магия и не инженерия промптов ради промптов. Это дисциплина передачи намерения без потерь. Роль задаёт компетенцию. Контекст — обстановку. Ограничения — безопасность. Формат — интероперабельность. Верификация — контроль качества.

Пиши приказы, а не просьбы. И тогда модель станет не «чат-ботом», а боевой единицей.