Промпты с явными критериями

Суть

Общие указания вроде «будь консервативнее» не снижают ложные срабатывания — область задаёт только конкретный категориальный критерий. Фильтрация по уверенности («сообщай только при высокой уверенности») не меняет область: модель принимает те же пограничные решения.

Доверие и определения severity

Когда доля ложных срабатываний превышает ~30%, разработчики перестают доверять всей категории — включая верные 70%. Явные определения важности (CRITICAL/HIGH/SKIP) с конкретными примерами кода устраняют неоднозначную классификацию. Высоко-ложную категорию лучше временно отключить, починить критерий и вернуть.

Anti-patterns

Ловушка	Почему не работает	Верный паттерн
Добавить «сообщать только высоко-уверенные находки»	Фильтр уверенности не меняет область — те же пограничные решения	Явно задать область: что входит, а что НЕТ
Оставить включённой высоко-ложную категорию	30% ложных рушит доверие ко всем находкам, включая реальные	Временно отключить категорию; починить критерий; вернуть
Использовать метки severity без определений	Несогласованная классификация ломает авто-триаж	Определить каждую severity конкретным примером кода

Exam traps

Ловушка	Почему не работает	Верный паттерн
Пороги уверенности как способ задать область	Они не меняют, что считается проблемой	Явное категориальное определение области
Постоянно держать высоко-ложную категорию	Доверие разрушается	Временно отключать для починки
Метки severity без примеров	Рождают несогласованность	Конкретные примеры под каждую метку

Практическое задание (T1)

Прогнать 10 файлов с расплывчатым промптом; классифицировать находки как true/false positive.
Переписать с 3 явными типами «сообщать» и 3 «пропускать»; прогнать те же 10 файлов.
Задокументировать снижение доли ложных срабатываний.
Добавить определения CRITICAL/HIGH/SKIP с одним примером кода на каждую.
Найти категорию с наибольшей долей ложных и убрать её из видимости разработчика.

Проверка знаний

Конвейер код-ревью в CI/CD

Конвейер помечает 40% валидных блоков комментариев как неточные. Разработчик предлагает добавить «помечать только при высокой уверенности». Что произойдёт?

A Доля ложных существенно упадёт — пороги уверенности эффективны
B Доля ложных улучшится в лучшем случае незначительно — корень в расплывчатой области, а не в калибровке уверенности
C Общее число находок сильно упадёт — меньше ревью, меньше трения
D Доля ложных улучшится, так как модель переоценит со строгим порогом

Конвейер код-ревью в CI/CD

Есть 5 категорий ревью; разработчики перестали читать находки из-за ложных срабатываний в «точности комментариев» и «именовании». Что сделать?

A Добавить ко всем находкам дисклеймер о повышенной доле ложных
B Сократить до 2 категорий — безопасность и логические ошибки
C Временно отключить категории «точность комментариев» и «именование», улучшая критерий
D Добавить «помечать только при уверенности выше 90%»

Конвейер код-ревью в CI/CD

После развёртывания конвейер ревью даёт 40% ложных. Коллега предлагает добавить больше примеров хорошего кода в промпт. Лучшее решение?

A Добавить пять примеров хорошего кода, который НЕ нужно помечать
B Добавить явные критерии исключения в system prompt (правила про покрытие тестами, длину кода, сложность)
C Поднять temperature для более тонких суждений
D Добавить второй проход Claude для проверки первого на ложные