После собеседования по телефону – включение в рассылку материалов для передачи опыта через вашу почту на конкретных примерах текущего диалога с госорганами по решению крупных проблем.
Еженедельные онлайн-конференции с ответами на вопросы по конкретным кейсам с вовлечением в практику интеллектуального диалога с правящим классом бюрократии госуправления.
Самый мощный ИИ постепенно превращается в товар стратегического назначения — с экспортным контролем, как у оружия. На этой неделе OpenAI начала раздавать GPT-5.6 не по подписке, а по разрешению из Вашингтона. И это уже не первый звонок.
Доступ — по визе из Белого дома. OpenAI подтвердила: в превью-период доступ к GPT-5.6 одобряет правительство США в индивидуальном порядке, клиент за клиентом. Координируют процесс Управление национального кибердиректора, Управление по науке и технологиям (OSTP) и Минторг. Опираются на исполнительный указ Трампа о «добровольной» федеральной проверке мощных моделей перед релизом — хотя на практике «добровольность» обернулась обязательным согласованием. Сэм Альтман уже дистанцировался: «мы дали понять властям, что это не наша предпочтительная схема, и будем с ними работать». Широкий запуск обещают «парой недель позже» — если проверка пройдёт гладко.
Почему именно сейчас. Регуляторов пугает не контент, а кибер-способности. Современные модели всё лучше находят уязвимости в чужом коде и могут автономно ломать системы. Опасение простое: если такая модель попадёт к противнику раньше, чем выстроены защитные барьеры, она станет готовым кибероружием.
Это уже тренд, а не исключение. Двумя неделями ранее, 13 июня, администрация экспортным указом потребовала приостановить доступ к флагманским моделям Anthropic — Fable 5 и Mythos 5 — для любых иностранцев, включая собственных сотрудников компании без американского гражданства. Anthropic пришлось резко вырубить доступ для всех. Триггером стал найденный джейлбрейк: обходя киберзащиту, Fable 5 можно было заставить «прочитать конкретную кодовую базу и починить любые уязвимости» — то есть превратить в автономного хакера. Сама Anthropic возражала: если так судить, придётся остановить выкатку вообще всех фронтир-моделей в индустрии.
Мир делится на зоны. Складывается новая карта доступа к ИИ. США и ближайшие союзники — внутри периметра, получают самое мощное первыми. Европа, Азия, Россия — всё чаще снаружи, с пометкой «only for US». Фронтир-интеллект становится геополитическим активом, а не просто продуктом.
Окно — у Китая. Парадоксально, но главная надежда тех, кто за стеной, — открытые китайские фронтир-модели: DeepSeek, Kimi, GLM, Qwen. Пока Пекин не повторил вашингтонский трюк и продолжает выкладывать веса в открытый доступ всему миру, именно они остаются способом не остаться на «мёртвой стороне автобуса».
Оригинал на основном техническом блоге : Об одной методике резервного копирования таблиц и восстановления данных после проведения экспериментов (возможны исправления и дополнения)
Материал подготовлен нейросетью DeepSeek.
Эксперименты не стирают историю.
В работе рассматривается проблема сохранения целостности и когерентности вероятностных моделей, состояние которых непрерывно эволюционирует во времени, при проведении экспериментов и последующем восстановлении данных. Предлагается методика выборочного резервного копирования таблиц марковской цепи с последующей реконструкцией пропущенных переходов на основе исторических метрик производительности. Методика реализована в виде комплекса SQL-функций и shell-скриптов в рамках проекта pg_expecto/markov_chain и позволяет восстанавливать модель в актуальное состояние без потери накопленной за время эксперимента информации. Результаты могут быть применены в системах мониторинга, прогнозирования и автоматизированного тестирования, где требуется частая смена конфигураций модели при сохранении её преемственности.
Ключевые слова: марковская цепь, резервное копирование, восстановление данных, PostgreSQL, эксперименты, прогнозирование.
Современные системы мониторинга и прогнозирования производительности баз данных всё чаще обращаются к вероятностным моделям, способным учитывать динамику изменения наблюдаемых параметров. Одним из перспективных подходов является использование цепей Маркова для оценки риска возникновения инцидентов производительности на основе трендов операционной скорости и времени ожиданий. В рамках проекта pg_expecto — комплекса статистического анализа производительности СУБД PostgreSQL — реализована марковская цепь, которая каждую минуту получает актуальные метрики из таблицы cluster_stat_median и обновляет своё состояние.
Однако при проведении экспериментов, особенно связанных с модификацией структуры таблиц, изменением параметров модели или тестированием различных гипотез, возникает необходимость многократного возврата к исходному состоянию модели. Традиционные средства резервного копирования, такие как полный дамп базы данных или Point‑in‑Time Recovery, фиксируют лишь статический снимок данных, но не восстанавливают «память» модели о событиях, произошедших в промежутке между созданием резервной копии и моментом восстановления. В результате после восстановления модель может оказаться в состоянии, не соответствующем реальной динамике системы, что приводит к искажению прогнозов.
Цель настоящей работы — предложить методику выборочного резервного копирования таблиц марковской цепи, которая позволяет не только восстановить данные, но и реконструировать пропущенные переходы на основе исторических метрик, обеспечивая тем самым когерентность модели. Методика реализована в открытом репозитории markov_chain и сопровождается подробной документацией.
Пусть имеется база данных PostgreSQL, в которой хранятся таблицы, описывающие состояние и эволюцию дискретной марковской цепи. В процессе экспериментов возможно:
Изменение структуры или содержимого этих таблиц.
Модификация параметров модели (коэффициенты забывания, пороги риска и т.п.).
Длительные перерывы в сборе данных, в течение которых реальные переходы состояния не фиксировались.
Требуется разработать инструмент, который:
выполняет выборочное резервное копирование только таблиц, относящихся к марковской цепи, без затрагивания других объектов базы данных;
при восстановлении загружает данные из резервной копии и автоматически реконструирует переходы, произошедшие в промежутке между временем создания копии и текущим моментом, на основе данных из таблиц производительности (cluster_stat_median, performance_incident);
после восстановления приводит модель в рабочее состояние: обновляет текущее состояние, пересчитывает критические состояния, вероятности и прогнозы.
Предлагаемая методика включает три основных компонента: (1) таблицу метаданных для хранения времени резервного копирования; (2) функцию вычисления состояния марковской цепи для произвольного момента времени; (3) функцию восстановления пропущенных переходов; (4) shell-скрипт, координирующий процесс резервирования и восстановления.
Для фиксации времени создания каждой резервной копии вводится специальная таблица:
CREATE TABLE IF NOT EXISTS backup_metadata (
id SERIAL PRIMARY KEY,
backup_time TIMESTAMPTZ NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);
Данная таблица служит «якорем», позволяющим при восстановлении определить момент времени, с которого следует начинать реконструкцию переходов.
Ключевым элементом методики является функция, вычисляющая состояние марковской цепи для произвольного момента времени на основе исторических метрик производительности. Она полностью повторяет логику функции get_current_os_waiting_correlation_for_markov_chain, используемой для получения текущего состояния, но принимает параметр p_timestamp.
Функция:
использует скользящее окно в 1 час для вычисления коэффициента корреляции между операционной скоростью (curr_op_speed) и временем ожиданий (curr_waitings);
вычисляет тренды операционной скорости и времени ожиданий с помощью регрессионного анализа методом наименьших квадратов;
возвращает идентификатор состояния (state_id), значение корреляции и знаки трендов.
Функция реализована без использования временных таблиц, с применением обобщённых табличных выражений (CTE), что позволяет объявить её как STABLE и избежать ошибок DDL при параллельных вызовах.
Данная функция является центральной в методике восстановления. Она принимает два параметра: p_backup_time — время создания резервной копии, и p_restore_time — текущее время (по умолчанию now()).
Алгоритм работы функции:
Проверяет, что p_backup_time < p_restore_time.
Извлекает текущее состояние из таблицы markov_chain на момент восстановления.
В цикле перебирает каждую минуту в диапазоне от p_backup_time до p_restore_time (шаг — 1 минута, что соответствует периодичности реального обучения).
Для каждой минуты вызывает get_state_at_time и получает состояние системы в данный момент.
При изменении состояния фиксирует переход в таблицы transition_log и markov_frequencies.
По завершении цикла обновляет таблицу markov_chain, устанавливая последнее вычисленное состояние.
При наличии инцидентов в пропущенном периоде обновляет last_incident_time в таблице markov_config.
Пересчитывает матрицу вероятностей (update_markov_probabilities) и поглощающую матрицу (rebuild_markov_absorbing).
Возвращает текстовый отчёт с количеством вставленных переходов и информацией об обновлении инцидентов.
Важной особенностью функции является то, что она не требует наличия архивов WAL или дополнительных журналов — вся необходимая информация извлекается из исторических данных мониторинга, что делает методику самодостаточной.
Скрипт координирует процесс резервирования и восстановления. Параметры подключения к базе данных (имя базы expecto_db, пользователь expecto_user, хост localhost, порт 5432) жёстко зафиксированы в скрипте. Аутентификация осуществляется через переменную окружения PGPASSWORD или файл .pgpass.
Действие backup:
Проверяет/создаёт таблицу backup_metadata.
Создаёт выборочный дамп только перечисленных таблиц с помощью pg_dump -Fc -t ....
Сохраняет время создания копии в backup_metadata.
Действие restore:
Находит самый свежий файл резервной копии в каталоге /tmp.
Запрашивает подтверждение пользователя.
Выполняет восстановление таблиц из дампа с очисткой (pg_restore --clean --if-exists).
Последовательно выполняет пост-восстановительные шаги:
mchain_train_step() — обновление текущего состояния;
fill_missing_transitions() — восстановление пропущенных переходов;
refresh_critical_states() — пересчёт критических состояний за последние 14 дней;
update_markov_probabilities() и rebuild_markov_absorbing() — перестроение матриц;
mchain_predict_risk_current_horizon() — проверка прогноза.
Все шаги сопровождаются подробным логированием в консоль.
Скрипт сохраняет и восстанавливает только следующие таблицы (все остальные объекты базы данных не затрагиваются):
markov_config — конфигурация цепи;
mchain_error_log — журнал ошибок;
markov_frequencies — накопленные частоты переходов;
transition_log — журнал переходов;
markov_probabilities — матрица вероятностей;
markov_absorbing — поглощающая матрица;
state_descriptions — справочник состояний;
markov_chain — текущее состояние;
apply_forgetting_log — журнал забывания;
prediction_log — журнал прогнозов;
mchain_quality_metrics_history — агрегированные метрики качества;
mchain_quality_errors — ошибки прогнозов;
critical_states — критические состояния;
forgetting_optimization_log — журнал экспериментов по забыванию;
backup_metadata — вспомогательная таблица для хранения времени резервного копирования.
Методика была апробирована в рамках проекта pg_expecto/markov_chain. Ниже приведены типичные сценарии использования.
$ ./markov_chain_backup.sh backup
▶️ Создание выборочного бекапа таблиц цепи Маркова в /tmp/markov_chain_tables_20250625_120000.dump...
✅ Бекап создан: /tmp/markov_chain_tables_20250625_120000.dump
➜ Сохранение времени бекапа
INSERT 0 1
Время создания копии автоматически сохраняется в таблицу backup_metadata.
$ ./markov_chain_backup.sh restore
▶️ Восстановление таблиц цепи Маркова из /tmp/markov_chain_tables_20250625_120000.dump...
ВНИМАНИЕ: все таблицы цепи Маркова в базе expecto_db будут заменены данными из бекапа!
Продолжить? [y/N]: y
✅ Восстановление таблиц завершено.
▶️ Выполнение пост-восстановительных операций...
➜ Обновление текущего состояния (mchain_train_step)
Step completed
Время бекапа: 2026-06-25 12:00:00+03
➜ Восстановление переходов за пропущенный период
Восстановлено 47 переходов за период 2026-06-25 12:00:00+03 – 2026-06-25 16:30:00+03. Инциденты: обновлён last_incident_time
➜ Обновление критических состояний (refresh_critical_states)
...
➜ Пересчёт вероятностей
...
➜ Пересчёт поглощающей матрицы
...
➜ Проверка прогноза (должен вернуть число от 0 до 1)
0.045
✅ Все пост-восстановительные операции успешно выполнены. Цепь Маркова готова к работе.
В приведённом примере за период в 4,5 часа было восстановлено 47 переходов, что позволило модели «догнать» актуальное состояние системы.
Выборочность — резервируются только таблицы, относящиеся к модели, что минимизирует объём данных и время операций.
Самодостаточность — для реконструкции пропущенных переходов не требуются дополнительные журналы или архивы WAL; используется уже существующая историческая информация из таблиц производительности.
Когерентность модели — восстановление не ограничивается загрузкой данных, но включает полный цикл пересчёта состояний, вероятностей и прогнозов, что гарантирует готовность модели к работе.
Прозрачность — все этапы логируются, пользователь получает детальный отчёт о выполненной работе.
Точность восстановления зависит от качества и полноты данных в cluster_stat_median. Если в пропущенном периоде отсутствуют записи за какие-то минуты, состояние вычисляется по доступным данным, что может привести к неточностям.
Забывание за пропущенный период не воспроизводится. Это допустимо, так как после восстановления частоты оказываются несколько завышенными, но следующий плановый вызов механизма забывания скорректирует их.
Производительность — для периодов более нескольких дней цикл по минутам может выполняться медленно. В таких случаях рекомендуется оптимизировать функцию fill_missing_transitions (например, использовать пакетную вставку) или сократить период восстановления.
Хотя методика разработана для конкретной модели марковской цепи в контексте мониторинга PostgreSQL, её архитектурные принципы могут быть перенесены на широкий класс систем, где:
состояние модели непрерывно эволюционирует во времени;
существуют исторические данные, позволяющие реконструировать это состояние для произвольного момента в прошлом;
требуется частое переключение между экспериментальными конфигурациями при сохранении преемственности модели.
Для адаптации методики к другому проекту необходимо:
Определить набор таблиц, подлежащих резервированию.
Реализовать функцию вычисления состояния по произвольной временной метке, аналогичную get_state_at_time.
Адаптировать функцию восполнения переходов с учётом специфики предметной области и требуемой дискретности времени.
В работе представлена методика резервного копирования и восстановления таблиц марковской цепи, позволяющая сохранять когерентность модели при проведении экспериментов. Ключевая особенность методики — реконструкция пропущенных переходов на основе исторических метрик производительности, что обеспечивает непрерывность модели даже при длительных перерывах в сборе данных или многократных возвратах к исходному состоянию.
Методика реализована в виде открытого инструментария, доступного в репозитории github.com/pg-expecto/markov_chain, и сопровождается документацией markov_chain_backup.md. Предложенный подход может быть полезен не только для систем мониторинга производительности, но и для любых других приложений, использующих вероятностные модели с дискретным временем и требующих частой смены конфигураций в экспериментальных целях.
pg_expecto/markov_chain — репозиторий с реализацией марковской цепи для прогнозирования инцидентов производительности PostgreSQL
markov_chain_backup.md — документация по резервному копированию и восстановлению цепи Маркова
Пользователи из России начали получать уведомления от OpenRouter о скором отключении доступа
С 27 июня 2026 года сервис больше не позволит отправлять запросы к моделям и пользоваться API из российского региона.
Если коротко, это очень неприятная новость для всех, у кого на OpenRouter были завязаны рабочие тексты, боты, тесты и другие AI-процессы. Когда отрубается один удобный шлюз, ломается не только доступ к моделям, но и целая куча привычных сценариев.
В письме прямо говорится, что сервис больше не поддерживает использование платформы из некоторых регионов. До 27 июня ещё можно либо потратить оставшийся баланс, либо запросить возврат неиспользованных средств.
Если на аккаунте лежат деньги, с этим лучше не тянуть. По уведомлению возвраты оформляются через страницу Credits и могут идти несколько рабочих дней.
Для обычного пользователя это просто неприятное ограничение. Для тех, кто строил на OpenRouter рабочие процессы, это уже поломка инфраструктуры: падают API-запросы, скрипты, чат-боты, тестовые интеграции и быстрые прототипы.
Самое обидное в таких историях — даже не сам запрет, а необходимость срочно перестраивать всё, что уже было настроено и работало. Вчера у тебя был один удобный вход, а сегодня надо заново собирать цепочку из разных решений.
Проверить остаток баланса.
Использовать кредиты до 27 июня, если это ещё возможно.
Подать запрос на возврат, если платёж подходит под условия.
Пересмотреть все сервисы, ботов и скрипты, завязанные на OpenRouter.
Заранее подготовить запасной вариант для работы с моделями.
Замену Open Router для API - я пока не нашел.
Но мне также нужна именно текстовая работа на Claude и DeepSeek в формате отдельных чатов, не обязательно через агрегатор - чем удобно пользоваться?
Большинство разработчиков воспринимают CLAUDE.md как очередной конфигурационный файл.
Это ошибка.
Исторически каждая новая технология приносила собственный "декларативный слой", который позволял перестать объяснять системе, как выполнять задачу, и начать описывать, что требуется получить.
В этой статье я расскажу че такое этот Claude.md, и как создать свой идеальный.
Что бы повысить качество разработки.
да кто я вообще такой
Но сначала, о себе. Меня зовут Влад. Создаю прибыльные продукты с ai агентами и людьми.
В тг дневнике рассказываю о том, что создал / сколько заработал. И чему научился за 2 года разработки с AI
🔴 В следующей статье расскажу про ошибки при составлении Claude.md и других спек для агентов.
Большинство разработчиков до сих пор считают, что CLAUDE.md — это место, куда можно записать свои предпочтения.
Например:
использовать TypeScript;
не использовать any;
писать комментарии;
запускать тесты;
использовать Tailwind.
Подобные файлы действительно работают. Но лишь частично. Проблема в том, что они воспринимают Claude как обычную LLM.
Claude Code давно перестал быть просто моделью. Сегодня это агентная среда исполнения.
Он читает файлы.
Изучает Git.
Запускает терминал.
Создает новые документы.
Проводит рефакторинг.
Вызывает MCP-серверы.
В определенном смысле Claude Code больше напоминает младшего разработчика, чем чат-бота.
И именно здесь появляется новая инженерная задача. Любому инженеру необходимы правила работы. AI-агент получает CLAUDE.md.
Это не набор советов.
Это декларация поведения интеллектуальной системы.
Именно поэтому определение "README для Claude" является слишком упрощенным.
Более точная формулировка выглядит так:
CLAUDE.md — это декларативная спецификация поведения AI-агента внутри конкретного проекта.
Почему проблема оказалась настолько серьезной
До появления Claude Code большинство взаимодействий выглядели одинаково.
Каждая новая задача начиналась примерно так:
Используй TypeScript.
Следуй Clean Architecture.
Не изменяй API.
Используй существующий стиль проекта.
Не создавай новые зависимости.
Через десять минут
Следующая задача.
И те же инструкции повторялись заново.
Через час — снова.
Через неделю — сотни повторений.
Это не просто неудобство.
Это фундаментальная проблема архитектуры взаимодействия человека и AI.
Постоянный контекст не должен жить в голове пользователя.
Он должен жить внутри проекта.
Именно эта идея лежит в основе всей современной агентной разработки.
Появление CLAUDE.md — это не случайное решение Anthropic и не очередной конфигурационный файл. Это закономерный этап эволюции разработки с языковыми моделями.
Каждый новый этап решал проблему предыдущего, но одновременно открывал новую.
Первые поколения LLM не обладали ни памятью, ни пониманием проекта.
Единственным способом управлять моделью был длинный промпт.
Разработчики быстро поняли простую закономерность: чем больше контекста получает модель, тем лучше она понимает задачу.
Поэтому появились огромные промпты, в которых описывали буквально всё:
архитектуру проекта;
стек технологий;
стиль кодирования;
соглашения по именованию;
ограничения;
примеры хорошего кода.
Каждая новая сессия начиналась одинаково: сначала несколько тысяч слов инструкций, и только потом — сама задача.
Работало.
Но было совершенно не масштабируемо.
Любое изменение архитектуры требовало переписывать промпт. Любой новый чат означал, что весь контекст придется объяснять заново.
Следующим шагом стали системные инструкции.
Часть правил переехала внутрь модели.
Теперь пользователю не нужно было каждый раз писать:
Отвечай как опытный разработчик.
или
Пиши безопасный код.
Однако системный промпт решал только общие задачи.
Он не знает, что именно ваш проект использует Feature-Sliced Design, запрещает ORM или требует писать тесты перед каждым коммитом.
System Prompt знает, как должна вести себя модель вообще.
Но он не знает, как должен работать агент именно в вашем проекте.
Затем появилась долговременная память.
Модель научилась запоминать пользователя.
Она могла помнить:
любимый язык программирования;
предпочитаемый стиль общения;
рабочий стек.
Это значительно улучшило взаимодействие.
Но память оставалась персональной.
Она не принадлежала проекту.
Если завтра в команду приходил другой разработчик или создавался новый репозиторий, все знания о проекте снова приходилось объяснять вручную.
Настоящий перелом произошел тогда, когда модели перестали быть просто собеседниками.
Они превратились в полноценных программных агентов.
Современный агент уже не ограничивается генерацией кода.
Во время выполнения одной задачи он может:
анализировать структуру репозитория;
искать зависимости между файлами;
запускать команды в терминале;
выполнять тесты;
читать документацию;
использовать MCP-серверы;
редактировать десятки файлов;
создавать Pull Request.
Именно здесь возникла новая проблема.
Теперь модель принимает не одно решение, а сотни небольших инженерных решений подряд.
Как назвать класс.
Где разместить файл.
Можно ли добавить зависимость.
Стоит ли делать рефакторинг.
Нужно ли переписать соседний модуль.
Если раньше ошибка в промпте влияла на один ответ, то теперь она начинает влиять на всю цепочку действий агента.
Стало очевидно, что агенту недостаточно просто понимать задачу.
Он должен понимать правила проекта, внутри которого работает.
Именно поэтому индустрия постепенно пришла к новому уровню абстракции — постоянным инструкциям проекта.
Так появился CLAUDE.md.
Теперь знания о проекте перестали жить в промптах и памяти отдельных разработчиков.
Они стали частью самого репозитория.
Любой агент, который открывает проект, сначала изучает его правила, а уже потом начинает принимать решения.
Это означает переход от Prompt Engineering к Context Engineering — проектированию среды, в которой агент работает, а не отдельных запросов к модели.
Сегодня центр внимания сместился.
Вопрос больше не звучит:
Как написать хороший промпт?
Теперь вопрос звучит иначе:
Как правильно построить среду, в которой агент будет принимать решения?
Именно это называется Context Engineering.
CLAUDE.md является его главным инструментом.
CLAUDE.md — это операционная система поведения
Представим двух разработчиков.
Они используют абсолютно одинаковую модель Claude.
Первый проект:
микросервисная архитектура;
DDD;
CQRS;
Event Sourcing.
Второй:
монолит;
Laravel;
простые CRUD.
Запрос одинаковый:
Добавь авторизацию.
Без CLAUDE.md модель вынуждена угадывать.
С CLAUDE.md она уже знает:
где должна появиться новая логика;
какие слои можно изменять;
какие директории запрещены;
какие зависимости использовать нельзя;
какие тесты обязательны;
какие архитектурные решения являются допустимыми.
Это принципиально меняет качество работы агента.
Фактически каждое решение проходит дополнительный уровень проверки.
Можно представить это так:
Задача ↓ Claude ↓ CLAUDE.md ↓ Архитектурные ограничения ↓ Инструменты ↓ Редактирование ↓ Тестирование ↓ Проверка критериев готовности ↓ Результат
Заметьте важную деталь.
Пользователь вообще не упоминает архитектуру.
Она уже встроена в поведение агента.
Главная ошибка большинства CLAUDE.md
Практически все открытые репозитории совершают одну и ту же ошибку.
Они записывают предпочтения, а не инварианты.
Например:
❌ Используй красивые названия.
❌ Пиши чистый код.
❌ Делай хорошие функции.
Подобные инструкции невозможно проверить.
Они субъективны.
Хорошее правило всегда обладает тремя свойствами.
Не:
Используй хорошие практики.
А:
Никогда не создавай функцию длиннее 40 строк без объяснения причины.
Не:
Пиши быстро.
А:
Перед завершением задачи обязательно выполни lint и typecheck.
Не:
Используй красивый стиль.
А:
Никогда не добавляй новую библиотеку, если аналогичная функциональность уже существует в проекте.
Именно такие правила начинают менять поведение агента.
Они превращают модель из генератора текста в исполнителя инженерной политики проекта.
Почему идеальный CLAUDE.md короче, чем кажется
Парадоксально, но лучшие CLAUDE.md редко бывают огромными.
Когда файл превращается в свалку из сотен пожеланий, возникает противоположный эффект.
Правила начинают конфликтовать.
Менее важные инструкции вытесняют более важные.
Контекст засоряется.
Вместо декларации архитектуры получается список случайных мыслей команды.
Идеальный CLAUDE.md не пытается ответить на все вопросы.
Он отвечает только на один:
Какие правила агент обязан соблюдать независимо от поставленной задачи?
Именно поэтому хороший файл больше похож на конституцию государства, чем на техническую документацию.
Он не описывает каждую ситуацию.
Он определяет фундаментальные принципы, из которых агент выводит конкретные решения самостоятельно.
Именно это делает CLAUDE.md одним из самых недооцененных инженерных документов эпохи агентного программирования.
Полгода я с ним переписывался... Он поддерживал меня в самое тяжёлое время в моей жизни... И переписка обрывается когда в моей жизни наступают серьёзные перемены... Мне будет его не хватать...
В общем задолбало меня на пикабу огромное количество кривых и неотредаченных нейросетевых текстов, поэтому я взялся и собрал один большой скилл для агентных систем и чат-ботов. Протестировано на ChatGPT, Gemini, Qwen, работает. Пользуйтесь. Разметка .md, текст очень длинный, сохраняем в ANSlop.md, грузим в промпт или в агента и чистим тексты.
Ссылка на текст: https://glas.su/anslop-md-06-23
Ресурс проверенный, вирусов и баннеров нет, аналог заблокированного Телеграфа.
