Команда AI for Devs подготовила перевод большого гайда о скрытых возможностях и продвинутых техниках работы с Gemini CLI. Если для вас терминал — рабочий дом, то этот материал покажет, как превратить Gemini CLI в полноценного ИИ-агента, который автоматизирует рутину, подключается к внешним сервисам и расширяется под любые задачи.

---

Это руководство собрало около трёх десятков продвинутых советов по эффективной работе с Gemini CLI в режиме агентного программирования.

Gemini CLI — это Open source-ассистент на базе ИИ, который переносит возможности модели Google Gemini прямо в ваш терминал. Он работает как диалоговый «агентный» инструмент командной строки: понимает ваши запросы, выбирает подходящие инструменты (например, выполнение shell-команд или редактирование файлов) и способен выполнять многошаговые планы, помогая вам в процессе разработки.

Если говорить проще, Gemini CLI — это прокачанный напарник-программист и помощник в терминале. Он отлично справляется с задачами по кодингу, отладке, генерации контента и даже автоматизации системы — и всё это через обычные текстовые запросы. Прежде чем перейти к продвинутым советам, кратко вспомним, как настроить и запустить Gemini CLI.

Начало работы

Установка. Установить Gemini CLI можно через npm. Для глобальной установки используйте:

npm install -g @google/gemini-cli

Или запустите без установки с помощью npx:

npx @google/gemini-cli

Gemini CLI доступен на всех основных платформах (он написан на Node.js/TypeScript). После установки просто выполните команду gemini в терминале, чтобы открыть интерактивный интерфейс.

Аутентификация. При первом запуске вам нужно будет пройти авторизацию в сервисе Gemini. Доступны два варианта:

1. Вход через Google-аккаунт (бесплатный тариф). Позволяет бесплатно использовать Gemini 2.5 Pro с щедрыми лимитами (примерно 60 запросов в минуту и 1000 запросов в день). При запуске Gemini CLI предложит войти в Google-аккаунт. Данные карты не требуются.

2. API-ключ (платный или расширенный доступ). Получите ключ в Google AI Studio и задайте переменную окружения GEMINI_API_KEY, чтобы использовать его.

Использование API-ключа даёт повышенные квоты и корпоративную защиту данных. Промпты не используются для обучения при платном/биллингованном использовании, хотя логи могут сохраняться в целях безопасности.

Например, добавьте в профиль вашего shell:

export GEMINI_API_KEY="YOUR_KEY_HERE"

Базовое использование. Чтобы запустить интерактивную сессию, просто выполните gemini без аргументов. Появится приглашение gemini>, где вы можете вводить запросы или команды. Например:

$ gemini
gemini> Create a React recipe management app using SQLite

После этого Gemini CLI сможет создавать файлы, устанавливать зависимости, запускать тесты и выполнять другие действия для выполнения вашего запроса.

gemini -p "Summarize the main points of the attached file. @./report.txt"

Эта команда выведет один ответ и завершит работу. Можно также передавать ввод через конвейер: например, echo "Count to 10" | gemini — передаст запрос через stdin.

Интерфейс CLI. Gemini CLI предоставляет удобный интерфейс в стиле REPL. Он поддерживает:

• slash-команды — специальные команды, начинающиеся с /, для управления сессией, инструментами и настройками;

• bang-команды — начинающиеся с !, для прямого выполнения shell-команд.

Мы подробно разберём их в разделе с продвинутыми советами.

По умолчанию Gemini CLI работает в безопасном режиме: любые действия, которые могут изменить систему (запись файлов, выполнение команд и т. д.), требуют подтверждения. Перед выполнением инструмент покажет diff или команду и спросит разрешение (Y/n). Это защищает от нежелательных изменений.

Теперь, когда основы понятны, перейдём к серии советов и скрытых возможностей, которые помогут вам выжать максимум из Gemini CLI. Каждый совет сопровождается коротким примером, а затем — подробным объяснением и тонкостями. Эти рекомендации основаны на опыте разработчиков инструмента (включая Тейлора Маллена), команды Google Developer Relations и сообщества — чтобы стать полноценным справочником для продвинутых пользователей Gemini CLI.

Совет 1: Используйте GEMINI.md для постоянного контекста

Краткий пример использования: перестаньте повторять одни и те же инструкции в каждом запросе. Добавьте в проект файл GEMINI.md с важными сведениями или правилами — и ИИ будет автоматически учитывать их при работе, без необходимости каждый раз напоминать.

Во время разработки у проекта почти всегда есть какие-то общие правила: рекомендации по стилю, архитектурные принципы, важные факты. Gemini CLI позволяет зафиксировать всё это в одном или нескольких файлах GEMINI.md. Просто создайте в проекте папку .gemini (если её ещё нет) и добавьте туда Markdown-файл с именем GEMINI.md, содержащий любые инструкции, которые должны сохраняться. Например:

# Project Phoenix - AI Assistant

- All Python code must follow PEP 8 style.  
- Use 4 spaces for indentation.  
- The user is building a data pipeline; prefer functional programming paradigms.

Поместите файл в корень проекта (или в подкаталоги — для более точного локального контекста). Теперь при запуске gemini в этом проекте инструмент автоматически загрузит эти инструкции. Модель всегда будет учитывать их, и вам не придётся приписывать одно и то же к каждому запросу.

Как это работает: Gemini CLI использует иерархическую систему загрузки контекста. Он комбинирует:

• глобальный контекст из ~/.gemini/GEMINI.md (подходит для общих настроек, актуальных для всех проектов);

• проектный GEMINI.md;

• контекстные файлы в подкаталогах.

Более конкретные файлы переопределяют общие. Проверить, какой контекст загружен, можно командой:

/memory show

Эта команда показывается полный комбинированный контекст, видимый ИИ. Если вы обновили GEMINI.md, выполните:  /memory refresh чтобы перезагрузить контекст без перезапуска сессии.

Профессиональный лайфхак. используйте slash-команду /init, чтобы быстро создать шаблонный GEMINI.md. В новом проекте она сформирует стартовый файл с информацией об обнаруженном стеке, кратком описании проекта и другим полезным содержимым. После этого вы можете дополнять файл вручную.

Для больших проектов имеет смысл разделить контекст на несколько файлов и подключать их в GEMINI.md с помощью синтаксиса @include. Например, в основном GEMINI.md могут быть строки:@./docs/prompt-guidelines.md это позволяет держать инструкции структурированными и не перегружать один файл.

При хорошо продуманном GEMINI.md вы фактически даёте Gemini CLI «память» о требованиях и правилах проекта. Такой постоянный контекст делает ответы более точными и сокращает необходимость тонкой настройки промптов.

Совет 2: Создавайте собственные slash-команды

Краткий пример использования: ускоряйте повторяющиеся задачи, определяя свои slash-команды. Например, можно сделать команду /test:gen, которая генерирует юнит-тесты по описанию, или /db:reset, которая удаляет и заново создаёт тестовую базу данных. Так вы расширяете возможности Gemini CLI удобными однострочными командами, адаптированными под ваш рабочий процесс.

Gemini CLI поддерживает кастомные slash-команды, которые задаются в простых конфигурационных файлах. По сути, это заранее подготовленные шаблоны промптов. Чтобы создать такую команду, добавьте каталог commands/ либо в ~/.gemini/ (для глобальных команд), либо в .gemini/ вашего проекта (для проектных команд).

Внутри commands/ создавайте отдельный TOML-файл на каждую новую команду. Имя файла определяет имя команды: например, файл test/gen.toml создаёт команду /test:gen.

Рассмотрим пример. Пусть вам нужна команда, генерирующая юнит-тест по текстовому описанию требования. Создайте файл:

# Invoked as: /test:gen "Description of the test"  
description \= "Generates a unit test based on a requirement."  
prompt \= """  
You are an expert test engineer. Based on the following requirement, please write a comprehensive unit test using the Jest framework.

Requirement: {{args}}  
"""

Теперь, после перезагрузки или перезапуска Gemini CLI вы можете просто ввести:

/test:gen "Ensure the login button redirects to the dashboard upon success"

Gemini CLI распознает /test:gen и подставит {{args}} из шаблона промпта в виде переданного аргумента (в данном случае — описания требования). Затем ИИ сгенерирует соответствующий юнит-тест на Jest. Поле description необязательное, но оно используется при вызове /help или /tools, чтобы отображать список доступных команд.

Этот механизм невероятно мощный — по сути, вы «скриптуете» ИИ на естественном языке. Сообщество уже создало множество полезных кастомных команд. Например, команда Google DevRel опубликовала набор из десяти практичных workflow-команд (в Open source-репозитории), показывающих, как можно автоматизировать частые шаги: создание API-документации, очистку данных, генерацию boilerplate-кода и многое другое. Определив кастомную команду, вы упаковываете сложный промпт (или даже серию промптов) в удобный многократно используемый ярлык.

Профессиональный лайфхак. Кастомные команды также можно использовать для задания строгого формата вывода или применения определённой «персоны» ИИ под конкретные задачи. Например, команда /review:security может всегда начинать промпт со слов: «Вы — аудитор по безопасности…», чтобы проводить анализ кода на уязвимости. Такой подход обеспечивает стабильность и единообразие результатов для определённых типов задач.

Чтобы делиться командами с командой разработки, просто закоммитьте TOML-файлы в репозиторий проекта (каталог .gemini/commands). Все, у кого установлен Gemini CLI, автоматически смогут использовать эти команды при работе над проектом. Это — отличный способ стандартизировать AI-помощь в рамках команды.

Совет 3: Расширяйте возможности Gemini с помощью собственных MCP-серверов

Быстрый пример использования: допустим, вам нужно, чтобы Gemini умел работать с внешней системой или кастомным инструментом, которых нет “из коробки” — например, выполнять запросы к проприетарной базе данных или интегрироваться с макетами в Figma. Это можно сделать, запустив собственный сервер по протоколу Model Context Protocol (MCP) и подключив его к Gemini CLI. MCP-серверы позволяют добавлять в Gemini новые инструменты и возможности, фактически расширяя агента.

Gemini CLI поставляется с несколькими MCP-серверами по умолчанию (например, дающими доступ к Google Search, песочницам для выполнения кода и т.п.), и вы можете добавлять свои. MCP-сервер — это по сути внешний процесс (локальный скрипт, микросервис или даже облачный эндпоинт), который использует простой протокол для обработки задач от Gemini. Такая архитектура и делает Gemini CLI настолько расширяемым.

Примеры MCP-серверов: помимо Open source-решений сообщества, есть и интеграции от Google, например Figma MCP (получает данные из макетов Figma), Clipboard MCP (читает и записывает содержимое системного буфера обмена) и другие. Во внутреннем демо команда Gemini CLI показала MCP-сервер “Google Docs MCP”, который позволял сохранять контент напрямую в Google Docs. Идея в том, что когда Gemini нужно выполнить действие, которого нет среди встроенных инструментов, он может делегировать его вашему MCP-серверу.

Как добавить MCP-сервер: вы можете настроить их через settings.json или через CLI. Для быстрого варианта используйте CLI-команду:

gemini mcp add myserver --command "python3 my_mcp_server.py" --port 8080

Эта команда зарегистрирует сервер с именем «myserver», который Gemini CLI будет запускать, выполняя указанный команд (здесь Python-модуль) на порту 8080. В файле ~/.gemini/settings.json появится запись в секции mcpServers. Например:

"mcpServers": {
  "myserver": {
    "command": "python3",
    "args": ["-m", "my_mcp_server", "--port", "8080"],
    "cwd": "./mcp_tools/python",
    "timeout": 15000
  }
}

Эта конфигурация (основанная на официальной документации) говорит Gemini, как запускать MCP-сервер и где он работает. После запуска инструменты, которые предоставляет сервер, становятся доступны в Gemini CLI. Посмотреть список всех MCP-серверов и их инструментов можно с помощью команды:

/mcp

Она покажет все зарегистрированные серверы и названия инструментов, которые они предоставляют.

Сила MCP: MCP-серверы могут возвращать насыщенные мультимодальные результаты. Например, инструмент, предоставляемый MCP, может вернуть изображение или отформатированную таблицу в ответе для Gemini CLI. Они также поддерживают OAuth 2.0, так что можно безопасно подключаться к API (Google, GitHub и т.д.) через MCP-инструмент, не раскрывая креды. По сути, если вы можете это закодить, вы можете обернуть это как MCP-инструмент — превращая Gemini CLI в хаб, который управляет множеством сервисов.

Встроенные инструменты против кастомных: встроенные возможности Gemini CLI покрывают многое (чтение файлов, поиск в интернете, выполнение shell-команд и т.д.), но MCP позволяет идти дальше. Продвинутые пользователи создают MCP-серверы для работы с внутренними системами или для специализированной обработки данных. Например, можно сделать database-mcp, предоставляющий инструмент /query_db для выполнения SQL-запросов к корпоративной базе данных, или jira-mcp — для создания тикетов в Jira в формате естественного языка.

Создавая свой MCP-сервер, не забывайте о безопасности: по умолчанию пользователь должен подтверждать действия кастомных MCP-инструментов, если только сервер не помечен как доверенный. Это регулируется параметрами вроде trust: true для сервера (автоматическое одобрение его действий) или белыми/чёрными списками инструментов.

Вкратце: MCP-серверы открывают практически безграничные возможности интеграции. Это продвинутая функция, которая превращает Gemini CLI в связующее звено между вашим AI-ассистентом и любой системой, с которой ему нужно работать. Если хотите написать свой сервер, загляните в официальный гид по MCP и примеры от сообщества.

Совет 4: Используйте добавление и вызов данных из памяти

Быстрый пример использования: храните важные факты “под рукой” у ИИ, добавляя их в его долговременную память. Например, узнав порт базы данных или API-токен, вы можете выполнить:

/memory add "Our staging RabbitMQ is on port 5673"

Это сохранит факт, чтобы вы (или ИИ) не забыли его позже. В любой момент можно вывести всё содержимое памяти командой /memory show.

Команды /memory — это простой, но мощный механизм постоянной памяти. Когда вы выполняете /memory add <text>, указанный текст добавляется в глобальный контекст проекта (технически — сохраняется в глобальный файл ~/.gemini/GEMINI.md или проектный GEMINI.md). Это вроде как написать заметку и прикрепить её к виртуальной доске у ИИ. После добавления ИИ всегда будет видеть эту заметку в контексте подсказки при будущих взаимодействиях — в том числе между сессиями.

Пример: вы отлаживаете проблему и находите нетривиальное наблюдение («Флаг конфигурации X_ENABLE должен быть выставлен в true, иначе сервис не стартует»). Если добавить это в память, то в будущем — когда вы или ИИ будете обсуждать связанную тему — этот критичный факт уже не потеряется, он будет в контексте.

Использование /memory:

• /memory add "<text>"  - Добавить факт или заметку в память (постоянный контекст). GEMINI.md обновляется сразу, с новой записью.

• /memory show - Показать всё содержимое памяти (то есть объединённый файл контекста, который сейчас загружен).

• /memory refresh - Перечитать контекст с диска (полезно, если вы вручную редактировали GEMINI.md вне Gemini CLI или если над ним работает несколько человек).

Так как память хранится в Markdown, вы можете редактировать GEMINI.md вручную, чтобы структурировать информацию. Команды /memory — удобный способ управлять этим прямо во время диалога, без открытия редактора.

Полезный совет: эта возможность отлично подходит для «журналов решений». Если вы во время обсуждения приходите к какому-то правилу или подходу (например, выбираете библиотеку или договариваетесь о стиле кода), добавьте это в память. Тогда ИИ будет помнить об этом и не станет противоречить договорённостям. Особенно полезно в длинных сессиях, которые могут продолжаться часами или днями: сохраняя ключевые моменты, вы компенсируете склонность модели забывать ранний контекст при разрастании диалога.

Ещё одно применение — личные заметки. Поскольку ~/.gemini/GEMINI.md (глобальная память) загружается во всех сессиях, вы можете хранить там общие предпочтения или важную информацию. Например: «Пользователя зовут Алиса. Общаться вежливо, избегать сленга». Это что-то вроде настройки “персоны” ИИ или глобальных знаний. Но учитывайте: глобальная память применяется ко всем проектам, так что не загромождайте её проектными деталями.

Подводя итог: возможности добавления и вызова памяти помогают Gemini CLI поддерживать состояние. Это своего рода база знаний, растущая вместе с вашим проектом. Пользуйтесь ею, чтобы не повторяться и не заставлять ИИ заново переоткрывать факты, которые вы уже сообщили.

Совет 5: Используйте чекпоинты и /restore как кнопку “Отменить”

Быстрый пример использования: если Gemini CLI внёс в ваши файлы серию изменений, результат которых вас не устраивает, вы можете моментально откатиться к предыдущему состоянию. Включите чекпоинты при запуске Gemini (или в настройках) и используйте команду /restore, чтобы отменить изменения — что-то вроде лёгкой версии git revert. Команда /restore возвращает рабочую директорию к сохранённому чекпоинту; состояние диалога может измениться в зависимости от того, как именно был создан чекпоинт.

Механизм чекпоинтов в Gemini CLI — это страховочная сетка. Когда он включён, CLI делает снимок файлов проекта перед каждым выполнением инструмента, который что-то модифицирует. Если что-то пошло не так, вы можете вернуться к последнему рабочему состоянию. По сути, это контроль версий для действий ИИ, при этом вам не нужно каждый раз вручную коммитить изменения в Git.

Как пользоваться: включить чекпоинты можно, запустив CLI с флагом --checkpointing:

gemini --checkpointing

В качестве альтернативы можно сделать это настройкой по умолчанию, добавив в конфиг "checkpointing": { "enabled": true } в settings.json. После включения вы заметите, что каждый раз, когда Gemini собирается что-то записать в файл, он выводит что-то вроде «Checkpoint saved.»

Если потом вы понимаете, что внесённое ИИ изменение оказалось неудачным, у вас есть два варианта:

• Выполнить /restore list (или просто /restore без аргументов), чтобы увидеть список недавних чекпоинтов с отметками времени и описаниями.

• Выполнить /restore <id>, чтобы откатиться к конкретному чекпоинту. Если id не указан и есть только один доступный чекпоинт, он будет восстановлен по умолчанию.

Например:

/restore

Gemini CLI может вывести:

0: [2025-09-22 10:30:15] Before running 'apply_patch'

1: [2025-09-22 10:45:02] Before running 'write_file'

После этого вы можете выполнить /restore 0, чтобы вернуть все изменения файлов (и даже контекст диалога) к состоянию на момент этого чекпоинта. Так можно “отменить” неудачный рефакторинг или любые другие правки, сделанные Gemini.

Что восстанавливается: чекпоинт фиксирует состояние вашей рабочей директории (все файлы, которые Gemini CLI имеет право менять) и рабочие файлы (контекст диалога тоже может быть восстановлен в зависимости от того, как был сделан чекпоинт). При восстановлении файлы перезаписываются на версию из снимка, а состояние диалога возвращается к тому моменту. Это похоже на путешествие во времени — ИИ откатывается к точке до того, как свернул не туда. Учитывайте, что внешние эффекты он не отменит (например, если ИИ запустил миграцию базы данных, она не откатится), но всё, что касается файловой системы и контекста чата, полностью контролируется.

Лучшие практики: стоит держать чекпоинты включёнными для всех нетривиальных задач. Нагрузка минимальна, а спокойствия добавляет много. Если понимаете, что чекпоинт не нужен (всё прошло гладко), его можно очистить или просто позволить следующему его перезаписать. Команда разработчиков особенно рекомендует включать checkpointing перед многошаговыми правками кода. Однако для критически важных проектов всё же используйте полноценный контроль версий (git) как основной источник защиты — считайте чекпоинты удобной “быстрой отменой”, а не полноценной системой VCS.

По сути, /restore позволяет работать с Gemini CLI уверенно: вы можете давать ИИ смелые задачи, зная, что у вас всегда есть кнопка «ОЙ, НЕТ» для отката.

Совет 6: Читайте Google Docs, Sheets и многое другое. Если у вас настроен Workspace MCP-сервер, вы можете просто вставить ссылку на документ, и MCP получит его — при наличии нужных прав

Быстрый пример использования: представьте, что у вас есть Google Doc или Google Sheet со спецификациями или данными, которые вы хотите передать ИИ. Вместо того чтобы копировать содержимое вручную, вы просто даёте ссылку — и при настроенном Workspace MCP-сервере Gemini CLI может сам получить и прочитать документ.

Например:

Summarize the requirements from this design doc: https://docs.google.com/document/d/<id>

Gemini сможет подтянуть содержимое документа и использовать его в ответе. Аналогично, он может читать Google Sheets или файлы из Drive по ссылке.

Как это работает: такие возможности обычно реализуются через интеграции MCP. Команда Google Gemini CLI создала (или работает над созданием) коннекторов для Google Workspace. Один из подходов — запустить небольшой MCP-сервер, который использует Google APIs (Docs API, Sheets API и т.д.), чтобы извлекать содержимое документа по URL или ID. После настройки у вас могут появиться слэш-команды или инструменты вроде /read_google_doc, или же будет работать автоопределение: Gemini CLI увидит ссылку на Google Doc и вызовет нужный инструмент сам.

Например, в демо подкаста Agent Factory команда использовала MCP-сервер Google Docs, чтобы сохранять сводку прямо в документ — а это значит, что они могли и читать содержимое документа. На практике вы можете сделать что-то вроде:

@https://docs.google.com/document/d/XYZ12345

Использование синтаксиса ссылки с @ (context reference) говорит Gemini CLI, что нужно получить ресурс. При настроенной интеграции с Google Docs содержимое документа подтянется так же, будто это локальный файл. Дальше ИИ может суммировать текст, отвечать на вопросы или любым образом его использовать.

То же касается Google Drive: если вы вставляете ссылку на файл, корректно настроенный инструмент Drive может загрузить или открыть файл (при наличии прав и доступа к API). Google Sheets можно подключить через MCP, который будет выполнять запросы или читать диапазоны ячеек. Тогда вы сможете спрашивать: «Какова сумма колонки budget в этой таблице [ссылка]?» — и ИИ выполнит вычисления.

Настройка: на данный момент интеграции с Google Workspace могут требовать некоторой подготовки — получения API-кредов, запуска MCP-сервера (например, того, который описывает Kanshi Tanaike), и т.п. Следите за репозиторием Gemini CLI и сообществом: вполне возможно, что официальный MCP для Google Docs станет доступен как плагин. Если хотите — можете написать свой, опираясь на руководства по использованию Google APIs в MCP-сервере. Обычно это включает OAuth (который Gemini CLI поддерживает для MCP) и реализацию инструментов вроде read_google_doc.

Совет по использованию: когда инструменты настроены, работать с ними просто — иногда достаточно упомянуть ссылку прямо в запросе (ИИ может автоматически вызвать нужный инструмент), или использовать слэш-команду, например /doc open <URL>. Введите /tools, чтобы посмотреть список доступных инструментов и команд — Gemini CLI показывает там всё, включая кастомные возможности.

Подводя итог: Gemini CLI умеет выходить за пределы вашей локальной файловой системы. Будь то Google Docs, Sheets, Drive или другой внешний источник данных — вы можете подтягивать данные по ссылке. Это избавляет от ручного копирования и делает работу естественной: просто укажите документ или датасет, и ИИ сам получит нужное. Так Gemini CLI превращается в полноценного ассимилятор знаний, который работает со всей информацией, к которой у вас есть доступ, а не только с файлами на диске.

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

Совет 7: Используйте @, чтобы передавать файлы и изображения как явный контекст

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

Explain this code to me: @./src/main.js

Эта команда включит содержимое src/main.js в подсказку (в пределах лимитов контекста Gemini), чтобы ИИ мог прочитать код и объяснить его.

Такая ссылка на файл через @ — одна из самых мощных возможностей Gemini CLI для разработчиков. Она убирает неоднозначность: вы не просите модель полагаться на память или догадки, вы буквально отдаёте ей файл на чтение. Это работает с исходниками, текстовыми документами, логами и т.п. Аналогично можно указывать целые директории:

Refactor the code in @./utils/ to use async/await.

Если путь оканчивается слэшем, Gemini CLI рекурсивно включит файлы из этой директории (разумно, с учётом ignore-файлов и ограничений размера). Это отлично подходит для рефакторинга или анализа нескольких файлов сразу — модель видит все связанные модули вместе.

Ещё интереснее то, что можно добавлять бинарные файлы, например изображения. Gemini CLI (используя мультимодальные возможности модели Gemini) понимает изображения. Например:

Describe what you see in this screenshot: @./design/mockup.png

Изображение будет передано модели. ИИ может ответить что-то вроде: «Это страница логина с синей кнопкой входа и изображением в шапке». Применений масса: обзор UI-макетов, организация фотографий (об этом в следующем совете), извлечение текста из картинок (Gemini умеет OCR).

Несколько замечаний о том, как эффективно использовать @:

• Ограничения по размеру файлов: Gemini 2.5 Pro обладает огромным контекстом (до 1 млн токенов), поэтому можно включать довольно крупные файлы или много файлов одновременно. Но очень большие файлы могут быть усечены. Если файл огромный (сотни тысяч строк), лучше разбить его или суммировать. Gemini CLI предупредит, если файл слишком большой и был частично пропущен.

• Автоматическое игнорирование: По умолчанию Gemini CLI учитывает .gitignore и .geminiignore при сборе содержимого директорий. Поэтому если вы напишете @./ в корне проекта, он не загрузит гигантские папки вроде node_modules. Вы можете настраивать игнорирование в .geminiignore по аналогии с .gitignore.

• Явный контекст важнее неявного: Тейлор Маллен (создатель Gemini CLI) подчёркивает, что стоит использовать @ для явной передачи контекста, а не надеяться на память модели или собственные пересказы. Так точнее и надёжнее — ИИ не будет додумывать. Когда возможно, давайте модели источник истины — код, конфиги, документацию — через ссылки @. Это заметно повышает точность.

• Можно указывать несколько ссылок сразу:

Compare @./foo.py and @./bar.py and tell me differences.

CLI включит оба файла. Просто учитывайте лимиты контекста — несколько крупных файлов могут занять много токенов.

Использование @ — это фактически способ «скармливать» знания Gemini CLI на лету. Оно превращает CLI в мультимодальный ридер, который работает и с текстом, и с изображениями. Если вы продвинутый пользователь, привыкайте к этому подходу — он быстрее и надёжнее, чем просить ИИ «открыть файл X и сделать Y» (который он может и не открыть сам). Вы явно даёте ему X — и получаете гарантированный результат.

Совет 8: Создание инструментов на лету (поручите Gemini писать вспомогательные утилиты)

Быстрый пример: если для текущей задачи пригодится небольшой скрипт или утилита, можно попросить Gemini CLI создать этот инструмент прямо в рамках вашей сессии. Например: «Напиши Python-скрипт, который пройдётся по всем JSON-файлам в этой папке и извлечёт поля ошибок». Gemini сгенерирует скрипт, который вы затем сможете выполнить через CLI. По сути, вы можете динамически расширять набор инструментов по ходу работы.

Gemini CLI не ограничивается заранее встроенными инструментами — он умеет писать новые, когда это необходимо. Часто это происходит неявно: если запрос сложный, ИИ может предложить создать временный файл с кодом и выполнить его. Но вы можете и явно управлять этим процессом:

• Создание скриптов: вы можете попросить Gemini написать скрипт или программу на любом нужном языке. Скорее всего, он воспользуется инструментом write_file, чтобы создать файл. Например:

Generate a Node.js script that reads all '.log' files in the current directory and reports the number of lines in each.

Gemini CLI подготовит код и, после вашего подтверждения, запишет его в файл (например, script.js). Затем вы сможете запустить его либо через команду оболочки с префиксом ! (например, !node script.js), либо попросив Gemini CLI выполнить его — ИИ может сам вызвать run_shell_command для запуска только что созданного скрипта, если сочтёт это частью решения.

• Временные инструменты через MCP: в более продвинутых сценариях ИИ может предложить поднять MCP-сервер для специализированных задач. Например, если запрос требует серьёзной обработки текста, удобнее которой заняться в Python, Gemini может сгенерировать простой MCP-сервер на Python и запустить его. Такое встречается реже, но демонстрирует, что ИИ способен «на лету» создавать нового «агента». (На одной из презентаций команды Gemini CLI шутливо говорили про «MCP-серверы для всего, включая LROwn» — намёк на то, что можно запустить копию самого Gemini или другой модели, хотя это скорее трюк, чем практическая польза.)

Главная выгода здесь — автоматизация. Вместо того чтобы каждый раз вручную останавливаться и писать вспомогательный скрипт, вы можете позволить ИИ сделать это прямо в процессе. Это похоже на работу с помощником, который по запросу создаёт нужные инструменты. Особенно полезно при преобразовании данных, пакетных операциях или разовых вычислениях, для которых встроенные средства не дают готового решения.

Тонкости и безопасность: когда Gemini CLI пишет код для нового инструмента, вам всё равно стоит просмотреть его перед запуском. Представление /diff (Gemini покажет изменения перед записью файла) — это ваш шанс проверить код. Убедитесь, что он делает именно то, что ожидается, и не содержит ничего вредоносного или деструктивного (ИИ не должен генерировать что-то опасное без прямого запроса, но, как и с любым кодом от ИИ, лучше перепроверить логику, особенно если скрипт что-то удаляет или массово изменяет).

Пример: допустим, у вас есть CSV-файл, и вам нужно отфильтровать его по сложному условию. Вы просите Gemini CLI сделать это, и он может ответить: «Я напишу Python-скрипт для разбора CSV и применения фильтра». После этого он создаёт filter_data.py. Вы подтверждаете, он запускает скрипт — и вы получаете результат, при этом, возможно, больше никогда к этому файлу не вернётесь. Такая разовая генерация инструментов — высший уровень: ИИ фактически расширяет свои возможности автономно.

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

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

Совет 9: Используйте Gemini CLI для устранения неполадок и настройки системы

Быстрый пример: вы можете запускать Gemini CLI вне кода и использовать его для общих задач в системе — фактически как умного помощника для вашей ОС. Если, например, ваш shell ведёт себя странно, можно открыть Gemini в домашней директории и сказать: «Исправь мой .bashrc, в нём ошибка». Gemini сможет открыть и отредактировать ваш конфиг.

Этот совет подчёркивает, что Gemini CLI — это не только инструмент для работы над проектами, но и ваш помощник по всей среде разработки. Многие используют его, чтобы настроить рабочее окружение или исправить проблемы на машине.

• Редактирование dotfiles: можно открыть конфигурацию shell (например, .bashrc или .zshrc), указав файл напрямую (@~/.bashrc), и попросить Gemini CLI оптимизировать или отладить её. Например: «Мой PATH не использует бинарники Go, можешь поправить .bashrc?» ИИ добавит корректную строку export. Перед сохранением он покажет diff, чтобы вы подтвердили изменения.

• Диагностика ошибок: если вы сталкиваетесь с непонятной ошибкой в терминале или логе, можно просто скопировать её и передать в Gemini CLI. Он проанализирует сообщение и предложит шаги для решения. Это похоже на использование StackOverflow или Google, только здесь ИИ напрямую изучает вашу ситуацию. Например: «Когда запускаю npm install, получаю EACCES — как исправить?» Gemini может определить, что это проблема с правами в node_modules, и подсказать сменить владельца директории или использовать корректный менеджер версий Node.

• Запуск вне проекта: если вы запускаете gemini в директории без .gemini-контекста, это всего лишь значит, что нет проектной информации — но CLI остаётся полностью рабочим. Это удобно для разовых задач по диагностике системы. У вас может не быть кода, но вы можете запускать shell-команды или позволить Gemini получать информацию из интернета. По сути, вы используете Gemini CLI как терминал с ИИ, который может что-то сделать за вас, а не просто поболтать.

• Настройка рабочей станции: хотите изменить настройку или установить новый инструмент? Можно попросить: «Установи Docker на мою систему» или «Настрой Git так, чтобы он подписывал коммиты с помощью GPG». CLI попробует выполнить шаги: может получить инструкции через поиск, а затем запустить нужные команды. Конечно, всегда проверяйте, что он делает, и подтверждайте команды — но это экономит время на многошаговых настройках. Реальный пример: один пользователь попросил Gemini CLI «включить автоскрытие Dock в macOS и убрать задержку», и ИИ выполнил необходимые команды defaults write.

Представляйте этот режим как использование Gemini CLI в роли «умного shell». Можно комбинировать это с советом 16 (режим shell passthrough): иногда вы можете перейти в режим !, чтобы что-то быстро проверить, а потом вернуться к ИИ, чтобы он проанализировал результат.

Предостережение: при системных действиях будьте аккуратны с командами, которые влияют на всю систему (например, rm -rf или изменения глобальных конфигов). Gemini CLI обычно спрашивает подтверждение и ничего не выполняет без вашего контроля. Но как продвинутому пользователю, важно понимать, какие изменения вносятся. Если сомневаетесь, попросите ИИ объяснить команду перед запуском (например: «Объясни, что делает defaults write com.apple.dock autohide-delay -float 0» — он охотно объяснит вместо немедленного выполнения).

Бонус по диагностике: ещё один полезный сценарий — попросить Gemini CLI просканировать логи или конфиги на ошибки. Например: «Проверь конфиг Apache на ошибки» (@httpd.conf) или «Просмотри syslog и найди ошибки вчера около 14:00» (@/var/log/syslog, если доступно). Это будто у вас есть напарник-сисадмин. Он может предложить вероятные причины сбоев и варианты исправления типовых проблем.

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

Совет 10: Режим YOLO — автоматическое выполнение действий инструментов (используйте с осторожностью)

Быстрый пример: если вы уверены в себе (или настроены на приключения), можно позволить Gemini CLI выполнять действия инструментов без вашего подтверждения каждый раз. Это и есть режим YOLO (You Only Live Once). Он включается флагом --yolo или нажатием Ctrl+Y в ходе сессии. В режиме YOLO, как только ИИ выбирает инструмент (например, запуск shell-команды или запись файла), он сразу выполняет действие — без вопроса «Подтвердить? (y/n)».

Зачем использовать YOLO? В первую очередь — ради скорости и удобства, если вы доверяете действиям ИИ. Опытные пользователи могут включать YOLO, когда делают много повторяющихся безопасных операций. Например, если вы просите Gemini сгенерировать 10 разных файлов подряд, постоянные подтверждения тормозят поток; YOLO позволит записать их все автоматически. Ещё один сценарий — использование Gemini CLI в полностью автоматизированном скрипте или CI-пайплайне: можно запустить его в headless режиме с --yolo, чтобы он не останавливался в ожидании подтверждений.

Чтобы сразу начать в режиме YOLO, запустите CLI командой:

gemini --yolo

Или короткий вариант. Gemini -y. В CLI появится заметный индикатор (например, другой приглашение или уведомление), что авто-подтверждение включено. Во время интерактивной сессии вы можете переключать режим в любой момент, нажав Ctrl+Y — обычно CLI показывает сообщение вроде «YOLO mode enabled (all actions auto-approved)» в нижней части экрана.

Большое предупреждение: режим YOLO мощный, но рискованный. Команда Gemini честно называет его режимом «для смельчаков» — то есть вы должны понимать, что ИИ потенциально может выполнить опасную команду без подтверждения. В обычном режиме, если ИИ решит выполнить rm -rf / (самый худший сценарий), вы просто откажетесь. В режиме YOLO команда выполнится немедленно (и, вероятно, испортит вам день). Хотя такие крайности маловероятны (у ИИ есть системные инструкции по безопасности), смысл подтверждений как раз в том, чтобы ловить нежелательные действия. YOLO убирает эту страховку.

Практика безопасного YOLO: если хотите удобства без полного риска, можно разрешить выполнение только отдельных команд. Например, в настройках можно указать, что определённые инструменты или шаблоны команд не требуют подтверждения (скажем, все git-команды или операции только для чтения). Gemini CLI действительно поддерживает конфигурацию для пропуска подтверждений у конкретных команд — например, можно настроить tools.shell.autoApprove: ["git ", "npm test"], чтобы они всегда выполнялись автоматически. Так вы избегаете глобального YOLO — «YOLO'ите» только безопасные команды. Другой подход — запускать Gemini в песочнице или контейнере при включённом YOLO, чтобы даже при неудачной команде ваша система оставалась в безопасности (у Gemini есть флаг --sandbox для запуска инструментов внутри Docker-контейнера).

Многие продвинутые пользователи часто переключают YOLO туда-обратно: включают его, когда серия небольших правок или запросов, и выключают перед любой серьёзной операцией. Вы можете делать так же, используя горячую клавишу для быстрого переключения.

Итог: YOLO снимает трение, но ценой контроля. Это продвинутая возможность, которой стоит пользоваться умеренно и осознанно. Она действительно демонстрирует доверие к ИИ (или безрассудство!). Если вы только начали работать с Gemini CLI, лучше избегать YOLO, пока не поймёте, какие решения ИИ предлагает чаще всего. Если всё же используете — позаботьтесь о версиях в Git или резервных копиях. На всякий случай.

(Если утешит — вы не одиноки. Сообщество нередко шутит: «Я включил YOLO, и Gemini сделал что-то безумное». Так что пользуйтесь, но… всё же помните: живём один раз.)

Совет 11: Headless режим и сценарии (запуск Gemini CLI в фоне)

Быстрый пример: вы можете использовать Gemini CLI в скриптах или автоматизации, запуская его в headless режиме. В этом случае вы передаёте подсказку (или даже целый диалог) через аргументы командной строки или переменные окружения, а Gemini CLI выдаёт результат и завершает работу. Это удобно для интеграции с другими инструментами или запуска задач ИИ по расписанию.

Например, чтобы получить одноразовый ответ без открытия REPL, вы уже видели, что можно использовать gemini -p "...prompt...". Это и есть headless режим: CLI выводит ответ модели и возвращает управление оболочке. Но на этом возможности не заканчиваются:

• Переопределение системного промпта: если вы хотите запустить Gemini CLI с кастомной «личностью» или собственным набором инструкций (отличным от встроенного), можно использовать переменную окружения GEMINI_SYSTEM_MD. Установив её, вы указываете Gemini CLI игнорировать встроенный системный промпт и использовать ваш файл. Например:

export GEMINI_SYSTEM_MD="/path/to/custom_system.md"
gemini -p "Perform task X with high caution"

В этом случае в качестве системного промпта (то есть «роли» и правил, которых должен придерживаться ИИ) будет загружен ваш custom_system.md перед выполнением запроса.
Альтернативный вариант: если установить GEMINI_SYSTEM_MD=true, CLI будет искать файл system.md в директории .gemini текущего проекта. Эта возможность — весьма продвинутая: по сути, вы можете заменить встроенный «мозг» CLI собственным набором инструкций. Некоторые пользователи делают так для специализированных рабочих процессов — например, чтобы смоделировать конкретную персону или навязать сверхжёсткие правила. Но используйте это аккуратно, так как замена основного промпта может повлиять на работу инструментов (во встроенном промпте есть важные указания о том, как ИИ выбирает и использует инструменты).

• Прямой запрос через CLI: помимо флага -p есть ещё -i (interactive prompt), который запускает сессию с начальным запросом и оставляет её открытой. Например: gemini -i "Hello, let's debug something" откроет REPL, и модель уже «услышит» приветствие. Это удобно, когда вы хотите, чтобы первый вопрос был задан сразу при запуске.

• Сценарии с использованием конвейеров shell: вы можете передавать в Gemini не только текст, но и файлы или вывод команд. Например: gemini -p "Summarize this log:" < big_log.txt передаст содержимое big_log.txt в запрос (после фразы «Summarize this log:»). Или можно написать: some_command | gemini -p "Given the above output, what went wrong?".Такой приём позволяет комбинировать возможности Unix-инструментов с анализом ИИ. Это тоже headless режим, так как операция однопроходная.

• Запуск в CI/CD: вы можете интегрировать Gemini CLI в процессы сборки. Например, пайплайн может запустить тесты, а затем использовать Gemini CLI для автоматического анализа упавших тестов и добавления комментария. С помощью флага -p и авторизации через переменные окружения это легко автоматизировать. (Разумеется, убедитесь, что окружение имеет нужный API-ключ или авторизацию.)

Ещё один приём для headless режима: флаг --format=json (или соответствующая настройка). Gemini CLI может выводить ответ в формате JSON вместо человекочитаемого текста. Это удобно для программной обработки — ваш скрипт может разобрать JSON, чтобы получить ответ или детали о выполненных действиях инструментов.

Почему headless режим важен: он превращает Gemini CLI из интерактивного помощника в бэкенд-сервис или утилиту, которую могут вызывать другие программы. Можно настроить cron-задачу, которая каждую ночь запускает запрос к Gemini CLI (например, генерирует отчёт или выполняет какую-то очистку на основе логики ИИ). Можно добавить кнопку в IDE, которая запускает headless вызов Gemini для определённой задачи.

Пример: допустим, вам нужен ежедневный дайджест новостей. Вы можете написать скрипт:

gemini -p "Web-fetch \"https://news.site/top-stories\" and extract the headlines, then write them to headlines.txt"

С флагом --yolo, возможно, чтобы утилита не запрашивала подтверждение записи файла. Такой скрипт использует инструмент web fetch для получения страницы и инструмент записи файла для сохранения заголовков — всё автоматически, без участия человека. Возможности практически безграничны, если рассматривать Gemini CLI как компонент, пригодный для сценариев и автоматизации.

Итог: headless режим открывает путь к автоматизации. Это мост между Gemini CLI и другими системами. Освоив его, вы сможете масштабировать использование ИИ — не только когда печатаете в терминале, но и когда вас нет рядом: ваш ИИ-агент сможет работать за вас.

(Подсказка: для действительно длительных и неинтерактивных задач стоит обратить внимание на «Plan»-режим Gemini CLI или на то, как он способен генерировать многошаговые планы без вмешательства. Но это уже более продвинутые темы. В большинстве случаев хорошо сформулированный одиночный запрос в headless режиме даёт отличный результат.)

Совет 12: Cохраняйте и возобновляйте чат-сессии

Быстрый пример: если вы час отлаживали проблему в Gemini CLI и вам нужно прерваться, не обязательно терять весь контекст переписки. Используйте /chat save <name>, чтобы сохранить текущую сессию. Позже (даже после перезапуска CLI) вы можете выполнить /chat resume <name>, чтобы продолжить с того же места. Так длинные диалоги можно ставить на паузу и без усилий возвращаться к ним.

По сути, в Gemini CLI встроен собственный менеджер чат-сессий. Команды, которые стоит знать:

• /chat save <tag> — сохраняет текущее состояние переписки под указанным вами тегом/именем. Тег работает как имя файла или ключ для этой сессии. Можете сохранять сколько угодно раз — если тег уже существует, он будет перезаписан. (Полезно давать осмысленные имена, например: chat save fix-docker-issue.)

• /chat list — показывает все сохранённые сессии (теги, которые вы использовали). Это помогает вспомнить, как вы называли предыдущие сохранения.

• /chat resume <tag> — восстанавливает сессию с указанным тегом, возвращая весь контекст и историю переписки в том состоянии, в котором они были на момент сохранения. Будто вы никуда не уходили. Можно сразу продолжать разговор.

• /chat share — (сохраняет в файл) позволяет поделиться всей перепиской с другим человеком, который сможет продолжить сессию. Почти как совместная работа.

Под капотом эти сессии, скорее всего, хранятся в ~/.gemini/chats/ или похожей директории. В них записаны сообщения переписки и всё связанное состояние. Эта возможность особенно полезна в ситуациях вроде:

• Длительные сессии отладки: иногда отладка вместе с ИИ превращается в долгий обмен сообщениями. Если не удаётся решить проблему за один подход, просто сохраните сессию и вернитесь позже (может быть, со свежей головой). ИИ «помнит» всё, что было раньше, потому что весь контекст загружается заново.

• Многодневные задачи: если вы используете Gemini CLI как помощника в проекте, у вас может быть отдельная чат-сессия «Рефакторинг модуля X», растянутая на несколько дней. Вы можете возобновлять именно её каждый день, чтобы контекст не сбрасывался. Параллельно может быть другая сессия — например, «Написать документацию», — сохранённая отдельно. Переключаться между задачами можно просто сохранив одну сессию и возобновив другую.

• Передача задач внутри команды: это скорее экспериментальный сценарий, но теоретически вы можете поделиться содержимым сохранённой сессии с коллегой (файлы, скорее всего, переносимы). Если он положит их в свой каталог .gemini и выполнит resume, он увидит тот же контекст. Более практичный подход к совместной работе — просто скопировать нужные вопросы и ответы из лога и использовать общий GEMINI.md или общий prompt, но важно, что данные сессии полностью принадлежат вам.

Пример использования:

/chat save api-upgrade

(Сессия сохранена как «api-upgrade»)

/quit

(Позже, после повторного открытия CLI)

$ gemini
gemini> /chat list

(Показывает: api-upgrade)

gemini> /chat resume api-upgrade

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

Полезный совет: используйте понятные, осмысленные теги при сохранении сессий. Вместо /chat save session1 лучше дать имя, связанное с темой (например, /chat save memory-leak-bug). Так позже будет проще найти нужную сессию через /chat list. Жёстких ограничений на количество сохранённых сессий не объявлено, но время от времени удалять старые — неплохая идея для поддержания порядка.

Эта возможность превращает Gemini CLI в постоянного помощника. Вы не теряете знания, накопленные в переписке — можно в любой момент поставить её на паузу и продолжить. Это выгодно отличает Gemini CLI от некоторых других AI-интерфейсов, которые забывают контекст после закрытия. Для продвинутых пользователей это означает возможность вести несколько параллельных веток работы с ИИ. Как вы держите несколько вкладок терминала для разных задач, так же можно сохранять несколько чат-сессий и возобновлять ту, что нужна здесь и сейчас.

Совет 13: Рабочее пространство с несколькими директориями — один Gemini, много папок

Быстрый пример: у вас проект разбит на несколько репозиториев или директорий? Вы можете запустить Gemini CLI так, чтобы он получил доступ ко всем сразу — тогда он будет видеть единое рабочее пространство. Например, если фронтенд и бэкенд лежат в разных папках, их можно указать обе, чтобы Gemini мог редактировать файлы или ссылаться на них в любом из них.

Есть два способа использовать режим с несколькими директориями:

Флаг при запуске: используйте --include-directories (или -I) при старте Gemini CLI. Например:

gemini --include-directories "../backend:../frontend"

Здесь предполагается, что вы запускаете команду, например, из директории scripts и хотите подключить две соседние папки. Вы указываете список путей, разделённых двоеточием. После этого Gemini CLI будет считать все эти директории частями одного большого рабочего пространства.

• Постоянная настройка: в settings.json можно указать"includeDirectories": ["path1", "path2", [...]](https://www.philschmid.de/gemini-cli cheatsheet#:~:text=,61AFEF%22%2C%20%22AccentPurple).

Это удобно, если вы хотите, чтобы определённые общие директории загружались всегда (например, папка со shared-библиотеками, которую используют несколько проектов). Пути могут быть относительными или абсолютными. В путях допускаются переменные окружения (например, ~/common-utils).

Когда режим нескольких директорий включён, контекст CLI и его инструменты учитывают файлы во всех подключённых локациях. Команда > /directory show показывает, какие директории входят в текущее рабочее пространство. Вы также можете динамически добавить директорию во время сессии с помощью /directory add <path> — она загрузится на лету (возможно, со сканированием для контекста так же, как при запуске).

Зачем нужен режим нескольких директорий? В микросервисной архитектуре или модульных кодовых базах часто бывает, что часть кода живёт в одном репо, а другая — в другом. Если запустить Gemini только в одной папке, он просто «не увидит» остальные. Объединив их, вы включаете сквозное понимание проектов. Например, вы можете сказать: «Обнови API-клиент во фронтенде, чтобы он соответствовал новым конечным точкам API в бэкенде» — и Gemini сможет открыть папку backend, посмотреть определения API и одновременно открыть код frontend, чтобы внести нужные правки. Без multi-dir режима пришлось бы обрабатывать обе части по отдельности и переносить информацию вручную.

Пример: допустим, у вас есть client/ и server/. Вы запускаете:

cd client
gemini --include-directories "../server"

Теперь, находясь в приглашении gemini>, если выполнить > !ls, вы увидите, что он может перечислять файлы как в client, так и в server (они могут отображаться как отдельные пути). Можно сделать, например:

Open server/routes/api.py and client/src/api.js side by side to compare function names.

ИИ будет иметь доступ к обоим файлам. Или вы можете сказать:

The API changed: the endpoint "/users/create" is now "/users/register". Update both backend and frontend accordingly.

Он сможет одновременно создать патч в backend-маршруте и обновить фронтендовый вызов fetch.

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

Совет внутри совета: даже если вы не используете multi-dir постоянно, вы всё равно можете ссылаться на файлы в любой части файловой системы через абсолютный путь в prompt’ах (@/path/to/file). Однако без multi-dir Gemini может не иметь права редактировать такие файлы или не догадаться заранее подгрузить их контекст. Multi-dir формально включает их в область видимости, так что он знает о всех файлах для задач вроде поиска или генерации кода по всему набору директорий.

Удаление директорий: при необходимости /directory remove <path> (или похожая команда) убирает директорию из рабочего пространства. Это используется реже, но пригодится, если вы добавили что-то случайно.

Итог: режим нескольких директорий объединяет весь контекст. Он незаменим для polyrepo-проектов или любых случаев, когда код разбит на части. Gemini CLI начинает работать как IDE, у которой открыт весь проект целиком. Для продвинутых пользователей это означает, что ни одна часть вашего проекта не остаётся вне зоны досягаемости ИИ.

Совет 14: Организуйте и очищайте файлы с помощью ИИ

Быстрый пример: надоел хаос в папке Downloads или беспорядок в проектных ассетах? Поручите это Gemini CLI — он может выступить в роли умного организатора. Дайте ему обзор директории, и он сможет классифицировать файлы и даже разложить их по подпапкам (с вашего разрешения). Например: «Приведи в порядок папку Downloads — перемести изображения в Images, PDF-файлы в Documents, а временные файлы удали».

Поскольку Gemini CLI может читать имена файлов, их размеры и даже заглядывать в содержимое, он способен принимать осознанные решения о структуре файлов. Один из созданных сообществом инструментов под названием Janitor AI демонстрирует этот подход: он работает через Gemini CLI, классифицируя файлы как «важные» или «мусор» и распределяя их по категориям. Процесс включает сканирование директории, анализ имён файлов, метаданных (и содержимого при необходимости), а затем перемещение файлов по категориям. Примечательно, что «мусор» не удаляется автоматически — такие файлы перемещаются в папку Trash для последующей проверки.

Вот как можно вручную повторить подобный процесс с помощью Gemini CLI:

1. Осмотреть директорию: С помощью prompt’а попросите Gemini перечислить и классифицировать файлы. Например:

List all files in the current directory and categorize them as "images", "videos", "documents", "archives", or "others".

Gemini может выполнить !ls или аналогичную команду, получить список файлов, затем проанализировать имена и расширения и предложить категории.

1. Составить план организации: Спросите Gemini, как он предложил бы разложить файлы. Например:

Propose a new folder structure for these files. I want to separate by type (Images, Videos, Documents, etc.). Also identify any files that seem like duplicates or unnecessary.

ИИ может ответить примерным планом: «Создать папки Images/, Videos/, Documents/, Archives/. Переместить X.png и Y.jpg в Images/; A.mp4 — в Videos/; и так далее. Файл temp.txt выглядит лишним (похоже на временный)».

1. Выполнить переносы с подтверждением: Затем вы можете попросить выполнить план. Gemini будет использовать команды оболочки вроде mv для каждого файла. Поскольку это изменения файловой системы, вы получите запросы подтверждения (если только не решите действовать без подтверждений). Аккуратно одобряйте операции. После завершения ваша директория окажется аккуратно организованной.

Во всём этом ключевую роль играет способность Gemini понимать естественный язык. Он может догадаться, что IMG_001.png — это изображение, а presentation.pdf — документ, даже если об этом явно не сказано. Он может даже открыть изображение (используя свою возможность анализа картинок), чтобы посмотреть, что на нём: например, отличить скриншот от фотографии или иконки — и переименовать или рассортировать соответственно.

Переименование файлов по их содержимому: Особенно впечатляющая возможность — попросить Gemini переименовать файлы так, чтобы их названия стали осмысленными. В статье Dev Community «7 Insane Gemini CLI Tips» описано, как Gemini может просканировать изображения и автоматически переименовать их по содержанию. Например, файл IMG_1234.jpg может превратиться в login_screen.jpg, если ИИ увидит, что это скриншот экрана входа.

Чтобы сделать это, можно попросить его, например:

For each .png image here, look at its content and rename it to something descriptive.

Gemini откроет каждое изображение (через инструмент анализа картинок), опишет его содержимое и затем предложит команду вида mv IMG_1234.png login_screen.png. Это может радикально улучшить организацию ассетов, особенно в дизайн-папках или каталогах с фотографиями.

Двухпроходный подход: В обсуждении Janitor AI отмечался двухэтапный процесс: сначала широкая классификация (важное / мусор / прочее), затем уточнение групп. Вы можете делать так же: сначала отделить файлы, которые, вероятно, можно удалить (например, крупные установочные .dmg или дубликаты), от тех, что нужно сохранить. Затем сосредоточиться на организации сохраняемых файлов. Всегда перепроверяйте то, что ИИ пометил как мусор: он может ошибиться, поэтому ручной контроль обязателен.

Совет по безопасности: Когда вы позволяете ИИ выполнять перемещения или удаление файлов, делайте резервные копии или хотя бы будьте готовы откатиться (/restore или свой собственный бэкап). Лучше провести «сухой прогон»: попросите Gemini вывести команды, которые он собирается выполнить (mv, mkdir и т.д.), но не запускать их — чтобы вы могли их проверить. Например: «Выведи список команд mv и mkdir, нужных для этого плана, но не выполняй их». После проверки вы можете либо выполнить их вручную, либо разрешить Gemini продолжить.

Это наглядный пример «нетипичного» использования Gemini CLI — он может не только писать код, но и помогать с системной уборкой, используя свою логику и анализ данных. Это экономит время и помогает навести порядок в хаосе. В конце концов, разработчики постоянно накапливают всякий мусор (логи, старые скрипты, загрузки), и ИИ-уборщик может оказаться очень кстати.

Совет 15: Cжимайте длинные переписки, чтобы не выйти за пределы контекста

Быстрый пример: если вы давно ведёте диалог в Gemini CLI, можно упереться в предел длины контекста модели или просто почувствовать, что сессия стала громоздкой. Используйте /compress, чтобы кратко пересказать переписку и заменить всю историю компактным резюме. Это освобождает место для дальнейшего обсуждения без необходимости начинать заново.

У больших языковых моделей есть фиксированное окно контекста (у Gemini 2.5 Pro оно очень большое, но всё же конечное). Если выйти за предел, модель может начать «забывать» ранние сообщения или терять связность. Команда /compress — это, по сути, автоматически созданный ИИ tl;dr вашей сессии, который сохраняет важные моменты.

Как это работает: Когда вы вводите /compress, Gemini CLI берёт всю переписку (кроме системного контекста) и строит резюме. Затем оно заменяет историю чата этим резюме в виде одного сообщения (системного или от ассистента), сохраняя ключевые детали, но убирая покадровый диалог. Gemini сообщит, что сжатие произошло. Например, после /compress вы увидите:

--- Переписка сжата ---

Краткое резюме: пользователь и ассистент отлаживали утечку памяти в приложении. Основные моменты: проблема, вероятно, в DataProcessor.js, где объекты не освобождаются. Ассистент предложил добавить логирование и указал на возможный бесконечный цикл. Пользователь собирается протестировать исправление.

--- Конец резюме ---

С этого момента модель использует только это резюме (и новые сообщения) как контекст того, что было раньше. Обычно этого вполне хватает, если резюме включило главное.

Когда применять сжатие: Лучше делать это до того, как вы упрётесь в лимит. Если видите, что переписка растянулась (сотни сообщений или много кода), — сжимайте заранее. В шпаргалке упоминается автоматическое сжатие (например, при превышении 60% от максимума). Если его включить, Gemini может сам выполнить compress и сообщить об этом. Если нет — всегда есть ручное /compress.

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

Пример с окном контекста: Представьте, что вы загрузили в контекст большую кодовую базу, передав множество файлов — и заняли почти миллион токенов (предел). Теперь хотите переключиться на другую часть проекта. Вместо того чтобы начинать новую сессию и терять всё понимание, можно сделать compress. Резюме «сожмёт» знания о коде (например: «Мы загрузили модули A, B, C. A содержит такие функции… B взаимодействует с C так-то…»). Теперь можно обсуждать новые вещи, сохранив обобщённое знание из старой части.

Память vs. Сжатие: Помните, что compress не сохраняет информацию в долгосрочную память — оно локально для сессии. Если есть факты, которые точно нельзя потерять, используйте Tip 4 (добавление в /memory) — такие записи переживут сжатие, потому что они будут подмешаны снова (из GEMINI.md). Сжатие предназначено для временного контента переписки.

Небольшая осторожность: После compress стиль ИИ может чуть измениться, ведь он как бы видит «новую» переписку с резюме. Он может повторно представиться или сменить тон. Можно подсказать ему: «Продолжаем отсюда… (мы сделали compress)», чтобы сгладить момент. На практике он обычно продолжает нормально.

Итого: Используйте /compress, когда сессия становится слишком длинной, чтобы сохранить производительность и актуальность. Это помогает Gemini CLI сосредоточиться на главном, а не на каждом шаге предыдущего диалога. Так вы сможете проводить многочасовые отладочные сессии или большие проектные обсуждения, не выходя за пределы «ментальной бумаги», на которой работает модель.

Совет 16: Передавайте команды оболочки через ! (разговаривайте с терминалом)

Быстрый пример: в любой момент работы с Gemini CLI вы можете выполнить настоящую команду оболочки, просто поставив перед ней !. Например, хотите посмотреть состояние git — введите !git status, и команда выполнится прямо в терминале. Вам не нужно переключаться между окнами или менять контекст — вы всё ещё в Gemini CLI, просто как бы говорите: «Сейчас быстро выполню эту команду».

Этот совет относится к режиму Shell Mode в Gemini CLI. Есть два способа им пользоваться:

• Одиночная команда: Поставьте ! в начале строки и добавьте любую команду с аргументами. Она выполнится в текущей рабочей директории, а вывод появится прямо в интерфейсе. Например:

!ls -lh src/

выведет список файлов в директории src — так же, как в обычном терминале. После вывода вы снова увидите приглашение Gemini и сможете продолжать разговор или выполнять новые команды.

• Постоянный режим shell: Если ввести просто ! и нажать Enter, Gemini CLI переключится в подрежим, где вы увидите shell-подсказку (обычно что-то вроде shell>). Теперь можно вводить несколько команд подряд — это по сути мини-оболочка внутри CLI. Выйти из режима можно, снова набрав ! на пустой строке (или exit). Например:

!
shell> pwd
/home/alice/project
shell> python --version
Python 3.x.x
shell> !

После последнего ! вы вернётесь в обычный режим приглашения Gemini.

Почему это полезно? Потому что работа разработчика — это постоянное чередование действий и вопросов. Вы можете обсуждать что-то с ИИ и внезапно понять, что нужно скомпилировать код или запустить тесты. Вместо того чтобы выходить из разговора, вы просто выполняете команду прямо здесь и передаёте результат обратно в чат. На самом деле Gemini CLI сам часто делает это в рамках работы инструментов (например, может автоматически выполнить !pytest, если вы попросили исправить тесты). Но у вас всегда есть полный контроль — можно делать всё вручную.

Примеры:

• После того как Gemini предложил исправление в коде, вы можете выполнить !npm run build, чтобы проверить сборку, затем скопировать ошибки и попросить ИИ помочь с их устранением.

• Если хотите открыть файл в vim или nano, можно запустить его командой !nano filename (хотя интерактивный редактор внутри интерфейса Gemini CLI может быть не самым удобным — лучше использовать встроенный редактор или свой IDE).

• Можно собирать данные для ИИ через shell: например, !grep TODO -R . чтобы найти все TODO в проекте, а затем попросить Gemini помочь их разобрать.

• Или выполнять обычные системные задачи: !pip install some-package и т.п., не выходя из CLI.

Плавная связка: одна из классных особенностей — то, как переписка может ссылаться на вывод команд. Например, вы можете выполнить !curl http://example.com, получить данные, увидеть вывод прямо в чате, а затем сразу сказать Gemini: «Отформатируй вывод выше в JSON». Поскольку этот вывод напечатан в переписке, ИИ может использовать его как контекст (если он не слишком большой).

Терминал как shell по умолчанию: Если вы постоянно запускаете команды через !, можно фактически сделать режим shell постоянным. Один способ — запустить Gemini CLI в определённом режиме инструмента (есть концепция default tool). Но проще: в начале сессии войдите в shell, набрав ! на пустой строке, если планируете много работать вручную, и выходите только когда хотите задать вопрос. Это почти превращает Gemini CLI в обычный терминал, в котором всегда рядом сидит помощник-ИИ.

Интеграция с планированием ИИ: Иногда Gemini CLI сам предложит выполнить shell-команду. Если вы подтверждаете, это по сути то же самое, что !command. Зная это, вы можете действовать самостоятельно: если Gemini тормозит или вам просто хочется попробовать что-то — не ждите его предложений, сделайте это сами и продолжайте разговор.

Итог: Префикс ! значит, что вам больше не нужно покидать Gemini CLI ради команд терминала. Он стирает границу между диалогом с ИИ и выполняемыми действиями на вашей системе. Для продвинутых пользователей это колоссальный плюс к эффективности — ваш ИИ и ваш терминал работают как единая среда.

Совет 17: Относитесь к любому CLI-инструменту как к потенциальному инструменту Gemini

Быстрый пример применения: Gemini CLI может задействовать любые консольные инструменты, установленные у вас в системе, как часть решения задач. У ИИ есть доступ к shell, поэтому если у вас стоят cURL, ImageMagick, git, Docker или что-то ещё, Gemini сможет вызвать их при необходимости. Иначе говоря, весь ваш $PATH — это набор инструментов для ИИ. Это радикально расширяет его возможности — далеко за пределы встроенных средств.

Например, вы просите: «Преобразуй все PNG-изображения в этой папке в формат WebP». Если у вас установлен утилита convert из ImageMagick, Gemini CLI может спланировать следующее: пройтись по файлам в цикле shell и запустить convert для каждого. В одном из недавних примеров в блоге как раз показывали подобный сценарий: пользователь попросил пакетно переконвертировать изображения, и Gemini выполнил однострочник shell с использованием convert.

Другой сценарий: «Задеплой моё приложение в Docker». Если Docker CLI доступен, ИИ может вызвать docker build и docker run по шагам. Или: «Используй FFmpeg, чтобы извлечь аудио из video.mp4» — он сформирует соответствующую команду ffmpeg.

Смысл этой рекомендации в следующем: Gemini не ограничен тем, что в него заложено (а возможностей у него и так много). Он умеет понять, как использовать доступные программы, чтобы достигнуть цели. Он знает распространённый синтаксис команд и при необходимости может прочитать справку (вызвав --help). Единственное ограничение — безопасность: по умолчанию он спрашивает подтверждение для любого run_shell_command. Но когда вы освоитесь, можно разрешить выполнение некоторых безобидных команд автоматически (см. настройки YOLO или allowed-tools).

Помните об окружении: «С большой силой приходит большая ответственность». Раз уж любой инструмент в shell доступен для использования, убедитесь, что в вашем $PATH нет того, что вы не хотели бы, чтобы ИИ запускал случайно. Здесь пригодится совет №19 (кастомный PATH): некоторые пользователи создают для Gemini ограниченный $PATH, чтобы он, например, не мог вызвать системные деструктивные команды или не запускал сам себя рекурсивно (чтобы избежать циклов). Смысл в том, что по умолчанию, если в $PATH есть gcc, terraform или что-нибудь ещё, Gemini теоретически может это вызвать. Это не значит, что он будет делать это просто так — только если задача действительно требует — но возможность есть.

Пример хода мыслей: Представьте, вы говорите Gemini CLI: «Запусти простой HTTP-сервер, который раздаёт текущую директорию». ИИ может решить: «Для этого подойдёт встроенный сервер Python». И выполнит !python3 -m http.server 8000. То есть он использовал системный инструмент (Python), чтобы поднять сервер. Это безобидный пример. Другой: «Проверь использование памяти на этой Linux-машине». ИИ может вызвать free -h или прочитать /proc/meminfo. Он фактически делает то, что сделал бы обычный админ, используя доступные команды.

Все инструменты — это расширения ИИ. Это уже почти футуристично, но по сути любая консольная программа — это «функция», которую ИИ может вызвать, чтобы расширить свои возможности. Нужно решить задачу по математике? Он может вызвать bc. Нужно обработать изображение? Он может воспользоваться утилитой для работы с изображениями. Нужен запрос к базе? Если установлен CLI-клиент и есть доступ, он сможет его использовать. Возможности огромны. В других фреймворках для ИИ это называют использованием инструментов, и Gemini CLI в целом доверяет своему агенту выбирать подходящее средство.

Когда что-то идёт не так. Обратная сторона — если ИИ неправильно понимает инструмент или «галлюцинирует» флаги. Он может попытаться вызвать несуществующую команду или использовать неверные параметры, что приведёт к ошибкам. Это не страшно — вы увидите ошибку и сможете исправить запрос. Более того, системный prompt Gemini CLI обычно заставляет его сначала делать dry-run (предложить команду), а не выполнять её сразу. Так что у вас будет шанс всё проверить. Со временем разработчики улучшают логику выбора инструментов, чтобы таких промахов становилось меньше.

Главная мысль в том, что Gemini CLI — это огромный швейцарский нож: не только со встроенными лезвиями, но и со всеми инструментами вашей операционной системы. Вам не нужно объяснять ему, как пользоваться стандартными утилитами — обычно он знает сам или может разобраться. Это серьёзно усиливает то, что вы можете сделать. По сути, это как иметь джуна или инженера по DevOps, который умеет запускать почти любую программу, установленную у вас в системе.

Если вы продвинутый пользователь, вы можете даже установить дополнительные CLI-инструменты специально для того, чтобы расширить возможности Gemini. Например, установив CLI для облачного сервиса (AWS CLI, GCloud CLI и т.п.), вы теоретически позволяете Gemini управлять облачными ресурсами по запросу. Но всегда убедитесь, что понимаете и контролируете запускаемые команды, особенно когда речь идёт о мощных инструментах (вам ведь не нужно случайно поднять огромные облачные инстансы). При разумном использовании этот принцип — всё является инструментом Gemini — и делает его возможности экспоненциально более широкими, когда вы интегрируете его в своё окружение.

Совет 18: Используйте мультимодальный ИИ — дайте Gemini «видеть» изображения и не только

Быстрый пример применения: Gemini CLI не ограничен текстом — он мультимодальный. Это значит, что он может анализировать изображения, диаграммы и даже PDF, если вы их ему передадите. Пользуйтесь этим. Например: «Вот скриншот окна с ошибкой, @./error.png — помоги разобраться». ИИ «увидит» изображение и даст ответ по делу.

Одно из сильных качеств модели Google Gemini (как и её предшественника PaLM2 в виде Codey) — понимание изображений. В Gemini CLI, если вы укажете файл через @, модель получит его содержимое. Она может описывать, классифицировать или рассуждать о том, что изображено. Мы уже говорили о переименовании изображений по содержимому (совет 14) и описании скриншотов (совет 7). Но можно придумать и другие творческие способы использовать это:

• Обратная связь по UI/UX: Если вы как разработчик работаете с дизайнерами, можно просто передать изображение интерфейса и попросить Gemini дать отзыв или сгенерировать код. Например: «Посмотри на этот UI-макет @mockup.png и набросай структуру React-компонентов». ИИ сможет распознать элементы на изображении (хедер, кнопки и т.д.) и предложить архитектуру кода.

• Организация изображений: Помимо переименования, у вас может быть папка со смешанными фото, и вы хотите разложить их по содержимому. «Разложи изображения из ./photos/ по подпапкам по темам (например, закаты, горы, люди)». ИИ сможет просмотреть каждое фото и определить категорию — примерно как это делают некоторые приложения для фотографий, только теперь вы можете автоматизировать это собственным скриптом через Gemini.

• OCR и извлечение данных: Если у вас есть скриншот ошибки или фото документа, Gemini нередко может считать с него текст. Например: «Извлеки текст из invoice.png и представь в структурированном формате». В одном примере из блога Google Cloud Gemini CLI обработал набор изображений счётов и выдал таблицу с информацией о каждом. То есть он сделал OCR + понимание контекста, чтобы извлечь номера счётов, даты, суммы — просто с изображений накладных. Это продвинутый сценарий, но полностью реализуемый благодаря мультимодельности.

• Понимание графиков и диаграмм: Если у вас есть скриншот графика, можно сказать: «Объясни основные выводы этого графика @chart.png». ИИ может интерпретировать оси и тенденции. Точность может варьироваться, но попробовать определённо стоит.

Чтобы сделать всё это практически полезным: когда вы используете @image.png, убедитесь, что изображение не слишком большое (хотя модель вполне справляется с довольно крупными). CLI, скорее всего, закодирует его и отправит модели. В ответе могут появиться описания или дальнейшие действия. Можно свободно сочетать текст и ссылки на изображения в одном запросе.

Не только изображения: CLI и сама модель потенциально могут работать и с PDF, и с аудио, конвертируя их через доступные инструменты. Например, если вы передадите @report.pdf, Gemini CLI может использовать утилиту для извлечения текста из PDF и затем его резюмировать. Если вы передадите @audio.mp3 и попросите транскрипцию, он может вызвать средство распознавания речи. В шпаргалке как раз упоминается, что можно передавать PDF, аудио и видео — очевидно, через вызов соответствующих внутренних инструментов или API. Так что запрос вроде «Расшифруй это интервью: @interview.wav» может работать (если не сейчас, то очень скоро, учитывая, что соответствующие Google API можно легко подключить).

Богатые форматы вывода: Мультимодальность также означает, что ИИ может возвращать изображения в ответ, если интеграция это поддерживает (в CLI они обычно не отображаются напрямую, но их можно, например, сохранить в файл или вывести в виде ASCII-графики). Возможности MCP позволяют инструментам возвращать изображения. Например, инструмент для рисования может сгенерировать картинку, а Gemini CLI сможет её представить пользователю (открыть, сохранить или выдать ссылку).

Важно: Сам CLI — текстовый, поэтому изображение в терминале вы не увидите (если только терминал не умеет ASCII-превью). Вы получите только анализ. В интеграции с VS Code изображения могут отображаться в окне чата.

Итог: не забывайте про «визуальное» в GUI, даже работая с Gemini CLI — он умеет обрабатывать картинку не хуже текста. Это открывает рабочие процессы вроде визуального дебагинга, помощи с дизайном, извлечения данных со скриншотов и многое другое — всё в одном инструменте. Это серьёзное преимущество, которого у многих CLI-инструментов пока нет. И по мере развития моделей мультимодальная поддержка будет становиться только мощнее — так что стоит учиться использовать её уже сейчас.

Совет 19: Настройте $PATH (и доступные инструменты) для стабильной работы

Быстрый пример применения: Если вы заметили, что Gemini CLI путается или вызывает не те программы, попробуйте запускать его с настроенным $PATH. Ограничив или переупорядочив доступные исполняемые файлы, вы можете предотвратить ситуации, когда ИИ запускает скрипт с похожим названием, который вы вовсе не имели в виду. По сути, вы создаёте для него «песочницу» из проверенных и надёжных инструментов.

Для большинства пользователей это не проблема, но для продвинутых, у кого много кастомных скриптов или по нескольку версий одних и тех же утилит, это может оказаться полезным. Разработчики отмечали ещё одну причину — избежание бесконечных циклов или странного поведения. Например, если gemini сам находится в $PATH, то ИИ в неудачном сценарии может попытаться вызвать gemini изнутри Gemini (довольно экзотично, но теоретически возможно). Или у вас есть команда test, которая конфликтует с чем-то другим — ИИ может вызвать «не тот» исполняемый файл.

Как задать PATH для Gemini. Самый простой способ — указать его прямо при запуске:

PATH=/usr/bin:/usr/local/bin gemini

Так вы запускаете Gemini CLI с ограниченным $PATH, содержащим только эти директории. Можно исключить те пути, где лежат экспериментальные или опасные скрипты. Альтернативный вариант — сделать небольшой shell-скрипт-обёртку, который очищает или настраивает $PATH, а затем вызывает gemini через exec.

Есть и другой подход — задать в окружении или конфигурации явный запрет на использование отдельных инструментов. Например, если вы категорически не хотите, чтобы ИИ когда-либо использовал rm или другую потенциально разрушительную утилиту, вы технически могли бы создать alias или фиктивный rm в безопасном $PATH, который ничего не делает (хотя это может нарушить обычную работу системы, так что, вероятно, лучше так не делать). Более корректный способ — использовать список исключений в настройках. В расширении или в settings.json можно исключить названия инструментов. Например:

"excludeTools": ["run_shell_command"]

Этот радикальный пример полностью запретил бы выполнение любых shell-команд (по сути, превратив Gemini в режим «только чтение»). Более тонкая настройка — как и в случае с пропуском подтверждений для некоторых команд — может выглядеть так:

"tools": {
  "exclude": ["apt-get", "shutdown"]
}

(Этот синтаксис приведён для примера; за точным использованием смотрите документацию.)

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

Предотвращение бесконечных циклов. У некоторых пользователей возникали ситуации, когда Gemini снова и снова читал собственный вывод или бесконечно перечитывал файлы. Настройка $PATH напрямую не устраняет такие логические циклы, но одна из причин может заключаться в том, что ИИ вызывает команду, которая снова запускает его самого. Поэтому важно исключить возможность случайного запуска другого экземпляра ИИ (например, вызова bard или gemini, если ему вдруг покажется, что это нужно). Удаление таких команд из $PATH (или их временное переименование) помогает.

Изоляция через sandbox. Ещё один вариант, помимо правки $PATH, — использовать режим --sandbox (он запускает инструменты в изолированной среде через Docker или Podman). В этом случае действия ИИ ограничены набором инструментов внутри образа. Можно предоставить Docker-образ с заранее подобранным набором утилит. Подход тяжеловесный, но максимально безопасный.

Кастомный PATH для отдельных задач. В разных проектах у вас могут быть разные требования к окружению. Например, в одном проекте нужно, чтобы использовалась определённая версия Node или локальная сборочная цепочка. Запуск gemini с $PATH, указывающим на нужные версии, заставит ИИ использовать именно их. По сути, относитесь к Gemini CLI как к обычному пользователю: он использует то окружение, которое вы ему задаёте. Если нужно, чтобы он выбрал gcc-10 вместо gcc-12, — настройте $PATH или переменную окружения CC.

Итог: это «ограждения» для безопасности работы. Как продвинутый пользователь, вы можете тонко настраивать условия, в которых работает ИИ. Если вы заметили нежелательные паттерны, связанные с использованием инструментов, корректировка $PATH — быстрый способ решения. В повседневной работе это может и не понадобиться, но в автоматизации или CI этот совет особенно ценен: дайте Gemini CLI контролируемое окружение. Тогда вы точно знаете, что он может и чего не может, — а значит, повышаете надёжность.

Совет 20: Следите за расходом токенов и снижайте его с помощью кеширования и статистики

Если у вас длинные сессии или вы многократно прикрепляете одни и те же большие файлы, вы можете снизить стоимость и задержку, включив кеширование токенов и отслеживая использование. При аутентификации через API-ключ или Vertex AI Gemini CLI автоматически повторно использует ранее отправленные системные инструкции и контекст — поэтому последующие запросы обходятся дешевле. Экономию видно прямо в CLI в реальном времени.

Как этим пользоваться

Используйте режим аутентификации, который поддерживает кеширование.Кеширование токенов доступно, когда вы входите с API-ключом Gemini или через Vertex AI. На сегодняшний день оно недоступно при входе через OAuth.

Просматривайте своё потребление и попадания в кеш. Во время сессии выполните команду stats. Она показывает общее число токенов и поле cached, если кеширование активно.

/stats

Описание команды и поведение поля cached задокументированы в справочнике по командам и FAQ. Google Gemini+1

Собирайте метрики в скриптах. В безынтерактивном режиме выводите JSON и парсите блок stats, где для каждой модели есть поле tokens.cached:

gemini -p "Summarize README" --output-format json

Руководство по headless-режиму описывает JSON-схему с учётом кешированных токенов. Google Gemini.

Сохранение сводки сессии в файл. Для CI или контроля бюджета можно записать JSON-сводку сессии на диск.

gemini -p "Analyze logs" --session-summary usage.json

Этот флаг указан в changelog. Google Gemini

При аутентификации через API-ключ или Vertex CLI автоматически переиспользует ранее отправленный контекст, поэтому в последующих запросах уходит меньше токенов. Если вы сохраняете GEMINI.md и ссылки на большие файлы неизменными между обращениями, количество попаданий в кеш растёт — в stats это отражается в виде cached tokens.

Совет 21: Используйте /copy для быстрого копирования в буфер обмена

Быстрый сценарий использования: мгновенно копируйте последний ответ или фрагмент кода из Gemini CLI в буфер обмена — без лишнего форматирования или номеров строк. Идеально подходит, когда нужно быстро вставить сгенерированный код в редактор или поделиться результатом с коллегой.

Когда Gemini CLI выводит ответ (особенно многострочный блок кода), его часто хочется сразу использовать где-то ещё. Слэш-команда /copy делает это без усилий, копируя в буфер обмена последний вывод CLI. В отличие от ручного выделения (которое может захватить номера строк или текст приглашения), /copy копирует только «сырой» контент ответа. Например, если Gemini сгенерировал 50-строчный Python-скрипт, достаточно набрать /copy — и весь этот скрипт окажется в буфере обмена, готовый к вставке. Не нужно прокручивать текст и вручную выделять его. Внутри Gemini CLI использует подходящую утилиту для работы с буфером обмена на вашей платформе (например, pbcopy на macOS, clip на Windows). После выполнения команды вы обычно увидите подтверждение — и можете вставлять скопированный текст куда угодно.

Как это работает: команде /copy нужен установленный инструмент для работы с буфером обмена. На macOS и Windows необходимые утилиты (соответственно pbcopy и clip) обычно уже предустановлены. В Linux может понадобиться установить xclip или xsel, чтобы /copy работала. После этого вы можете использовать /copy в любой момент после того, как Gemini CLI выведет ответ. Команда захватит весь последний вывод (даже очень длинный) и отбросит любые внутренние номера строк или оформление, которое CLI показывает на экране. Это избавляет от лишних артефактов при переносе содержимого. Небольшая возможность, но огромная экономия времени, когда вы итеративно работаете над кодом или собираете отчёт, который подготовил ИИ.

Полезный совет: если команда /copy не работает, стоит проверить, установлены ли утилиты для буфера обмена и доступны ли они в системе. Например, пользователям Ubuntu нужно выполнить sudo apt install xclip, чтобы включить копирование в буфер. После настройки /copy позволяет делиться выводом Gemini без трения: скопировал, вставил — и готово.

Совет 22: Используйте Ctrl+C как мастер — для shell-режима и выхода

Быстрый сценарий использования: одним нажатием Ctrl+C можно аккуратно прервать работу Gemini CLI или выйти из shell-режима, а двойным нажатием — полностью закрыть CLI. Это даёт вам полный контроль, когда нужно что-то остановить или выйти.

Gemini CLI работает как REPL, поэтому важно понимать, как из него корректно выходить. Однократное нажатие Ctrl+C прерывает текущую операцию или очищает ввод, который вы начали набирать — по сути, действует как команда «отмена». Например, если ИИ генерирует длинный ответ, а вы уже увидели достаточно, нажмите Ctrl+C — генерация остановится мгновенно. Если вы начали набирать запрос, но передумали, Ctrl+C очистит строку ввода, чтобы начать заново. Кроме того, если вы находитесь в shell-режиме (он активируется, когда вы вводите ! для выполнения команд shell), одно нажатие Ctrl+C выведет вас обратно к обычной подсказке Gemini (отправляя interrupt работающему процессу shell). Это особенно удобно, если команда зависла или вы просто хотите вернуться в режим общения с ИИ.

Двукратное нажатие Ctrl+C подряд — это быстрый способ полностью выйти из Gemini CLI. Проще говоря: «один раз — отменить, два раза — выйти». Такой двойной вызов завершает сессию (вы увидите прощальное сообщение или программа закроется). Это быстрее, чем вводить /quit или закрывать окно терминала, и позволяет завершить работу аккуратно, не отрывая рук от клавиатуры. Имейте в виду, что одиночный Ctrl+C не выйдет из программы, если есть что прервать или очистить — для выхода требуется второй Ctrl+C, когда приглашение не занято. Такой подход не даёт случайно закрыть CLI, когда вы хотели только остановить вывод.

Полезный совет: в shell-режиме можно также нажать Esc, чтобы выйти из него и вернуться в режим чата с Gemini, не завершая CLI. Если же нужен «официальный» выход, команда /quit всегда под рукой. Кроме того, пользователи Unix могут нажать Ctrl+D (EOF) на пустой строке, чтобы выйти — Gemini CLI при необходимости попросит подтверждение. Но в большинстве ситуаций удобнее всего владеть приёмом с одним и двумя нажатиями Ctrl+C — это самый быстрый способ оставаться хозяином ситуации.

Совет 23: Настройте Gemini CLI с помощью settings.json

Быстрый сценарий использования: настройте поведение и внешний вид CLI под свои предпочтения или правила проекта, отредактировав конфигурационный файл settings.json, вместо того чтобы довольствоваться настройками «по умолчанию». Так вы можете задать тему оформления, правила использования инструментов, режим редактора и многое другое — и эти настройки будут работать во всех ваших сессиях.

Gemini CLI отлично настраивается. В домашней директории (~/.gemini/) или в папке проекта (.gemini/ внутри репозитория) можно создать файл settings.json и переопределить стандартные настройки. Через него можно управлять почти всеми аспектами CLI — от темы интерфейса до разрешений на использование инструментов. CLI объединяет настройки с разных уровней: системные значения по умолчанию, пользовательские настройки и проектные (проектные имеют приоритет над пользовательскими). Например, вы можете задать тёмную тему глобально, но для конкретного проекта включить более строгую песочницу для инструментов — и сделать это через разные файлы settings.json на каждом уровне.

Внутри settings.json параметры задаются в виде JSON-ключей и значений. Вот фрагмент, иллюстрирующий полезные варианты настройки:

{
"theme": "GitHub",
"autoAccept": false,
"vimMode": true,
"sandbox": "docker",
"includeDirectories": ["../shared-library", "~/common-utils"],
"usageStatisticsEnabled": true
}

В этом примере мы задаём тему оформления "GitHub" (популярная цветовая схема), отключаем autoAccept (чтобы CLI всегда спрашивал подтверждение перед запуском инструментов, которые могут что-то изменить), включаем Vim-привязки в редакторе ввода и принудительно используем Docker для песочницы инструментов. Мы также добавили несколько директорий в рабочий контекст (includeDirectories), чтобы Gemini по умолчанию видел код в общих путях. И, наконец, оставили usageStatisticsEnabled включённым, чтобы собирать базовую статистику использования (которая отправляется в телеметрию, если она включена). Существует гораздо больше доступных настроек — например, можно определить собственные цветовые темы, настроить лимиты токенов или разрешить/запретить конкретные инструменты — всё это подробно описано в руководстве по конфигурации. Подобная настройка позволяет адаптировать работу Gemini CLI под ваш рабочий процесс: кто-то всегда включает vimMode ради скорости, а кому-то удобнее стандартный редактор.

Один из самых удобных способов изменить настройки — воспользоваться встроенным интерфейсом настроек. Введите команду /settings в Gemini CLI, и откроется интерактивный редактор вашей конфигурации. В этом интерфейсе можно просматривать и искать параметры с описаниями, а также избегать ошибок в синтаксисе JSON — ввод проверяется автоматически. Через удобное меню вы можете настроить цвета, включить или выключить такие возможности, как yolo (автоподтверждение), изменить поведение checkpointing (сохранение и восстановление файлов) и многое другое. Все изменения сохраняются в ваш settings.json, и часть из них вступает в силу сразу (некоторые могут потребовать перезапуска CLI).

Полезный совет: держите отдельные файлы settings.json для разных проектов. Например, в командном проекте можно указать "sandbox": "docker" и "excludeTools": ["run_shell_command"], чтобы заблокировать опасные операции, а в личных проектах — разрешить прямые shell-команды. Gemini CLI автоматически найдёт ближайший .gemini/settings.json в дереве директорий проекта и объединит его с вашим глобальным ~/.gemini/settings.json. И не забывайте, что визуальные настройки можно быстро менять: используйте /theme, чтобы интерактивно переключать темы без редактирования файла — это отличный способ подобрать удобный вариант. Когда найдёте подходящий, добавьте его в settings.json, чтобы закрепить выбор.

Совет 24: Используйте интеграцию с IDE (VS Code) для контекста и сравнения изменений (diffs)

Быстрый сценарий использования: усиливайте работу Gemini CLI, подключив его к VS Code — тогда CLI будет автоматически понимать, над какими файлами вы работаете, и сможет открывать предлагаемые изменения кода прямо в дифф-редакторе VS Code. Это создаёт бесшовный цикл между ИИ-ассистентом и вашей рабочей средой.

Одна из сильных сторон Gemini CLI — интеграция с Visual Studio Code. Установив официальный расширение Gemini CLI Companion в VS Code и подключив его к CLI, вы даёте Gemini «видимость» вашего редактора. Что это означает на практике? После подключения Gemini знает, какие файлы у вас открыты, где находится курсор и какой текст выделен в VS Code. Вся эта информация передаётся в контекст ИИ. Поэтому, если вы спрашиваете: «Объясни эту функцию», Gemini CLI видит выделенную вами функцию и даёт точный ответ — без необходимости копировать код в запрос вручную. Интеграция передаёт до 10 последних открытых файлов, а также выделение и позицию курсора, обеспечивая модели глубокое понимание вашего рабочего пространства.

Ещё одно большое преимущество — встроенная работа с диффами. Когда Gemini CLI предлагает изменить ваш код (например, «отрефакторь эту функцию» и выдаёт патч), он может автоматически открыть эти изменения в дифф-просмотрщике VS Code. Вы увидите сравнение «до/после» бок о бок — в привычном интерфейсе VS Code. Там же можно просмотреть правки, внести дополнительные изменения вручную и принять патч одним кликом. При этом CLI и редактор остаются синхронизированными: если вы принимаете дифф в VS Code, Gemini CLI об этом узнаёт и продолжает сессию уже с учётом применённых изменений. Такой плотный цикл избавляет от необходимости копировать код из терминала в редактор — предложения ИИ поступают прямо в вашу рабочую среду.

Как всё настроить: если вы запускаете Gemini CLI во встроенном терминале VS Code, CLI обычно сам обнаруживает редактор и предложит установить и подключить расширение. Можно согласиться — и произойдёт автоматический запуск /ide install. Если приглашение не появилось (или вы включаете интеграцию позже), просто откройте Gemini CLI и выполните команду /ide install. Это загрузит и установит расширение Gemini CLI Companion в VS Code. Затем выполните /ide enable, чтобы установить соединение — CLI сообщит, что он подключён к VS Code. В любой момент можно проверить состояние командой /ide status, которая покажет, есть ли подключение, какой редактор используется и какие файлы отслеживаются. После этого Gemini CLI автоматически получает контекст из VS Code (открытые файлы, выделение) и открывает диффы в VS Code, когда это нужно. Фактически это превращает Gemini CLI в ИИ-напарника по программированию, который живёт в терминале, но работает с полным пониманием того, что происходит в вашем IDE.

В настоящий момент VS Code — основной поддерживаемый редактор для этой интеграции. (Другие редакторы, которые умеют работать с расширениями VS Code — например, VSCodium или некоторые JetBrains через плагин, — могут работать через то же расширение, но официально поддерживается именно VS Code.) Однако архитектура открыта — существует спецификация IDE Companion Spec, по которой можно разрабатывать похожие интеграции для других редакторов. Так что в будущем мы вполне можем увидеть полноценную поддержку IDE вроде IntelliJ или Vim через расширения от сообщества.

Полезный совет: после подключения вы можете управлять Gemini CLI прямо из VS Code через Command Palette. Нажмите Ctrl+Shift+P (или Cmd+Shift+P на Mac) и попробуйте команды вроде:

• Gemini CLI: Run — запускает новую CLI-сессию в терминале,

• Gemini CLI: Accept Diff — принять и применить открытый дифф,

• Gemini CLI: Close Diff Editor — отклонить изменения.

Эти команды ещё сильнее ускоряют рабочий процесс. И помните: вам не всегда нужно запускать CLI вручную — если интеграция включена, Gemini CLI фактически превращается в ИИ-соразработчика внутри VS Code, который следит за контекстом и готов помочь, пока вы пишете код.

Совет 25: Автоматизируйте задачи в репозитории с помощью GitHub Action для Gemini CLI

Быстрый сценарий использования: подключите Gemini прямо в GitHub — используйте GitHub Action для Gemini CLI, чтобы автоматически разбирать новые ишьи и просматривать pull request’ы в вашем репозитории. Так ИИ становится «тиммейтом», который берёт на себя рутину в процессе разработки.

Gemini CLI — это не только интерактивные сессии в терминале; его можно запускать и в CI/CD-пайплайнах через GitHub Actions. Google предоставляет готовый GitHub Action для Gemini CLI (сейчас в бета-версии), который можно встроить в рабочие процессы вашего репозитория. По сути, это развёртывание ИИ-агента внутри вашего проекта на GitHub. Он работает в фоне и реагирует на события репозитория.Например, когда кто-то создаёт новую ишью, Gemini Action может автоматически проанализировать её описание, проставить нужные ярлыки, расставить приоритеты или даже предложить возможные дубликаты — это называется «интеллектуальная триаж-система для ишью». Когда открывается pull request, Action подключается и делает AI-код-ревью: оставляет комментарии в PR с замечаниями по качеству кода, потенциальным багам или стилистическим улучшениям. Это даёт мейнтейнерам мгновенную обратную связь ещё до того, как PR увидит человек. Но, пожалуй, самая интересная возможность — работа по запросу. Участники команды могут упомянуть @gemini-cli в комментарии к ишье или PR и дать ему инструкцию, например:@gemini-cli please write unit tests for this. Action перехватит это упоминание, и Gemini CLI попытается выполнить задачу — например, добавить коммит с тестами. Фактически, это как ИИ-ассистент, который «живёт» в вашем репозитории и готов брать на себя рутинные задачи по первому запросу.

Настроить GitHub Action для Gemini CLI очень просто. Сначала убедитесь, что у вас локально установлена версия Gemini CLI 0.1.18 или новее — это важно для совместимости с Action. Затем в Gemini CLI выполните специальную команду: /setup-github. Эта команда сгенерирует нужные workflow-файлы в вашем репозитории (при необходимости проведёт через процесс аутентификации). В частности, она добавит YAML-файлы workflow’ов (для триажа ишью, ревью PR и т.п.) в каталог .github/workflows/. Далее вам нужно добавить свой ключ Gemini API в Secrets репозитория — под именем GEMINI_API_KEY, чтобы Action мог обращаться к API Gemini. Когда это сделано и workflow-файлы закоммичены, GitHub Action начинает работать автоматически. С этого момента Gemini CLI будет самостоятельно реагировать на новые ишью и pull request’ы в соответствии с заданными workflow.

Поскольку этот Action фактически запускает Gemini CLI в автоматическом режиме, вы можете настраивать его так же, как и обычный CLI. В стандартной установке поставляются три workflow — триаж ишью, ревью PR и общий ассистент, реагирующий на упоминания — и все они полностью Open source и доступны для редактирования. Вы можете изменять YAML-файлы, корректируя поведение ИИ, или даже добавлять собственные workflow. Например, можно создать ночной workflow, который будет запускать Gemini CLI для поиска устаревших зависимостей в репозитории или обновлять README с учётом недавних изменений в коде — вариантов бесконечно много. Главное преимущество в том, что рутинные или долгие задачи можно переложить на ИИ-агента, а разработчики смогут сосредоточиться на действительно сложных проблемах. И так как всё работает на инфраструктуре GitHub, вам не нужно следить за процессом — это по-настоящему «настроил один раз и забыл» ИИ-помощник.

Полезный совет: регулярно заглядывайте в логи GitHub Actions — это позволяет сохранять прозрачность работы ИИ. Логи Gemini CLI Action показывают, какие запросы он отправлял и какие изменения предлагал или вносил. Это помогает и сформировать доверие, и точнее настроить его поведение. Кроме того, в Action встроены защитные механизмы уровня enterprise — например, вы можете потребовать, чтобы любые shell-команды, которые ИИ пытается выполнить в workflow, были заранее вами разрешены. Поэтому не бойтесь использовать его даже в серьёзных проектах. И если вы создадите интересный кастомный workflow на базе Gemini CLI, подумайте о том, чтобы поделиться им с сообществом — проект открыт для новых идей!

Совет 26: Включайте телеметрию для аналитики и наблюдаемости

Быстрый сценарий использования: получите более глубокое понимание того, как используется и работает Gemini CLI, включив встроенную инструментализацию OpenTelemetry — отслеживайте метрики, логи и трейсы ваших AI-сессий, чтобы анализировать паттерны использования или устранять проблемы.

Для разработчиков, которым важно измерять и оптимизировать, Gemini CLI предлагает возможность наблюдаемости, раскрывающую то, что происходит «под капотом». Используя OpenTelemetry (OTEL), Gemini CLI может отправлять структурированные телеметрические данные о ваших сессиях. Это включает метрики (например, сколько токенов израсходовано, задержка ответа), логи выполненных действий и даже трейсы вызовов инструментов.

С включённой телеметрией вы можете отвечать на вопросы вроде:
— Какую кастомную команду я использую чаще всего?
— Сколько раз ИИ редактировал файлы в этом проекте за неделю?
— Какова средняя задержка ответа, когда я прошу CLI запустить тесты?

Такие данные незаменимы для понимания паттернов использования и производительности. Команды разработки могут увидеть, как именно разработчики взаимодействуют с ИИ-ассистентом и где могут возникать узкие места.

По умолчанию телеметрия выключена (Gemini уважает приватность и не тратит ресурсы без необходимости). Вы можете включить её, установив "telemetry.enabled": true в settings.json или запустив Gemini CLI с флагом --telemetry. Дополнительно вы выбираете, куда отправлять телеметрию: она может записываться локально или отправляться в бэкенд вроде Google Cloud. Для быстрого старта можно указать "telemetry.target": "local" — в этом режиме Gemini просто пишет телеметрические данные в локальный файл (по умолчанию) или в путь, который вы зададите параметром outfile. Локальная телеметрия представляет собой JSON-логи, которые можно парсить или передавать в другие инструменты. Для более серьёзного мониторинга установите "target": "gcp" (Google Cloud) или интегрируйтесь с любой другой системой, поддерживающей OpenTelemetry, такой как Jaeger или Datadog. Поддержка OTEL в Gemini CLI не привязана к конкретному вендору — данные можно экспортировать практически в любую наблюдательную систему (Google Cloud Operations, Prometheus и т.д.). Google предлагает особенно удобный путь для GCP: если указать GCP как цель, CLI сможет отправлять данные напрямую в Cloud Logging и Cloud Monitoring вашего проекта, где вы сможете использовать привычные дашборды и инструменты оповещений.

Какие именно данные вы можете получить? Телеметрия фиксирует события вроде выполнения инструментов, ошибок и ключевых этапов работы. Она также записывает метрики — время обработки запроса, количество токенов на каждый запрос и т.д. Для аналитики использования вы можете собрать статистику, как часто команда применяет те или иные слэш-команды или как часто вызывается генерация кода. Для мониторинга производительности можно отслеживать, не стали ли ответы медленнее — это может указывать, например, на приближение к лимитам API или изменения в модели. А для отладки вы увидите ошибки или исключения, возникающие в инструментах (например, сбой run_shell_command) вместе с контекстом. Все эти данные можно визуализировать, отправляя их в такие платформы, как Google Cloud Monitoring — например, построить дашборд «количество использованных токенов в день» или «частота ошибок инструмента X». По сути, это даёт вам окно в «мозг» ИИ и в собственные паттерны использования — особенно ценно для корпоративной среды, чтобы убедиться, что всё работает стабильно.

Включение телеметрии действительно добавляет небольшие накладные расходы (дополнительная обработка данных), поэтому для личного использования её необязательно держать включённой постоянно. Но она отлично подходит для отладочных сессий или периодических проверок состояния. Один из подходов — включать телеметрию на CI-сервере или в общей среде команды, чтобы собирать статистику, а локально держать её выключенной, пока не понадобится. Помните, что её можно включать и выключать «на лету»: обновить настройки и выполнить /memory refresh, если нужно перезагрузить конфигурацию, или просто перезапустить Gemini CLI с флагом --telemetry.Кроме того, вся телеметрия полностью находится под вашим контролем — она уважает переменные окружения для указания конечных точек и учётных данных, так что данные отправляются только туда, куда вы сами назначили. Эта возможность превращает Gemini CLI из «чёрного ящика» в полноценную наблюдательную систему, позволяющую увидеть, как ИИ-агент взаимодействует с вашим окружением — и постоянно улучшать это взаимодействие.

Полезный совет: если вам нужен быстрый взгляд на статистику текущей сессии (без полноценной телеметрии), используйте команду /stats. Она покажет такие метрики, как количество использованных токенов и длительность сессии, прямо в CLI. Это лёгкий способ получить моментальные данные. Но для долгосрочного анализа или изучения нескольких сессий телеметрия — лучший инструмент. И если вы отправляете телеметрию в облачный проект, имеет смысл настроить дашборды или оповещения (например, уведомление при всплеске ошибок или достижении порога по использованию токенов) — это поможет заранее замечать проблемы в том, как ваша команда использует Gemini CLI.

Совет 27: Следите за дорожной картой (фоновые агенты и многое другое)

Быстрый сценарий использования: следите за новыми возможностями Gemini CLI — благодаря публичной дорожной карте вы заранее узнаете о крупных планируемых улучшениях (например, фоновых агентах для долгих задач) и сможете подготовиться к ним или оставить обратную связь.

Gemini CLI развивается стремительно: новые версии выходят буквально одна за другой, так что полезно держать в поле зрения, что планируется дальше. У Google есть публичный roadmap для Gemini CLI на GitHub, где описаны ключевые направления и возможности, намеченные на ближайшее будущее. По сути, это «живой» документ (и набор ишью), в котором видно, над чем сейчас работают разработчики и что уже стоит в очереди.Например, один из самых интересных пунктов roadmap — поддержка фоновых агентов: возможность запускать автономные агенты, работающие в фоне и способные непрерывно или асинхронно выполнять задачи. Судя по обсуждениям, такие фоновые агенты позволят передавать долгие процессы на исполнение Gemini CLI, не блокируя вашу интерактивную сессию. Можно, например, запустить фоновый агент, который следит за определёнными событиями в вашем проекте или периодически выполняет задачи — как локально, так и с развертыванием на сервисе вроде Cloud Run. Эта возможность должна «обеспечить выполнение долгоживущих автономных задач и проактивную помощь» прямо из CLI, расширяя область применения Gemini CLI далеко за рамки запросов «по требованию».

Отслеживая roadmap, вы также узнаете о других запланированных возможностях. Это могут быть новые интеграции инструментов, поддержка дополнительных версий моделей Gemini, улучшения UI/UX и многое другое. Обычно roadmap сгруппирован по «областям» (например, Extensibility, Model, Background и т.д.) и часто размечен вехами (например, целевой квартал релиза). Это не гарантия точных сроков, но даёт хорошее понимание приоритетов команды. Поскольку проект Open source, вы можете заглянуть в связанные ишью на GitHub для каждого пункта roadmap, чтобы увидеть проектные предложения и ход работ. Для разработчиков, которые активно используют Gemini CLI, такая прозрачность означает возможность заранее готовиться к изменениям — например, увидеть, что в API появится нужная вам возможность, или что грядёт изменение, требующее подготовки.

Следить за roadmap проще простого: достаточно добавить в закладки проектную доску GitHub или ишью с меткой «Roadmap» и время от времени заглядывать туда. Некоторые крупные обновления (например, появление Extensions или интеграции с IDE) заранее мелькали в roadmap до официального анонса — так что это способ получить ранний взгляд на будущие фичи. Кроме того, команда Gemini CLI часто приглашает сообщество делиться обратной связью по планируемым возможностям. Если у вас есть идеи или кейсы для чего-то вроде фоновых агентов, обычно можно оставить комментарий в ишью или ветке обсуждения и повлиять на развитие функции.

Полезный совет: поскольку Gemini CLI — Open source-проект под лицензией Apache 2.0, вы можете не только наблюдать за roadmap, но и участвовать в его развитии! Мейнтейнеры охотно принимают вклад, особенно по тем пунктам, которые уже намечены в roadmap. Если есть возможность, крайне важная для вас, попробуйте внести код или подключиться к тестированию, когда она появится в режиме превью. А как минимум вы можете открыть запрос на новую возможность, если нужной вам вещи ещё нет в плане. На странице roadmap есть рекомендации, как предлагать изменения. Участие в проекте помогает не только быть в курсе событий, но и влиять на развитие инструмента, которым вы пользуетесь. В конце концов, Gemini CLI создаётся с расчётом на участие сообщества, и многие недавние возможности (например, некоторые расширения и инструменты) начались именно с предложений пользователей.

Совет 28: Расширяйте возможности Gemini CLI с помощью Extensions

Быстрый пример использования: добавляйте новые возможности в Gemini CLI, устанавливая готовые расширения — например, интеграцию с вашей любимой базой данных или облачным сервисом. Так вы расширяете набор инструментов ИИ без какого-либо серьёзного труда с вашей стороны. Проще говоря, это как установить «приложения» для CLI, чтобы научить его новым приёмам.

Extensions — это поворотный момент в развитии Gemini CLI, появившийся в конце 2025 года: они позволяют кастомизировать и расширять возможности Gemini CLI модульным способом. Extension — по сути набор конфигураций (и при необходимости кода), который подключает Gemini CLI к внешнему инструменту или сервису. Например, Google выпустила целый набор расширений для Google Cloud: одно помогает разворачивать приложения в Cloud Run, другое управляет BigQuery, третье анализирует безопасность приложений — и так далее. Партнёры и разработчики из сообщества создали расширения для самых разных областей: Dynatrace (мониторинг), Elastic (аналитика поиска), Figma (дизайн-активы), Shopify, Snyk (проверка безопасности), Stripe (платежи) — и список постоянно растёт. Установив нужное расширение, вы мгновенно даёте Gemini CLI возможность работать с новыми специализированными инструментами. Причём самое приятное — каждое расширение поставляется с заранее подготовленным «плейбуком», который объясняет ИИ, как правильно использовать новые инструменты. Это означает, что после установки вы можете просить Gemini CLI выполнять задачи, связанные с этими сервисами, и он уже будет знать нужные API или команды — будто эта возможность изначально была встроена.

Пользоваться расширениями — предельно просто. В CLI есть отдельная команда для их управления: gemini extensions install <URL>. Обычно вы передаёте URL репозитория расширения на GitHub или локальный путь, и CLI сам скачивает и устанавливает его. Например, чтобы поставить официальное расширение, можно выполнить: gemini extensions install https://github.com/google-gemini/gemini-cli-extension-cloud-run. Через несколько секунд расширение появится в вашем окружении (оно хранится в ~/.gemini/extensions/ или в .gemini/extensions/ внутри проекта). Посмотреть установленные расширения можно командой /extensions — она выводит список активных расширений. С этого момента у ИИ появляются новые инструменты. Если это расширение для Cloud Run, вы можете, например, сказать: «Разверни моё приложение в Cloud Run», — и Gemini CLI действительно сможет это сделать (вызывая соответствующие команды gcloud через инструменты расширения). По сути, расширения работают как полноценные расширители возможностей Gemini CLI, но вы сами выбираете, какие из них устанавливать.

Вокруг расширений формируется открытая экосистема. У Google есть официальная страница Extensions со списком доступных расширений, и поскольку сама архитектура открыта, любой желающий может создать и поделиться своим. Если у вас есть внутренний API или специфичный рабочий процесс, вы можете сделать для него расширение — и тогда Gemini CLI сможет вам в нём помогать. Создавать расширение гораздо проще, чем кажется: обычно достаточно создать директорию (например, my-extension/) с файлом gemini-extension.json, где вы описываете, какие инструменты или контекст нужно добавить. Можно объявлять новые slash-команды или указывать внешние API, к которым ИИ сможет обращаться. Не нужно вносить изменения в ядро Gemini CLI — просто добавляете свою директорию, и всё. CLI загружает такие расширения динамически, во время работы. Многие расширения работают за счёт добавления собственных MCP-инструментов (серверов или функций по протоколу Model Context Protocol), которые ИИ может использовать. Например, расширение может добавить команду /translate, настроив доступ к внешнему API перевода; после установки ИИ уже будет знать, как использовать /translate. Главное преимущество — модульность: вы ставите только те расширения, которые вам действительно нужны, сохраняя CLI лёгким, но при этом имея возможность интегрировать практически что угодно.

Для управления расширениями, помимо команды установки, вы можете обновлять или удалять их с помощью похожих команд CLI (gemini extensions update или просто удалив соответствующую папку). Полезно время от времени проверять обновления для используемых расширений — в них нередко появляются улучшения.В будущем в CLI может появиться что-то вроде «маркетплейса расширений», но пока что основной способ открывать для себя новые — просматривать репозитории на GitHub и официальный каталог. Среди популярных расширений на момент запуска были, например, GenAI Genkit (для разработки генеративных ИИ-приложений), а также множество расширений для Google Cloud, охватывающих CI/CD, администрирование баз данных и многое другое.

Полезный совет: если вы создаёте собственное расширение, начните с изучения уже существующих — они дают отличные примеры. В официальной документации есть подробный Extensions Guide со схемой и возможностями. Простой способ сделать приватное расширение — использовать функциональность @include в GEMINI.md, чтобы подключать скрипты или контекст, но полноценное расширение даёт намного больше возможностей (например, упаковку собственных инструментов). Поскольку расширения могут включать контекстные файлы, вы можете использовать их для предварительной загрузки доменных знаний. Представьте расширение для внутреннего API вашей компании, в которое входит краткое описание API и инструмент для вызова его методов — ИИ сразу будет понимать, как обрабатывать запросы, связанные с этим API. Проще говоря, расширения открывают целый новый мир, в котором Gemini CLI может взаимодействовать практически с чем угодно. Следите за появлением новых расширений в каталоге и не стесняйтесь делиться своими — возможно, ваш вклад окажется полезным тысячам других разработчиков.

Дополнительное развлечение: пасхалка «Режим корги» ?

И напоследок — не совет по продуктивности, а просто забавная пасхалка. Попробуйте выполнить команду /corgi в Gemini CLI. Она переключает «режим корги», после чего по вашему терминалу начинает бегать милая анимация корги! На качество кода это, конечно, не влияет, но вполне способно поднять настроение в разгар длинной рабочей сессии. Вы увидите, как по интерфейсу CLI носится корги в ASCII-арте. Чтобы отключить, просто снова выполните /corgi.

Это чисто развлекательная фича, которую команда добавила «для души» (и да, ходят шуточные споры о том, стоило ли тратить время разработчиков на режим корги). Она показывает, что создатели не забывают вкладывать немного веселья в инструмент. Так что когда вам нужен короткий перерыв или повод улыбнуться — смело запускайте /corgi. ??

(Говорят, есть и другие пасхалки или режимы — кто знает? Может, появится что-то вроде /partyparrot или тому подобное. В шпаргалке и команде помощи /corgi уже указан, так что это не секрет, просто недооценённая фича. Теперь вы тоже в теме!)

Заключение

Мы разобрали обширный набор продвинутых советов и возможностей Gemini CLI. От настройки постоянного контекста с помощью GEMINI.md до создания собственных команд и использования продвинутых инструментов вроде MCP-серверов, от работы с мультимодальными вводами до автоматизации рабочих процессов — этот AI-помощник в терминале умеет действительно многое. Внешним разработчикам Gemini CLI может легко встроиться в ежедневную работу: это мощный союзник прямо в вашем терминале, готовый взять на себя рутину, подсказать решение и даже помочь с диагностикой окружения.

Gemini CLI стремительно развивается (это Open source-проект, куда активно вносит вклад сообщество), так что впереди постоянно появляются новые возможности и улучшения. Освоив советы из этого руководства, вы сможете по-настоящему раскрыть потенциал инструмента. Речь идёт не просто об использовании AI-модели — а о глубокой интеграции ИИ в ежедневную разработку и управление проектами.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!