Book-as-context: проектирование сложной архитектуры с ИИ через подложку из книги

Проблема

Если сказать Claude или Cursor «сделай передачу заказов из интернет-магазина в ERP» — на выходе будет наколеночный файловый обмен по FTP и рапорт «готово». Дальше разработчики смеются и делают вывод «ИИ не тянет архитектуру».

Корень не в модели. Модель опирается на «среднюю температуру по интернету» — усреднённый код из открытых источников, где production-grade интеграции встречаются реже, чем туториалы. Без предметной базы агент не знает, что правильный ответ здесь — event-driven с гарантиями доставки, идемпотентностью и согласованностью данных между системами. На уровне intake ту же дыру закрывает clarify gate в Jira (#11): пока в тикете нет цели, scope и AC, задача не уходит в разработку.

Методика

Заземлить агента на конкретную авторитетную книгу по предметной области.

1. 1. Выбор книги. Под архитектуру / хайлоад / событийку — Таненбаум, «Распределённые системы: принципы и парадигмы». Это уровень «как Котлер у маркетологов»: жёсткий сопромат с формулами, не пересказ.
2. 2. Нарезка в wiki. Скрипт на двух LLM-моделях нарезает книгу на чанки и собирает текстовую wiki-структуру (формат Obsidian: ~100–150 страниц с перекрёстными ссылками). Скрипт также эксплейнит каждый найденный термин — это позволяет модели реверсить задачу: от бизнес-требования к инженерному паттерну, к реализации, к библиотеке.
3. 3. Параметры. Несколько итераций по чанкам / токенам / моделям. Стоимость полного прогона книги — порядка $1.5 через OpenRouter.
4. 4. Подкладка в проект. Wiki кладётся в репозиторий. Агент ходит по индексу и вытаскивает концепты под задачу — через встроенную индексацию Cursor либо через отдельный скилл. Контекст не деградирует: агент бегает по файлам, не загружая книгу целиком в окно.
5. 5. Агентный слой поверх поиска. Wiki + retrieval — это инфраструктура, не методика. Поверх неё нужна дисциплина агентного поведения: query routing (тип задачи определяет, идти ли по перекрёстным ссылкам или брать топ-k чанков), интерпретация scores (когда BM25 важнее семантики — на точных терминах), traversal от бизнес-требования к паттерну к реализации. Ключевое отличие от generic RAG: агент знает структуру, терминологию и оглавление конкретной книги — поэтому формулирует запросы в терминах источника, а не в терминах задачи. Это и даёт точность: не «найди что-то про консенсус», а «найди раздел про Paxos в контексте репликации». Без этого слоя агент получает правильные чанки, но навигирует вслепую.

   Как выглядит механизм изнутри (фрагмент book-search-helper/SKILL.md):

   ## Шаг 2 — Проверить наличие досье
   Проверь books/<slug-книги>.md — структура книги,
   ключевые термины, темы глав.
   
   ## Шаг 3в — Сформулировать умный запрос
   Используй термины автора из досье, а не парафраз пользователя.
   Котлер пишет «запрос», а не «спрос»;
   Талеб пишет «Чёрный лебедь», а не «непредвиденное событие».

   Досье на книгу (books/tanenbaum-distributed-systems.md) содержит оглавление и авторскую терминологию — поэтому запрос формулируется не «найди что-то про Kafka», а «найди message delivery semantics в контексте главы про репликацию».

6. 6. Эффект. Все диалоги, планы работ, API-контракты, инфраструктурные решения и дальнейший вайб-кодинг идут через оптику книги. Уровень держится «с одного промпта» — не нужно каждый раз дописывать «сделай событийность, асинхронность, контракты».

Как выглядит реальная страница сгенерированной вики (фрагмент из tanenbaum/wiki/.drafts/Атомарные транзакции.md):

Атомарная транзакция гарантирует, что серия операций будет выполнена
либо полностью, либо не выполнена вовсе ([[все-или-ничего принцип]]).
Этот принцип критичен для [[целостность данных|целостности данных]]
в [[распределённая система|распределенных системах]] [[Tanenbaum Full_Rag_00001]].

## Реализация

Реализация в распределенных системах включает [[двухфазный коммит]] (2PC),
[[Paxos (протокол)|Paxos]] или [[Practical Byzantine Fault Tolerance|PBFT]].
Paxos обеспечивает консенсус между репликами, требуя кворума участников
для принятия решения даже при сбоях [[Tanenbaum Full_Rag_00024]].

## See Also
[[Paxos (протокол)]] · [[двухфазный коммит]] · [[распределённая система]]
· [[целостность данных]] · [[масштабируемость]]

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

Механика переносима: wiki — это текст, копируется/симлинкается между проектами. Под разные фазы — разные книги: «Чистый код» на разработке, Фаулер на ревью/рефакторинге, Савин на QA.

Артефакт

Скрипт генерации wiki: вход — PDF или текст книги и параметры чанков, выход — Obsidian-vault со ~150 связанными страницами. Социальное доказательство: публичный пост с самой высокой реакцией во всём корпусе — 105 399 просмотров, 203 комментария.

Для кого и почему

Если вы строите AI-assisted разработку и хотите, чтобы агент держал архитектурный уровень без напоминаний — методика переносима на любую предметную область. Bottleneck здесь не код: это выбор правильного первоисточника и дисциплина его применения.