Подложите агенту авторитетную книгу по предмету как wiki в репозитории — целиком, с индексом и ссылками, а не разовым вложением файла в диалог. Тогда даже с короткого промпта он проектирует в понятиях первоисточника: очереди, гарантии доставки, идемпотентность, отказоустойчивость. Ниже — приём book-as-context, сквозной пример магазин→ERP и ограничения метода.
Картина знакомая. Человек — основатель, продакт, иногда даже разработчик в новой для себя зоне — открывает Claude или Cursor и пишет что-то вроде: «сделай передачу заказов из интернет-магазина в ERP». Задача звучит нормально: заказы появляются на сайте, их надо донести до учёта. Детали он не расписывает — не потому что ленится, а потому что не знает, какие детали вообще важны. ERP «иногда лежит», заказы «не должны теряться», дубликаты «как-то плохо», CRM «тоже надо подтянуть» — это всё живёт в голове как здравый смысл, а не как требования.
Агент отвечает уверенно. Через минуту у вас на столе схема: выгрузка заказов в CSV по крону, файл уезжает по FTP, на той стороне «что-нибудь подхватит». В чате — рапорт «готово». Снаружи это выглядит как решение. Внутри — учебниковый минимум: ночной батч, шара, ручной разбор, когда ERP не ответила, и магическое «перешлём ещё раз», если что-то потерялось.
Дальше история расходится на две ветки.
Первая — рядом есть инженер, который уже строил такие контуры. Он смотрит на FTP и понимает цену: что будет при простое ERP на шесть часов, как разъедутся остатки, кто отвечает за повторную доставку, где аудит. Он возвращается в чат и дожимает постановку: асинхронность, очередь, идемпотентность, журнал состояний, безопасность канала. После десятка уточнений агент уже рисует взрослый контур. Вывод у этой ветки привычный: «с ИИ можно, если сам умеешь спрашивать».
Вторая ветка — такого опыта рядом нет. Или опытный коллега есть, но смеётся со стороны: «ну да, гуманитарии с чатом склепают сайтик на три страницы, а архитектуру — никогда». Для него CSV по FTP — не баг метода, а доказательство, что модель «не тянет». И формально он прав в одном: с пустого промпта промышленного уровня не выходит. Не прав в другом: виновата не «глупость» модели.
Корень в том, на чём модель обучена. В открытом интернете туториалов про «выгрузи CSV и положи на FTP» на порядки больше, чем разборов production-интеграций с брокером, outbox и семантикой повторов. Средняя температура выборки — учебник и Stack Overflow, а не разбор с реального корпоративного контура. Без предметной базы агент не знает, что нормальный ответ здесь — event-driven контур: заказ не «файл уехал», а событие, которое переживает недоступность ERP, не плодит дубликаты при повторе и оставляет след, по которому потом разбирают инцидент.
Значит, вопрос не «умеет ли ИИ в архитектуру». Вопрос — откуда он берёт планку, когда вы сами эту планку сформулировать не можете. Если предмет ваш — вы и есть эта планка, и длинный диалог спасает. Если нет — нужен внешний носитель экспертизы на время проектирования. Не ещё один абзац в промпте («сделай надёжно и по-взрослому»), а подложка, которую агент обязан читать как справочник техлида.
Приём: book-as-context
Book-as-context — агенту дают авторитетный первоисточник (книгу, спецификацию) как структурированную подложку контекста: wiki с концептами, перекрёстными ссылками и трассировкой к чанкам книги. Она лежит в проекте; агент ходит по ней как по справочнику техлида — без надежды, что одна фраза в system prompt или сырой поиск по PDF сами удержат архитектурную планку.
Это частный случай того, что сейчас называют context engineering: модель работает не «из головы», а из собранного для задачи корпуса. Близкие имена в сообществе — другие упаковки той же идеи. LLM Wiki у Карпатого — скомпилировать источники в связанные markdown-страницы, а не каждый раз вытаскивать сырые чанки из RAG. Book-to-skill (и вариации «turn a book into a Claude skill») — сжать книгу в skill для Claude Code / Copilot: SKILL.md, главы, чеклисты, чтобы агент подтягивал справочник по команде. Разница в форме поставки: skill живёт в каталоге навыков ассистента; book-as-context кладёт wiki в репозиторий проекта, чтобы планы, ТЗ и код опирались на одну и ту же подложку. Суть одна — книга становится рабочим контекстом, а не разовым саммари в чате.
Под распределённые системы, хайлоад и событийку я брал Таненбаума, «Распределённые системы: принципы и парадигмы». Для этой зоны это уровень «как Котлер у маркетологов»: жёсткий сопромат, не пересказ блога.
Пайплайн нарезки — obsidian-llm-wiki (olw, форк в духе LLM Wiki): fast-модель на ingest (концепты из чанка), heavy — на compile (concept-статьи). На прогоне по Таненбауму: 30 source-чанков → 116 concept-страниц. Полный прогон — порядка $1.5 через OpenRouter. «Запустил один раз и готово» не работает: три прогона дали 16 + 14 + 23 заметки — параметры чанков и моделей приходится крутить.
Wiki кладётся в репозиторий (или симлинк). Агент не грузит книгу целиком в окно: ходит по индексу и вытаскивает нужные узлы — встроенной индексацией Cursor или через hybrid-search MCP. Дальше планы, API-контракты, инфраструктура и вайб-кодинг опираются на понятия и приёмы из книги. Уровень держится «с одного промпта»: не нужно каждый раз дописывать «сделай событийность, асинхронность, контракты и ещё сто требований».
Один промпт — два разных мира
Один класс задачи. Два результата.
Без подложки:
«Сделай передачу заказов из интернет-магазина в ERP»
→ CSV, cron, FTP, «готово».
С wiki Таненбаума — реальная постановка: 1С-Битрикс → ERP «Галактика» → CRM Creatio. Агент не бросается сразу писать код и не отделывается списком умных слов. Сначала проходит по графу концептов книги — от бизнес-риска к термину автора, от термина к паттерну:
«ERP может быть недоступна часами, заказы не должны теряться»
→ message-oriented middleware:
persistent communication — очередь хранит сообщение до доставки
vs transient — получатель должен принять прямо сейчас
→ message queue systems — гарантии, журнал, балансировка
→ AMQP: unsettled → settled → forgotten
→ two-phase commit — если две БД должны обновиться атомарноЭти формулировки не зависают красивыми словами в переписке. Агент прорабатывают их дальше по всем слоям. В постановке — разделы ТЗ, SLO, приоритет транспорта, правила partial success, таблица «принцип из wiki → номер раздела». В реализации — те же решения становятся конкретными механизмами: transactional outbox рядом с заказом, персистентный брокер, адаптеры ERP/CRM, idempotency key на повторах, DLQ, журнал сквозного состояния. Без wiki агент называет «очередь» и рисует FTP; с wiki очередь из книги обязана дожить до схемы и до кода.
| Вопрос | Без wiki | С wiki |
|---|---|---|
| Синхронность | REST «отправил — готово» | outbox в БД → брокер → адаптеры |
| ERP offline | «перешлём завтра вручную» | очередь копит; магазин работает |
| Потеря / дубликат | «перешлём ещё раз» | idempotency key, at-least-once, DLQ |
| Транспорт к ERP | FTP как основной путь | шина/очередь → REST/SOAP → файл только fallback |
| ERP + CRM | best effort | журнал состояний, partial success, eventual consistency |
Фрагмент ТЗ: outbox, брокер, адаптеры
Источник событий — Битрикс после фиксации заказа. Событие сначала пишется в ту же БД, что и заказ (transactional outbox: «сначала зафиксировали факт, потом обещаем доставить»), превращается в каноническую модель и уходит в персистентный брокер. Адаптеры асинхронно доставляют в ERP и CRM; сквозное состояние — в журнале интеграции. Повторы — через idempotency (повтор не создаёт второй заказ), backoff и DLQ (очередь «битых» сообщений); порядок изменений одного заказа — по causal ordering.
[ИМ 1С-Битрикс] --(Outbox)--> [Интеграционный сервис]
|
канонизация, валидация, обогащение НСИ
|
[Брокер (персистентные очереди)]
/
[Адаптер ERP «Галактика»] [Адаптер CRM Creatio]
/
`--> [Журнал состояний] <--'Приоритет транспорта к ERP: (1) корпоративная шина / менеджер очередей, (2) HTTPS REST или SOAP, (3) файловый обмен — только аварийный или пакетный канал.
И это не только «схема из кубиков». В том же контуре агент вытащил нефункциональные требования по критериям из книги:
| Показатель | В ТЗ |
|---|---|
| RPO (сколько данных можно потерять) для событий в брокере/outbox | 0 — потеря недопустима |
| RTO (за сколько поднять обработку) | ≤ 1 ч штатно, ≤ 4 ч при деградации |
| End-to-end ERP + CRM | P95 ≤ 5 мин, P99 ≤ 15 мин |
| Доступность контура | ≥ 99,9% / месяц |
Частичный успех ERP + CRM решён как eventual consistency без автоматического 2PC: успешная запись в целевой системе не откатывается сама; если ERP принял, а CRM лежит — повторы в CRM с тем же idempotency key; если CRM исчерпала повторы — partial success, DLQ, алерт. Пока ERP недоступна — CRM не вызываем.
Безопасность каналов тоже не «добавим потом»: TLS 1.2+, mTLS между компонентами, webhook от ИМ с HMAC/JWS и защитой от replay, rate limiting, переполнение очередей → DLQ.
В приложении к ТЗ — явная таблица wiki → раздел документа: guaranteed delivery и persistence → SLO и схема; failure models → отказоустойчивость; retry/idempotency → семантика повторов; fallacies of distributed computing («сеть надёжна», «latency = 0») — в запрещённые предпосылки. Постановщик в моменте мог этого не знать. След экспертизы нёс первоисточник.
Почему «не разбираюсь в теме» — не значит «не читаю результат»
Book-as-context не делает из вас Таненбаума. Он делает так, что агент перестаёт предлагать учебниковый минимум, пока вы не научились формулировать требования уровня прода.
Разбирать то, что выдал агент, всё равно нужно — как читают ТЗ от сильного архитектора: спорите с решениями, режете scope, принимаете компромиссы. Разница в стартовой точке. Без wiki вы спорите с FTP. С wiki — с выбором между outbox и 2PC, с RPO и DLQ. Это другой разговор, даже если вчера вы не отличали persistent communication от «положили файл на шару».
Второй навык, без которого подложка проседает: запросы к wiki формулировать языком автора, не языком задачи.
| Плохой запрос | Хороший |
|---|---|
| «найди что-то про Kafka» | reliable multicast + FIFO ordering |
| «как синхронизировать заказы» | persistent vs transient communication |
| «гарантии доставки» | AMQP: unsettled → settled → forgotten |
Wiki + retrieval без этого слоя — слепой RAG: чанки правильные, а попадание мимо. Подробнее про поиск — в howto про hybrid-search.
Как собрать у себя
- Выбрать книгу под фазу. Архитектура интеграций — Таненбаум (или эквивалент вашего домена). Разработка — «Чистый код». Ревью — Фаулер. QA — профильный Савин и т.п. Слабый источник размножит слабость в каждом ответе агента.
- Нарезать в wiki.
olw init→ чанки вraw/→olw run. На выходе sources + concept-страницы с wikilinks и ссылкой на чанк. - Подложить в проект. Каталог wiki в репо или симлинк. Агент должен видеть индекс.
- Искать в терминах автора. От бизнес-требования к паттерну из книги, от паттерна к реализации (Kafka или Rabbit — уже частный выбор инструмента).
- Проверять draft перед цитированием. У olw бывают
confidence: 0.35иsingle-source— сигнал перепроверить, прежде чем нести формулировку на архитектурный комитет.
Анатомия vault'а и параметры прогона — в howto: Book-as-context.
Ограничения метода
- Параметры решают качество wiki. Первые прогоны часто дают обрывки или простыни — крутите чанки, модели и число прогонов, пока страницы перестанут разваливаться.
- Покрытие частичное. На прогоне 30 чанков и 116 концептов; запрос вне этой сетки уводит агента обратно к средней температуре интернета.
- Слабый первоисточник размножает слабость. Блогерский сборник без failure models даст такую же «среднюю» архитектуру, только увереннее.
- Запросы языком задачи промахиваются. Пока агент ищет «про Kafka» вместо порядка доставки и семантики повторов, он снова тянет туториалы.
- Подложка не снимает ответственность. Черновик становится взрослее, но в прод всё равно решаете вы: scope, деньги, риск, политика стейкхолдеров.
Для кого
Для основателей, product- и delivery-лидов, которые уже видят, что «сделай мне систему» не работает, и для инженеров, которые хотят меньше писать руками, а получать решения ближе к промышленным. Методика переносима: wiki — текст, копируется между проектами. Узкое место — выбор первоисточника; фраза «ты же умный, придумай сам» его не заменяет.
Итог
ИИ «не умеет в архитектуру», пока вы кормите его пустым промптом и ждёте чуда из средней температуры интернета. Подложите книгу — и спор сдвинется к outbox, RPO и DLQ.
Часть программистов этот приём сознательно не трогает: боятся за рабочие места. Срабатывает синдром вахтера — ценность будто в том, чтобы никого «не туда» не пустить к архитектуре, а не в том, чтобы система стала лучше. Проще твердить, что «ИИ не умеет в архитектуру», чем признать: book-as-context, LLM Wiki, book-to-skill и соседние механизмы уже поднимают планку постановки и реализации. Кто реально хочет довести систему до промышленного уровня — берёт эти инструменты. Кто охраняет проходку на «сложное» — оставляет агента на CSV и FTP и называет это доказательством.
Репозиторий: github.com/dobryakov/obsidian-llm-wiki-local
Howto: dobryakov.com/howto/book-as-context.html
Retrieval-слой: dobryakov.com/howto/hybrid-search.html
Рядом по теме: онбординг скиллов и периметр безопасности вокруг AI-агента — там же, где system prompt перестаёт быть контролем.