Большинство пользователей применяют Claude Code исключительно по прямому назначению — для написания программного кода. Это логично, учитывая название инструмента, его работу в терминале и позиционирование со стороны Anthropic в качестве агента для разработчиков. Задействовать его для иных целей приходит в голову далеко не сразу. Тем не менее главная причина популярности этого инструмента заключается в том, что он не просто дает советы, а самостоятельно выполняет действия от вашего имени. Поскольку утилита функционирует в терминале, она способна изучать файлы, запускать команды, создавать сценарии, редактировать конфигурации и взаимодействовать с операционной системой гораздо глубже, чем стандартный чат-бот. Осознав это, автор решил, что ограничивать сферу применения одними лишь проектами нецелесообразно. Так началась качественная оптимизация macOS с помощью Claude Code, когда вместо привычной кодовой базы под прицел попал весь персональный компьютер.

Аудит производительности: что замедляло работу системы

Прежде чем позволить утилете вносить какие-либо изменения в операционную систему, потребовалось выяснить реальное положение дел. Работа началась с комплексного аудита производительности и эффективности. Автор открыл терминал, запустил Claude Code и передал ему подробный перечень задач для проверки: от нагрузки на центральный процессор и оперативную память до фоновых служб, объектов входа, заполненности диска, процессов браузера и накопившегося мусора от инструментов разработчика.

С самого начала были установлены жесткие ограничения. Ассистенту разрешалось выполнять диагностические команды только в режиме чтения. Ему категорически запрещалось удалять файлы, завершать процессы, менять конфигурации или задействовать привилегии sudo без предварительного запроса. Более того, разработчик строго запретил делать выводы о падении производительности лишь на основании того, что файл или процесс выглядел крупным или необычным. По каждому обнаруженному замечанию требовалось предоставить реальные доказательства из системы, точное описание объекта и оценку его реального влияния на быстродействие.

Анализ оказался на удивление глубоким. Система проверила нагрузку на CPU, память и файл подкачки, элементы автозагрузки, фоновые агенты LaunchAgents и Daemons, занятое пространство накопителя, кэш, вкладки браузеров, Docker, инструменты разработки, активность индексации Spotlight и даже дубликаты установщиков, скопившиеся в папке «Загрузки». Учитывая, что этот MacBook используется ежедневно на протяжении четырех лет без регулярного обслуживания, состояние ноутбука оказалось далеко от идеального.

Главная проблема — почти забитый накопитель

Самая серьезная проблема, выявленная в ходе проверки, оказалась вполне предсказуемой: на ноутбуке критически не хватало свободного места. Свободными оставались всего около 6 гигабайт. Сама папка загрузок разрослась примерно до 12 гигабайт, и значительная часть этого объема состояла из бесполезных файлов. Утилита обнаружила дубликаты установщиков таких приложений, как ChatGPT, Docker, VS Code и Codex, а также прочие крупные файлы, скачанные однажды и благополучно забытые.

Кроме того, выяснилось, что кэши разработчиков и менеджеров пакетов удерживают 35 гигабайт. Например, кэш uv занял около 12 гигабайт, Hugging Face — еще 3,7 гигабайта, npm и pnpm суммарно забрали еще несколько гигабайт, а Docker Desktop удерживал виртуальную машину объемом 7,6 гигабайта даже в те моменты, когда сам Docker не был запущен. При общем объеме накопителя в 256 гигабайт подобное загромождение пространства накапливалось очень быстро.

На этом этапе может возникнуть закономерный вопрос: почему нельзя было самостоятельно зайти в раздел «Хранилище» в системных настройках и разобраться с забитым диском? Технически такая возможность есть. Однако штатная страница показывает лишь общие категории вроде «Программы», «Документы», macOS и «Системные данные», чего зачастую явно недостаточно для понимания того, какой именно файл пожирает память.

Именно здесь утилита проявила себя гораздо эффективнее. Вместо банальной констатации факта, что раздел системных данных занимает слишком много места, ИИ углубился в анализ вложенных каталогов и выявил конкретные причины. В их числе оказались 12 ГБ кэша менеджера пакетов uv, устаревшие служебные файлы и массивные данные Docker. Что еще важнее, ассистент подробно объяснил назначение каждого такого объекта и оценил целесообразность его удаления, избавив от необходимости самостоятельно блуждать по незнакомым системным директориям в страхе случайно повредить важные компоненты.

Разумеется, обнаружение всего этого мусора было лишь половиной дела — его требовалось физически удалить. Ранее уже приходилось задействовать аналогичные инструменты для очистки накопителя, что позволило вернуть почти 60 ГБ свободного пространства на том же самом MacBook. Это подтвердило высокую практическую пользу предоставления ИИ-агенту доступа к файловой системе для наведения порядка. Однако в этот раз загроможденный накопитель оказался лишь малой частью масштабной проблемы.

Нехватка оперативной памяти и нагрузка на систему

Да, приобретение ноутбука с 8 ГБ памяти трудно назвать дальновидным шагом. В свое оправдание можно сказать, что устройство покупалось четыре года назад, когда никто не предполагал сценарий, при котором одновременно придется запускать среду разработки, Docker, Slack, Spotify, саму утилиту и десятки вкладок в браузере, вынуждая их конкурировать за скромные ресурсы. Проведенный аудит со всей очевидностью показал, что эти 8 ГБ работают на пределе возможностей.

В момент проверки macOS уже задействовала около 2,9 ГБ пространства подкачки (swap), что свидетельствует о регулярном обращении к твердотельному накопителю при исчерпании физической памяти. Ассистент прямо указал на совокупность запущенных процессов вроде Zen, Docker, Slack, Spotify, Claude и IntelliJ как на причину критической нагрузки на столь ограниченный объем ОЗУ.

Анализ аппетитов браузера и фоновых процессов

В ходе проверки выяснилось, что главный потребитель памяти — веб-браузер. Браузер Zen удерживал около 1,7 ГБ ОЗУ, распределенных по 44 процессам, что составляло порядка 23 % всей физической памяти компьютера. Справедливости ради, искусственный интеллект не обнаружил каких-либо аномалий в работе самого приложения: примерно 30 процессов приходилось на отдельные вкладки, что абсолютно нормально для движка на базе Firefox. Проблема заключалась лишь в банальном переизбытке открытых страниц.

Куда более тревожным симптомом выступали действия самой операционной системы по поддержанию стабильности. Система зафиксировала использование примерно 3 ГБ сжатой памяти и от 5,5 до 6,6 ГБ файла подкачки. Последующий мониторинг в течение нескольких минут должен был показать, является ли это следствием прошлой рабочей сессии, однако диагностика подтвердила: данные продолжали активно переноситься между оперативной памятью и SSD.

Любопытно, что многие программы, на которые пал бы первый подозрение, в тот момент даже не функционировали. Docker, IntelliJ, VS Code, Notion, Discord и ряд других утилит были выключены, а все восемь приложений из списка автозагрузки находились в неактивном состоянии. Zen удерживал абсолютное лидерство по потреблению памяти, за ним с большим отрывом следовали сам помощник (около 357 МБ), Spotify (132 МБ) и Slack (110 МБ).

К сожалению, в данной ситуации ИИ не мог совершить чудо. Не существовало какого-то одного зависшего процесса на несколько гигабайт, который можно было бы просто принудительно завершить. Наиболее эффективными мерами оставались банальные действия: переход на другой браузер, сокращение числа одновременно открытых вкладок, а также закрытие мессенджеров и музыкальных клиентов в периоды бездействия.

Автоматизация рутины

В определенный момент стало очевидно, что главная ценность подобных инструментов заключается не только в диагностике неполадок. Они помогают системно бороться с мелкими, повторяющимися неудобствами, которые незаметно накапливаются месяцами. Ведь та же папка «Загрузки» забивается хламом вовсе не из-за какого-то одного неудачного дня.

Беспорядок на диске образовался не из-за единого крупного файла, а из-за постоянной загрузки установщиков, пресс-китов, изображений и случайных документов, к которым руки так и не доходили. Накопление мусора происходило постепенно на фоне общего бездействия. Перестав воспринимать Claude Code исключительно как инструмент диагностики, автор материала переключился на создание небольших сценариев автоматизации для устранения повседневных раздражающих факторов.

Вместо ручной проверки состояния памяти или поиска забивающих пространство папок инструмент стал основой для создания быстрых скриптов. Один из первых созданных скриптов позволил запускать полноценный экспресс-аудит системы одной командой. Теперь при появлении признаков замедления компьютера достаточно ввести простую команду, чтобы мгновенно увидеть объем свободного места, уровень нагрузки на оперативную память, использование файла подкачки, а также процессы, потребляющие больше всего ресурсов CPU и RAM.

Кроме того, удалось автоматизировать рутинные действия, которые повторяются изо дня в день. Подготовка к работе обычно требует запуска стандартного набора приложений: браузера, корпоративного мессенджера, среды разработки и других привычных инструментов. С помощью Claude Code был написан специальный скрипт для рабочего режима, который берет эту подготовку на себя, изнуряя необходимостью открывать каждое приложение вручную.

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

Источник: xda-developers.com