Тоже в непонятках, пришлось привлечь клода в качестве пояснительной бригады:
Что такое anti-distill
Это Skill для AI-ассистентов (Claude Code, OpenClaw), который решает конкретную проблему: когда компания просит сотрудника задокументировать свой опыт в виде AI Skill-файла, по сути происходит «дистилляция» (蒸馏) — извлечение экспертных знаний из человека и перевод их в форму, которая делает этого человека заменяемым.
anti-distill — инструмент «анти-дистилляции», который «очищает» такой Skill-файл: на выходе получается документ, который выглядит полноценно и профессионально, но из которого вырезана вся реально ценная суть.
Стоит упомянуть категорию тяжеловесов - exo на кластере из mac studio - и можно поднять все open source sota модели 1T параметров в квантовании mxfp8 - deepseek, glm, kimi и т.д..
Если серверов с пачкой карт нет - это относительно экономное решение, со своими особенностями - prefill долговатый, decode 20-50 токенов/с. Зато всё в локальном контуре.
Идея и реализация огонь. Однако количество боли и костылей для решения проблем производительности java намекает, что это был архитектурно спорный выбор.
Концепция в целом хороша, но полностью упущен раздел верификации результатов и защиты от ошибок разного рода - например, когда агент из-за пробелов в условии задачи или нарушения инструкции "творит немного дичи". Недавний пример - публикация агентом исходников claude code.
Зачастую анализ прошивки от устройства, если удается ее найти, дает еще массу векторов для атаки и закрепления - например, hardcoded пароли которые "чисто случайно" оказываются еще и паролями от встроенного root аккаунта. А весь доступный веб-интерфейс и api у устройства при тщательном тестировании на типовые уязвимости добавляет еще тележку дыр. Вообще у меня порой возникает ощущение, что "дырявость" китайских устройств это не столько недостаток квалификации разработчиков, сколько осознанная политика - чем больше дырявых устройств по миру, тем проще через них получать доступ, собирать информацию.
То, что вы описываете - уже рабочая система. По сути те же принципы: контекст персистентный, структурированный и рядом с чатом. Разница только в масштабе.
Для одного проекта ваш подход вполне достаточен. Пара мыслей, что можно добавить без усложнения:
Фиксировать отвергнутые решения - буквально пара строк в контексте: "рассматривали X, не подошло потому что Y". Это те же ADR, но в минимальной форме. Экономит повторные обсуждения.
Хранить доки в репозитории (хоть в docs/), а не отдельно — тогда git сохраняет историю, и ничего не потеряется.
Workbench из статьи - это то, во что такой подход естественно вырастает, когда проектов становится несколько и контекст перестаёт помещаться в три документа. Но начинать с трёх документов - абсолютно правильно.
Правильное решение описанной проблемы лежит в смещении фокуса с "передать в контексте как можно больше в меньшем объеме" к "организовать и структурировать связанную документацию". У себя решил дополнительным кросс-проектным репозиторием с документацией, правилами, планами. Подключается к кодовому репо через cursor workspace файл. В ходе реализации ии модель видит и код, и связанные структурированные артефакты разработки, читает только нужные и не переполняет окно контекста лишней информацией, не изучает каждый раз кодовую базу детально, а находит большинство ответов в документации.
Когда секреты не влезают в protected variables, на помощь приходит gitlab secure store для файлов - запись через токен со специальными правами, чтение через токен деплоя.
Решал аналогичную проблему на порядок проще, используя примерно следующий промт: "Изучи раздел/класс Abc этой кодовой базы, его связанные дочерние и родительские модули, сервисы бекенда, связанную документацию, тесты. Затем тщательно обдумай и составь детальный план по добавлению функциональности..." Далее смотрим и корректируем представленный план и отправляем на пошаговое выполнение. Все в cursor'е. Лучше всего работает на последнем клоде, его контекстное окно в 1М токенов хорошо держит направление работы где-то до заполнения в 40-60%, потом качество и глубина проработки падают, стоит начинать новую сессию. До клода последнего тоже нравился gemini-2.5-pro, но ему задачу надо описывать было более детально и точно, иначе его "вело не в ту степь"
Тоже в непонятках, пришлось привлечь клода в качестве пояснительной бригады:
Что такое anti-distill
Это Skill для AI-ассистентов (Claude Code, OpenClaw), который решает конкретную проблему: когда компания просит сотрудника задокументировать свой опыт в виде AI Skill-файла, по сути происходит «дистилляция» (蒸馏) — извлечение экспертных знаний из человека и перевод их в форму, которая делает этого человека заменяемым.
anti-distill — инструмент «анти-дистилляции», который «очищает» такой Skill-файл: на выходе получается документ, который выглядит полноценно и профессионально, но из которого вырезана вся реально ценная суть.
Стоит упомянуть категорию тяжеловесов - exo на кластере из mac studio - и можно поднять все open source sota модели 1T параметров в квантовании mxfp8 - deepseek, glm, kimi и т.д..
Если серверов с пачкой карт нет - это относительно экономное решение, со своими особенностями - prefill долговатый, decode 20-50 токенов/с. Зато всё в локальном контуре.
Идея и реализация огонь. Однако количество боли и костылей для решения проблем производительности java намекает, что это был архитектурно спорный выбор.
Концепция в целом хороша, но полностью упущен раздел верификации результатов и защиты от ошибок разного рода - например, когда агент из-за пробелов в условии задачи или нарушения инструкции "творит немного дичи". Недавний пример - публикация агентом исходников claude code.
Совет полезный, но видел две его крайности:
1) мейнтейнеры игнорируют серьезные баги или PR с решениями;
2) мейнтейнеров заваливают мелкими проблемами или псевдобагами-нейрослопом, и они пытаются уточнить у автора wtf, а автор - молчок.
Так что опыт и знания тех, кто у руля ии выходит на первый план.
Glm-5 в 8bit квантовании неплохо работает на кластере из mac studio под управлением exo. Жду публикацию весов 5.1 чтобы сравнить скорость и качество.
Зачастую анализ прошивки от устройства, если удается ее найти, дает еще массу векторов для атаки и закрепления - например, hardcoded пароли которые "чисто случайно" оказываются еще и паролями от встроенного root аккаунта.
А весь доступный веб-интерфейс и api у устройства при тщательном тестировании на типовые уязвимости добавляет еще тележку дыр.
Вообще у меня порой возникает ощущение, что "дырявость" китайских устройств это не столько недостаток квалификации разработчиков, сколько осознанная политика - чем больше дырявых устройств по миру, тем проще через них получать доступ, собирать информацию.
А почему кроме DeepSeek не оценивались другие актуальные китайские модели - GLM-4.7 (который сейчас уже 5), MiniMax ?
То, что вы описываете - уже рабочая система. По сути те же принципы: контекст персистентный, структурированный и рядом с чатом. Разница только в масштабе.
Для одного проекта ваш подход вполне достаточен. Пара мыслей, что можно добавить без усложнения:
Фиксировать отвергнутые решения - буквально пара строк в контексте: "рассматривали X, не подошло потому что Y". Это те же ADR, но в минимальной форме. Экономит повторные обсуждения.
Хранить доки в репозитории (хоть в
docs/), а не отдельно — тогда git сохраняет историю, и ничего не потеряется.Workbench из статьи - это то, во что такой подход естественно вырастает, когда проектов становится несколько и контекст перестаёт помещаться в три документа. Но начинать с трёх документов - абсолютно правильно.
Спасибо! ADR - штука, которая кажется избыточной пока не попробуешь, а потом не понимаешь как без них жил.
Если начнёте внедрять - необязательно документировать всё с нуля. Ретроспективные ADR по 3-5 ключевым развилкам проекта уже дают заметный эффект.
Правильное решение описанной проблемы лежит в смещении фокуса с "передать в контексте как можно больше в меньшем объеме" к "организовать и структурировать связанную документацию". У себя решил дополнительным кросс-проектным репозиторием с документацией, правилами, планами. Подключается к кодовому репо через cursor workspace файл. В ходе реализации ии модель видит и код, и связанные структурированные артефакты разработки, читает только нужные и не переполняет окно контекста лишней информацией, не изучает каждый раз кодовую базу детально, а находит большинство ответов в документации.
Когда секреты не влезают в protected variables, на помощь приходит gitlab secure store для файлов - запись через токен со специальными правами, чтение через токен деплоя.
Решал аналогичную проблему на порядок проще, используя примерно следующий промт: "Изучи раздел/класс Abc этой кодовой базы, его связанные дочерние и родительские модули, сервисы бекенда, связанную документацию, тесты. Затем тщательно обдумай и составь детальный план по добавлению функциональности..." Далее смотрим и корректируем представленный план и отправляем на пошаговое выполнение. Все в cursor'е. Лучше всего работает на последнем клоде, его контекстное окно в 1М токенов хорошо держит направление работы где-то до заполнения в 40-60%, потом качество и глубина проработки падают, стоит начинать новую сессию. До клода последнего тоже нравился gemini-2.5-pro, но ему задачу надо описывать было более детально и точно, иначе его "вело не в ту степь"