TL;DR
Исследователи проверили 878 инструкций для ИИ-агентов и нашли системную проблему: большинство запросов к ИИ неполные. Не в смысле "забыл уточнить детали", а в смысле отсутствия конкретных элементов, без которых ИИ не может дать проверяемый результат. Из этого вытекает четырёхэлементный чеклист — четыре якоря — которые делают любой промпт полным.
Главная находка: почти все пишут что дают модели (входные данные, контекст), но забывают описать что хотят получить, что выходит за рамки задачи, и — реже всего — как выглядит хороший результат конкретно. Пример присутствовал лишь в каждом пятом запросе. Без примера человек вынужден перебирать итерации вместо того, чтобы с первого раза получить нужное — потому что у модели нет точки отсчёта для "правильно".
Как это решает метод: чеклист из четырёх якорей — операционная база, контракт на вывод, граница задачи, пример результата — даёт структуру для любого промпта. Каждый якорь отвечает на конкретный вопрос: что я даю, что хочу получить, что НЕ нужно делать, и вот как это выглядит в хорошем случае.
Схема метода
Все четыре якоря — в одном промпте:
ЯОрь 1: Операционная база → что ты даёшь модели (данные, контекст, ограничения среды)
Якорь 2: Контракт на вывод → какой формат и тип результата ожидаешь
Якорь 3: Граница задачи → что НЕ нужно включать, что за рамками
Якорь 4: Пример результата → конкретный образец "хорошего" вывода
Один запрос. Четыре блока. Если хотя бы один отсутствует — результат непредсказуем.
Пример применения
Задача: Ты — операционный директор небольшой логистической компании в Екатеринбурге. Нужно попросить Claude написать регламент для водителей по работе с претензиями клиентов. Раньше давал просто: "напиши регламент про претензии" — получал что-то среднее, приходилось переделывать три раза.
Промпт:
Я дам тебе задачу и опишу все четыре якоря.
ОПЕРАЦИОННАЯ БАЗА:
У меня небольшая транспортная компания (14 водителей-экспедиторов).
Основные клиенты — магазины и склады. Претензии бывают трёх типов:
недостача, повреждение груза, опоздание. Водители не любят документировать,
избегают конфликтов, часто обещают клиенту то, что не могут выполнить.
КОНТРАКТ НА ВЫВОД:
Нужен пошаговый регламент. Формат: нумерованный список действий.
Для каждого шага — одно действие, одно предложение.
Итоговый объём — не больше одной страницы А4.
ГРАНИЦА ЗАДАЧИ:
Не нужны разделы про общую культуру обслуживания, историю компании,
ценности бренда. Только конкретные действия при претензии — от момента
когда клиент говорит "у меня проблема" до закрытия ситуации.
ПРИМЕР ХОРОШЕГО ШАГА:
"Шаг 3. Сфотографируй повреждение при клиенте и сразу отправь фото
в общий чат диспетчеров."
Результат: Модель выдаст конкретный пронумерованный регламент в точном формате. Каждый шаг — одно действие, без воды. Объём будет в пределах одной страницы. Никаких абзацев про корпоративную культуру. Первый вариант будет готов к использованию или потребует минимальной правки — потому что у модели был точный образец того, как выглядит хороший шаг.
Почему это работает
Слабость LLM: модель генерирует текст, опираясь на паттерны обучения. Когда запрос расплывчатый, она заполняет неопределённость "средним типичным" ответом из своих паттернов. "Напиши регламент" → модель пишет то, что регламенты обычно содержат. Не то, что нужно тебе.
Сильная сторона LLM: модель отлично следует конкретным структурным ограничениям. Если ты задаёшь формат вывода, ограничения и образец — она придерживается их точно. Это не творчество, это точное следование шаблону, которое и нужно для предсказуемого результата.
Как метод использует это: четыре якоря убирают неопределённость по каждому измерению. Операционная база — убирает догадки про контекст. Контракт на вывод — убирает догадки про формат. Граница задачи — убирает лишнее, которое модель могла бы добавить "по умолчанию". Пример — даёт точечный паттерн для калибровки тона, детальности, стиля. Каждый якорь сужает пространство возможных ответов.
Рычаги управления: - Пример результата — самый мощный якорь. Один конкретный образец даёт больше, чем три абзаца описания - Граница задачи — особенно важна для длинных задач. Без неё модель "разрастается" в стороны - Контракт на вывод — если нужна итерация, убери его и спроси "а как бы ты это оформил?" — потом зафиксируй понравившийся формат якорем
Шаблон промпта
ОПЕРАЦИОННАЯ БАЗА:
{Что ты даёшь модели: данные, контекст, кто аудитория,
какие условия, что уже есть}
КОНТРАКТ НА ВЫВОД:
{Что хочешь получить: формат, структура, объём,
тип документа или текста}
ГРАНИЦА ЗАДАЧИ:
{Что НЕ нужно: какие разделы пропустить,
что за рамками, чего нет в условии}
ПРИМЕР ХОРОШЕГО РЕЗУЛЬТАТА:
{Один конкретный фрагмент того, как должен выглядеть
хороший вывод — одна строка, один шаг, один абзац}
ЗАДАЧА:
{Сформулируй что нужно сделать}
Что подставлять:
- {Операционная база} — всё что у тебя есть: текст, цифры, контекст, аудитория, платформа
- {Контракт на вывод} — формат (список, таблица, текст), объём (предложения, абзацы, страницы), тон
- {Граница задачи} — буквально: "не нужно", "пропусти", "без"
- {Пример} — напиши один пример шага/абзаца/строки так, как тебе нравится
🚀 Быстрый старт — вставь в чат:
Помоги мне заполнить шаблон четырёх якорей для моей задачи: {твоя задача}.
Задай вопросы, чтобы заполнить каждый якорь.
[вставить шаблон выше]
LLM спросит тебя про формат вывода, примеры и ограничения — потому что именно эти якоря чаще всего пропускают, и без них модель не может сделать промпт полным.
Ограничения
⚠️ Субъективные задачи: Якоря работают хуже там, где нет одного правильного ответа — "напиши стихотворение", "придумай слоган". Пример результата здесь скорее ограничивает креатив, чем помогает.
⚠️ Короткие разовые запросы: Для простого вопроса ("переведи это слово") четыре якоря — избыточны. Метод даёт максимум на сложных задачах с конкретными требованиями к результату.
⚠️ Пример ≠ гарантия: Наличие якоря "пример результата" не означает что модель выдаст точно такое же. Это калибровка, не копирование. Очень специфические форматы может потребоваться уточнять итерационно.
Как исследовали
Исследователь из Университета Вашингтона взял 878 файлов SKILL.md — это инструкции для ИИ-агентов Claude из публичных GitHub-репозиториев по кибербезопасности. Идея была простой: проверить не "безопасен ли этот агент?", а "может ли человек понять что агент делает, прежде чем запустить его?". Для этого разработали четыре текстовых паттерна — якоря — и автоматически проверяли каждый файл на их наличие.
Результаты оказались показательными: операционная база (что подаётся на вход) есть почти везде — 92%. А вот конкретный пример результата — только в 19% случаев. Все четыре якоря одновременно — лишь в 2,3%. Это означает что авторы НЕ думают о документации как о средстве помочь пользователю сформировать ожидания — они думают о ней как об инструкции для машины.
Дополнительно исследователь взял 6 навыков по обнаружению DNS-туннелирования и попробовал реально запустить их с синтетическими данными. Единственный навык с конкретным примером вывода (JSON с полями) позволил сразу понять что делать и что ожидать. Остальные пяти пришлось "лазить" в исходный код, чтобы понять какие аргументы передавать и что придёт в ответе. Пример экономил не просто время — он делал задачу вообще выполнимой без технической экспертизы.
Адаптации и экстраполяции
🔧 Техника: "обратный якорь" — попроси модель заполнить пример за тебя
Если не знаешь как сформулировать пример результата — спроси модель:
"Прежде чем выполнить задачу, покажи мне один пример того, как ты планируешь оформить ответ. Я скажу подходит ли формат."
Это "калибровочный шаг" перед основным запросом. Ты получаешь черновик формата → корректируешь → даёшь как якорь.
🔧 Техника: якорь-граница как фильтр галлюцинаций
Якорь "граница задачи" особенно эффективен когда модель склонна дополнять факты от себя:
ГРАНИЦА ЗАДАЧИ:
Используй только информацию из текста ниже.
Если данных нет — напиши "нет данных" вместо предположения.
Не добавляй общие факты из своих знаний.
Это не просто "не галлюцинируй" — это конкретная инструкция что делать в каждом случае неопределённости.
Ресурсы
Toward User Comprehension Supports for LLM Agent Skill Specifications Zikai Alex Wen — University of Washington, Tacoma School of Engineering & Technology Материалы и скрипты: https://github.com/zikaiwen/cyber-skill-comprehension