Auto Review в Bionic: как отличить безопасную команду от нужного действия

Автоматическая проверка команд освобождает от части однообразных подтверждений. Чтобы это удобство не превратилось в привычку доверять любой зелёной отметке, полезно сначала понять, какие действия команда действительно совершит. В Bionic этот вопрос разделён между анализатором оболочки и отдельным проверяющим агентом.

Одна команда, два разных последствия

Возьмём учебный пример: помощник должен сохранить заметку. В пустой временной папке выполните две команды ниже. Первая создаёт файл или заменяет его содержимое, вторая дописывает строку. После обеих операций cat notes.txt покажет две одинаковые строки.

printf '%s\n' 'draft' > notes.txt
printf '%s\n' 'draft' >> notes.txt
cat notes.txt

Здесь нет сложного программирования, но уже есть три вопроса для проверки: в какой папке работает оболочка, какой файл затрагивается и разрешено ли заменять его содержимое? Одно имя printf не отвечает ни на один из них. Если заметка уже существовала, первая команда уничтожила бы прежний текст. Для эксперимента поэтому нужна отдельная папка без рабочих файлов.

Что именно проверяет Bionic

В техническом разборе от 27 августа команда сначала проходит Shell Judge: разбор синтаксиса, извлечение возможных действий и сопоставление с правилами. Если механический этап не подтвердил безопасность, решение передаётся Shell Reviewer, который учитывает контекст поручения. Это описание разработчика, а не независимый аудит защиты.

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

Проверка перед реальной задачей

Составьте короткую карточку действия: ожидаемый результат, допустимая папка, разрешённые изменения и способ проверить итог. Для заметки это может быть: «добавить строку в notes.txt внутри учебной папки; существующий текст должен сохраниться». Тогда вариант с одним знаком > не соответствует задаче, даже если выглядит безобидно.

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

Этот пример проверен в Bash: получены две строки draft. Поведение Auto Review в установленной Bionic мы не испытывали. Принцип применим и без неё: сначала определите границы допустимого изменения, затем оценивайте команду внутри этих границ. Это даёт проверяющему конкретное поручение и оставляет человеку понятный критерий результата.