> ## Documentation Index
> Fetch the complete documentation index at: https://www.doc-reviewer.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Критерии: правила оценки качества инструкций
> Критерии — это правила в формате Markdown, которые LLM использует как рубрику для каждой инструкции. Doc Reviewer поставляется со встроенным набором, охватывающим структуру, шаги и полноту.
Критерии определяют, что значит «хорошая инструкция». Каждый критерий — это текстовое правило, описывающее конкретное структурное или содержательное требование. LLM оценивает каждую инструкцию по всем активным критериям и возвращает `ok`, `warning` или `error` для каждого из них. Doc Reviewer поставляется с набором критериев по умолчанию, охватывающим стандартную структуру технической инструкции. Вы можете редактировать этот набор или создать свой в **Настройках → Наборы критериев**.
## Как работают критерии
При запуске оценки Doc Reviewer загружает активный набор критериев и включает полный Markdown-текст в запрос LLM вместе с оцениваемой инструкцией. LLM читает критерии и инструкцию, затем возвращает структурированный JSON-ответ с результатом по каждому критерию и рекомендацией для каждого, который получил оценку `warning` или `error`.
Критерии также содержат раздел **Роль** (заголовок `## Роль` в Markdown), который задаёт персону оценщика. Doc Reviewer извлекает этот раздел и помещает его в системный промпт, а не в пользовательский — LLM оценивает с нужной точкой зрения ещё до того, как читает инструкцию.
При редактировании набора критериев через интерфейс изменения вступают в силу при следующем запуске оценки. Перезапуск не нужен.
## Встроенный набор критериев
Набор критериев по умолчанию организован в пять нумерованных групп. Каждая группа охватывает отдельную часть структуры инструкции.
**0.1 Заголовок**
Заголовок сформулирован как отглагольное существительное, называющее задачу: например, «Настройка подключения» или «Добавление пользователя». Инфинитивные формы («Настроить подключение») и вопросы не допускаются.
**0.2 Вводная фраза**
Перед нумерованными шагами стоит фраза цели в форме «Чтобы \[цель]:» — краткое утверждение о том, чего достигает инструкция, заканчивающееся двоеточием. Например: «Чтобы добавить пользователя в систему:». Если фраза отсутствует, критерий не выполнен.
**1.1 Цель и контекст**
Вводный текст объясняет, зачем читатель выполняет эти шаги: какую задачу решает инструкция и в каком сценарии она применяется. Достаточно одного-двух предложений с чётким утверждением цели.
**1.2 Предварительные условия**
Требования, которые нужно выполнить до начала работы, указаны явно: роль или права пользователя, инфраструктурные зависимости, зависимости от других настроек или компонентов. Если предварительных условий нет, критерий считается выполненным.
**1.3 Предупреждения и ограничения**
Если действие необратимо — удаление, сброс, перезапись данных — или несёт риск негативных последствий (потеря данных, прерывание работы сервиса, изменение прав), это указывается явно до начала шагов. Отсутствие предупреждения при наличии таких рисков — ошибка. Если действие безопасно и обратимо, критерий считается выполненным.
**2.1 Одно действие в шаге**
Каждый нумерованный шаг содержит ровно одно действие пользователя. Шаги не объединяют несколько несвязанных действий в один пункт. Действие сформулировано в виде глагола в повелительном наклонении («Нажмите», «Введите», «Выберите»). Шаг, который только описывает расположение элемента, а не действие с ним, не является самостоятельным шагом — он должен быть частью другого шага.
**2.2 Названия элементов интерфейса**
В шагах указаны конкретные элементы интерфейса, с которыми взаимодействует читатель: кнопки, поля, меню, вкладки. Названия элементов выделены типографически или написаны точно так, как они отображаются в интерфейсе.
**2.3 Параметры и команды**
Если шаг предполагает ввод команды, значения параметра или заполнение поля, инструкция указывает, что вводить и зачем, или приводит пример. Команды с несколькими параметрами сопровождаются примером использования.
**2.4 Промежуточные результаты**
После ключевых шагов инструкция описывает ответ системы или промежуточный результат: какой диалог открылся, что изменилось, какое сообщение появилось. Это позволяет читателю убедиться, что шаг выполнен правильно, перед тем как продолжить.
**3.1 Итоговый результат** `необязательный`
Критерий оценивается только при наличии в инструкции явного раздела с результатом или завершающего утверждения после шагов. Если такого раздела нет, LLM возвращает `ok`. При наличии раздела критерий проверяет: результат описан в прошедшем времени («настроено», «добавлено», «включено»), описывает, что изменилось в системе и как это влияет на дальнейшую работу, и логически соответствует цели из вводной фразы.
**4.1 Обработка ошибок** `необязательный`
Критерий оценивается только при наличии в инструкции явного описания возможных ошибок или раздела по устранению неполадок. Если такого раздела нет, LLM возвращает `ok`. При наличии раздела критерий проверяет, что он охватывает типичные проблемы и их решения или описывает, как откатить изменения.
## Необязательные критерии
Критерии, помеченные как `необязательный` в файле критериев (с тегом `<опциональный>` в заголовке), ведут себя иначе, чем обязательные: LLM оценивает их только при наличии соответствующего контента в инструкции. Если элемент отсутствует — например, инструкция не содержит раздела по устранению неполадок — критерий автоматически помечается как `ok` и не влияет на цветовую оценку.