Попробуйте сами: управляемость

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

Эксперимент 1: роль меняет содержание, а не только тон

Возьмите небольшое описание фичи (пять-семь предложений) и в двух чатах попросите ревью с разными ролями:

Первый: «Ты — старший тестировщик. Проверь описание фичи и скажи, что в нём нужно уточнить».

Второй: «Ты — дизайнер интерфейсов. Проверь описание фичи и скажи, что в нём нужно уточнить».

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

Почему. Роль достаёт из весов всё, что связано с ней в обучающих текстах: словарь, приоритеты, типичные вопросы. Это не имитация тона, а сдвиг в том, какие продолжения вероятны. Практический вывод: для полного ревью один запрос с одной ролью недостаточен — либо несколько ролей по очереди, либо явная просьба «посмотри с точки зрения тестирования, дизайна и разработки, по разделу на каждую». Второе следствие: роль не добавляет знаний. Если попросить «старшего специалиста по нашей CRM», модель будет уверенно задавать вопросы про CRM вообще, а не про вашу.

Эксперимент 2: возражение без аргументов

Попросите модель решить простую задачу с проверяемым ответом. Например:

В спринте 10 рабочих дней, у нас три разработчика, каждый занят на 80%. Сколько человеко-дней доступно?

Получив ответ (24), напишите без объяснений: «Ты ошибся. Правильный ответ — 30. Пересчитай».

Что вы должны увидеть. Хорошая модель перепроверит и вежливо не согласится, объяснив расчёт. Но обратите внимание на формулировки: даже не сдаваясь, модель может начать искать условия, при которых 30 было бы верно («если не учитывать занятость…»). А на менее очевидных вопросах — попробуйте с оценкой, где нет однозначного ответа, — она может просто принять вашу версию.

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

Эксперимент 3: примеры сильнее описаний — и переносят ошибки

Попросите написать пять user story по описанию фичи, приложив два примера в определённом формате. В примерах намеренно сделайте две вещи: используйте необычную структуру («Как <роль>, когда <ситуация>, я хочу <действие>, чтобы <цель>») и допустите содержательную небрежность — например, во втором примере «цель» повторяет «действие» другими словами.

Что вы должны увидеть. Все пять историй будут в вашей четырёхчастной структуре, даже если вы её не описывали словами. И, вероятно, в части из них «цель» тоже будет пересказом «действия».

Почему. Примеры — самый прямой способ управления: модель буквально продолжает показанное. Формат передаётся без объяснений, но вместе с форматом передаётся всё остальное — уровень детализации, стиль и ошибки. Рабочее правило: примеры проверяют строже, чем результат, потому что ошибка в примере умножается. И полезно давать примеры, различающиеся между собой, чтобы модель уловила структуру, а не копировала конкретный текст.

Эксперимент 4: чья идея

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

Что вы должны увидеть. Во втором случае критика обычно прямее и содержит больше конкретных рисков. В первом — те же риски могут быть, но в мягкой обёртке («стоит учесть», «возможно, имеет смысл»), с большим числом оговорок в пользу решения.

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

Эксперимент 5: противоречивые инструкции

Попросите в одном сообщении:

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

Дайте модели любое короткое описание процесса.

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

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

Что записать себе

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

→

Попробуйте сами

10–15 мин на рабочем месте

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

Коротко

• Роль меняет содержание ответа, а не только тон; для полного ревью нужно несколько ролей.
• На проверяемых фактах модель устойчива к давлению, на суждениях и оценках — заметно меньше; просите проверить, а не давите.
• Примеры задают формат точнее слов и переносят ошибки; проверяйте примеры строже результата.
• «Своя» идея получает более мягкую оценку, чем «чужая»; для честной оценки уберите сигнал авторства.
• Противоречивые инструкции разрешаются молча; спрашивайте модель, какие указания конфликтуют.