TL;DR
В прошлой статье я запустил GigaChat под Roo Code и погонял на задачах аналитика. Результаты в сравнении с Qwen оказались так себе. Улучшим их.
Показываю пошаговый процесс улучшения промта для извлечения требований из интервью с заказчиком. Каждая итерация — конкретная проблема и её решение. В конце — готовый промт, который можно использовать.
Проблема
Типичный запрос к LLM:
Проанализируй интервью и создай документ требований
Типичный результат: поверхностный анализ на 2 страницы, вода и галлюцинации.
Я решил разобраться, можно ли систематически улучшить качество вывода. Взял простое интервью с заказчиком:
Клиент: - нужно сделать CRM - на каждое физлицо есть папка, где хранятся документы, в том числе с ПД - из этих физлиц нужно формировать реестр (фильтрация, сортировка, выборка по атрибутам) - у каждого ФЛ должен быть личный кабинет на сайте организации (НКО)
И начал итеративно дорабатывать промт, фиксируя результаты.
Метод оценки
Для каждой итерации оценивал вывод по чек-листу:
Критерий | Вес |
|---|---|
Полнота ролей (Stakeholders) | 1 |
Качество AS-IS (текущая ситуация) | 2 |
Структура функциональных требований | 2 |
Разделение FR и NFR | 1 |
Отсутствие галлюцинаций | 2 |
Качество уточняющих вопросов | 2 |
Максимум — 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 требования - [ ] Предположения с % и основанием - [ ] Вопросы без технического жаргона - [ ] Словарь содержит ВСЕ аббревиатуры
Динамика улучшений
Итерация | Оценка | Ключевое изменение |
|---|---|---|
0 | 4/10 | Базовый промт |
1 | 7/10 | Структура + минимумы |
2 | 7.5/10 | Антипаттерны |
3 | 8/10 | Маркировка уверенности |
4 | 8.5/10 | Валидационный чек-лист |
Что работает
1. Явные минимумы
«Минимум 5 пунктов», «минимум 3 требования» — заставляет модель думать глубже.
2. Формат требований
«Система должна позволять [роль] [действие]» — убирает абстракции.
3. Антипаттерны
Явный запрет типичных ошибок работает лучше, чем просьба «быть точным».
4. Самопроверка
Чек-лист в конце промта снижает количество пропусков.
5. Разделение фаз
Анализ → Структурирование → Валидация — модель не пытается делать всё сразу.
Что НЕ работает
1. Просьбы «быть внимательным»
Общие указания игнорируются. Нужны конкретные правила.
2. Слишком длинные промты без структуры
Модель «теряется». Разделители ==== и заголовки помогают.
3. Надежда на здравый смысл
Если не написано «не спрашивай про SQL» — модель спросит.
Ограничения метода
Промт оптимизирован под не очень длинные интервью - нужно помнить про размер контекстного окна моделей
На длинных интервью нужно разбивать на части
Модель всё ещё требует валидации человеком — это ускоритель, не замена
Разные модели требуют калибровки
Выводы
Качество вывода LLM на 70% зависит от промта, а не от модели
Итеративное улучшение эффективнее попыток написать идеальный промт сразу
Антипаттерны и чек-листы — самые эффективные инструменты против галлюцинаций
Маркировка уверенности делает вывод пригодным для работы
Промт из статьи можно использовать как отправную точку. Адаптируйте под свой контекст и итерируйте.
