Контекст по паттернам: один факт, одно место, пять уровнейContext by patterns: one fact, one place, five layers
Сергей Пак · проектирует AI-операционные системы
Систему разваливают копии одного и того же знания, разбросанные по разным местам. Две формулировки одного термина, три версии одной схемы, статус проекта в четырёх документах. Каждая копия живёт своей жизнью, и через месяц система спорит сама с собой. Я собираю AI-операционные системы и держу их в целости одним правилом: у каждого факта одно каноническое место, у каждого уровня логики своя форма записи. Это и есть контекст по паттернам.
Один факт, одно место
Определение термина AIOS у меня лежит в одном файле конфигурации. Сайт, разметка schema.org, посты блога, страницы для финансиста и бухгалтера читают формулировку оттуда. Никто не пересказывает её своими словами: пересказ – это уже вторая версия, а две версии термина крошат его смысл и для читателя, и для поисковых машин.
Тот же паттерн ниже по стеку. Схема базы данных существует только в файлах миграций, их сейчас 52. Написать CREATE TABLE прямо в коде нельзя: автоматический страж блокирует такой коммит. Цвета и типографика сайта заданы в одном файле токенов; когда сегодня понадобился тёмный футер поверх «бумажных» страниц, я не красил футер, а объявил остров токенов из десяти строк, и все элементы внутри перекрасились сами.
Правило скучное, зато изменение вносится один раз и согласованно доезжает до каждой поверхности.
Карта, не содержание
Второй паттерн: верхний уровень системы хранит указатели, не тексты. Корневой файл моей рабочей системы, который читается в начале каждой сессии, занимает 87 строк. При этом справочной документации 93 файла. В карте только маршруты: правишь коннектор – открой такой-то док. Содержание подгружается, когда нужно, и токены не горят на балласт.
Так же устроена память о проектах. Статус каждого проекта – одна строка в индексе, тело – в отдельном файле. Снапшот проекта для штаба ограничен 35 строками: статус, роль, риски. Полная операционка, контакты и переписка живут в модуле проекта, и штаб запрашивает их по требованию, а не хранит копию.
Уровни дают согласованность через границы: каждый слой знает, где спросить, и не тащит чужое знание к себе.
Пять уровней одной системы
AIOS я собираю в фиксированном порядке слоёв: контекст, данные, интеллект, автоматизация, сборка. Порядок задан зависимостями: интеллект без слоя данных галлюцинирует, автоматизация без контекста автоматизирует хаос.
На моей системе это выглядит так. Слой данных – 64 коннектора, и приложения ходят к базам только через них, напрямую нельзя. Слой интеллекта – один шлюз для всех LLM-вызовов: он выбирает модель по сложности задачи, кэширует и пишет стоимость в журнал. Из-за этой единственной точки входа 81% запросов закрывает локальная модель на обычном Mac, а недельный счёт за облачные вызовы держится около полутора долларов. Слой автоматизации – решения: всё, что построено и ждёт моего «да», собирается скриптом в один входящий список, и утром в 08:45 приходит в Telegram. Сейчас в этом списке 23 позиции, и я закрываю их в одно касание, вместо того чтобы вспоминать по четырём чатам, что где зависло.
Паттерн повторяется на каждом уровне зума
Самое полезное свойство: те же паттерны работают на любом масштабе. Репозиторий целиком устроен как «карта плюс содержание», отдельный проект внутри него – тоже, отдельный документ – тоже. Форма заявки на моём сайте одна, а обликов у неё два: строгий для классического вида и рукописный для доски. Логика отправки общая, различаются только слои оформления. Когда сегодня чинил семь дефектов сайта за одну сессию, каждый фикс вносился в одно место и не ломал соседние: границы уровней делают правки локальными.
Клиентская установка держится на том же. Личная AIOS встаёт на ноутбук за один день, потому что контекст клиента собирается по готовому шаблону: кто человек, какие процессы, где данные, кто решает. Руководитель направления из дорожно-строительной отрасли на второй неделе уже готовил в системе финансовую модель нового завода. День на установку получается из заранее разложенных уровней: знание о бизнесе ложится в готовую структуру, и её не приходится изобретать на ходу.
Контекст, собранный по паттернам, делает систему предсказуемой: она действует как одно целое, потому что нигде не хранит противоречий. А финальное слово остаётся там же, где всегда: человек ведёт, система работает.
What breaks a system is copies of the same knowledge scattered across different places. Two wordings of one term, three versions of one schema, a project status kept in four documents. Each copy drifts on its own, and a month later the system argues with itself. I build AI operating systems and keep them whole with one rule: every fact has one canonical home, and every level of logic has its own form of record. That's context by patterns.
One fact, one place
The definition of the term AIOS lives in a single config file on my side. The site, the schema.org markup, the blog posts, the pages for the finance lead and the accountant all read the wording from there. Nobody paraphrases it: a paraphrase is already a second version, and two versions of a term crumble its meaning for the reader and for search engines alike.
The same pattern runs lower in the stack. The database schema exists only as migration files, 52 of them right now. You can't write CREATE TABLE straight in the code: an automatic guard blocks that commit. The site's colors and typography sit in one token file; when I needed a dark footer over the «paper» pages today, I didn't repaint the footer. I declared a ten-line token island, and everything inside recolored itself.
The rule is boring, but a change gets made once and lands on every surface, consistently.
A map, not the content
The second pattern: the top level of the system stores pointers, not texts. The root file of my working system, read at the start of every session, is 87 lines. The reference docs count 93 files. The map holds routes only: editing a connector, open this doc. Content loads when needed, and tokens don't burn on ballast.
Project memory works the same way. Each project's status is one line in an index, the body sits in its own file. A project snapshot for the headquarters is capped at 35 lines: status, role, risks. The full operations, contacts and correspondence live in the project's own module, and the headquarters queries them on demand instead of keeping a copy.
Layers create consistency through boundaries: each one knows where to ask and doesn't drag someone else's knowledge home.
Five layers of one system
I assemble an AIOS in a fixed order of layers: context, data, intelligence, automation, assembly. The order encodes dependencies: intelligence without a data layer hallucinates, automation without context automates chaos.
On my own system it looks like this. The data layer is 64 connectors, and applications reach the databases only through them. The intelligence layer is a single gateway for all LLM calls: it picks the model by task complexity, caches, and logs the cost. Because of that single entry point, a local model on an ordinary Mac handles 81% of requests, and the weekly bill for cloud calls stays around a dollar and a half. The automation layer is decisions: everything built and waiting for my «yes» gets collected by a script into one inbox and lands in Telegram at 8:45 every morning. The list holds 23 items today, and I close them with one tap instead of digging through four chats to recall what's stuck where.
The pattern repeats at every zoom level
The most useful property: the same patterns work at any scale. The repository as a whole is «a map plus content», a single project inside it is too, so is a single document. The request form on my site is one component with two skins: a strict one for the classic view and a handwritten one for the pinboard. The submit logic is shared; only the presentation layers differ. When I fixed seven site defects in one session today, each fix went into one place and didn't break the neighbors: layer boundaries keep changes local.
Client installs rest on the same thing. A personal AIOS lands on a laptop in one day because the client's context is assembled from a ready template: who the person is, which processes, where the data lives, who decides. A division head from the road-construction industry was building the financial model for a new plant inside the system by week two. The one-day install comes from layers laid out in advance: knowledge about the business drops into a ready structure, and nobody invents the structure on the fly.
Context assembled by patterns makes the system predictable: it acts as one whole because it stores no contradictions. And the final word stays where it always was: the person leads, the system works.
Частые вопросы
- Что значит «контекст по паттернам»?
- Каждый тип знания в системе имеет своё каноническое место и форму: определения – в одном файле, схема данных – в миграциях, статусы проектов – в снапшотах фиксированного размера. Любая часть системы читает факт из канона, а не хранит свою копию. Меняешь в одном месте – согласованно меняется везде.
- Зачем раскладывать логику системы на уровни?
- Уровень – это граница ответственности: карта отдельно от содержания, доступ к данным отдельно от приложений, определение отдельно от подачи. Верхний уровень держит только указатели и остаётся коротким, детали подгружаются по требованию. Так система масштабируется без расползания.
- Что это даёт на практике?
- Дешёвые изменения и предсказуемое поведение. Пример: LLM-вызовы идут через один шлюз, поэтому 81% запросов закрывает локальная модель, а счёт – около $1,5 в неделю. Установка системы клиенту занимает один день, потому что контекст собирается по готовому шаблону, а не с нуля.
FAQ
- What does «context by patterns» mean?
- Every kind of knowledge in the system has a canonical home and a fixed shape: definitions in one file, the data schema in migrations, project statuses in snapshots of a set size. Every part of the system reads the fact from the canon instead of keeping its own copy. Change it once and it changes everywhere, consistently.
- Why split the system's logic into layers?
- A layer is a boundary of responsibility: the map apart from the content, data access apart from the apps, the definition apart from the presentation. The top layer holds pointers only and stays short; details load on demand. That's how the system grows without sprawling.
- What does this give you in practice?
- Cheap changes and predictable behavior. One example: all LLM calls go through a single gateway, so a local model handles 81% of requests and the bill stays around $1.5 a week. A client install takes one day because the context is assembled from a ready template rather than from scratch.