> ## 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. Критерии — это Markdown-файлы с определённой структурой, которую Doc Reviewer разбирает для построения рубрики оценки, передаваемой в LLM. Вы можете написать собственные критерии, отражающие стандарты документации вашего продукта, команды или отрасли. Пользовательские критерии добавляются через **Настройки → Наборы критериев → Новый набор критериев** или путём размещения файла `criteria.md` рядом с `doc-reviewer.exe` до первого запуска. ## Структура файла Файл критериев содержит четыре вида блоков: | Блок | Синтаксис | Назначение | | ----------------------- | ------------------------------------------ | ------------------------------------------------------------------------- | | Раздел Роль | `## Роль` | Задаёт экспертную персону, присваиваемую LLM в системном промпте | | Заголовок группы | `## Название группы` | Объединяет связанные критерии под именованной категорией | | Критерий | `### 1.1 Название критерия` | Одна проверяемая единица с числовым идентификатором через точку | | Необязательный критерий | `### 1.1 Название критерия <опциональный>` | Проверка, которая оценивается только при наличии соответствующего раздела | ### Полный пример формата ```markdown theme={null} ## Роль You are a [role description]. [What you evaluate and why your expertise is relevant]. --- ## Название группы ### 1.1 Название критерия Описание того, что проверяется. Как выглядит прохождение проверки. ### 1.2 Другой критерий <опциональный> Описание. Оценивается только при наличии этого раздела в инструкции. ## Вторая группа ### 2.1 Название критерия Описание. ``` ### Раздел Роль Раздел `## Роль` в начале файла определяет экспертную персону, которую LLM принимает при оценке инструкций. Doc Reviewer извлекает этот текст и помещает его в системный промпт до постановки задачи оценки. Пишите раздел Роль как описание компетенций оценщика: его опыт, что он оценивает и какие специализированные знания должен применять. Например: ```markdown theme={null} ## Роль You are a senior technical writer with a background in information security products. You evaluate the completeness and structural correctness of instructions — checking whether all steps are present, preconditions are stated, and potential errors are addressed. You also assess style and formatting: headings, introductory phrases, verb forms, and result descriptions. ``` Если раздел Роль отсутствует, Doc Reviewer использует встроенную роль по умолчанию. ### Необязательные критерии Пометьте критерий как необязательный, добавив `<опциональный>` к заголовку: ```markdown theme={null} ### 3.1 Итоговый результат <опциональный> ``` Необязательный критерий оценивается только при наличии соответствующего раздела в инструкции. Если раздел отсутствует, критерий автоматически получает проходной балл (`ok`). Используйте необязательные критерии для разделов, которые могут законно отсутствовать — например, раздел по устранению неполадок или абзац с итоговым результатом. ## Структура критериев по умолчанию Встроенный набор критериев охватывает пять групп. Это структура, используемая в `criteria.md` по умолчанию: Проверяет верхнеуровневую форму инструкции до оценки содержимого. | ID | Критерий | Необязательный | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | 0.1 | **Заголовок** — заголовок использует существительную или отглагольную форму, называющую задачу (например, «Настройка подключения», «Добавление пользователя»). Инфинитивные формы и вопросы не допускаются. | Нет | | 0.2 | **Вводная фраза** — фраза «Чтобы \[цель]:» стоит перед нумерованными шагами, цель сформулирована и заканчивается двоеточием. | Нет | Проверяет поясняющий контент, предшествующий шагам. | ID | Критерий | Необязательный | | --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | 1.1 | **Цель и контекст** — вводный текст объясняет, зачем пользователь выполняет эти шаги: какую задачу решает инструкция и в каком сценарии применяется. | Нет | | 1.2 | **Предварительные условия** — требования до начала работы указаны явно: роль или права пользователя, инфраструктурные требования, зависимости от других настроек. При их отсутствии критерий считается выполненным. | Нет | | 1.3 | **Предупреждения и ограничения** — если действие необратимо (удаление, сброс, перезапись данных) или несёт риск (потеря данных, прерывание сервиса, изменение прав), это явно указано до шагов. Если действие безопасно и обратимо, критерий считается выполненным. | Нет | Проверяет качество и полноту нумерованной процедуры. | ID | Критерий | Необязательный | | --- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | 2.1 | **Одно действие в шаге** — каждый нумерованный шаг содержит ровно одно действие пользователя в повелительном наклонении («Нажмите», «Введите», «Выберите»). Шаги не объединяют несвязанные действия. | Нет | | 2.2 | **Элементы интерфейса** — в шагах названы конкретные элементы интерфейса (кнопки, поля, меню, вкладки), с которыми взаимодействует пользователь. Названия даны точно так, как они отображаются в интерфейсе. | Нет | | 2.3 | **Параметры и команды** — если шаг предполагает ввод команды, значения параметра или заполнение поля, инструкция указывает, что вводить и зачем, или приводит пример. Команды с несколькими параметрами сопровождаются примером. | Нет | | 2.4 | **Промежуточные результаты** — после ключевых шагов описывается ответ системы: что открылось, что изменилось, какое сообщение появилось. Это позволяет пользователю убедиться в успешном выполнении шага. | Нет | Проверяет завершающий раздел инструкции. | ID | Критерий | Необязательный | | --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------- | | 3.1 | **Итоговый результат** — если инструкция содержит явный раздел с результатом или завершающее предложение после шагов, он описывает в прошедшем времени, что изменилось в системе и как это влияет на дальнейшую работу, и логически соответствует цели из вводной фразы. | Да | Проверяет контент по обработке ошибок при его наличии. | ID | Критерий | Необязательный | | --- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | 4.1 | **Обработка ошибок** — если инструкция явно описывает возможные ошибки или содержит раздел по устранению неполадок, в нём перечислены типичные проблемы с шагами их решения или описан способ отката изменений. | Да | ## Советы по написанию критериев **Указывайте конкретно, как выглядит прохождение проверки.** Расплывчатые критерии дают непоследовательные результаты LLM. Вместо «шаги понятны» пишите «каждый шаг содержит ровно одно действие в повелительном наклонении». **Используйте маркеры необязательности для разделов, которые могут отсутствовать.** Если критерий проверяет раздел, который законно может не быть в части инструкций (блок по устранению неполадок, абзац с итоговым результатом), помечайте его как `<опциональный>`. Это предотвращает ложные ошибки. **Пишите кратко.** Одного-двух предложений на критерий достаточно. LLM читает весь файл критериев для каждой оценки — длинные описания увеличивают расход токенов и могут размывать фокус. **Подбирайте раздел Роль под тип вашего продукта.** Описывайте компетенции, наиболее релевантные вашей документации: оценщик продуктов для информационной безопасности, технический писатель для инструментов разработчика, специалист по соответствию требованиям для регулируемых отраслей. Чем конкретнее роль, тем последовательнее LLM применяет ваши стандарты. **Нумеруйте критерии через точку.** Используйте `1.1`, `1.2`, `2.1` и т.д. Этот номер используется как идентификатор критерия в результатах оценки — сохраняйте его стабильным при редактировании. ## Применение пользовательских критериев Перейдите в **Настройки → Наборы критериев → Новый набор критериев**, вставьте содержимое в формате Markdown, задайте имя набора и нажмите **Сохранить**. Затем нажмите **Активировать**, чтобы сделать набор активным. Поместите файл `criteria.md` в ту же папку, что и `doc-reviewer.exe`, до первого запуска приложения. Doc Reviewer прочитает этот файл и использует его как набор критериев по умолчанию. Файл рядом с `.exe` имеет приоритет над встроенным набором по умолчанию. Это работает только при первом запуске, когда база данных пустая. Если вы уже запускали Doc Reviewer, используйте интерфейс для создания или редактирования наборов критериев.