Чому «напиши мені книгу» не працює — і як писати довгі тексти зі ШІ знизу вгору

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

«Напиши мені книгу» не працює: після кількох тисяч слів ШІ втрачає нитку, забуває, що писав на початку, і починає суперечити сам собі. Рішення — писати не згори вниз одним шматком, а знизу вгору: спершу атоми (тези, факти, структура), потім збірка по частинах із явним контролем консистентності. Це метод, а не чарівний промпт.

Що важливо зрозуміти одразу:

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

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

Чому «напиши мені книгу» розвалюється

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

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Другий ефект — lost-in-the-middle: модель краще пам’ятає початок і кінець контексту, ніж середину (крива точності має U-подібну форму). Практичний висновок неочевидний, але важливий: найважливіші інструкції й факти кладіть у кінець промпту, а не в середину — там вони «видніші» моделі.

Claude Code vs Cursor vs Codex: який обрати під свою роботу

Другий мозок на Claude без коду: база знань, клон вашого стилю й особисті асистенти

Монтаж відео кодом: пайплайн із Deepgram, FFmpeg і Remotion

Supabase і Stripe за вечір з Claude Code — і три речі, які агент зробить не так

Деплой на Vercel через GitHub: як викласти проект покроково

Із цих двох ефектів випливає все інше. Написати довгий документ ШІ одним шматком не можна: до середини книги початок уже «вицвів», і текст попливе — виникнуть повтори, суперечності в термінах і висновки, що сперечаються з ранніми розділами. Що довший текст, то сильніший цей ефект, і жоден «промпт кращий» його в корені не скасовує — це фундаментальна властивість архітектури моделі, а не якості вашого запиту. Тому й потрібен інший підхід — знизу вгору.

Два різні ліміти: 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) тезовий план розділів за наростанням складності,
а не за хронологією. Не пиши самі розділи — лише фундамент.

Зверніть увагу на останній рядок: ви явно забороняєте моделі стрибати до написання. На етапі основи це важливо — інакше ШІ за звичкою почне «писати книгу», і ви отримаєте текст без фундаменту.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Як виглядає прохід на практиці

Зберемо метод у короткий наскрізний приклад — гайд із продуктивності на 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 проти спеціальних «книжкових» платформ

Резонне питання: навіщо морочитися з біблією й станом вручну, якщо є спеціалізовані ШІ-сервіси для авторів (на кшталт Sudowrite чи Novarrium)? Різниця — у контролі й розумінні.

Спеціальні платформи ховають керування контекстом під капот: вони самі ведуть «пам’ять» книги, підставляють потрібні шматки й згладжують context rot. Це зручно, але має дві ціни. Перша — ви не розумієте, що відбувається, і коли текст «пливе», не знаєте, де лагодити. Друга — прив’язка: ваша книга живе всередині їхнього формату й їхньої підписки.

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

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

Ризики й типові помилки

Довгий текст зі ШІ несе кілька конкретних ризиків — їх треба закривати свідомо, а не сподіватися, що «модель розбереться».

• Галюцинації у фактах і цитатах. ШІ вигадує джерела навіть у серйозному нон-фікшн — за даними одного розслідування, у 51 науковій роботі нарахували понад 100 сфабрикованих цитат. Кожну цифру, дату й цитату з ШІ-тексту перевіряйте на першоджерелі. Це не опція.
• «AI slop» — шаблонний, плаский текст. Упізнається за гладкою безликістю. Важлива тонкість: низька «перплексія» (гладкість) — це діагностика плаского тексту, а не детектор ШІ. Не женіться за «обходом детекторів»; працюйте над тим, щоб текст ніс думку й голос.
• Авторські права. Питання авторства ШІ-тексту юридично не усталилося в різних країнах. Якщо це важливо для публікації, уточніть правила майданчика й юрисдикції заздалегідь.
• Один чат на всю книгу. Класична помилка — див. розділ про вузькі сесії.

FAQ

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

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

Що робити, якщо контекст обірвався і ШІ «забув» книгу? Нічого страшного — на те й потрібні біблія і файл стану. Відкриваєте нову сесію, підкладаєте обидва документи, і модель продовжує з потрібного місця, не перечитуючи все написане.

Як перевірити, що готовий текст не бреше? Ручний факт-чек за першоджерелами: кожна цифра, дата, цитата й ім’я. ШІ впевнено вигадує правдоподібні посилання, тому фінальну звірку робить людина, а не модель.

Чим цей метод відрізняється від спеціальних «книжкових» ШІ-платформ? Спеціалізовані сервіси (на кшталт Sudowrite чи Novarrium) ховають керування контекстом під капот. Метод знизу вгору з Claude дає вам той самий контроль руками й розуміння, чому він працює, — а заразом не прив’язує до одного сервісу.

З чого почати просто зараз? З «біблії»: одна сторінка — про що документ, для кого, ключові тези й глосарій. Це фундамент, на який далі наростає структура й розділи. Без нього будь-який довгий текст зі ШІ рано чи пізно попливе.