Промпты для работы над книгой
— Сделай эту сцену живее.
— Отлично! Вот переработанная версия: я усилил эмоциональную составляющую и добавил динамики.
Дальше идут полторы тысячи слов, в которых от вашей сцены уцелели три реплики. Героиня стала решительной, дождь за окном превратился в метафору её сомнений, а разговор, ради которого сцена и писалась, ужался до строчки «они наконец объяснились».
Модель отработала запрос правильно. Запрос назвал задачу и умолчал обо всём остальном: какой кусок трогать, что оставить слово в слово, чем сцена была до правки. Недостающее модель придумала сама, потому что автор оставил ей это право.
Запрос по книге отличается от запроса на пост или описание товара не длиной. Он повторяется. Сорок глав — это сотни обращений к модели, и половина текста в каждом из них одна и та же.
Каталоги промптов написаны под разовую работу
Подборки для писателей раздают две вещи. Первая — формула «роль → контекст → задача → формат». Вторая — список готовых запросов по этапам: придумать идею, собрать персонажа, распутать сюжет, написать диалог, вычитать главу.
Формула не врёт. На разовой работе она даёт результат: у поста, статьи и описания товара нет вчерашнего дня и не будет завтрашнего, весь мир задачи помещается в одно сообщение. Автор книги живёт иначе. Он приходит к модели в понедельник с шестой главой, в среду с восьмой, а через месяц переписывает третью. И каждый раз объясняет заново: кто такая Аглая, почему она не может просто уехать, отчего в этой книге не бывает счастливых финалов глав.
Роль заслуживает отдельного абзаца: с неё начинается почти каждый готовый промпт. В работе, представленной на конференции EMNLP в 2024 году, исследователи собрали 162 роли, от «ты опытный редактор» до «ты профессор литературы», и проверили каждую на 2 410 вопросах о фактах в четырёх семействах моделей. Роль в системном промпте не дала преимущества перед вариантом, где роли не было вообще.
Пол, тип и область роли на ответы влияли, но предсказать, какая роль сработает на конкретном вопросе, исследователи не смогли: автоматический выбор лучшей роли оказался не точнее случайного.
Художественного текста в замере не было, и о романе он напрямую не говорит ничего. Зато он показывает, куда не стоит тратить первые строки запроса: «ты — известный писатель» занимает место, которое пригодилось бы материалу.
Запрос по книге состоит из трёх слоёв. Модель должна что-то видеть, чего-то не делать и что-то сделать сейчас. Каталоги промптов описывают третий слой. Первые два в них отсутствуют, потому что на разовой задаче они не нужны.
Модель отвечает по тому, что видит
Разговор о запросе начинается не с формулировки. Перед ней стоит другой вопрос: что у модели перед глазами.
Модель не читала вашу книгу. Она видит текст сообщения, приложенные куски и то, что передал ей инструмент для писателей, если автор работает в таком инструменте. Всё остальное для неё не существует, и вместо несуществующего она подставляет среднее по своей памяти: героиню вообще, сцену прощания вообще, финал, который подойдёт любой книге.
Тут появляется соблазн приложить всю книгу разом. Команда Нельсона Лю из Стэнфорда проверила, что происходит с длинным входом. Моделям давали набор документов и вопрос, ответ на который лежал в одном из них, а нужный документ переставляли с места на место. Точность оказалась самой высокой, когда нужное стояло в начале или в конце входа, и заметно падала, когда оно попадало в середину. Работа так и называется — «Потерянные в середине».
Отдельный отчёт компании Chroma добавляет к этому вторую половину картины: на восемнадцати моделях качество ответа портится по мере роста входа, причём задолго до того, как вход дойдёт до предела окна. Отчёт корпоративный, не рецензируемый, и как доказательство он слабее стэнфордской работы, но направление у обоих замеров одно.
Практический вывод один: в запрос идёт материал под эту задачу, а не всё, что есть. Пятая глава для сверки детали, две реплики героини для правки диалога, краткое содержание третьей главы, чтобы модель понимала, откуда герой пришёл. А материал, на который модель обязана опираться дословно, автор ставит по краям сообщения: в начало или в конец.
С длинной прозой универсальные модели справляются по-разному, и это отдельный сюжет — о нём обзор нейросетей для длинной прозы.
Три части запроса: задача, границы, материал
Сильный запрос состоит из трёх частей.
Задача отвечает на вопрос «что сделать»: переписать, сократить, предложить варианты, найти нестыковки, продолжить сцену.
Границы говорят, чего не делать: какой кусок трогать, какой не трогать, что сохранить слово в слово.
Материал — сам текст: фрагмент в сообщении, открытая глава, краткие содержания соседних глав.
Авторы пишут первую часть и пропускают вторую. Модель достраивает границы сама и делает это по своему вкусу: расширяет там, где автор хотел точечной правки, сглаживает конфликт, добавляет объяснения. Разница между «перепиши сцену» и полноценным запросом выглядит так:
Перепиши сцену на перроне — от гудка до конца главы. Всё, что до гудка, не трогай, оно готово. Сохрани дословно реплики проводницы и деталь с забытым зонтом, она понадобится в седьмой главе. Авторские пояснения чувств убери, покажи то же через действие.
Здесь модель знает четыре вещи: где начинается её работа, где заканчивается, что уцелеет в любом случае и по какому принципу переделывать остальное.
Внутри границ живёт приём, который заслуживает отдельного имени. Самый дисциплинированный автор из тех, чьи запросы мы видели, вынес его в отдельную секцию с заголовком «особенно важно сохранить» и перечисляет там предметные якоря сцены, две-три реплики и то ощущение, которым сцена заканчивается. Механика тут обидная: переписывая, модель заменяет частное общим. Конкретная вещь становится «предметом», конкретная реплика — пересказом реплики, названная деталь исчезает как случайная. Именной список сохраняемого служит замком: перечисленное модель не трогает.
Запрет работает, если его видно в готовом тексте
У того же автора запрос начинается с секции «жёсткие условия», и в ней десяток строк:
- не менять сюжет и порядок событий;
- не добавлять новых событий и не убирать существующие;
- не смягчать конфликт;
- не усиливать сентиментальность;
- не добавлять авторских объяснений чувств;
- не вставлять формулы «он чувствовал», «в глубине души», «она вдруг поняла»;
- не заканчивать сцену утешением.
За ними идут запреты под конкретную главу: не удлинять реплики немногословного героя, не превращать антагониста в злодея, не делать героиню карикатурой.
Тут возникает возражение, и возражение сильное. Языковые модели плохо работают с отрицанием — это показывают бенчмарки, и это знает всякий, кто просил модель «не использовать слово "внезапно"» и получал два «внезапно» в первом абзаце. Запрет думать о розовом слоне работает на моделях примерно так же, как на людях.
Практика авторов и бенчмарки расходятся не случайно. Работает не отрицание само по себе, а проверяемость. «Не вставляй формулы "он чувствовал" и "в глубине души"» — это список строк, который модель может поискать в собственном черновике перед отправкой. «Не пиши скучно» проверить нечем: у скуки ведь нет признака, который видно в тексте.
Рабочее правило выглядит так. Запрет называет то, что автор нашёл бы в готовом куске глазами. Рядом с запретом стоит замена: не «убери канцелярит», а «замени отглагольные существительные глаголами». Каталог запретов для правки главы, со сверкой возвращённого текста и диагностическими запросами, собрала статья о редактуре книги с помощью ИИ.
Формат ответа автор задаёт сам
Русские авторы формулируют эту секцию через запрет: «только отредактированный текст, без комментариев, без объяснений, что изменено». Англоязычные шаблоны для разбора рукописи требуют обратного: структурированного отчёта из трёх частей — общий диагноз с двумя-тремя приоритетами, заметки по главам, список задач, по которому можно править.
Противоречия тут нет. В первом случае модель отдаёт художественный текст, и любое «я усилил атмосферу» автор вычищает руками. Во втором она ставит диагноз, и заметки нужны целиком.
Когда формат не задан, модель выбирает его сама и обычно смешивает оба: кусок прозы, обрамлённый пояснениями, с извинениями в конце. Одна строка в запросе снимает эту работу.
Какого размера кусок отдавать модели
Практики приходят к одинаковым числам с разных сторон.
Тот же автор работает битами по 500–800 слов: модель пишет кусок, останавливается и ждёт подтверждения. Его объяснение точнее любой теории: «при длинной генерации сползают голоса, ритм и детали. Короткие биты с проверкой — единственный способ удержать качество».
Sudowrite, англоязычный сервис для художественной прозы, переписывает до 6 000 слов за один заход — и в собственном руководстве пишет, что отрывки короче 600 слов дают более точный результат.
Причину видно сразу. Чем длиннее кусок, который модель пишет без остановки, тем дальше она уезжает от исходных условий: на третьей странице запреты из начала запроса действуют слабее, чем на первой. Плюс своё берёт арифметика проверки: полторы тысячи слов автор читает по диагонали, а вот шестьсот — целиком.
Размер куска автор выбирает не по терпению, а по готовности проверить результат. Продолжение сцены на сто пятьдесят слов автор просматривает за минуту и сразу видит, куда модель повела героя. Как устроена такая работа по шагам, показывает статья о продолжении главы.
Собранный запрос обгоняет десять реплик
Диалог с моделью кажется естественным способом договориться: попросил, посмотрел, уточнил, ещё раз уточнил. Проверка показала: способ обходится дорого.
Филипп Лабан с коллегами из Microsoft Research и Salesforce взяли одни и те же задачи и подали их двумя способами: целиком одним сообщением и раздробленными на реплики, когда условие раскрывается по ходу разговора. Замер охватил шесть типов задач, пятнадцать моделей и больше двухсот тысяч смоделированных разговоров. Раздробленный вариант потерял 39% результата. В 2026 году работу отобрали в устную программу ICLR, главной конференции по машинному обучению.
Интереснее выглядит устройство потери. Способность моделей упала умеренно, примерно на 16%, а ненадёжность выросла на 112%: разброс результата увеличился больше чем вдвое. Устроено это так: модель делает допущения на ранних ходах, преждевременно выдаёт итоговое решение и дальше цепляется за него. Сами исследователи заканчивают резче: свернув не туда, модель теряется и не возвращается.
Оговорка нужна обязательно: замер шёл на технических задачах — код, база данных, математика, пересказ. Проза туда не входила, и переносить проценты на роман никто не предлагает. Направление переносится.
Для работы над книгой отсюда следуют два вывода. Первый: запрос, поданный целиком, работает лучше разговора в десять реплик. Четыре строки условий, написанные сразу, дают больше, чем те же четыре строки, добавленные по одной после каждого неудачного ответа. Второй: испорченный ответ дешевле выбросить вместе с разговором, чем чинить внутри него. Автор дописывает недостающее условие в исходный запрос и отправляет его заново в новом чате.
Что хранить, а что писать каждый раз
В любом рабочем запросе по книге половина строк повторяется. Кто такие герои, что случилось в предыдущих главах, чего в этой книге не бывает, как звучит авторский голос — всё это переезжает из запроса в запрос неизменным. Меняется одна секция: что сделать сейчас.
Авторы решают задачу переноса руками. Автор с жёсткими условиями собирает после каждой главы сводку и вставляет её в начало нового разговора. Внутри лежат состояния каждого героя, отношения попарно, предметные якоря и открытые долги текста, а двумя отдельными списками идут «в следующей главе не забыть» и «в следующей главе нельзя». Дисциплина серьёзная, и результат она даёт — до тех пор, пока у автора есть силы её поддерживать.
Цена ручного переноса известна каждому, кто пробовал. Сводка устаревает через две главы. В новом чате её нет, и автор лезет за вчерашним сообщением. Занимает она изрядную часть запроса, а длинный вход, как показали замеры, бьёт по точности. А главное — она не переживает перерыв: после недели без работы над книгой автор возвращается и обнаруживает, что проще написать сцену самому, чем восстановить обстановку разговора.
Постоянная часть запроса должна храниться отдельно от него и подставляться сама. Такое хранение — работа инструмента, и авторская дисциплина её не заменяет. Эту задачу и решает Литраб, ИИ-помощник для писателей: он пишет и правит прозу внутри вашей рукописи.
Как Литраб подставляет постоянную часть
В Литрабе постоянная часть живёт в Досье — это раздел с материалами книги: синопсис, оглавление, карточки персонажей, элементы мира, портрет авторского стиля. Ничего из этого автор в запрос не переносит.
Контекст книги приходит в чат сам. Название, жанр, портрет стиля, синопсис, оглавление, карточки героев, элементы мира и краткие содержания глав уходят к модели без действий автора. Плюс текст главы, открытой сейчас в редакторе: у длинной главы — фрагмент вокруг того места, где автор работает.
Решётка добавляет точность. Полные тексты остальных глав сами не приходят: их автор добавляет через «#». Тем же способом приходит полное описание карточки, если у большой книги оно приехало сокращённым.
Длинная работа идёт кусками. Объёмную задачу чат выполняет кусками примерно по 800 слов, в конце каждого спрашивает «Продолжать?» и ждёт ответа. Ту же работу битами Литраб берёт на себя.
У кнопки «Продолжить» есть поле инструкции. В него помещаются пять тысяч знаков: и задача, и границы, и список сохраняемого. Контекст книги эта кнопка получает сама, поэтому в инструкции остаётся одна переменная часть: что делать в этой сцене.
«Переписать» работает иначе: четыре режима для выделенного фрагмента, без синопсиса и без условий, зато мгновенно.
Остаются три оговорки. Треды в чате независимы: новый разговор не помнит предыдущий, и это осознанное решение — иначе каждый следующий ответ обходился бы дороже, а вчерашние ошибки ехали бы дальше по всей книге. Для модели краткое содержание главы остаётся замыслом, а не текстом: по нему она обсуждает и предлагает, но дословно не правит. И у большой книги описания из Досье приезжают не целиком — тогда чат сам говорит об этом автору, а решётка возвращает нужное полностью.
Портрет авторского голоса живёт по своим правилам. Как собрать его из образца прозы и по каким признакам виден уехавший голос, рассказывает статья о том, как научить нейросеть писать в вашем стиле.
Чего модель не знает о вашей книге
Модель не знает, зачем в главе стоит сцена. Она не знает, что зонт выстрелит через две главы, что героиня молчит не от растерянности, а от расчёта, и что утешительный финал убьёт всю книгу. Такие вещи автор и вписывает в границы, в запреты и в список сохраняемого.
Отсюда выходят две новости сразу, неприятная и приятная. Хорошего запроса не бывает без ответа на вопрос, чего вы хотите от сцены. Работа модели этот ответ не заменяет. Зато, ответив однажды, вы получаете формулировку, которая работает и в шестой главе, и в двадцатой.
Постоянную часть автор собирает один раз. Литраб хранит материалы книги, подставляет их сам и оставляет автору ту часть запроса, которая меняется от сцены к сцене. Попробуйте на своей рукописи: пробный доступ не требует карты.
Рядом по теме
- Как написать книгу — что стоит за словом «книга» и с чего начинается работа.
- Как редактировать книгу с помощью ИИ — устройство запроса на правку главы и каталог запретов.
- Как научить нейросеть писать в вашем стиле — портрет стиля и признаки уехавшего голоса.
- Как продолжить главу — продолжение сцены по шагам.