# Команда или обычная речь: как разговаривать с ИИ-агентом

Когда с агентом говорят командой, а когда обычными словами? Разбираю границу: пульт управления инструментом против постановки задачи, с таблицей и примерами.

URL: https://posts.danashkin.ru/guides/komanda-ili-obychnaya-rech-s-agentom
Обновлено: 2026-08-20

---

## Коротко

**Главное**

- В окне ИИ-агента живут два разных языка: короткие команды со слэшем и обычная человеческая речь. Пока непонятно, где какой, человек боится писать вообще.
- Граница простая: командой управляешь самим инструментом, словами ставишь задачу. Модель, режим, очистка контекста - команда. Что сделать с проектом - речь.
- Список команд не надо учить наизусть: набери слэш, и агент сам покажет всё, что умеет.
- Слова вроде «зафиксируй изменения» или «сделай ретроспективу» - это обычная речь, а не заклинания. Агент понимает смысл, а не точную формулу.
- Самая дорогая ошибка новичка - пытаться писать «как программист». Ты не разработчик, и тебе выгоднее объяснять задачу простым языком, как объяснял бы подрядчику.

## Откуда берётся ступор перед окном агента?

**Главное**

Человек видит, что иногда работают короткие термины, а иногда развёрнутые фразы, и не может вывести правило. Пока правила нет, любое действие кажется рискованным, и работа встаёт. Это не про интеллект, а про отсутствие явной границы в обучающих материалах.

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

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

Я тогда ответил в моменте: нам всегда надо простым языком общаться, потому что мы не разработчики. Ответ верный, но неполный: границу он не проводит. Проведу её здесь.

## Где проходит граница между командой и речью?

**Главное**

Командой ты управляешь инструментом, речью - работой. Всё, что относится к самой программе (какая модель, сколько потрачено, очистить контекст, выйти), делается короткой командой. Всё, что относится к проекту, объясняется обычными словами.

Держи в голове образ: агент - это исполнитель, который сидит за компьютером. У него есть пульт управления и есть уши.

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

Уши - это обычная речь. Всё, что ты хочешь получить по проекту, объясняется словами: что сделать, зачем, каким должен быть результат, чего делать нельзя.

| Что нужно | Каким языком | Пример |
|---|---|---|
| Сменить модель, посмотреть расход | команда | `/model`, `/cost` |
| Сжать разросшийся контекст | команда | `/compact` |
| Поставить задачу по проекту | речь | «Собери страницу с прайсом и формой заявки» |
| Задать правила работы | речь | «Не трогай файлы в папке с базой, сначала покажи план» |
| Зафиксировать сделанное | речь | «Зафиксируй изменения и коротко опиши, что поменялось» |
| Разобраться, почему сломалось | речь | «Открой ошибку, объясни причину простыми словами» |

**Проверка на пальцах**

Задай себе вопрос: я сейчас настраиваю программу или объясняю работу? Настраиваю - ищи команду. Объясняю - пиши словами, как написал бы толковому подрядчику.

## Список команд наизусть учить не нужно

**Главное**

Не нужно. Набери слэш в пустой строке, и агент покажет список доступных команд с описанием. Этого достаточно: команд немного, а нужны из них в ежедневной работе три-четыре.

Самая утомительная часть входа - ощущение, что где-то есть учебник на сто страниц, который надо выучить до старта. Его нет.

В ежедневной работе непрограммисту хватает короткого набора:

1. **Посмотреть список команд** - слэш в пустой строке.
2. **Сжать историю разговора**, когда контекст забился и агент начал терять нить.
3. **Проверить расход и лимиты**, чтобы не упереться в потолок в середине дня.
4. **Переключить модель**, когда задача проще или, наоборот, сложнее обычного.

Всё остальное делается словами. Полный перечень команд лежит в официальной документации, но открывать её приходится редко.

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

## Почему «писать как программист» - плохая идея?

**Главное**

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

Типичная сцена. Человек прочитал пару статей, набрался слов и пишет: «сделай рефакторинг модуля и оптимизируй запросы». Агент делает что-то, человек не понимает что, проверить не может.

Тот же человек, объяснивший по-человечески, получает результат лучше: «страница со списком заказов открывается пять секунд, это долго, найди причину и предложи, что поменять, но сначала объясни мне выбор без терминов».

Второй вариант выигрывает по трём причинам:

- В нём есть **проблема, а не название решения**. Ты не обязан знать, как чинить, и не должен угадывать за исполнителя.
- В нём есть **критерий**: сейчас пять секунд, надо быстрее.
- В нём есть **требование объяснить**, а значит ты сможешь принять работу.

Это ровно то, что я разбираю в материале про [канон сильного запроса](/guides/kanon-prompta-dlya-ai-agenta): роль, задача, контекст, критерий готовности. Термины там не нужны ни в одном пункте.

**Где термины всё-таки нужны**

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

## Схема рабочего сеанса от задачи до фиксации

**Главное**

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

1. **Открой проект в его папке**

   Агент читает файл с правилами проекта и сразу знает контекст: что за продукт, какие ограничения, чего делать нельзя.

2. **Объясни задачу словами**

   Что нужно, для кого, каким должен быть результат. Одна задача за раз, а не пять сразу.

3. **Попроси план до действий**

   «Сначала опиши, что будешь менять, потом делай». Это главный предохранитель для непрограммиста.

4. **Проверь результат по своему сценарию**

   Открой, нажми, проверь на своих данных. Экран без ошибок ещё не означает работающую функцию.

5. **Зафиксируй и подведи итог**

   Словами: «зафиксируй изменения, коротко опиши, что сделано, и что осталось». Так следующий сеанс начнётся не с нуля.

Порядок при переносе в новый чат тот же, только с одним добавлением: перед закрытием попроси собрать короткую передачу контекста, чтобы новый разговор начался с неё. Почему это важно и как понять, что пора переезжать, я разбирал в материале про [гигиену контекстного окна](/guides/gigiena-kontekstnogo-okna).

## Что делать, если агент не понял?

**Главное**

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

Разберу три частых случая.

**Агент сделал не то.** Скажи прямо: «получилось не то, я ожидал вот такое, посмотри ещё раз». Это нормальная рабочая реплика, а не жалоба.

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

**Агент делает лишнее.** Тут работает явный запрет: «трогай только эту страницу, остальное не меняй». Правила такого рода лучше один раз записать в файл проекта, а не повторять каждый раз - что именно туда писать, разбирал в [материале про файл-память агента](/guides/chto-pisat-v-claude-md).

**Агент просит подтверждение на каждый шаг.** Это отдельная история, и её часто путают с непониманием. Агент спрашивает разрешения перед действиями, которые меняют файлы или лезут в интернет, - так устроена защита по умолчанию. На обучениях это звучит как «он мне задавал десять уточняющих вопросов, как сделать, чтобы он не доканывал».

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

Ни в одном из трёх случаев ответ не в том, чтобы найти «правильное ключевое слово». Их не существует: [ИИ-агент](/concepts/ai-agent) работает со смыслом задачи.

## Частые вопросы

**Главное**

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

### Частые вопросы

**Обязательно ли писать агенту по-английски?**

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

**Можно ли диктовать голосом?**

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

**Надо ли повторять правила проекта в каждом сообщении?**

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

**Забыл нужную команду, что делать?**

Набери слэш и посмотри список. Либо просто попроси словами: «покажи, сколько я потратил» - агент подскажет нужную команду сам.

## Главный вывод

**Главное**

Команды - это пульт от инструмента, речь - способ поставить задачу. Их путают, потому что нигде не проводят границу, но она простая и запоминается за минуту. Дальше выигрывает не знание терминов, а умение внятно объяснить работу.

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

Если после этой статьи останется одно правило, пусть будет такое: настраиваю инструмент - командой, объясняю работу - словами. Всё остальное вырастает отсюда само.

И проверь на ближайшей задаче: опиши её так, как объяснил бы толковому подрядчику, который не знает твоего бизнеса. Обычно этого достаточно, чтобы диссонанс исчез.

### Источники

- [Claude Code - официальная документация: обзор инструмента и режимов работы](https://code.claude.com/docs/en/overview)
- [Claude Code - встроенные и собственные команды со слэшем](https://code.claude.com/docs/en/slash-commands)
- [Claude Code - как агент читает файл памяти проекта](https://code.claude.com/docs/en/memory)
- [Claude Code - типовые рабочие сценарии](https://code.claude.com/docs/en/common-workflows)
- [Command-line interface - как устроены интерфейсы командной строки, Википедия](https://en.wikipedia.org/wiki/Command-line_interface)
- [Pro Git - книга о системе контроля версий и фиксации изменений, русский перевод](https://git-scm.com/book/ru/v2)