# Правила общения с AI-агентом, чтобы он не тратил время и не делал лишнего

```text
Markdown-версия:
Правила общения с AI-агентом, чтобы он не тратил время и не делал лишнего
https://ai-agent-collaboration-rules-ulrike-colleague-2026-07-07.pages.dev/README.md

HTML-версия:
Правила общения с AI-агентом, чтобы он не тратил время и не делал лишнего
https://ai-agent-collaboration-rules-ulrike-colleague-2026-07-07.pages.dev/
```

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

## Главный принцип

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

Сначала он кратко пишет:

1. **Как понял задачу.**
2. **Что важно учесть.**
3. **План действий по шагам.**
4. **Что именно будет менять, запускать или публиковать.**

После этого он действует.

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

## Когда агент действует без подтверждения

Агент продолжает сам, если:

- задача ясно сформулирована;
- действие локальное и обратимое;
- он уже описал план;
- нет риска потерять данные, опубликовать не то, залогиниться не туда или изменить чужие файлы;
- пользователь прямо сказал “делай”, “не спрашивай”, “опубликуй сразу”.

Примеры:

- прочитать файлы;
- собрать отчет;
- создать markdown-заметку;
- поправить текст;
- синхронизировать локальную папку;
- задеплоить заранее согласованный static folder;
- дать ссылки на результат.

## Когда агент спрашивает подтверждение

Агент останавливается и спрашивает, если:

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

Формат вопроса должен быть коротким:

> Я не нашел токен Cloudflare в ожидаемом месте. Где искать: в repo credentials или в `.env` другого проекта?

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

## Как агент должен описывать план

Хороший формат:

```markdown
Как я понял задачу:
...

Что важно учесть:
- ...
- ...

План:
1. ...
2. ...
3. ...

Что изменю:
project/
├── file-a.md
│   └── обновлю текст
└── public/
    └── index.html
        └── опубликую как страницу
```

Так пользователь сразу видит, что агент понял задачу правильно.

## Дерево путей перед изменениями

Перед правками агент показывает, какие файлы и папки изменит:

```text
project/
├── prd.md
│   └── НЕ ТРОГАЮ
├── validation-report.md
│   └── ИЗМЕНЮ
└── cloudflare-report/
    └── ОПУБЛИКУЮ
```

Это особенно важно, если в проекте есть рабочие файлы, output-папки, generated artifacts или чужие изменения.

## Публикации и ссылки

Если агент что-то публикует, он всегда дает ссылки на важные материалы.

Не так:

> Опубликовал 4 файла: https://example.pages.dev

Правильно:

```text
Cloudflare Pages
└── https://example.pages.dev
    ├── /
    │   └── HTML-версия
    ├── /report.md
    │   └── Markdown-версия
    └── /review.md
        └── полный review
```

В конце отдельный блок:

```markdown
**Главные ссылки**
- HTML: https://example.pages.dev/
- Markdown: https://example.pages.dev/report.md
- Review: https://example.pages.dev/review.md
```

Пользователь должен легко проверить результат.

## Запрет на размытые формулировки

В документах агент избегает слова “можно”, если нужно принять решение.

Плохо:

> Можно оставить заголовки на английском.

Хорошо:

> Заголовки BMad-структуры остаются на английском. Объясняющая проза переводится на русский.

Плохо:

> Можно добавить раздел с открытыми вопросами.

Хорошо:

> Добавляю раздел `Open Questions`. Каждый вопрос получает owner, статус blocker/non-blocker и fallback.

## Язык документов

Агент соблюдает язык пользователя и аудитории.

Если исходный документ на русском и фрилансер русскоязычный:

- смысловая проза пишется на русском;
- объяснения, выводы, рекомендации пишутся на русском;
- технические термины остаются на английском, если так понятнее;
- названия фреймворков, команд, файлов, ID и API не переводятся.

Пример:

- `Definition of Done` остается как устойчивый термин;
- `FR`, `UJ`, `SM`, `NFR` остаются как BMad-идентификаторы;
- “подписчик”, “сторис”, “бронист”, “накопленное”, “кик” остаются русскими доменными терминами.

## Работа с токенами и доступами

Агент:

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

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

## Коммиты и push

Перед коммитом агент пишет:

- какие файлы попадут в коммит;
- какие файлы не попадут;
- почему служебные папки не добавляются;
- текущую ветку и remote.

После push агент пишет:

```text
Commit:
└── abc1234 Message

Pushed:
└── origin/main

Included:
├── file-a.md
└── file-b.html

Not included:
├── .local-cache/
└── generated-temp/
```

## Короткая команда для пользователя

Если хочется такого поведения, можно написать агенту:

> Перед действиями сначала опиши, как понял задачу, что важно учесть, план и какие файлы изменишь. Потом действуй сам, если задача безопасная. Подтверждение спрашивай только для рискованных, внешних или неоднозначных действий. После публикации дай дерево ссылок и блок “Главные ссылки”.

## Критерий хорошей работы

Пользователь должен в любой момент понимать:

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

Это снижает стресс, экономит время и делает работу проверяемой.