Первый запрос полезнее строить не вокруг вопроса «что ты умеешь?», а вокруг небольшого результата, который легко проверить. Возьмите своё письмо или короткий фрагмент кода, сформулируйте задачу и заранее решите, по каким признакам примете ответ. Я бы начал именно с этого: так после одного обмена сообщениями понятно, что исправить в запросе, а не приходится оценивать общее впечатление.
На STIVA.ai доступны отдельные страницы этих моделей. Названия СТИВА и СТИВА ИИ обозначают тот же сервис; ниже ссылки ведут на конкретные страницы, а не на общий обзор Claude.
С чего начать и какую версию выбрать
Для редактирования письма можно открыть страницу Claude Fable 5: среди описанных для неё задач есть улучшение текста с сохранением авторского голоса. Если первый запрос касается кода, логичный вариант - страница Claude Fable 5.1, где отдельно описаны анализ ошибок, предложения по исправлению и объяснение изменений. Это выбор по задаче, а не обещание, что одна версия непременно даст лучший ответ на любом примере.
- Подготовьте небольшой исходный материал. Для текста хватит одного письма; для кода - функции и описания ожидаемого поведения.
- Уберите из примера сведения, которыми не готовы делиться. Для первого запроса реальные имена клиентов, ключи доступа и внутренние документы не нужны.
- Откройте страницу выбранной версии. Если она доступна для запроса в текущем интерфейсе, передайте запрос вместе с исходным материалом. Не заменяйте материал фразой «посмотри мой проект»: без самого фрагмента проверить вывод будет трудно.
- Сохраните исходник и ответ отдельно. Сравнивать следует конкретные изменения, а не только гладкость формулировок.
Хороший первый запрос содержит четыре вещи: цель, исходные данные, ограничения и формат ответа. Для кода добавьте способ проверки. Не нужно перечислять модели десятки правил; достаточно тех, нарушение которых действительно сделает результат бесполезным.
Первый запрос для текста: отредактировать письмо
Задача ниже намеренно узкая. Модель должна сделать письмо яснее, но не придумывать обещания, сроки или причины задержки. Скопируйте весь блок, а затем замените текст между маркерами своим черновиком. Если факты ещё не согласованы, так и оставьте их неподтверждёнными.
Ты редактор деловой переписки. Сделай письмо ясным и спокойным для клиента. Сохрани факты и смысл, не добавляй обещаний, дат и причин, которых нет в исходнике. Объём готового письма - не более 90 слов. Ответ дай в двух частях: 1. Готовое письмо. 2. Список из 2-3 существенных правок с кратким объяснением. Если в исходнике не хватает данных для точной формулировки, отметь это после письма, а не заполняй пробел догадкой. [ИСХОДНИК] Здравствуйте! Ваш вопрос по отчёту поступил. Сейчас уточняем данные у команды. Когда получим подтверждение, напишем вам отдельно. Спасибо за ожидание. [/ИСХОДНИК]
Здесь есть что сверить вручную: получен вопрос по отчёту, данные уточняются, ответ придёт после подтверждения. Если готовый текст превратит это в обещание ответить «сегодня» или сообщит, что ошибка уже найдена, результат нельзя отправлять без правки. Также проверьте, не исчезла ли вежливая благодарность и не стал ли тон неоправданно категоричным.
Для статьи или инструкции принцип тот же, но единицей проверки будет не письмо, а абзац. Вставьте один раздел, укажите читателя и попросите отдельно перечислить неоднозначные места. Не начинайте с требования переписать большой документ целиком: на небольшом фрагменте проще понять, правильно ли модель трактует ваши ограничения.
Первый запрос для кода: найти ошибку и проверить исправление
Claude Fable 5.1 описана как модель для анализа и улучшения кода. Но формулировка «найди баги» без ожидаемого поведения оставляет слишком много вариантов ответа. Ниже маленькая функция с воспроизводимой проблемой: пустой список приводит к делению на ноль. Запрос просит сначала объяснить причину, затем предложить минимальное изменение и проверку.
Ты помогаешь проверить небольшой фрагмент Python-кода. Функция должна возвращать среднее арифметическое чисел. Для пустого списка она должна возвращать None. Найди причину сбоя, предложи минимальное исправление и не меняй поведение для непустого списка.
Ответ дай в таком порядке:
1. Причина ошибки в одном-двух предложениях.
2. Полный исправленный код функции.
3. Три проверки с ожидаемым результатом: пустой список, один элемент и несколько элементов.
4. Одно ограничение предложенного решения, если оно есть.
Не утверждай, что запускал код: я выполню проверки самостоятельно.
[КОД]
def mean(values):
return sum(values) / len(values)
[/КОД]Ожидаемые проверки можно выполнить и без догадок о большом проекте: mean([]) is None, mean([7]) == 7 и mean([2, 4, 6]) == 4. Перенесите предложенную функцию в свою среду, выполните эти выражения и посмотрите, проходят ли они. Если ответ предлагает иной контракт для пустого списка, верните модель к условию вместо того, чтобы незаметно принимать новый вариант поведения.
В рабочем проекте потребуется больше контекста: сообщение об ошибке, вызывающий код, типы входных данных и действующие тесты. Передавайте ровно те части, которые нужны для разбора. Просьба «не меняй публичную сигнатуру» или «сохрани совместимость с этими тестами» полезнее абстрактного требования «исправь качественно».
Что делать после первого ответа
Для письма сравните итог с исходником построчно: все ли факты на месте, не появились ли новые обязательства, подходит ли тон адресату. Затем можно попросить второй вариант, но обозначить конкретную причину: «сделай короче, сохрани фразу о подтверждении данных». Так уточнение опирается на наблюдаемую проблему.
Для кода сначала проверьте предложенные тесты и крайние случаи, затем оцените масштаб изменений. Если вместо одной проверки пустого списка вам предложили переписать модуль, попросите минимальный патч и объяснение, зачем нужна каждая дополнительная правка. Проверка в вашей среде и просмотр изменений остаются обязательными: убедительный текст ответа не доказывает, что программа работает.
Не путайте заявленный размер контекста с удобным объёмом первого запроса. Для Fable 5.1 на странице указан контекст до 1 млн токенов, но фактический полезный объём зависит от структуры данных и лимитов платформы. Поэтому для старта я бы не ориентировался на предельные цифры: один фрагмент, одна задача и явный критерий проверки дадут более понятный результат.
С файлами тоже не стоит делать предположений по одному названию модели: для Fable 5.1 обработка PDF на странице поставлена в зависимость от интерфейса. Если у вас документ, а доступный способ передачи неясен, начните с нужного текстового отрывка. И не считайте настройки других интерфейсов или агентные возможности частью обычного запроса на странице модели: примеры выше рассчитаны на переданный вами текст и код, без доступа к вашему компьютеру.
Итог простой: сначала дайте маленькую проверяемую задачу, потом расширяйте контекст. Для текста проверяйте сохранность фактов; для кода - поведение на оговорённых входных данных. В обоих случаях полезный второй запрос обычно начинается со слов «вот что не подошло», а не «попробуй ещё раз».
