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

Коротко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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