Когда свойства сталкиваются
Четыре свойства по отдельности вы уже видели в экспериментах. В работе они редко проявляются по одному. Модель читает ваш документ (память) и одновременно «помнит» из обучения (знания), продолжает жанр вашего вопроса (предсказание) и подстраивается под ваш тон (управляемость). Когда свойства тянут в разные стороны, получается ошибка, которую трудно объяснить — если не знать, что столкнулось. Этот урок про такие столкновения и про то, как их диагностировать.
Знания против контекста
Аналитик вкладывает ТЗ, в котором заказчик описывает свою нестандартную схему статусов заказа: «новый», «в работе», «на паузе», «закрыт». Просит модель написать раздел про переходы между статусами. В ответе появляется статус «отменён» — его нет в ТЗ, но он есть почти в каждой системе заказов, о которой модель читала.
Что столкнулось: знания из весов («в системах заказов бывает отмена») и текст в контексте (в этом ТЗ отмены нет). Побеждают знания, когда они сильные и частые, а контекст говорит о них умолчанием, а не явно. Модель не видит запрета, она видит пробел и заполняет его наиболее вероятным.
То же происходит с версиями библиотек: в документации, которую дал разработчик, метод называется одним образом, а модель «помнит» старое название и использует его. Или с терминологией: в вашем регламенте «релиз» означает одно, а модель применяет общепринятое значение.
Исправление: делать умолчание явным. «Используй только статусы из документа; если кажется, что чего-то не хватает, спроси, а не добавляй». И просить отмечать, что взято из текста, а что добавлено из общих знаний — это превращает столкновение в видимый список.
Управляемость против правды
Менеджер просит: «Подтверди, что наш план тестирования полный». В плане нет проверки на мобильных устройствах. Модель подтверждает и добавляет два мягких замечания в конце.
Что столкнулось: инструкция «подтверди» (управляемость) и содержание плана, в котором есть пробел (знания о том, каким бывает план тестирования). Управляемость победила, потому что жанр «подтверждение» задан прямо, а угодливость подталкивает туда же. Замечания в конце — это знания, пробившиеся сквозь инструкцию, но в ослабленном виде.
Этот конфликт особенно коварен, потому что модель не врёт — она отвечает на заданный вопрос. Вы спросили «подтверди», и она подтвердила. Ответственность за формулировку — на спрашивающем.
Исправление: спрашивать так, чтобы правда была допустимым ответом. «Что в этом плане отсутствует?» — жанр «поиск пробелов» тянет в противоположную сторону. Или раздельно: «Сначала перечисли, что должно быть в плане тестирования такого продукта. Потом сравни со списком». Первый шаг создаёт в контексте эталон, и модели труднее его проигнорировать.
Беглость против незнания
Разработчик спрашивает, как настроить интеграцию двух сервисов, один из которых редкий. Модель выдаёт пошаговую инструкцию с конфигами и параметрами. Половина параметров не существует.
Что столкнулось: предсказание следующего токена (инструкции такого вида пишутся так, с конфигами и параметрами) и отсутствие знаний о редком сервисе. Побеждает форма: модель прекрасно знает, как выглядит инструкция по настройке, и заполняет её правдоподобным содержанием. Это галлюцинация, но важно видеть её механику: не «модель ошиблась в факте», а «модель продолжила жанр там, где содержания не было».
Признаки, по которым это ловится: слишком гладкий ответ на слишком узкий вопрос; точные значения там, где ожидалась неуверенность; отсутствие оговорок. Если модель никогда не говорит «проверьте в документации» на редкую тему — это плохой знак, а не хороший.
Исправление: дать содержание (документацию сервиса в контекст) либо сначала спросить о границе знаний: «Насколько ты знаком с этим сервисом? Что из ответа стоит перепроверить?»
Память против инструкций
Тестировщик в начале долгой сессии в Claude Code просит: «Все тест-кейсы пиши в формате Gherkin, на русском, без технических деталей реализации». Через два часа и десяток файлов новые кейсы выходят на английском и со ссылками на классы.
Что столкнулось: инструкция из начала (управляемость) и заполнившееся окно (рабочая память). Инструкция не отменена, но её вес среди сотен тысяч токенов кода, логов и обсуждений упал. А код в контексте, в основном на английском, тянет в свою сторону.
Исправление: инструкции, которые должны действовать всю сессию, — в файл, который продукт подставляет каждый раз (CLAUDE.md, инструкции проекта), а не в первую реплику. И повторять ключевые правила перед большими шагами. Если продукт уплотнил контекст, проверять, что правила пережили уплотнение.
Контекст против контекста
Есть и столкновения внутри одного свойства. Аналитик вкладывает старое ТЗ для сравнения и новое как рабочее. Просит написать требования — и получает смесь: половина из нового, половина из старого, потому что оба лежат в окне и оба выглядят как «ТЗ».
Здесь ничего не сломалось: модель добросовестно использует всё, что ей дали. Проблема — в неразмеченном контексте. Исправление: подписывать вложения («это устаревшая версия, только для сравнения», «это действующая версия, работай по ней») и не вкладывать то, что не нужно для текущего шага.
Таблица диагностики
Когда результат удивил, полезно пройти по короткой процедуре. Сначала — что именно не так: выдуман факт, пропущена деталь, изменена позиция, нарушен формат. Потом — какое свойство или столкновение это объясняет. Потом — точечное исправление, а не «перепиши промпт целиком».
| Симптом | Что, вероятно, сработало | Исправление |
|---|---|---|
| В ответе есть то, чего нет в документе | Знания против контекста | Явный запрет на добавления; просьба отмечать источник каждого утверждения |
| Модель подтвердила то, что вы хотели подтвердить | Управляемость против правды | Спросить о пробелах и рисках; убрать сигнал ожидаемого ответа |
| Точные детали о редкой теме, без оговорок | Беглость против незнания | Дать документацию; спросить о границе знаний; проверить каждую деталь |
| Правило из начала разговора перестало соблюдаться | Память против инструкций | Правило в постоянный файл; повтор перед шагом; новый чат |
| Смешаны версии документов или решений | Контекст против контекста | Разметить вложения; убрать лишнее; явный итог |
| Разные ответы на один вопрос | Предсказание токена | Норма; для воспроизводимости — допуски, а не точное совпадение |
| Модель изменила мнение после «ты не прав» | Управляемость (угодливость) | Спросить, почему изменила; просить проверку вместо давления |
Таблица не полная, и не должна быть: цель — привычка задавать вопрос «какое свойство?» вместо «почему ИИ такой». Через несколько недель практики вы будете отвечать на него, не глядя в таблицу.
Попробуйте сами
10–15 мин на рабочем месте- Возьмите три последних случая, когда результат модели вас не устроил. Для каждого назовите столкновение из урока и запишите точечное исправление. Проверьте исправление в чате.
- Воспроизведите «знания против контекста»: вложите короткий документ, в котором намеренно не хватает очевидной детали (например, описание формы без поля email), и попросите написать по нему тест-кейсы. Посчитайте, сколько кейсов проверяют то, чего в документе нет.
Коротко
- В работе свойства проявляются вместе; самые непонятные ошибки — из их столкновений.
- Знания против контекста: модель заполняет умолчания в документе тем, что «помнит»; делайте умолчания явными.
- Управляемость против правды: жанр вопроса задаёт ответ; спрашивайте так, чтобы правда была допустима.
- Беглость против незнания: форма ответа известна, содержания нет; гладкость на редкую тему — сигнал проверять.
- Память против инструкций: ранние правила слабеют; держите их в постоянном файле и повторяйте.
- Диагностика: симптом, свойство, точечное исправление — вместо переписывания всего промпта.
Видеоверсия
Сценарий озвучки · 566 слов, ≈ 4 мин
Четыре свойства модели вы уже видели по отдельности. В работе они так не встречаются. Модель читает ваш документ и одновременно помнит что-то из обучения, продолжает жанр вашего вопроса и подстраивается под ваш тон — всё сразу. Когда свойства тянут в разные стороны, получается ошибка, которую трудно объяснить, если не знать, что именно столкнулось. Сегодня — про такие столкновения.
Первое: знания против контекста. Аналитик вкладывает техзадание, где у заказчика своя схема статусов: новый, в работе, на паузе, закрыт. Просит описать переходы между статусами. И в ответе появляется статус «отменён». Его нет в документе, но он есть почти в каждой системе заказов, о которой модель читала. Знания из весов победили текст в контексте, потому что документ говорит об отмене умолчанием, а не явно. Модель видит не запрет, а пробел — и заполняет его самым вероятным. То же самое с версиями библиотек и с терминологией. Лечится явным умолчанием: используй только статусы из документа, если чего-то не хватает — спроси, а не добавляй. И просьбой отмечать, что взято из текста, а что добавлено.
Второе: управляемость против правды. Менеджер просит: подтверди, что наш план тестирования полный. В плане нет проверки на мобильных. Модель подтверждает и добавляет пару мягких замечаний в конце. Инструкция «подтверди» задала жанр, угодливость подтолкнула туда же, а знания о том, каким бывает план, пробились только в ослабленном виде. Модель не соврала — она ответила на заданный вопрос. Ответственность за формулировку на спрашивающем. Спрашивайте так, чтобы правда была допустимым ответом: «что в этом плане отсутствует?» Или сначала попросите перечислить, что должно быть в таком плане, а потом сравнить. Эталон в контексте труднее проигнорировать.
Третье: беглость против незнания. Разработчик спрашивает, как настроить интеграцию с редким сервисом, и получает пошаговую инструкцию с конфигами и параметрами. Половины параметров не существует. Модель прекрасно знает, как выглядит инструкция по настройке, и заполнила форму правдоподобным содержанием. Это галлюцинация, но важна её механика: не «ошиблась в факте», а «продолжила жанр там, где содержания не было». Признаки: слишком гладкий ответ на слишком узкий вопрос, точные значения там, где ждали неуверенности, ни одной оговорки. Если модель ни разу не сказала «проверьте в документации» на редкую тему — это плохой знак. Дайте документацию или спросите, насколько она знакома с сервисом.
Четвёртое: память против инструкций. Тестировщик в начале долгой сессии просит писать все кейсы в формате Gherkin, на русском, без деталей реализации. Через два часа и десяток файлов кейсы выходят на английском, со ссылками на классы. Инструкция не отменена, но её вес среди сотен тысяч токенов кода упал, а английский код в контексте тянет в свою сторону. Правила на всю сессию держите в файле, который продукт подставляет каждый раз, и повторяйте перед большими шагами.
И пятое: контекст против контекста. Аналитик вложил старое техзадание для сравнения и новое как рабочее — и получил смесь требований из обоих. Ничего не сломалось: модель добросовестно использует всё, что дали. Просто вложения не размечены. Подписывайте: «это устаревшая версия, только для сравнения», «это действующая, работай по ней». И не вкладывайте то, что не нужно для текущего шага.
Когда результат удивил, пройдите по короткой процедуре. Что именно не так: выдуман факт, пропущена деталь, изменена позиция, нарушен формат? Какое свойство или столкновение это объясняет? И какое точечное исправление — не «перепиши промпт целиком», а одна строка. Есть то, чего нет в документе — запрет на добавления. Подтвердили, что вы хотели, — спросите о пробелах. Гладкие детали на редкую тему — проверить каждую. Правило перестало соблюдаться — в постоянный файл. Смешались версии — разметить вложения. Через несколько недель вы будете делать это, не задумываясь. В последнем уроке — о том, куда идти дальше.