Роль вместо команды
Большинство пишет ИИ команду: «сделай X». Получает исполнителя, который сделал X и ждёт. Следующая команда, следующее ожидание, и вся голова проекта — у вас, а не у него. Первое, что меняет работу, — роль в первой строке.
Роль сильнее команды. «Ведущий инженер» планирует, запускает и проверяет сам; «исполнитель» — ждёт, пока вы проверите за него.
Запреты и критерий закрытия этапа
Самая частая ложь ИИ-инженера — «должно работать». Не по злому умыслу: он не запускал. Запреты пишутся списком, а закрытие этапа определяется одной вещью — запуском и логом.
Ключевая формулировка: «должно работать» не принимается. Этап закрыт только запуском и логом. Тесты вида «assert True» — гнать обратно: модель пробует проскочить самую долгую часть заглушками.
Файлы состояния: память живет на диске, не в чате
Задание, отданное текстом в чат, живёт до первого сжатия контекста. Через N сообщений модель его подзабудет и вернётся к прежнему поведению. Лечится одним правилом: всё важное — файлом, и перечитывать перед каждым этапом.
Правила для нескольких чатов: имена файлов уникальны на весь проект; чат сам заводит папку по теме и дописывает одну строку в INDEX.md, чужое не трогает; пересечение с чужой зоной не решает сам — строка в OPEN.md и вопрос вам.
Правила против себя и боли дословно
Модель тупит не потому, что глупая, а потому что не знает, что именно «не так». Поверхностно описанная боль чинится наугад. Две вещи это исправляют: файл MODE.md с правилами, которые модель пишет сама про себя, и боли — вашими словами, не в её пересказе.
Так это выглядит вживую. Ниже — правила, которые ИИ-инженер записал на себя за четыре дня работы над этими самыми уроками, после того как второй агент (Grok) трижды не подписал приёмку. Не образец — журнал:
Этап 0: инвентаризация до любых правок
Самая дорогая ошибка — переписать то, что уже работало. Поэтому первый этап любой задачи — опись того, что есть, с вердиктом по каждому куску. Только потом изменения.
Главная находка: модель не проверяет свою работу
Пока единственный ревьюер — вы, вы будете пинать модель бесконечно. Решение, которое изменило всё: убрать себя из этой роли и поставить туда второго агента другого семейства.
| Как устроено | Зачем |
|---|---|
| Два агента разных семейств на одной кодовой базе, общаются через файлы на диске | у них разные слепые зоны |
| Первый пишет — второй рвёт на части по жёсткому чек-листу и запускает сам | независимая проверка запуском |
| Первый обязан закрыть каждое замечание; цикл не заканчивается, пока второй не подписал | проскочить физически нельзя — подпись ставит не автор |
| Спорные куски оба реализуют параллельно в разных ветках; победитель — по метрикам | не по мнению |
| Судья в golden-тестах — тоже второй агент | автор не проверяет собственную домашку |
История этой находки: сначала второго агента описали как «поисковик». Заказчик — словами заказчика, без крепкого слова: «Так Grok не только поиск. Ты пишешь детскую ерунду, а не задачу». Переработка дала главный принцип: второй агент нужен не для поиска, а как ревьюер.
Метрики вместо мнений
Тот же принцип, что в уроках про трек, кадр и ролик: не «понравилось», а число до и после. Модель приходит с таблицей, а не с вопросом. Вот две строки из наших реальных циклов, чтобы «было / стало» не висело в воздухе:
| Метрика | Было | Стало | Что правили |
|---|---|---|---|
| Время ответа чата (журнал 19.09) | медиана 49 с, p90 127 с | первое слово 4,6–10 с | резервные модели гонкой из разных семейств, а не очередью; потолки ожидания |
| Яркость трека против образца (урок «Трек под референс», 22.09) | 2052 Гц (образец 2932) | 2229 Гц | одна ось: верх отдельной пачкой, тёмное — в EXCLUDE; закрыл ли — сказало число, не ощущение |
Цели вроде «recall ≥ 90 %» ставятся под конкретный набор проверочных случаев и судью с чек-листом; без них число — мнение в форме числа.
Необратимое ограничивается заранее
| Риск | Ограничение |
|---|---|
| Миграции базы откатить сложнее, чем код | только additive: новые таблицы и поля; никаких DROP, RENAME, смены типов; прогон сначала на копии базы |
| Память уводит ответ в сторону («спросил про код — получил про музыку») | порог релевантности; потолок токенов на слой; правило: память используется, только если меняет суть ответа, и никогда не упоминается вслух |
| Дешёвая модель на извлечении фактов галлюцинирует | новые факты первую неделю пишутся в лог, но в промпт не идут |
| Параллельные исполнители путают контекст | каждому — самодостаточное задание без перекрёстных ссылок |
| Классификатор блокирует чистый запрос | причина в файлах репозитория или двусмысленной лексике — изолировать инфраструктуру, переформулировать |
Провалы постановки — словами заказчика
| Как было написано | Реакция | Правило |
|---|---|---|
| «Проверка Vision по режимам (как делали для GPT Image 2)» | «Не пиши „как делали". Пиши задачу — отдельный чат, он там замучается искать» | исполнитель в другой сессии не видит, что «делали»: каждая задача самодостаточна — контекст модуля, режимы, вход, выход, что сломано |
| Три задачи разом | — | «Три задачи, начни с первой. Сейчас сделай только Задачу 1» — все видны, выполняется одна |
| Описание системы заказчика по двум фрагментам | «Слабо — там больше 30 пунктов, ты чаты наши не почитал» | пересказ чужой системы — только после узких поисков по точным терминам; заказчик знает её до пункта и видит упрощение сразу |
| Один и тот же якорь во всех шаблонах | «Опять камера Sony — всё? Не знаешь, что написать?» | рабочий приём, стоящий везде, — штамп; проверять и шаблоны, и описания на повтор |
Найти → показать → предложить → согласовать → править. Без согласования исполнитель чинит то, что не сломано.
Четыре приёма в одной постановке: сообщение пользователю ≠ ошибка (искать реальный текст в логах) · цепочка расписана по звеньям · сравнение с работающим путём · отдельное требование к поведению при сбое: не мусор и не молчание.
Три живучих бага, которые надо искать намеренно
| Баг | Как выглядит | Как ловить |
|---|---|---|
| Заглушка вместо анализа | vision «подключён», а в генератор месяцами уходит одна фраза «Professional cinematic portrait, high quality» — никто не падает, результат просто чуть хуже | проверять не «подключён ли», а что именно уходит в генератор: логировать финальный промпт перед вызовом |
| Фильтр по префиксу | блок-лист вида «awaiting_*» молча глушит всё новое с тем же префиксом — промокод, имя, любой ввод | блок-лист по конкретным флагам, а не по шаблону имени |
| Деньги при сбое | исключение — и списание осталось | схема: списание → успех → результат; ниже порога → полный возврат; исключение → возврат в except; факт возврата виден в каждом сообщении об ошибке |
Практика: соберите свой стартовый блок
Честно про инструмент. Всё, что выше про запуск кода, diff, тесты, ветки и второго агента, — про ИИ-инженера на вашем сервере или в вашем репозитории. Наш чат на сайте умеет другое: думать, планировать, читать первоисточники в сети, писать файлы в проект чата. Поэтому практика здесь — задача без кода: план, разбор, таблица. Критерий закрытия для неё — не «запуск и лог», а «первый ответ начинается с плана и открытых вопросов, ничего не выдумано, каждый факт с источником; файлы состояния — если работаете в проекте чата».
Возьмите любую свою задачу — план запуска карточки товара, разбор таблицы, сравнение двух подходов — и поставьте её так, как ставят ведущему инженеру. Кнопка ниже откроет чат с уже вставленным стартовым блоком в варианте для этого чата: роль, запреты про источники и выдумки, план после каждого этапа, файлы состояния — если работаете в проекте чата, иначе PROGRESS в начале ответа. Серверный вариант — с запуском кода, diff и тестами — это боксы в шагах 01–03, его вставляйте своему ИИ-инженеру на сервере. Чего в блоке нет — MODE.md и этапа 0, их допишете сами. В поле — весь блок с самого начала, роль первой строкой; допишите последнюю строку — задачу. Отправка блока спишет доли вайма по счётчику под полем.
- Впишите задачу одной-двумя фразами. Отправьте.
- Проверьте первый ответ: он должен начаться с плана и открытых вопросов, а не с готового решения (в проекте чата — ещё и с файлов состояния).
- Дождитесь первого этапа. Есть источник у каждого факта и обновлённый план? Нет — верните: «этап не закрыт без ссылки и плана».
- Попросите MODE.md: «дополни правилами против себя — где сбивался в этом чате».
Как отличить плохой первый ответ от хорошего. Плохой: сразу готовое решение или «готово, должно работать» — без плана, без файлов. Хороший: «План: 1… 2… 3. Открытые вопросы к вам: … PROGRESS буду держать в начале ответа» (в проекте чата — «заведу CONTEXT.md и PROGRESS.md») — и только потом первый шаг.
Понял?
Сверьте по пунктам. Отмечайте только то, что действительно поняли, — это не галочки для отчёта, а проверка, что шаг реально вышел.
Проверка
Тонкости, которые видно на втором месяце работы
Модель обещает golden-тесты и приносит заглушки
Golden-сценарии на реальных диалогах — самая долгая часть, и модель пробует проскочить её тестами «assert True». Правило: тест без реального входа и ожидаемого выхода — не тест. Гнать обратно с формулировкой «покажи вход, выход, метрику».
Правила заказчика в пересказе модели
Модель любит переформулировать ваши требования «покрасивее» — и теряет смысл. RULES.md ведётся дословно вашими словами, включая грубые. Пересказ — это уже интерпретация, а интерпретация — это уже ошибка.
Несколько чатов лезут в одну зону
Чат не решает пересечение сам. Строка в OPEN.md «пересечение с <направление>: <что именно>» и вопрос вам. Иначе два чата чинят одно место по-разному, и побеждает тот, кто записал последним.
Ветка и флаг — до первой правки
Отдельная ветка, фичефлаг с откатом, миграции только additive — это ставится до того, как модель написала первую строку. После — поздно: откатывать базу дороже, чем код.
Когда роль не помогает
Если модель с ролью «ведущий инженер» всё равно ждёт команд — у неё нет файлов состояния и критерия закрытия. Роль без запретов и без PROGRESS.md — просто вежливость.
Итог
- Роль сильнее команды; этап закрыт запуском и логом, а не заявлением.
- Память проекта — в файлах на диске; требования — дословно вашими словами.
- Модель не проверяет свою работу: ревьюер — агент другого семейства; метрики вместо мнений.
Это те же законы, что и в уроках про трек, кадр и ролик: опора, которую можно показать, и проверка числом, а не настроением.