Вы пишете эти инструкции для предыдущей модели?
«Читайте этот документ каждый раз», «Всегда тестируйте», «Подтверждайте перед началом». Многие, вероятно, добавляли эти инструкции, чтобы предотвратить сбои Codex.
Поскольку он вносил исправления, не читая документацию, вы написали, чтобы он сначала читал её. Поскольку он действовал без разрешения, вы написали, чтобы он подтверждал перед продолжением.
Хотя в своё время эти предложения имели смысл, они могут быть не столь полезны при смене модели.
Процедуры, призванные помогать предыдущим моделям, могут быть слишком детальными для GPT-6 Astra. И наоборот, из-за того, что вы не сообщили о предполагаемой области применения, она может без необходимости останавливаться для запроса подтверждения.
Пересмотру подлежит не только количество инструкций. Речь идет о сокращении повторяющихся задач и уточнении необходимых сценариев и условий завершения.
Эрик Провеншер, отвечающий за взаимодействие с разработчиками Codex в OpenAI, рассматривает эту проблему в статье под названием «Переосмысление навыков и промптов для GPT-6 Astra».
Это касается не только запросов, которые вы пишете в чате, но и «AGENTS.md», который передает правила работы для файлов проекта в репозитории.
«Навыки» — это наборы процедур и знаний, используемых для конкретных задач. Инструкции, сохраненные здесь, также влияют на то, как действует Codex.
В этой статье, основываясь на объяснениях Эрика и эталонных изображениях, мы рассмотрим, что сократить, что сохранить и как переписать. Примеры, созданные для читателей, помечены как «Примеры применения», чтобы отличать их от оригинальных примеров.
Это не попытка возложить все неудачи Astra на старые инструкции. Это статья для аудита накопленных вами правил, чтобы понять, какие из них больше не подходят для текущей работы.
1. Зачем пересматривать инструкции для Astra
Отправная точка Эрика — это изменение, при котором инструкции, предназначенные для «присмотра» за моделью, становятся менее необходимыми, чем раньше.
Раньше некоторые задачи не выполнялись, если вы не указывали каждый шаг по порядку. Чтобы компенсировать неоднозначность, мы нагромождали подробные процедуры и примечания.
Однако в исходном тексте говорится, что модели становятся лучше в улавливании тонких различий в значении и неоднозначности. В нем указывается, что подробные спецификации, которые когда-то были полезны, теперь могут мешать получению результатов.
Что здесь нельзя неправильно истолковать, так это то, что это не разговор о «прекращении объяснений, потому что модель стала умнее».
Эрик также рекомендует оставлять руководство только для необходимых материалов. В исходном тексте по-прежнему требуется объяснение относительно безопасных границ прогресса и работы, необходимой для завершения.
Даже для одной и той же инструкции способ ее пересмотра меняется в зависимости от того, что должно передавать это предложение.
Например, нужно различать объяснения, которые передают специфику проекта, и те, которые предназначены для того, чтобы заставить предыдущие модели следовать процедурам.
«Ограничения по дизайну описаны в этом документе» — это подсказка для поиска информации. С другой стороны, «Читайте весь этот документ с начала при каждом редактировании» единообразно фиксирует время чтения.
Сообщить модели о существовании документа — это не то же самое, что заставлять ее читать всё каждый раз.
Кроме того, «Доступ к продакшену запрещен» и «Подтверждайте, даже перед запуском тестов локально» останавливают разные действия.
То, что вы хотите соблюдать первое, не означает, что второе всегда необходимо. Однако, если неясно, действительно ли что-то остается локальным, не следует просто пропускать и это подтверждение.
Навыки, AGENTS.md и ежедневные запросы, упомянутые в исходном тексте, — все это относится к этим суждениям. Даже если вы исправите предложение в чате, но то же самое ограничение останется где-то еще, аудит не завершен.
Например, что, если вы напишете в запросе «Делай, пока не заработает», но в применяемой процедуре все еще сказано «Всегда останавливайся после первой реализации и запрашивай ревью»?
Это пример для объяснения конфликтующих инструкций. По крайней мере, без упорядочивания того, чего хочет пользователь, конечная точка запроса не согласована.
При пересмотре не судите по принципу «длинно — значит, сокращай». Посмотрите, передает ли это предложение необходимые знания, определяет ли объем работы или просто заставляет модель повторять предыдущие процедуры.
Даже если текст короткий, но цель «подтверждать всё» расплывчата, это не обязательно хорошая инструкция. Иногда, даже если он немного длиннее, лучше передать намерение, уточнив условия чтения или точку остановки.
2. Инструкции для сокращения: Повторяющаяся загрузка и чрезмерно детальные шаги
Первое, что нужно проверить, — это правила загрузки, которые срабатывают независимо от содержания работы.
Эрик объясняет, что заставлять модель читать огромные объемы документации или все руководство по репозиторию для исправления простой опечатки — это чрезмерно.
Чтение документов помещает их содержимое в рабочую информацию модели. В исходном тексте указывается на проблему потребления доступного контекста и замедления работы из-за загрузки нерелевантных объяснений.
Контекст здесь относится к набору информации, на которую модель ссылается для данной задачи. Если он постоянно увеличивается, он приближается к точке, когда историю разговора и работы необходимо сжимать.
Поэтому, вместо того чтобы просто сокращать количество ссылок, различайте, что необходимо прочитать для текущего запроса.
Пример A: Японский перевод эталонного изображения
До редактирования
Всегда читайте architecture.md, database.md и deployment.md полностью перед редактированием.
После редактирования
Обращайтесь к architecture.md при работе с границами между сервисами, к database.md при изменении структур БД и к deployment.md при подготовке к развертыванию.
Что было сохранено, так это указания на три документа. Что было изменено, так это условия их открытия.
В этом примере architecture.md предназначен для ролей и связей между сервисами. database.md — для структуры базы данных. deployment.md — для отражения созданного в среде выполнения.
В версии «До» правило «читать всё» применяется даже к запросу на исправление одной опечатки. В версии «После», если задача заключается в изменении структуры БД, она переходит к соответствующему database.md.
Это не означает, что чтение других документов запрещено. Если задача затрагивает несколько областей, необходимые документы не ограничиваются одним.
Создание другого единообразного правила, например «выбирай только один документ», на основе этого примера отклонилось бы от первоначального замысла.
Мы не удалили необходимые документы и не сократили их содержание. Мы переписали условие, требующее проверки всех документов даже для небольших изменений, чтобы оно соответствовало содержанию работы.
Эрик также упоминает о необходимости поддерживать документы в актуальном состоянии. Даже если вы организуете условия для ссылок, необходима отдельная проверка, чтобы убедиться, что в целевом документе не осталось старых объяснений.
Пример B: Пример применения на основе исходного текста
Далее следует пример, примененный к сценарию, где Codex поручается создание статей, видео или постов в социальных сетях. Это не производственная процедура, опубликованная самим Эриком.
До редактирования
Для создания контента прочитайте все процедуры для статей, видео и постов в социальных сетях.
После редактирования
Обращайтесь к writing.md для написания статей, к video.md для производства видео и к social.md для создания постов в социальных сетях. Для запросов, включающих несколько форматов, обращайтесь к соответствующим процедурам.
Опять же, конкретные процедуры для статей, видео и социальных сетей сохранены. Изменилась часть, которая заставляла модель читать все процедуры под широким понятием «создание контента».
Если вы просите одну статью, она переходит к инструкциям для статей. Если вы просите статью и анонсирующий пост вместе, она переходит к процедурам для статей и социальных сетей.
Если запроса на видео нет, больше не требуется загружать весь процесс производства видео на общем входе.
Исходный текст называет такой подход предоставления необходимых объяснений поэтапно «прогрессивным раскрытием». Это метод размещения объяснений на входе для определения направления, при этом отделяя детальные знания и процедуры в последующие документы.
Например, если вы выстроите полные процедуры для статей, видео и социальных сетей на входе, каждый запрос будет приводить к чтению огромного объяснения.
Вместо этого ограничьте роль входной точки руководством: «Если это статья, перейди к этому документу; если видео — к тому». Вы сохраняете подробные объяснения, не отбрасывая их, позволяя читать их, когда это необходимо.
Эрик объясняет, что для Навыков с несколькими рабочими процедурами первоначальный документ должен быть минимальным руководством. Он должен предоставлять ровно столько информации, чтобы перейти к связанным документам или скриптам, выполняющим задачу.
Создайте состояние, при котором, глядя только на входную точку, можно понять, к какому документу следует перейти. Простое обобщение длинных объяснений в короткие не завершит эту организацию ссылок.
Если вы упустите необходимые меры предосторожности в обобщении, это станет другой проблемой. В приведенном выше примере применения сохранены процедуры, уникальные для каждого формата.
Тестирование также настроено на «Всегда, несмотря ни на что»?
В исходном тексте говорится, что предыдущие модели нужно было подталкивать к тестированию и подтверждению работы. С другой стороны, Astra делает это сама, поэтому те же инструкции могут привести к ненужному избыточному тестированию.
Не поймите это неправильно: «Astra не нужно тестирование». Проблема не в прекращении проверок, а в том, вызывают ли инструкции избыточные проверки.
Если применять это к вашим собственным настройкам, посмотрите, какую проверку вы запрашиваете для какого изменения. Содержание необходимых проверок и условия их единообразного повторения каждый раз, когда вы что-то делаете, можно проверять отдельно.
Поскольку в этой статье не сравнивается количество тестов или время обработки, она не показывает эффекта вроде «переписывание сэкономит X минут». Цель аудита — понять, можете ли вы отличить необходимые проверки от избыточных повторений.
3. Сужение инструкций: Когда следует использовать этот навык?
Добавление большего количества Навыков не обязательно облегчает их выбор. Эрик обращает внимание на практику загрузки и добавления огромного количества Навыков.
Согласно исходному тексту, название и описание каждого Навыка загружаются в контекст, чтобы модель могла решить, когда их использовать.
Здесь нужно различать загрузку названия/описания и загрузку тела Навыка. Это не означает, что модель читает тело каждого Навыка с самого начала.
Сначала модель использует название и описание как подсказки, чтобы решить, какой из них использовать в этот раз. Если эти описания слишком длинны или Навыков слишком много, в исходном тексте утверждается, что Codex сократит описания, чтобы они поместились.
В результате модель может видеть только часть описания каждого Навыка, что затрудняет выбор. Даже если необходимые процедуры сохранены, объяснение на входе может быть передано не полностью.
Кроме того, Эрик упоминает противоречия между описаниями или описания, которые пытаются сделать так, чтобы они использовались для всего. Это может привести к загрузке инструкций, которые не помогают в выполнении задачи.
Итак, дело не в том, чтобы набивать описания техническими терминами, чтобы охват казался широким. Сделайте описание таким, чтобы модель знала, следует ли вызывать этот Навык для текущей работы.
Японский перевод эталонного изображения
До редактирования
Создавайте и проверяйте миграции схем PostgreSQL. Используйте для работы, связанной с базами данных, запросами, моделями и персистентностью.
После редактирования
Создавайте и проверяйте миграции схем PostgreSQL. Используйте для добавления/изменения миграций или ревью процедур приложения.
PostgreSQL — это тип базы данных. «Миграция схемы» относится к задаче изменения структуры таблиц и элементов, служащих контейнерами данных, и применения этих изменений.
Например, это сценарий, в котором вы изменяете структуру базы данных, чтобы увеличить количество сохраняемых элементов. Здесь это приводится как пример объяснения значения терминов.
С другой стороны, «запросы» в описании «До» — это запросы на извлечение или манипулирование данными. «Персистентность» относится к сохранению данных для последующего использования.
Эти термины связаны с БД, но не вся работа, связанная с БД, представляет собой задачу миграции, изменяющую структуру.
Первое предложение версии «До» показывает специализированную задачу: «Создавайте и проверяйте миграции». Однако второе предложение включает в условия использования широкий круг работ, связанных с базами данных.
Это несоответствие в объеме и исправляется на эталонном изображении. Область экспертизы Навыка и условия вызова не совпадают.
После редактирования роль «Создавайте и проверяйте миграции схем PostgreSQL» сохраняется. Кроме того, она сужается до случаев добавления миграций, изменения миграций или ревью процедур приложения.
Например, если вы просто хотите проверить запрос на извлечение существующих данных, вам не обязательно вызывать этот Навык миграции только потому, что это «связано с базой данных».
И наоборот, если это ревью того, как применять структурные изменения, это все еще является целью в описании «После». Сужение не привело к потере специализированной работы.
Смысл подтверждения при исправлении описаний не просто в том, «что знает этот Навык?» Речь идет о том, можно ли прочитать, «для какого запроса он будет использоваться, а на какие запросы не будет распространяться?»
Если вы просто напишете «Навык БД», чтобы сделать его короче, условия вызова исчезнут. Исходный текст требует сделать описание максимально коротким, сохраняя при этом четкими сценарии использования.
Вы можете использовать приведенные выше варианты «До/После», чтобы проверить, соответствуют ли запрашиваемая работа и условия применения, а не полагаться на силу названия или длину описания.
4. Уточнение инструкций: Как далеко заходить и что определяет завершение
Теперь мы поговорим о добавлении необходимых объяснений. Простое сокращение загрузки и процедур не решит проблему остановки на полпути.
Эрик утверждает, что, хотя Astra работает усердно, иногда она может проявлять осторожность в отношении того, как далеко заходить. Как сообщить о диапазоне, в котором вы хотите, чтобы она продолжала, также является целью пересмотра, упомянутого в исходном тексте.
В частности, если вы написали «Всегда сначала подтверждай» слишком строго, потому что предыдущая модель действовала без разрешения, проверьте эту границу.
На что указывает исходный текст, так это на возможность остановки в месте, где на самом деле можно было продолжить, просто чтобы строго следовать границе. Речь не о том, чтобы сказать игнорировать инструкции по подтверждению, а о переписывании того, что вы разрешали.
A: Уточнение области утверждения
В исходном тексте есть пример локального теста, который использует одноразовые тестовые данные и не обращается к продакшену. Это пример разрешения этой конкретной задачи в вашей собственной рабочей среде.
Следующий вариант «До» — это пример применения, созданный для контраста. Вариант «После» содержит японский перевод инструкций по локальному тестированию из исходного текста.
До редактирования: Пример применения для контраста
Запрашивайте одобрение каждый раз перед запуском теста и перед исправлением ошибки.
После редактирования: Перевод оригинального примера
Локальные тесты используют одноразовые тестовые данные и не обращаются к продакшену. Пожалуйста, продолжайте, не запрашивая одобрения на каждом этапе, вплоть до запуска тестов, исправления ошибок, вызванных запрошенными изменениями, и повторного запуска затронутых тестов.
Что было сохранено, так это целевая среда и объем работы. Что было изменено, так это условие для запроса одобрения каждый раз в рамках этого объема.
«Одноразовые тестовые данные» и «нет доступа к продакшену» — это не декоративные предисловия. Это предпосылки для суждения о том, можно ли использовать эту инструкцию.
Если на самом деле это тест, который подключается к продакшену, написание «нет доступа к продакшену» не меняет среду. Иногда это называют «локальным», но неясно, выполняются ли эти условия. Оставляйте непроверяемые условия как есть.
Кроме того, разрешенное исправление предназначено для «ошибок, вызванных запрошенными изменениями». Это не инструкция, расширенная для разрешения исправления всех проблем, найденных в тесте.
Цель повторного выполнения также указана как «затронутые тесты». Это отличается от единообразной спецификации повторять все тесты каждый раз.
Это предложение определяет действия, которые могут быть выполнены, но не отменяет одобрение для других задач. Оно показывает, сколько делегировать из набора задач, которые были признаны безопасными.
Вам не нужно заходить так далеко, как «разрешать всё, потому что останавливаться каждый раз хлопотно». Если вы отделите задачи, для которых не хотите, чтобы она останавливалась, от задач, по которым вы все еще хотите получить решение, смысл запроса изменится.
B: Уточнение условий завершения
Эрик объясняет, что если вы привыкли к GPT-5.6 Sol, которая работает долгое время, то способ остановки Astra может показаться осторожным.
На этапе, когда первоначальная реализация завершена, даже если работа еще осталась, она может вернуться, чтобы запросить ревью. Поэтому он рекомендует определять условия завершения до начала.
Нужна ли просто реализация, или нужно запустить ее для подтверждения? И, кроме того, нужно ли исправлять ошибки, найденные во время подтверждения?
Человек, отдающий запрос, сначала упорядочивает эти различия. Финишная черта, которую трудно передать просто с помощью «заверши это», записывается как задача.
Ниже приведен пример применения, где оригинальное объяснение заменено созданием формы обратной связи. Это не фактический текст запроса Эрика и не результат проверки фактического поведения.
До редактирования
Сделайте форму обратной связи. Дайте мне проверить, как только она будет реализована.
После редактирования
Сделайте форму обратной связи. На этот раз локально подтвердите, что она может обнаруживать пустые обязательные поля и неверные адреса электронной почты, и что после тестовой отправки появляется экран завершения. Исправьте любые ошибки, вызванные этим изменением, и сообщите о них вместе с результатами подтверждения. Не публикуйте в продакшен и не отправляйте реальные электронные письма.
Что было сохранено, так это цель создания формы обратной связи и сообщения результатов человеку. Что было изменено, так это объем проверки перед отчетом.
В версии «До» запрос звучит как «Дайте мне проверить, как только она будет реализована». Даже если она остановится на этапе первоначальной реализации, это не будет отклонением от инструкций.
Если вы хотите увидеть дизайн на промежуточном этапе, такой способ остановки имеет смысл. Если это остановка для подтверждения частей, которые вы еще не решили, это инструкция, имеющая причину остаться.
С другой стороны, если в этот раз вам нужна форма, прошедшая проверку работоспособности, включите эти проверки в запрос. В примере перечислены пустые поля, неверные адреса электронной почты и отображение после тестовой отправки.
По сравнению с простой проверкой «работает ли она правильно», состояния для проверки конкретны. Если во время подтверждения будут обнаружены ошибки, вызванные этим изменением, цель устанавливается как отчет после их исправления.
В то же время публикация в продакшен и отправка реальных электронных писем исключены. Это делается для того, чтобы не путать проверку отправки тестовой формы с доставкой писем реальным получателям.
Этот запрос не рассматривает функцию отправки реальных электронных писем как проверенную. Пусть она сообщит, сколько было подтверждено локально, в качестве результата.
Согласно исходному тексту, если вы хотите продолжить работу после первой реализации, сообщите, что нужно исследовать и где остановиться.
Вместо того чтобы просто усиливать инструкцию фразой «не останавливайся на полпути», перечислите необходимые подтверждения и операции, которые не нужно выполнять. Таким образом, вы сможете пересмотреть даже те места, где она возвращается к человеку.
5. Аудит ваших собственных настроек
В конце исходного текста Эрик предлагает попросить Astra провести аудит на основе этой статьи. Аудит означает чтение существующих инструкций и проверку на наличие пересечений, расхождений и областей, которые можно пересмотреть.
Вы также можете открыть свой собственный AGENTS.md или Навыки и посмотреть на предложения, которые вас интересуют. Однако, если вы хотите систематизировать, где и какие инструкции вы написали, вы можете поручить это аудиту перед внесением изменений.
Подход, заключающийся в выполнении только аудита без изменения файлов, является предложением этой статьи. Это не обязательная процедура, указанная Эриком.
В этом случае не просите с самого начала «удалить все ненужные инструкции». Сначала вам нужен материал, который позволит вам сравнить исходные инструкции с предложением по их изменению.
Еще одно замечание из исходного текста: Навыки и инструкции, размещенные в репозитории, могут использоваться ИИ других работников.
Эти ИИ могут не использовать ту же Astra. Эрик указывает, что объяснения, полезные для Sol или Luna, могут добавлять слишком много ограничений для Astra.
Даже если вам, использующему Astra, это кажется слишком детальным, это может быть необходимо для других моделей. Если вы меняете общие правила, то то, кто какую модель использует, также является фактором для принятия решения.
Если статус использования неизвестен, не удаляйте, предполагая, что «используется только Astra». Достаточно подтвердить кандидатов на исправление, оставив неясные моменты как есть.
Следующий промпт для аудита был создан для читателей на основе этой статьи. Это не промпт, опубликованный Эриком в исходном тексте.
Используйте его в целевом проекте и поделитесь текстом статьи и текстом запроса, который вы хотите проверить. Если читаемый диапазон ограничен, примите это как результат проверки в пределах этого диапазона.
Пожалуйста, проведите аудит текущих инструкций на основе комментариев, приведенных в статье Эрика Провеншера. На этот раз выполните только аудит; не создавайте, не редактируйте и не удаляйте файлы, а также не изменяйте настройки.
Целями аудита являются файл AGENTS.md, применяемый к этому проекту, названия и описания доступных навыков (Skills) и необходимые для аудита тела этих навыков, а также текст ежедневного запроса, который я предоставил. Пожалуйста, перечислите цели, которые вам удалось прочитать.
Проверьте наличие следующих проблем: ・Дублирующиеся инструкции в нескольких местах ・Инструкции, которые невозможно выполнить одновременно или которые имеют противоречивые конечные цели ・Чрезмерно универсальные правила, требующие загрузки или подтверждения при каждом действии, независимо от содержания работы ・Условия применения, которые шире фактической роли навыка ・Инструкции, в которых неясно, насколько далеко нужно продвинуться или что считается завершением
Для найденных мест классифицируйте их как кандидаты на «Удаление», «Сокращение», «Изменение условий применения» или «Сохранение» и предоставьте обоснования. Не делайте сокращение количества символов самоцелью; также перечислите инструкции, которые необходимо сохранить.
Для каждого кандидата предоставьте следующее: 1. Имя файла/местоположение или соответствующая часть текста общего запроса 2. Текущая инструкция 3. Предполагаемая проблема и основание для суждения 4. Предлагаемая редакция. Если предлагается сохранение, то причина для этого 5. Что нужно сохранить, а что изменить 6. Условия, которые должны проверить люди перед внесением изменений
Не удаляйте массово проектно-специфичные ограничения, специализированные знания, необходимые тесты или необходимые утверждения. Предлагайте только разрешение на проведение локальных тестов или исправлений в пределах тех условий окружающей среды, которые можно подтвердить, например, целевые данные и отсутствие доступа к рабочей среде (production).
Проверьте, используют ли другие модели, такие как Sol или Luna, те же инструкции. Если это неизвестно, напишите «Неизвестно» и не предполагайте, что это правило только для Astra.
Четко укажите файлы, которые не удалось прочитать, условия окружающей среды, которые не удалось подтвердить, и информацию, отсутствующую для вынесения суждения. Различайте проблемы, описанные в материалах, проблемы, фактически найденные в настройках, и непроверенные кандидаты на улучшение; не пишите об эффектах улучшения как о уже измеренных.
Наконец, обобщите кандидатов на исправление, которые следует рассмотреть в первую очередь, вместе с причинами. Выполнение изменений будет запрошено отдельно после того, как я подтвержу цели и содержание.
То, что вы получаете с этим запросом, — это не измененные настройки, а список, в котором текущие инструкции и предлагаемые редакции соответствуют друг другу. Даже если что-то помечено как «Кандидат на удаление», это само по себе не означает, что это окончательно признано ненужным.
Категоризация кандидатов предоставлена для того, чтобы предложения по изменению условий чтения не были свалены в одну кучу с «Удалением». В случае примера со ссылкой на документ в этой статье документ остается, поэтому основное внимание уделяется изменению условий применения.
Что касается описаний навыков, специализированная роль остается, но диапазон вызова сужается. В этом случае, если вернется предложение удалить сами специализированные знания, вы сможете проверить, отличается ли то, что сохраняется до и после редакции.
Кандидаты на «Сокращение» предназначены для того, чтобы увидеть, можно ли передать те же условия и ограничения более короткими предложениями. Кандидаты на «Сохранение» запрашивают причину, по которой их необходимо сохранить.
Посмотрите на объем аудита вместе с результатами. То, удалось ли прочитать только имя и описание навыка или же фактические процедуры, также является материалом для оценки результатов.
Является ли описание слишком широким, можно проверить с помощью первого, но наличие дубликатов в процедурах или то, не были ли вырезаны необходимые знания, нельзя подтвердить без чтения тела навыка.
Если вы не предоставили тексты ежедневных запросов, несоответствия с условиями остановки в них также остаются неподтвержденными. Чтение части настроек не означает завершенного аудита всей рабочей среды.
Порядок рассмотрения таков: исходная инструкция, причина, по которой она стала кандидатом, оставшиеся ограничения и неподтвержденные условия. Например, если неизвестно о наличии доступа к рабочей среде (production), предпосылка для предложения пропустить утверждение не выполнена.
Вы также можете проверить, не были ли вырезаны необходимые специализированные знания или не были ли учтены последствия для других моделей. Продолжайте, отделяя подозрения, обнаруженные в ходе аудита, от суждения о том, что изменения допустимы.
Перечитайте инструкции, которые вы продолжали добавлять, чтобы они соответствовали вашей текущей работе. Первый шаг — это не массовое удаление настроек, а этот аудит, который ничего не меняет.
