Почему «напиши мне книгу» не работает — и как писать длинные тексты с ИИ снизу вверх

15 мин. чтения
BYBIT · СПОТ И ФЬЮЧЕРСЫ
Крипта с нуля
Комиссия 0,1%, торги 24/7, старт с $10
Открыть счёт

Коротко (TL;DR)

«Напиши мне книгу» не работает: после нескольких тысяч слов ИИ теряет нить, забывает, что писал в начале, и начинает противоречить сам себе. Решение — писать не сверху вниз одним куском, а снизу вверх: сначала атомы (тезисы, факты, структура), потом сборка по частям с явным контролем консистентности. Это метод, а не волшебный промпт.

Что важно понять сразу:

  • У модели ограниченная память. По мере роста текста в контексте качество падает неравномерно — это называется context rot. Написать связную книгу «в один заход» невозможно физически.
  • Реальный лимит — не «миллион токенов». Миллион — это API. В обычном чате на claude.ai у вас около 200 000 токенов. Большинство авторов работают именно в чате, и планировать надо от реального потолка.
  • Ключ к консистентности — паттерн «библия + состояние». Неизменная база (тезисы, факты, глоссарий, структура) плюс версионируемый снимок «что уже написано». С ним глава 15 пишется, не перечитывая все предыдущие.
  • Риски реальны: ИИ выдумывает факты и цитаты даже в нон-фикшн. Финальную сверку делаете вы, а не модель.

Что понадобится: доступ к Claude (чат claude.ai или API), место для рабочих файлов (заметки, структура) и готовность вести проект как стройку, а не как один разговор.

Почему «напиши мне книгу» разваливается

Короткий ответ: языковая модель не «помнит» текст, она держит его в контекстном окне — и чем больше туда попадает, тем хуже работает. Anthropic называет эффект прямо — context rot: точность и способность вспомнить нужное падают по мере роста объёма входных данных, причём неравномерно. Это не мнение, а измеренный эффект: независимое исследование Chroma подтвердило деградацию на 18 разных языковых моделях, включая Claude.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Второй эффект — lost-in-the-middle: модель лучше помнит начало и конец контекста, чем середину (кривая точности имеет U-образную форму). Практический вывод неочевиден, но важен: самые важные инструкции и факты кладите в конец промпта, а не в середину — там они «виднее» модели.

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

Два разных лимита: 200К в чате против 1М на API

Здесь — путаница, на которой спотыкается почти каждый. Вы читаете «Claude держит миллион токенов контекста» и думаете, что можете загрузить в чат всю книгу. Это не так.

  • API (для разработчиков, через код) — до 1 000 000 токенов на актуальных моделях (на 12 июля 2026).
  • Чат на claude.ai (где вы, скорее всего, и пишете) — около 200 000 токенов на платных тарифах на 12 июля 2026; на отдельных корпоративных моделях — до 500 000.

Разница принципиальна. 200 000 токенов — это примерно 150 000 слов, то есть небольшая книга целиком, но без запаса на диалог, правки и ваши инструкции. На практике потолок ещё ниже: чем ближе к лимиту, тем сильнее context rot. Планируйте контекстное окно нейросети как ограниченный ресурс: в одной сессии — одна глава или один блок, а не весь текст.

Метод снизу вверх, шаг за шагом

Суть структуры снизу вверх: не начинать с «главы 1», а сначала собрать основание, из которого главы вырастут.

  1. Атомы. Соберите сырьё: тезисы, факты с источниками, ключевые примеры, глоссарий терминов. Для нон-фикшн это костяк — то, что книга должна донести. ИИ помогает выгружать и структурировать, но факты вы проверяете (см. риски).
  2. «Библия проекта». Сведите атомы в один неизменный документ: о чём книга, для кого, каким голосом написана, глоссарий, тезисный план. Это ваша константа — её вы будете подкладывать в каждую сессию как опору.
  3. Структура по принципам, а не по хронологии. Разложите материал по логике «от чего зависит понимание следующего», а не «что было раньше». Хороший нон-фикшн ведёт читателя по нарастанию сложности.
  4. Главы по частям. Пишите по одному блоку за сессию, подкладывая «библию» и краткий снимок состояния (о нём ниже). Не тащите в контекст предыдущие главы целиком — только их конспект.
  5. Сверка. После каждой главы проверяйте её на противоречия с «библией» и уже написанным: не поменялся ли термин, не противоречит ли вывод раннему тезису.
  6. Компрессия и полировка. В конце — проход на удаление воды и выравнивание голоса. Это отдельная задача, не смешивайте её с написанием.

Пример стартового промпта для сбора «библии»:

Я пишу нон-фикшн-книгу про <тема> для <аудитория>.
Помоги собрать «библию проекта»: 1) один абзац — о чём книга и зачем;
2) 5–7 ключевых тезисов, которые она должна донести;
3) глоссарий терминов; 4) тезисный план глав по нарастанию сложности,
а не по хронологии. Не пиши сами главы — только фундамент.

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

BYBIT EARNЗаставь крипту работатьПроценты на USDT и BTC без блокировки — деньги остаются под рукой.Разместить

Как выглядит проход на практике

Соберём метод в короткий сквозной пример — гайд по продуктивности на 8 глав.

  1. Библия. За одну сессию собираете: о чём гайд, для кого, 6 тезисов, глоссарий, план из 8 глав по нарастанию. Сохраняете как отдельный файл. Это ваша константа.
  2. Состояние. Заводите второй файл: «Написано: —. Введены термины: —. Открытые тезисы: все». По ходу будете его обновлять.
  3. Глава 1. Новая сессия: подкладываете библию + состояние, просите написать первую главу по плану. Получаете черновик.
  4. Обновляете состояние. Дописываете: «Написано: гл.1. Введены термины: X, Y. Закрыт тезис №1». Теперь следующая сессия знает, что уже было, не читая саму главу.
  5. Глава 5, новая сессия. Подкладываете библию + актуальное состояние (не предыдущие главы целиком). Модель пишет пятую главу консистентно — она видит, какие термины уже введены и какие тезисы закрыты.
  6. Сверка. Раз в несколько глав проверяете на противоречия: не поменялось ли определение термина, не дублируются ли тезисы.
  7. Финальная компрессия. Отдельным проходом убираете воду и выравниваете голос по всей книге.

Ключевое наблюдение: ни на одном шаге вы не держите в контексте всю книгу. Модель работает с двумя короткими документами, а не с сотней тысяч токенов текста, — и именно поэтому качество не проседает к финалу.

Паттерн «библия + состояние» — как удержать консистентность

Это главный приём, перенесённый из мира ИИ-прозы в нон-фикшн. Он состоит из двух файлов:

  • Библия (bible) — неизменная база: тезисы, факты, глоссарий, голос, структура. Не меняется по ходу.
  • Состояние (state) — версионируемый снимок «что уже раскрыто»: какие главы написаны, какие тезисы закрыты, какие термины введены.

Работает так: в новую сессию вы подкладываете библию (константа) и текущее состояние (что уже есть) — и просите написать следующую главу. Модели не нужно перечитывать всю книгу, ей достаточно этих двух документов. Этот принцип проверен на практике в экспериментальном проекте Claude Book — автоматизированном фреймворке, который сам ведёт библию и версионирует состояние: там 18-главный текст собирался так, что глава 15 писалась без загрузки сотни тысяч токенов предыдущего контекста. Вы делаете то же самое руками — подкладываете два коротких документа вместо всей книги. Именно это обеспечивает консистентность текста при работе с ИИ на длинной дистанции.

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

Claude Projects как рабочее пространство книги

Если пишете в экосистеме Claude, удобный дом для проекта — Projects. Это рабочее пространство со своей базой знаний: загружаете туда библию, структуру, справочные материалы, и модель опирается на них в каждом чате проекта. При большом объёме знаний Projects переходит в RAG-режим (достаёт релевантные куски по запросу), что расширяет эффективную ёмкость в разы. На бесплатном тарифе доступно ограниченное число проектов — для одной книги хватает.

Практический приём — гибридная стратегия контекста: неизменный ядровый файл (библия) подкладывается всегда, а остальное подтягивается по необходимости, а не грузится целиком.

Продвинутое: узкие сессии вместо одного гигантского чата

Соблазн — вести всю книгу в одном бесконечном чате. Не надо: он быстро упрётся в context rot, и качество к концу просядет. Профессиональный подход — много узких сессий, каждая под свою задачу (написать главу, свести факты, вычитать голос), с передачей между ними короткого файла состояния. Для соло-автора это ручной аналог субагентов: вместо одного перегруженного разговора — цепочка свежих, каждый с чистой памятью и точным заданием.

Какая модель Claude на каком этапе

Не для всех этапов нужна самая мощная модель. Ориентир (конкретные имена моделей меняются — сверяйте актуальные в документации):

ЭтапЗадачаКакая модель
Диагностика/структурапродумать план, найти дырысильная модель (глубокое рассуждение)
Черновик по частямписать главы по библиибыстрая/средняя (Claude Sonnet 5 и подобные)
Финальная сверкафакт-чек, противоречиясильная модель + ваша ручная проверка

Метод с Claude против специальных «книжных» платформ

Резонный вопрос: зачем возиться с библией и состоянием вручную, если есть специализированные ИИ-сервисы для авторов (вроде Sudowrite или Novarrium)? Разница — в контроле и понимании.

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

Метод снизу вверх с обычным Claude даёт противоположный набор: чуть больше ручной работы (вы сами ведёте два файла), но полный контроль над тем, что попадает в контекст, и понимание, почему метод работает. Библия и состояние — это обычные текстовые файлы, они ваши и переносятся куда угодно. А главное — освоив принцип на Claude, вы легко примените его в любом инструменте: он про то, как устроена память модели, а не про кнопки конкретного сервиса.

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

Риски и типичные ошибки

Длинный текст с ИИ несёт несколько конкретных рисков — их надо закрывать сознательно, а не надеяться, что «модель разберётся».

  • Галлюцинации в фактах и цитатах. ИИ выдумывает источники даже в серьёзном нон-фикшн — по данным одного расследования, в 51 научной работе насчитали более 100 сфабрикованных цитат. Каждую цифру, дату и цитату из ИИ-текста проверяйте на первоисточнике. Это не опция.
  • «AI slop» — шаблонный, плоский текст. Узнаётся по гладкой безликости. Важная тонкость: низкая «перплексия» (гладкость) — это диагностика плоскости, а не детектор ИИ. Не гоняйтесь за «обходом детекторов»; работайте над тем, чтобы текст нёс мысль и голос.
  • Авторские права. Вопрос авторства ИИ-текста юридически не устоялся в разных странах. Если это важно для публикации, уточните правила площадки и юрисдикции заранее.
  • Один чат на всю книгу. Классическая ошибка — см. раздел про узкие сессии.

FAQ

Сколько текста писать за один заход? Один логический блок — главу или крупный раздел. Не всю книгу: к её середине начало уже «выцветет» из контекста (context rot), и текст поплывёт. Одна сессия — одна задача.

Нужен ли API или хватит обычного чата? Для большинства авторов хватает чата claude.ai. Просто помните, что там около 200 000 токенов, а не рекламный миллион (это API). Метод снизу вверх как раз позволяет писать книгу в пределах чат-лимита.

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

Как проверить, что готовый текст не врёт? Ручной факт-чек по первоисточникам: каждая цифра, дата, цитата и имя. ИИ уверенно выдумывает правдоподобные ссылки, поэтому финальную сверку делает человек, а не модель.

Чем этот метод отличается от специальных «книжных» ИI-платформ? Специализированные сервисы (вроде Sudowrite или Novarrium) прячут управление контекстом под капот. Метод снизу вверх с Claude даёт вам тот же контроль руками и понимание, почему он работает, — а заодно не привязывает к одному сервису.

С чего начать прямо сейчас? С «библии»: одна страница — о чём документ, для кого, ключевые тезисы и глоссарий. Это фундамент, на который дальше нарастает структура и главы. Без него любой длинный текст с ИИ рано или поздно поплывёт.

Курс «Claude Code с нуля до продакшена» · модуль «Прикладные проекты». Полная программа и два маршрута обучения — на странице курса.

Предыдущий урок: Монтаж видео с Claude Code · Следующий урок: Claude как второй мозг

Bybit
$30,100 + $5,030
100 USDT в подарок
Получить →
Поделиться
Связаться:
Крипто- и data-аналитик, инженер-программист (факультет компьютерных наук ХНУРЭ). В IT с 2008 года: администрировал корпоративный мониторинг в «Vodafone Украина», семь лет разрабатывал и продвигал веб-проекты, пять лет руководил маркетингом на метриках — конверсия, CTR, ROI, LTV.Криптовалютными рынками занимаюсь с 2021 года: ончейн-метрики, токеномика, макроэкономические индикаторы. Разработал собственную data-driven модель анализа рынка на 30+ метрик. Стек — Python (pandas, NumPy, SciPy, matplotlib), математическая статистика и EDA; сбор и сверку данных автоматизирую AI-агентами.Принцип — «Don't trust, verify»: каждая цифра проверена по первоисточнику, ключевые — минимум по двум независимым; прогнозы — только сценарии с условиями. Тезис без данных не публикуется.