TL;DR

В прошлой статье я запустил GigaChat под Roo Code и погонял на задачах аналитика. Результаты в сравнении с Qwen оказались так себе. Улучшим их.

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

Проблема

Типичный запрос к LLM:

Проанализируй интервью и создай документ требований

Типичный результат: поверхностный анализ на 2 страницы, вода и галлюцинации.

Я решил разобраться, можно ли систематически улучшить качество вывода. Взял простое интервью с заказчиком:

Клиент:
- нужно сделать CRM
- на каждое физлицо есть папка, где хранятся документы, в том числе с ПД
- из этих физлиц нужно формировать реестр (фильтрация, сортировка, выборка по атрибутам)
- у каждого ФЛ должен быть личный кабинет на сайте организации (НКО)

И начал итеративно дорабатывать промт, фиксируя результаты.

Метод оценки

Для каждой итерации оценивал вывод по чек-листу:

Максимум — 10 баллов.

Итерация 0: Базовый промт

Проанализируй интервью из файла interview.txt и создай 
структурированный документ requirements.md со следующей структурой:

1. Stakeholders (роли пользователей)
2. Текущая ситуация (AS-IS)
3. Функциональные требования (по категориям)
4. Нефункциональные требования
5. Ограничения
6. Вопросы для уточнения

Формат: Markdown с четкой иерархией

Результат

## 2. Текущая Ситуация (AS-IS)
В настоящее время данные о физических лицах хранятся 
в отдельных папках...

## 3. Функциональные Требования
- Управление данными: хранение документов и персональных данных.
- Личный Кабинет: доступ к информации для каждого физического лица.

Проблемы

• AS-IS в 2 предложения — бесполезен

• Функциональные требования — просто слова из интервью без структуры

• Вопросы размытые: «Какие дополнительные функции могут потребоваться?»

• Безопасность попала в функциональные требования (это NFR)

Оценка: 4/10

Итерация 1: Добавляем структуру и минимумы

Гипотеза

Модель выдаёт поверхностный результат, потому что промт не задаёт ожидания по глубине.

Изменения

### 1. Stakeholders (роли пользователей)
- Выдели ВСЕ роли, включая неявно упомянутые 
  (кто будет администрировать? кто просматривать данные?)
- Для каждой роли укажи: название, основные задачи, уровень доступа

### 2. Текущая ситуация (AS-IS)
- Опиши текущий процесс пошагово
- Укажи проблемы/боли текущего подхода
- Минимум 5 пунктов

### 3. Функциональные требования
- Сгруппируй по подсистемам (минимум 3 группы)
- В каждой группе — минимум 3 конкретных требования
- Формулируй как: "Система должна позволять [роль] [действие] [объект]"
- НЕ включай сюда безопасность, производительность, масштабируемость

Результат

AS-IS вырос до 5 пунктов с конкретными проблемами. Требования структурированы по подсистемам. Появился формат «Система должна позволять...».

Оценка: 7/10 (+3)

Итерация 2: Добавляем антипаттерны

Новая проблема

Модель галлюцинирует:

### Ограничения
- Использование облачных сервисов запрещено
- База данных должна размещаться на выделенных серверах

Этого нет в интервью. Модель «додумала».

Изменения

## Антипаттерны (НЕ делай):
- Не придумывай технические ограничения (облако/on-premise, стек), 
  если они не упомянуты явно
- Не добавляй роли, которые не упомянуты (служба поддержки, модераторы)
- Не задавай вопросы про функции без намёков в интервью (мультиязычность)
- Все предположения помечай как [предположение]

Результат

Галлюцинации исчезли. Там, где модель не уверена, появились пометки [предположение].

Оценка: 7.5/10 (+0.5)

Итерация 3: Маркировка уверенности и источники

Новая проблема

Непонятно, какие требования взяты из интервью, а какие выведены логически.

Изменения

## Правила извлечения

ЯВНЫЕ требования (? уверенность 100%):
- "Нужно чтобы...", "Система должна...", "Обязательно..."

ПОДРАЗУМЕВАЕМЫЕ (? уверенность 60-80%):
- "Сейчас приходится..." → требование автоматизации
- "ПД", "персональные данные" → требования 152-ФЗ

ПРЕДПОЛАГАЕМЫЕ (❔ уверенность 30-50%):
- Стандартные практики отрасли
- Логические следствия из контекста

Для каждого требования указывай:
- Источник: "[цитата из интервью]"
- Уверенность: ?/?/❔

Результат

- **FR-003**: Система должна позволять администратору 
  формировать реестры с фильтрацией и сортировкой
  - Источник: "из этих физлиц нужно формировать реестр 
    (фильтрация, сортировка, выборка по атрибутам)"
  - Приоритет: Must
  - Уверенность: ? Явное

- **NFR-S-001**: Система должна обеспечивать защиту ПД 
  в соответствии с 152-ФЗ
  - Источник: "в том числе с ПД"
  - Уверенность: ? Выведено (80%)

Теперь видно происхождение каждого требования.

Оценка: 8/10 (+0.5)

Итерация 4: Валидационный чек-лист

Новая проблема

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

Изменения

## Валидация перед выводом

Проверь чек-лист:
- [ ] AS-IS содержит минимум 5 пунктов
- [ ] AS-IS описывает ТЕКУЩЕЕ состояние, не требования
- [ ] Каждая подсистема содержит минимум 3 требования
- [ ] Все предположения имеют % уверенности И основание
- [ ] Вопросы НЕ содержат технических терминов (SQL, API)
- [ ] Заданы вопросы про: типы документов, объёмы данных, действия в ЛК
- [ ] Словарь содержит ВСЕ аббревиатуры из интервью

Если пункт не выполнен — исправь перед выводом.

Результат

Модель стала выдавать более полные результаты. Словарь содержит все термины (CRM, ФЛ, ПД, НКО). Вопросы конкретные и без технического жаргона.

Оценка: 8.5/10 (+0.5)

Итоговый промт

Ты эксперт по системному анализу и извлечению требований из интервью.

ЗАДАЧА: Проанализировать interview.txt и создать requirements.md.

КРИТИЧЕСКИ ВАЖНО:
- Сохранять оригинальные формулировки заказчика
- Извлекать явные и подразумеваемые требования
- Помечать степень уверенности для неявных требований
- НЕ додумывать — выносить в вопросы

==================================================
ФАЗА 1: ПЕРВИЧНЫЙ АНАЛИЗ
==================================================

Извлеки из интервью:

1. АКТОРЫ: прямые упоминания ролей, косвенные указания ("мы делаем")
2. ПРОБЛЕМЫ: жалобы, слова "приходится", "вынуждены", ошибки
3. ЖЕЛАНИЯ: "хотелось бы", "нужно", сравнения с другими системами
4. КОНТЕКСТ: размер организации, существующие системы, сроки

==================================================
ФАЗА 2: СТРУКТУРИРОВАНИЕ
==================================================

# Требования к системе [название]

## 1. Stakeholders
Только ЯВНО упомянутые или ПРЯМО следующие из контекста.
- **[Роль]**
  - Задачи: [что делает]
  - Боли: [что не устраивает]
  - Ожидания: [что хочет]
  - Уровень доступа: [к чему имеет доступ]

## 2. AS-IS
### 2.1 Существующий процесс (минимум 5 пунктов)
### 2.2 Проблемы
- ? Критичные: [блокируют работу]
- ? Важные: [замедляют]
- ? Желательные: [неудобства]
### 2.3 Технический контекст

## 3. Функциональные требования
Минимум 3 подсистемы, минимум 3 требования в каждой.

- **FR-001**: Система должна позволять [роль] [действие] [объект]
  - Источник: "[цитата]"
  - Приоритет: Must/Should/Could
  - Уверенность: ? Явное / ? Выведено (80%) / ❔ Предположение (50%)

## 4. Нефункциональные требования
Безопасность, производительность, доступность, совместимость, масштабируемость.

## 5. Ограничения
Только ЯВНО упомянутое. Категории: технические, организационные, регуляторные, бюджетные.

## 6. Предположения
- [предположение] — уверенность X%, основание: [почему]

## 7. Вопросы для уточнения
### ❗ Критичные (блокируют проектирование)
### ⚠️ Важные (влияют на архитектуру)  
### ❓ Уточняющие

## 8. Словарь терминов

==================================================
ПРАВИЛА ИЗВЛЕЧЕНИЯ
==================================================

? ЯВНЫЕ (100%): "нужно", "должно", "обязательно"
? ПОДРАЗУМЕВАЕМЫЕ (60-80%): "приходится" → автоматизация, "ПД" → 152-ФЗ
❔ ПРЕДПОЛАГАЕМЫЕ (30-50%): стандартные практики, логические следствия

==================================================
АНТИПАТТЕРНЫ
==================================================

❌ Не добавляй роли без упоминания (служба поддержки)
❌ Не придумывай ограничения (облако/on-premise)
❌ Не спрашивай клиента про технологии (SQL/NoSQL)
❌ Не включай предположения в ограничения

==================================================
ОБЯЗАТЕЛЬНЫЕ ВОПРОСЫ
==================================================

Всегда спрашивай про:
- Атрибуты для фильтрации/сортировки
- Типы хранимых документов
- Действия пользователя в ЛК
- Объёмы данных и количество пользователей

==================================================
ВАЛИДАЦИЯ ПЕРЕД ВЫВОДОМ
==================================================

- [ ] AS-IS ≥ 5 пунктов, описывает текущее, не будущее
- [ ] Каждая подсистема ≥ 3 требования
- [ ] Предположения с % и основанием
- [ ] Вопросы без технического жаргона
- [ ] Словарь содержит ВСЕ аббревиатуры

Динамика улучшений

Что работает

1. Явные минимумы
«Минимум 5 пунктов», «минимум 3 требования» — заставляет модель думать глубже.

2. Формат требований
«Система должна позволять [роль] [действие]» — убирает абстракции.

3. Антипаттерны
Явный запрет типичных ошибок работает лучше, чем просьба «быть точным».

4. Самопроверка
Чек-лист в конце промта снижает количество пропусков.

5. Разделение фаз
Анализ → Структурирование → Валидация — модель не пытается делать всё сразу.

Что НЕ работает

1. Просьбы «быть внимательным»
Общие указания игнорируются. Нужны конкретные правила.

2. Слишком длинные промты без структуры
Модель «теряется». Разделители ==== и заголовки помогают.

3. Надежда на здравый смысл
Если не написано «не спрашивай про SQL» — модель спросит.

Ограничения метода

• Промт оптимизирован под не очень длинные интервью - нужно помнить про размер контекстного окна моделей

• На длинных интервью нужно разбивать на части

• Модель всё ещё требует валидации человеком — это ускоритель, не замена

• Разные модели требуют калибровки

Выводы

1. Качество вывода LLM на 70% зависит от промта, а не от модели

2. Итеративное улучшение эффективнее попыток написать идеальный промт сразу

3. Антипаттерны и чек-листы — самые эффективные инструменты против галлюцинаций

4. Маркировка уверенности делает вывод пригодным для работы

Промт из статьи можно использовать как отправную точку. Адаптируйте под свой контекст и итерируйте.