Промпт-инжиниринг для системного аналитика: паттерны промптов для требований, ТЗ и документации

Промпт-инжиниринг — это не магия и не «просто хорошо попросить модель». Это инженерная дисциплина: вы собираете промпт из компонентов, каждый из которых отвечает за конкретное свойство результата. Пропустили один слой — модель додумает сама (читай: сгаллюцинирует). Добавили лишний — потеряли точность. Разберёмся, как это работает в контексте системного анализа: требования, ТЗ, документация.

Если вы ещё не пробовали применять LLM в повседневной работе аналитика — начните с общего обзора AI в системном анализе: как собирать и формализовать требования. Там — pipeline целиком. Здесь — только про промпты: как их конструировать, чтобы результат был не «вроде нормально», а ровно то, что нужно для ТЗ.

Что такое промпт-инжиниринг (на самом деле)

Промпт-инжиниринг — дисциплина проектирования инструкций для LLM, нацеленная на получение предсказуемых, структурированных и свободных от галлюцинаций результатов.

Промпт — текстовый запрос к языковой модели, содержащий инструкцию, контекст и ограничения. В контексте системного анализа промпт — это мини-ТЗ для модели: что анализировать, в каком формате выдать и чего не делать ни под каким видом.

Аналогия прямая. Вы даёте разработчику мутное описание задачи — получаете реализацию, которая решает не ту проблему. LLM ведёт себя точно так же, только она не переспросит (обычно). Всё, что вы не сказали явно, модель заполнит наиболее вероятным — и не обязательно правильным — вариантом.

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

Анатомия промпта аналитика

Хороший промпт собирается из семи слоёв. Пропускать можно, но каждый пропущенный слой — это степень свободы, которую вы отдаёте модели. А модель, напомню, не аналитик. Она — вероятностный автомат, который предсказывает следующее слово.

graph TD
  ROLE["1. РОЛЬ<br/>Кто ты?<br/>«Ты — системный аналитик<br/>в банковской сфере»"]
  CONTEXT["2. КОНТЕКСТ<br/>Что происходит?<br/>«Мы проектируем<br/>платёжный шлюз»"]
  TASK["3. ЗАДАЧА<br/>Что сделать?<br/>«Выдели функциональные<br/>требования из текста»"]
  FORMAT["4. ФОРМАТ<br/>В каком виде?<br/>«JSON с полями:<br/>id, name, actor...»"]
  EXAMPLES["5. ПРИМЕРЫ<br/>Как должно выглядеть?<br/>«Пример: FR-001...»"]
  CONSTRAINTS["6. ОГРАНИЧЕНИЯ<br/>Что нельзя?<br/>«Не выдумывай,<br/>ставь ТРЕБУЕТ УТОЧНЕНИЯ»"]
  OUTPUT["7. ВЫВОД<br/>Результат работы модели"]

  ROLE --> CONTEXT
  CONTEXT --> TASK
  TASK --> FORMAT
  FORMAT --> EXAMPLES
  EXAMPLES --> CONSTRAINTS
  CONSTRAINTS --> OUTPUT

  style ROLE fill:#7b68ee,stroke:#5a4db2,color:#fff
  style CONTEXT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style TASK fill:#f0a500,stroke:#c88400,color:#fff
  style FORMAT fill:#50c878,stroke:#3a9a5c,color:#fff
  style EXAMPLES fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style CONSTRAINTS fill:#f0a500,stroke:#c88400,color:#fff
  style OUTPUT fill:#50c878,stroke:#3a9a5c,color:#fff

Схема — конвейер. На входе роль (фиолетовый) задаёт точку зрения модели: аналитик из финтеха будет мыслить категориями compliance и аудит-логов, аналитик из e-commerce — категориями корзины и промокодов. Контекст (синий) сужает пространство: не «спроектируй систему», а «мы делаем платёжный шлюз к существующему core-banking». Задача (жёлтый) формулирует конкретное действие. Формат (зелёный) фиксирует структуру выдачи. Примеры (синий) калибруют стиль и глубину. Ограничения (жёлтый) — страховка от галлюцинаций. Вывод (зелёный) — то, что вы получаете.

Семь слоёв не означают, что каждый промпт должен быть на три страницы. Для простых задач (вроде «переведи этот список требований в Gherkin») хватит трёх. Но если вы генерируете ТЗ на модуль — семь слоёв окупаются: модель не додумывает то, о чём вы забыли.

Паттерн #1: Zero-shot — когда модель уже знает

Zero-shot — это промпт без примеров. Вы просто говорите, что нужно сделать, и модель делает. Работает для задач, паттерн которых хорошо представлен в обучающих данных: перевод в Gherkin, рерайт текста, выделение сущностей.

1
Ниже — описание функции на естественном языке. Переведи
2
его в формат Gherkin (Given / When / Then). Сгенерируй
3
ровно столько сценариев, сколько логически вытекает
4
из описания. Не добавляй сценарии, не упомянутые в тексте.
5

6
Описание:
7
Кнопка «Оформить заказ» доступна, только если корзина
8
не пуста и пользователь авторизован. Если корзина пуста —
9
кнопка заблокирована и отображается подсказка.
10
Если пользователь не авторизован — кнопка ведёт на страницу
11
логина.

Модель выдаст 2–3 сценария Given/When/Then. Без примеров. Потому что Gherkin — это стандартный формат, и LLM «видела» его миллионы раз.

Zero-shot — ваш вариант по умолчанию. Начинайте всегда с него. Если результат кривой — подключайте примеры (Few-shot).

Паттерн #2: Few-shot — показываем, как надо

Few-shot добавляет в промпт 2–3 примера того, что вы хотите получить. Это самый мощный и, как ни странно, самый недооценённый паттерн в работе аналитика.

Пример: превращаем сырые заметки со встречи в структурированные User Story.

1
Преврати заметки со встречи в User Story по шаблону:
2
«Как <роль>, я хочу <действие>, чтобы <ценность>».
3

4
Пример 1:
5
Заметка: «Менеджер должен видеть отчёт по продажам за период»
6
→ Как менеджер по продажам, я хочу видеть отчёт по продажам
7
за выбранный период, чтобы оценивать эффективность команды
8
и корректировать план.
9

10
Пример 2:
11
Заметка: «Клиент хочет сохранять товары в избранное»
12
→ Как авторизованный покупатель, я хочу добавлять товары
13
в избранное, чтобы вернуться к ним позже без повторного поиска.
14

15
Важно:
16
— Ценность формулируй с точки зрения роли, а не системы.
17
— Если заметка не содержит явной роли — определи её
18
  по контексту и укажи в скобках «(предположительно)».
19
— Не придумывай действия, которых нет в заметке.
20

21
Заметки:
22
1. Админ должен мочь менять цену товара без удаления
23
   и пересоздания карточки.
24
2. После оформления заказа клиенту должно приходить письмо
25
   с составом заказа и трек-номером.
26
3. Поддержка хочет видеть историю заказов клиента,
27
   когда тот обращается.

Два примера калибруют модель: она понимает и уровень детализации (лаконично, но с конкретной ценностью), и стиль (инфинитив «видеть», а не «просматривать»). Третий промпт в том же стиле она напишет сама — потому что вы задали паттерн.

Примечательно, что few-shot «лечит» многие проблемы с форматом выдачи. Без примеров модель может выдать JSON вместо таблицы, или наоборот. С двумя примерами — формат фиксирован.

Паттерн #3: Role-prompting — назначаем роль и доменный контекст

Role-prompting задаёт точку зрения, с которой модель «думает». Для аналитика это критично, потому что требования из одного и того же текста в e-commerce и в банкинге выглядят по-разному.

1
Ты — ведущий системный аналитик в финтех-компании.
2
Твой проект — платёжный шлюз для интернет-эквайринга.
3
Ты работаешь в домене, где действуют:
4
— Стандарт PCI DSS (безопасность платёжных данных).
5
— Регуляторные требования ЦБ (отчётность, аудит).
6
— Соглашение об уровне обслуживания (SLA):
7
  доступность 99.95%, время ответа API ≤ 200 мс
8
  для 95-го перцентиля.
9

10
На основе технического описания ниже выдели
11
нефункциональные требования. Особое внимание обрати
12
на безопасность транзакций, отказоустойчивость
13
и аудит-логи.

Роль делает две вещи. Во-первых, подключает доменную терминологию: модель будет говорить «эквайринг» и «3-D Secure», а не «оплата» и «дополнительная проверка». Во-вторых, задаёт приоритеты: аналитик из финтеха обратит внимание на compliance, аналитик из e-commerce — на воронку конверсии.

Комбинируйте role-prompting с few-shot — это даёт самый стабильный результат. Роль задаёт контекст, примеры — формат.

Паттерн #4: Chain-of-Thought — рассуждаем по шагам

Chain-of-Thought (CoT) заставляет модель проговаривать промежуточные шаги, прежде чем дать финальный ответ. Для аналитика это полезно в двух сценариях: анализ trade-off архитектурных решений и проверка требований на полноту.

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

1
Ты — системный аналитик. Оцени компромисс между двумя
2
архитектурными вариантами для сервиса нотификаций.
3

4
Вариант A: Синхронная отправка — запрос к внешнему сервису
5
SMS/Email во время обработки заказа.
6
Вариант B: Асинхронная отправка через очередь сообщений
7
(Kafka).
8

9
Рассуждай по шагам:
10

11
Шаг 1. Опиши, что происходит в каждом варианте при пиковой
12
нагрузке (100 заказов/сек).
13
Шаг 2. Опиши, что происходит при отказе внешнего сервиса
14
SMS/Email в каждом варианте.
15
Шаг 3. Сравни задержку, которую ощущает пользователь.
16
Шаг 4. Сравни сложность разработки и эксплуатации.
17
Шаг 5. На основе шагов 1–4 дай рекомендацию и укажи,
18
при каком сценарии твоя рекомендация меняется на
19
противоположную.

Важный нюанс: CoT работает только если вы явно перечислили шаги. Просто добавить «подумай шаг за шагом» в конце промпта — работает хуже, чем явная нумерация. Исключение — модели с нативной поддержкой reasoning (Claude 3.5+ с extended thinking, o1), где внутренняя цепочка рассуждений происходит автоматически.

Паттерн #5: Structured Output — получаем JSON или таблицу по схеме

Самый практичный паттерн для аналитика. Вы описываете схему вывода — модель заполняет её. Если вам нужны требования для импорта в Jira через API — просите JSON. Если вам нужна таблица для Confluence — просите Markdown-таблицу.

1
На основе описания фичи ниже составь спецификацию API
2
в формате JSON по следующей схеме:
3

4
{
5
  "endpoint": "строка, метод и путь",
6
  "method": "GET | POST | PUT | PATCH | DELETE",
7
  "description": "строка, что делает ручка",
8
  "request": {
9
    "headers": [{"name": "...", "required": true/false,
10
      "description": "..."}],
11
    "path_params": [{"name": "...", "type": "...",
12
      "required": true/false, "description": "..."}],
13
    "query_params": [{"name": "...", "type": "...",
14
      "required": true/false, "description": "..."}],
15
    "body": "JSON-схема или null"
16
  },
17
  "response": {
18
    "200": "описание успешного ответа",
19
    "4xx": ["перечень возможных ошибок"],
20
    "5xx": ["перечень возможных ошибок"]
21
  }
22
}
23

24
Опиши все эндпоинты, которые вытекают из описания.
25
Ошибки 4xx/5xx указывай только те, что специфичны
26
для этой ручки (не пиши «500 Internal Server Error»
27
для каждой).
28

29
Описание фичи:
30
[текст]

Structured Output решает главную боль: вы тратите ноль времени на переформатирование. Модель выдала JSON — вы скормили его скрипту, который создаёт задачи в Jira. Или вставили Markdown-таблицу в Confluence и пошли пить кофе. А не «сейчас я полчаса буду перебивать это в нормальный вид».

Кстати, если вы пишете ТЗ — загляните в разбор структуры ТЗ: шаблоны и частые ошибки. Structured Output отлично ложится на заполнение разделов ТЗ по шаблону: модель заполняет секции, вы верифицируете.

Дерево решений: какой паттерн когда применять

Аналитику не нужны все пять паттернов одновременно. Нужен situational awareness — понимание, что включить в промпт под конкретную задачу.

graph TD
  START["Задача для LLM"]
  SIMPLE{"Модель уже знает паттерн?"}
  ZS["Zero-shot: простой промпт без примеров"]
  EXAMPLE_EXIST{"Есть примеры требований?"}
  FS["Few-shot: 2-3 примера в промпте"]
  REASONING{"Нужно рассуждение по шагам?"}
  COT["Chain-of-Thought: давай подумаем по шагам"]
  STRUCT{"Нужен фиксированный формат вывода?"}
  SO["Structured Output: JSON или таблица по схеме"]
  ROLE["Role-prompting: Ты аналитик из финтеха"]

  START --> SIMPLE
  SIMPLE -->|Да| ZS
  SIMPLE -->|Нет| EXAMPLE_EXIST
  EXAMPLE_EXIST -->|Да| FS
  EXAMPLE_EXIST -->|Нет| ROLE
  ROLE --> REASONING
  FS --> REASONING
  ZS --> STRUCT
  REASONING -->|Да| COT
  REASONING -->|Нет| STRUCT
  COT --> STRUCT
  STRUCT -->|Да| SO
  STRUCT -->|Нет| ZS

  style START fill:#e0e0e0,stroke:#999,color:#333
  style SIMPLE fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style ZS fill:#50c878,stroke:#3a9a5c,color:#fff
  style FS fill:#50c878,stroke:#3a9a5c,color:#fff
  style COT fill:#50c878,stroke:#3a9a5c,color:#fff
  style SO fill:#50c878,stroke:#3a9a5c,color:#fff
  style ROLE fill:#7b68ee,stroke:#5a4db2,color:#fff
  style EXAMPLE_EXIST fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style REASONING fill:#f0a500,stroke:#c88400,color:#fff
  style STRUCT fill:#4a90d9,stroke:#2c5f8a,color:#fff

Диаграмма — шпаргалка. Стартуете с серого узла «Задача». Первый вопрос — знает ли модель паттерн? Если задача типовая (вроде «переведи в Gherkin») — идите по левой ветке: Zero-shot, и если нужна структура — добавляйте Structured Output. Если задача специфична для вашего домена — правая ветка: задаёте роль, добавляете примеры (если есть), подключаете CoT для сложного анализа.

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

Борьба с галлюцинациями: как заставить модель признаваться в незнании

Главная боль LLM для аналитика — модель склонна выдумывать требования. Не со зла. Просто её архитектурная задача — предсказать наиболее вероятное продолжение, а не сказать «я не знаю». Три приёма, которые снижают галлюцинации радикально:

Приём 1. Явный запрет на выдумывание. Не «будь аккуратнее» — модель не понимает намёков. Пишите прямо:

1
Если в тексте недостаточно информации для какого-либо
2
пункта — напиши «[ТРЕБУЕТ УТОЧНЕНИЯ]».
3
Не придумывай недостающие данные.

Работает. Модель начинает ставить маркер неопределённости в 60–70% случаев, где раньше додумывала.

Приём 2. Тернарный статус. Делите вывод на три категории: «Явно указано», «Выведено из контекста», «Требует уточнения». Модель лучше классифицирует собственную неуверенность, когда ей дают формальные категории, а не просят «быть честной».

1
Для каждого требования укажи статус:
2
— ЯВНОЕ: требование прямо сформулировано в тексте.
3
— КОСВЕННОЕ: выведено из контекста [ТРЕБУЕТ ПОДТВЕРЖДЕНИЯ].
4
— ПРОБЕЛ: данных недостаточно [ТРЕБУЕТ УТОЧНЕНИЯ].

Приём 3. Перекрёстная проверка. Прогоните один и тот же текст через два разных промпта (или две разные модели) и сравните списки требований. Всё, что совпало, — с высокой вероятностью действительно есть в тексте. Всё, что различается, — кандидат на галлюцинацию. Звучит как перестраховка? Возможно. Но когда вы генерируете требования для системы с бюджетом разработки в несколько миллионов — 20 минут на перекрёстную проверку дешевле, чем переписывание модуля из-за выдуманного требования.

Таблица: шпаргалка по паттернам

Паттерн	Что делает	Когда применять	Пример задачи аналитика
Zero-shot	Промпт без примеров	Типовые форматы (Gherkin, рерайт, перевод терминов)	«Переведи требования в формат Given/When/Then»
Few-shot	2–3 примера в промпте	Специфичный формат или стиль, нестандартный шаблон	«Сгенерируй User Story как в примере»
Role-prompting	Назначение роли и домена	Нужна доменная терминология и приоритеты	«Ты — аналитик в страховании, выдели НФТ»
Chain-of-Thought	Пошаговое рассуждение	Анализ trade-off, поиск противоречий, сложный вывод	«Сравни два архитектурных варианта по шагам»
Structured Output	Фиксированная схема вывода	Результат нужен для импорта в Jira, Confluence, API	«Выдай спецификацию эндпоинта в JSON по схеме»

Каждый следующий паттерн не заменяет предыдущий, а накладывается. Самые стабильные результаты — когда в одном промпте собраны роль, few-shot-примеры и structured output. Да, промпт получается длинным. Но он работает с первого раза, а не с пятого.

Что НЕ работает (или работает хуже, чем обещают)

Огромный системный промпт на 5 страниц. Звучит солидно. На практике модель «забывает» середину длинного промпта (эффект lost-in-the-middle). Правило: системный промпт — до 500 слов. Всё, что длиннее, лучше разбить на цепочку последовательных промптов.

«Ты — эксперт мирового уровня». Пафосные роли не улучшают качество. Модель не становится умнее от того, что вы назвали её «экспертом мирового уровня». А вот «Ты — системный аналитик в финтехе, знаешь PCI DSS и 115-ФЗ» — работает, потому что задаёт конкретный контекст.

«Будь креативным». Креативность LLM в контексте требований — это галлюцинации. Вам не нужна креативность. Вам нужна точность. Поэтому «не выдумывай» должно быть в каждом промпте к требованиям.

Один универсальный промпт для всего. Не работает по определению. Промпт для извлечения ФТ из переписки не подходит для генерации ТЗ, и наоборот. Коллекция из 5–7 отлаженных промптов под конкретные задачи даст больше, чем попытка написать один «супер-промпт».

Заключение

Промпт-инжиниринг не делает из аналитика промпт-инженера. Он делает из аналитика — более эффективного аналитика. Разница в том, что вы перестаёте гадать, почему модель выдала ерунду, и начинаете собирать промпт как спецификацию: слой за слоем, от роли до формата вывода.

Пять паттернов покрывают 90% задач системного аналитика. Zero-shot для типовых операций, few-shot для калибровки формата, role-prompting для доменного контекста, CoT для анализа и structured output для машиночитаемого результата. Комбинируйте — и промпт перестанет быть лотереей.

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

P.S. Если вы дочитали до этого места и подумали «ну, zero-shot’ом я и так пользуюсь» — попробуйте на следующей задаче собрать промпт из четырёх слоёв: роль + контекст + few-shot + structured output. Разница в качестве выдачи вас удивит. А потом вы удивитесь, что раньше писали промпты в одну строку и называли это «работой с AI».