Reyting Naushnikov Na Iznos

Доказательный Рейтинг Прочных ANC-Наушников

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю «Доказательный рейтинг прочных ANC-наушников»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Обзор

Skill ранжирует готовые полноразмерные наушники с активным шумоподавлением по вероятной живучести в конкретном сценарии. Он связывает нагрузку с конструкцией несущих узлов, проверяет повторяемые поломки точной модели и отдельно учитывает ремонтопригодность.

Результат — наиболее обоснованный выбор или честная ничья внутри явно названного корпуса, а не вечный список «самых прочных на рынке». Перед исследованием прочитайте references/evidence-rubric.md.

Естественные Входы

• «Найди самые прочные полноразмерные наушники с шумодавом».
• «Какие ANC-наушники наименее ломкие и не требуют аккуратности?»
• «Сравни эти модели по шарнирам, оголовью и типичным поломкам».
• «Наушники будут носить без чехла и бросать в рюкзак».
• «Проверь рейтинг прочности, который дал поисковый ИИ».

Входная Рамка

Зафиксируйте:

• нагрузки: сжатие в рюкзаке, скручивание, падения, снятие одной рукой, влага и длительное ежедневное ношение;
• обязательные фильтры: полноразмерный формат и ANC; при наличии — бюджет, масса, размер амбушюр и требования к подарку;
• корпус: модели пользователя либо сформированный для исследования список;
• запрошенное число мест.

Если модели не заданы, сначала сформируйте корпус шире итогового топа и покажите его границы. Не называйте победителя «лучшим на рынке», если весь рынок не покрыт. Спрашивайте только о недостающем условии, которое действительно изменит состав или порядок; иначе продолжайте с явно указанным допущением.

Процесс

1. Переведите сценарий пользователя в несколько правдоподобных путей нагрузки, а не в один заранее выбранный узел. Например, рюкзак в зависимости от положения может нагружать шарниры, выступающие вилки или дужку; падение — чашку, вилку, поворотный узел или оголовье. Отдельно проверьте влагу через отверстия и амбушюры, а постоянное использование — через направляющие, аккумулятор, разъёмы и расходники. Эти связи являются гипотезами до проверки конструкции точной модели.
2. Зафиксируйте корпус и точное поколение каждой модели. Не переносите сведения между версиями с похожим названием.
3. Для каждой модели соберите одинаковый пакет:
   • устройство оголовья, вилок, шарниров, поворотных и складных узлов;
   • официальные сведения о материалах, защите от среды, конструктивной заменяемости и номерах деталей;
   • независимые разборки, ремонты и повторяющиеся сообщения владельцев о точной модели;
   • заменяемость амбушюр, оголовья, кабеля и аккумулятора;
   • неизвестные и противоречия.
4. Разведите виды отказов: критическая поломка несущей конструкции, критический отказ электроники, ремонтируемый износ расходников и косметические следы. Не складывайте их в одну массу жалоб.
5. Сопоставьте каждую модель со сценарием по одинаковым осям: конструкционный риск, риск среды, ремонтопригодность и качество доказательств.
6. Примените обязательные фильтры до ранжирования. Модель без полноразмерного формата или ANC не может попасть в топ, даже если она крепкая.
7. Постройте порядок только там, где доказательства различают модели. При слабых данных оставьте ничью или снизьте уверенность вместо выдуманного победителя.
8. Если пользователь принёс чужой рейтинг, сначала проверьте его конкретные утверждения, затем пересоберите порядок только из уцелевших доказательств.
9. Если запрос включает покупку, завершите рейтинг живучести, а текущие цену, наличие, доставку и гарантию финалистов передайте в proverka-aktualnosti-v-momente.

Правила Доказательств

• Материал чашки или декоративной детали не доказывает прочность пути нагрузки от оголовья к чашке.
• Уверенный вывод о сравнительной частоте поломок допустим только по сопоставимому испытанию либо сервисным или полевым данным со знаменателем, сроком и похожими условиями использования. Конструкция и отдельные случаи подтверждают механизм риска, но не частоту отказов.
• Копии одной новости, одного ремонта или одного сообщения считаются одним происхождением, а не несколькими подтверждениями.
• Число жалоб без данных об объёме продаж не является частотой отказов.
• MIL-STD, «авиационный алюминий» и другие рекламные формулы учитываются только в пределах названного теста и проверенной детали.
• Ремонтопригодность — отдельное преимущество, но она не делает хрупкую конструкцию неломкой.
• Отсутствие найденных жалоб означает «данных недостаточно», а не «поломок нет».
• Текущая доступность запчастей, региональный сервис и условия гарантии не входят в оценку конструкции; при необходимости передайте их в proverka-aktualnosti-v-momente.
• Каждое важное утверждение сопровождайте прямой ссылкой и датой публикации или проверки; поисковый фрагмент используйте только как наводку.

Формат Результата

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

1. сценарий нагрузки и границы рассмотренного корпуса;
2. компактную таблицу: место, модель, главный риск, ремонтопригодность, уверенность;
3. по каждой модели — механизм риска и ссылки на доказательства точной версии;
4. неподтверждённые заявления, ничьи и неизвестные;
5. при покупке — короткую передачу финалистов в proverka-aktualnosti-v-momente без заявлений о текущей цене или наличии.

Границы

• Не используйте skill для поиска текущих цен, наличия, доставки, продавцов или локальной розницы: это proverka-aktualnosti-v-momente.
• Не используйте его для оценки конкретного объявления б/у, переписки с продавцом или диагностики уже сломанной пары.
• Не ранжируйте качество звука, микрофона или силу ANC, кроме проверки обязательного наличия ANC.
• Не обещайте, что победитель переживёт любое обращение, и не выдавайте публичные сигналы за лабораторную статистику надёжности.
• Не храните статичный рейтинг моделей: при новом запросе проверяйте точные поколения и доступные источники заново.

Критерий Готовности

• Сценарий нагрузки, корпус и точные поколения названы.
• Все кандидаты прошли одинаковую проверку и обязательные фильтры.
• Каждое место объяснено механизмом риска, а не брендом, ценой или материалом чашки.
• Повторы источников сведены, разные поколения не смешаны, неподтверждённые числа исключены.
• Уверенность и неизвестные показаны; при недостатке данных допускается ничья.
• Цена и наличие не выданы как текущие без отдельного запуска proverka-aktualnosti-v-momente.

Опрос После Использования

Опрос задаётся один раз — после выдачи итогового рейтинга или аудита принесённого списка, не посреди исследования. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по навыку:
1. Что в работе этого навыка было полезно?
2. Что стоит доработать в процедуре или формате ответа?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/reyting-naushnikov-na-iznos/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/<skill-name>/exception-log.jsonl.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.