"⚛️ Атомарные Duo файлы Сегодня день своеобразных терминов. Почему некоторые концепции имеют такие своеобразные названия? Потому что их нужно упоминать, а для этого им нужно какое либо название. Общепринятого не пришло в голову, подтому было выбрано настоящее название. К сути. Сейчас обсуждаем концепцию ""атомарных duo файлов"". Это файлы, документирующие те или инце концепции в системе, причём построенные строго по определённым правилам: - каждый duo-файл описывает только одну концепцию, отсюда в названии ""атомарные"" - duo файлы ""работают"" в паре: арх-файл + гайд-файл - первый хранится в папке architecture/ - арх-файл - второй хранится в папке guides/ - гайд-файл - парные файлы содержат аннотированные ссылки друг на друга - арх-файл содержит высокоуровневое декларативное описание ЧТО и ПОЧЕМУ, архитектурную концепцию - гайд файл описывает КАК ИМЕННО, операционные инструкции и детали Такими файлами у меня в мемори банке описаны многие элементы фич, сущности в системе - от окружений для разработки (app stages) до визуального стиля ui-system ❓ Зачем атомарность? Почему только одна концепция? Это попытка добиться максимально гранулярного знания для максимально точного формирования контекста. Единственная концепция в файле похволяет приблизится к этому. Мы можем точечно собрать в контекст агента именно то, что ему нужно знать Единственная концепция - удобный способ обеспечить принцип Single source of truth. Это важно для: - группировки концепций в одном месте (полезно для внимания модели) - упрощает обеспечение непротиворечивости контекста Важная часть качественного контекста - его непротиворечивость. Если по вашим документам сведения ""размазаны"" по нескольким файлам, то с многословностью моделей вы легко получаете немного разные сведения об одном и том же! А после эволюции этого контекста могут появиться противоречия, что очень вредит качеству. ❓ Почему делим на 2 части? Когда мы хотим дать агенту некоторые общие сведения о чем-либо, мы можем ""положить"" ему только арх-файл. Если агенту нужно будет работать с этой концепцией, мы добавляем гайд-файл. Получается удобная управляемая схема. ❓В файле не одна концепция Некоторые файлы неизбежно усложняются! например, система тестирования с описанием разных типов тестов. Процесс носит естественных характер с развитием вашей системы, нужно просто контролировать ситуацию, и когда она уже становится проблемной - делать рефакторинг. ❓А если никак не обойтись одной концепцией? Я делаю составные концепции. Например, та же система тестирования может содержать групповой файл, который описывает систему тестирования в общем виде, и отдельные файлы про юнит тесты, e2e тесты и любые другие виды тестов, которые вы применяете. ❓ Сейчас модели получают большие контексты - зачем эта микро оптимизация? Действительно, выходят модели с контекстами 400к токенов и 1м токенов. Но помимо контекста остаётся ещё механизм внимания модели, который тоже ""не резиновый"". Чем меньше нерелевантных задаче деталей ""отвлекают"" модель, тем выше будет качество работы. Этот аспект становится важнее с ростом системы. #post @deksden_notes"