Спасибо, ты собрал тезис точнее, чем я в выводе. Да, скрипт работает и без Claude Code: обычный node, на вход хексы и пара флагов. Так что как CI-чек вполне, только не для всей дизайн-системы, а для её chart-токенов: шкалы, статусные цвета. Смысл гейта в том, что палитра ломается поштучно: ребренд трогает один цвет, сам по себе он хорош, а различимость с соседом при дальтонизме умерла — и глазами этого никто не увидит.
Но ту же проверку можно поставить и раньше, до кода плагином в Фигме. Токены там живут в Variables с режимами, так что плагин может проверять палитру сразу в светлой и тёмной теме — прямо в момент, когда дизайнер меняет цвет (гипотеза). Код скрипта копировать не буду (лицензия), но проверки те же, собираются на открытой библиотеке (culori например). Если соберу — напишу разбор.
Эксперимент в статье настоящий: свой прогон, свои скрины, ранги сверены вручную с сырыми CSV,таблица в тексте. Модель по ходу дела ошиблась в выводе о данных (Sofia/Sophia), и поймал это я, ручной сверкой,про эту границу статья и написана. Инструменты в работе использую и не скрываю: разбор того, что им можно делегировать, а что нельзя, странно было бы делать без них. Если найдёшь в тексте фактическую ошибку — покажи, поправлю и скажу спасибо.
Весь «личный опыт» в репозитории: код, логи семи сессий и история коммитов, github.com/inforobotvit/habr-corpus-parser. Формат «эксперимент по сценам» может не зайти это ок. Но что конкретно оказалось непонятным? Пригодится для следующих статей.
О, вот это по-настоящему ценно, спасибо. Похоже, ткнули прямо в корень: по умолчанию llama.cpp выдаёт Gemma мало токенов на картинку – она видит её в низком разрешении, плотные ячейки не читаются, и дальше модель дорисовывает правдоподобное. То есть «врёт» она не от вредности, а оттого, что я ей зрение задушил дефолтным конфигом. Это заметно меняет вывод статьи.
Перепрогоню обе таблицы с --image-max-tokens 2240 и поднятыми batch/ubatch (там ведь non-causal attention – ubatch должен вмещать все токены картинки, иначе падает с ассертом). Заодно проверю, влезет ли это вообще в мои 16 ГБ – и так впритык. Результат отпишу. Спасибо, что поймали до того, как я наломал дров дальше.
Вот за что я люблю Хабр, вот за такие комментарии, которые реально расширяют горизонт!
Справедливо, спасибо за наводку – GLM-OCR не щупал, возьму на тест. Для чистого OCR таблиц заточенная 0.9B действительно правильнее, чем 12B-универсал, тут не спорю.
Я писал статью не для того, чтобы сказать: «Gemma – лучший OCR» (она им и не является). Скорее некая карта, где у общего локального VLM ломается зрение и как это ловить. И вы сами назвали ключевое – «тоже способна врать». Вот это и есть суть. Приёмы из статьи (флаг происхождения значений, сверка числа подписей, спасение обрезанного вывода) не зависят от модели – обернут GLM-OCR ровно так же. Ценность не в выборе модели, а в недоверии к её выводу.
Спасибо за пайплайн (GLM извлекает → Gemma причёсывает в csv/markdown) – здравое разделение ролей: специалист читает, универсал форматирует. Возможно, соберу и протестирую на тех же таблицах – честное сравнение.
А «возвышающий обман» – это буквально подзаголовок статьи, так что цитата в точку. Снимаю шляпу!
Спасибо, за ответ, очень ценно. Твоя тема прям на фронтире!
Особенно интересно, как ты технически разделила тесты – contractLayer с моком, qualityLayer с реальной моделью. Это аккуратная декомпозиция: разные затраты, разная частота запуска, разные цели.
Несколько вещей резонируют с тем, что я разбирал. Hallucination detection в contractLayer – у Anthropic в research_subagent.md есть блок про оценку источников: они руками прописывают агенту красные флаги типа «marketing language, nameless sources, news aggregators citing other news». По сути это те же domain invariants, только записанные не в виде runtime-тестов, а в виде инструкции внутри промпта. Получается два уровня защиты: то, что модель должна отлавливать сама, и то, что проверяется внешним кодом после неё.
Про gap между концепцией и рабочим кодом – да, и у меня этот разрыв тоже есть. Я разбираю что положить в тело агента, ты разбираешь как валидировать поведение. Это смежные грани одной задачи, и из обоих углов пока больше теории, чем кода. Если соберёшься писать про contractLayer/qualityLayer с примерами кода обязательно напиши, прочитаю первым.
Интересно! Spurious correctness и block coverage – это уже территория профессионального AI-тестирования, в которую я не уходил намеренно. Я разбирал анатомию промпта, не методологию верификации. Это смежная дисциплина, и спасибо, что подсветил её отдельно — буду погружатся. )
Если у тебя есть публичные материалы или практики по block coverage для агентных систем — поделись, мне бы было интересно почитать.
Да, я согласен: если задача стоит "записать встречу и получить транскрипт без танцев с бубном", то приложение с понятным UI часто лучше, чем сборка пайплайна из консольных утилит.
Мой гайд скорее для тех, кому хочется заглянуть под капот и собрать всё руками — там и про универсальность (любое видео, не только встречи), и про возможность вмешаться в логику (флаги Whisper, VAD-модель против зацикливания, свои промпты для саммари). Это не «лучше», это для другого настроения и другой задачи.
BoringMeeting посмотрел, классно! Понравился подход "полностью локально, без облака»"и явное разделение микрофона и системного звука, сам мучался давно когда пытался скринкастом с корпоративных звонилок записывать. Удачи с развитием!
Вы поймали место, где аналогия честно ломается – и не в пользу статьи. Я веду к "делегируй ИИ так же тщательно, как человеку". А вы показываете обратное: с ИИ можно позволить себе небрежность, которую человек не простит. Итерация ничего не стоит, эго нет, на "сделай на своё усмотрение, дальше разберусь" он не обижается. С людьми так не очень хорошо – у них итерация не бесплатна: каждый заход стоит времени, труда и капельки самолюбия. Так что да ИИ прощает постановщику то, чего не прощает человек.
Про "сделай проще" против "постарайся получше" – точное наблюдение, оно уточняет мой первый урок. Обе формулировки расплывчатые, но "проще" задаёт вектор, а "получше" – нет, это просто "сделай хорошо" другими словами. Дело не в расплывчатости, а в том, есть ли в формулировке направление. И с человеком даже вектор сработает только при высокой квалификации – ему ещё нужно знать, что в этом контексте считается "проще"
Очень точное разграничение, и вы правы – в статье оно не проговорено, это её честная граница. Соглашусь по первой части полностью: делегирование задачи ресурс не высвобождает, а перекладывает в другую форму — с "придумать решение" на "проверить и поправить" плюс держать в голове список поручений. Проверка становится явным шагом процесса. Облегчение тут не в том, что работа испаряется, а в том, что она перестаёт быть невидимой.
А вот вторая часть, на мой взгляд, не столько "не учтена в статье", сколько в принципе лежит вне её темы – и вы сами на это указали. Делегирование ответственности – это не приём формулировки, это про доверие и про то, что человек растёт и может отвечать за результат. Его нельзя "хорошо сформулировать", его можно только дать тому, кто способен нести. ИИ сюда не помещается не из-за плохого промпта, а потому что ответственность предполагает субъекта, который ею рискует.
Так что да – промптинг даёт язык для первого режима и честно молчит про второй. Спасибо, что подсветили это.
Соглашусь про занятость. Но цена этой сэкономленной минуты просто перекладывается на исполнителя, причём с процентами: переделка стоит дороже, чем нормальная постановка с самого начала. То, что недосформулировано наверху, всё равно будет досформулировано – только ниже и дороже.
Про мини-ТЗ – отличный приём. По сути вы делаете сверку картинок: своё видение задачи и решения кладёте перед постановщиком, и он сразу видит несоответствие – если оно есть – и поправляет на этапе, который дёшев для вас обоих. Плюс мягко приучаете постановщика, что у задачи есть форма.
Спасибо! Про переделку это вы попали в то, что я в статье недокрутил. Там акцент на «исполнитель сделает мимо», а ведь обиднее всего именно ваш сценарий: задача размытая, ты честно вложился в своё видение, оно живое и осмысленное, а потом выясняется, что у постановщика в голове было другое, и всё в корзину. Причём формально к тебе не придраться, ты сделал «как понял».
Похоже, тут напрашивается шестой пункт – про сверку картинок на старте. Не молча "я понял задачу", а проговорить вслух: вот как конечный результат вижу я, вот как его видит постановщик — и убедиться, что это одна картинка, до того как вложено время. По сути это пятый урок про критерий, но повёрнутый: критерий мало записать, его надо ещё и сверить — понимаем ли мы с постановщиком его одинаково.
И да, по поводу "1-2 за двадцать лет" – грустно, но похоже на правду. Подозреваю, отчасти потому, что навык невидимый, хорошая постановка выглядит так, будто задача "сама была простая", и заслуги не видно. А плохую замечаешь только на этапе переделки, когда уже поздно.
Спасибо, поймал реальную нестыковку. «Через месяц» висело без явной точки отсчёта – читалось как «через месяц после мая 2025», хотя я имел в виду «через месяц от дня публикации моей статьи, 16 мая 2026». Сейчас поправлю в тексте, чтобы временные якоря были разведены явно.
Точное наблюдение, оно открывает отдельную целую тему! Согласен, разделение ролей через системный промпт работает на уровне «договорённости», но не на уровне принудительной изоляции. Как только в контекст попадает враждебный tool output или запись из памяти, агент читает её как продолжение своих инструкций – и роль переопределяется снизу вверх. В статье я разбирал анатомию тела одного агента – то есть что положить внутрь. Security boundary – это уже про архитектуру вокруг агента: песочницы для инструментов, валидация ввода до того, как агент его увидит, разделение прав на уровне runtime. Это смежная дисциплина, которая требует отдельной статьи, и я её обязательно сделаю. Anthropic, кстати, в последнее время явно идёт именно туда – Computer Use sandboxing, Code Execution with MCP с изоляцией, harness engineering как отдельный паттерн. В пятой статье серии у меня запланирован разбор фронтир-паттернов, security там само-собой будет. Заберу твоё наблюдение про prompt injection через память – это очень крутой пример, который я в свой материал не закладывал. Спасибо за red-team-перспективу, такой опыт в комментариях ценнее, чем сам разбор. Запишу в полевые заметки к серии.
Метафора "поводок" – лучше, чем "потолок". Действительно, у LLM нет встроенного механизма остановки: в тренировочных данных "правильный ответ" почти всегда существует, и модель училась его искать, а не отказываться. Бюджет вызовов работает как внешняя обратная связь – то, чего у модели в архитектуре нет.
Anthropic, кстати, в research_subagent.md явно угрожает агенту терминацией, («If you exceed this limit, the subagent will be terminated.») и это работает именно по той же причине: модель должна знать, что её отключат, иначе сама не остановится, но я не одушевляю ). То есть бюджет – это даже не один поводок, а двухуровневая защита: soft budget (рекомендация) + hard cap (явная угроза).
Спасибо за дополнение, забрал в свою заметку для следующей статьи.
Хороший поинт, и для личного использования это действительно так — Claude Code + cron + Telegram бот закрывает сценарий и стоит только подписки.
Разница появляется, если хочется отдать это другим людям как сервис. Тут три момента:
ToS Claude Code явно говорит, что Pro/Max — это «ordinary, individual usage», и что routing запросов через эти credentials «on behalf of their users» не разрешён. Anthropic пишет, что может принимать меры без предупреждения. То есть для своего бота — окей, для чужих — нет.
С 15 июня 2026 Agent SDK и claude -p на подписках начнут считаться отдельным месячным кредитом, не из интерактивных лимитов. Anthropic постепенно режет use case «подписка как замена API».
Managed Agents — это про другое: per-user OAuth-vaults для интеграций, webhooks, versioned agents, permission policies. На Claude Code это всё доделывается руками; на Managed Agents — из коробки.
Короче: для личного автоматизатора Claude Code + cron — рабочее решение и оно дешевле. Для продукта поверх — это история про время до первого бана и про мультитенантность, которую всё равно придётся строить.
Спасибо, ты собрал тезис точнее, чем я в выводе. Да, скрипт работает и без Claude Code: обычный node, на вход хексы и пара флагов. Так что как CI-чек вполне, только не для всей дизайн-системы, а для её chart-токенов: шкалы, статусные цвета. Смысл гейта в том, что палитра ломается поштучно: ребренд трогает один цвет, сам по себе он хорош, а различимость с соседом при дальтонизме умерла — и глазами этого никто не увидит.
Но ту же проверку можно поставить и раньше, до кода плагином в Фигме. Токены там живут в Variables с режимами, так что плагин может проверять палитру сразу в светлой и тёмной теме — прямо в момент, когда дизайнер меняет цвет (гипотеза). Код скрипта копировать не буду (лицензия), но проверки те же, собираются на открытой библиотеке (culori например). Если соберу — напишу разбор.
Эксперимент в статье настоящий: свой прогон, свои скрины, ранги сверены вручную с сырыми CSV,таблица в тексте. Модель по ходу дела ошиблась в выводе о данных (Sofia/Sophia), и поймал это я, ручной сверкой,про эту границу статья и написана. Инструменты в работе использую и не скрываю: разбор того, что им можно делегировать, а что нельзя, странно было бы делать без них. Если найдёшь в тексте фактическую ошибку — покажи, поправлю и скажу спасибо.
Весь «личный опыт» в репозитории: код, логи семи сессий и история коммитов, github.com/inforobotvit/habr-corpus-parser. Формат «эксперимент по сценам» может не зайти это ок. Но что конкретно оказалось непонятным? Пригодится для следующих статей.
Не, не. Просто будет выбирать самый вероятный ответ. 0,1 ставят, чтоб был для иишки хоть небольшой коридор манёвра.
Будет, будет)))
К выходным думаю, в будни работа выматывает, вечером только и мысли о сне.
О, вот это по-настоящему ценно, спасибо.
Похоже, ткнули прямо в корень: по умолчанию llama.cpp выдаёт Gemma мало токенов на картинку – она видит её в низком разрешении, плотные ячейки не читаются, и дальше модель дорисовывает правдоподобное. То есть «врёт» она не от вредности, а оттого, что я ей зрение задушил дефолтным конфигом. Это заметно меняет вывод статьи.
Перепрогоню обе таблицы с
--image-max-tokens 2240и поднятымиbatch/ubatch(там ведь non-causal attention – ubatch должен вмещать все токены картинки, иначе падает с ассертом). Заодно проверю, влезет ли это вообще в мои 16 ГБ – и так впритык. Результат отпишу. Спасибо, что поймали до того, как я наломал дров дальше.Справедливо, для чистых таблиц классический OCR/парсер дешевле. ценность была в разборе Gemma: даже на таких синтетических задачах, но вопрос честный.
Да, большая модель справляется, но 35B это не локально-на-16-ГБ, а такое ограничение к сожалению есть.
Вот за что я люблю Хабр, вот за такие комментарии, которые реально расширяют горизонт!
Справедливо, спасибо за наводку – GLM-OCR не щупал, возьму на тест. Для чистого OCR таблиц заточенная 0.9B действительно правильнее, чем 12B-универсал, тут не спорю.
Я писал статью не для того, чтобы сказать: «Gemma – лучший OCR» (она им и не является). Скорее некая карта, где у общего локального VLM ломается зрение и как это ловить. И вы сами назвали ключевое – «тоже способна врать». Вот это и есть суть. Приёмы из статьи (флаг происхождения значений, сверка числа подписей, спасение обрезанного вывода) не зависят от модели – обернут GLM-OCR ровно так же. Ценность не в выборе модели, а в недоверии к её выводу.
Спасибо за пайплайн (GLM извлекает → Gemma причёсывает в csv/markdown) – здравое разделение ролей: специалист читает, универсал форматирует. Возможно, соберу и протестирую на тех же таблицах – честное сравнение.
А «возвышающий обман» – это буквально подзаголовок статьи, так что цитата в точку. Снимаю шляпу!
Спасибо, за ответ, очень ценно. Твоя тема прям на фронтире!
Особенно интересно, как ты технически разделила тесты – contractLayer с моком, qualityLayer с реальной моделью. Это аккуратная декомпозиция: разные затраты, разная частота запуска, разные цели.
Несколько вещей резонируют с тем, что я разбирал. Hallucination detection в contractLayer – у Anthropic в research_subagent.md есть блок про оценку источников: они руками прописывают агенту красные флаги типа «marketing language, nameless sources, news aggregators citing other news». По сути это те же domain invariants, только записанные не в виде runtime-тестов, а в виде инструкции внутри промпта. Получается два уровня защиты: то, что модель должна отлавливать сама, и то, что проверяется внешним кодом после неё.
Про gap между концепцией и рабочим кодом – да, и у меня этот разрыв тоже есть. Я разбираю что положить в тело агента, ты разбираешь как валидировать поведение. Это смежные грани одной задачи, и из обоих углов пока больше теории, чем кода. Если соберёшься писать про contractLayer/qualityLayer с примерами кода обязательно напиши, прочитаю первым.
Интересно!
Spurious correctness и block coverage – это уже территория профессионального AI-тестирования, в которую я не уходил намеренно. Я разбирал анатомию промпта, не методологию верификации. Это смежная дисциплина, и спасибо, что подсветил её отдельно — буду погружатся. )
Если у тебя есть публичные материалы или практики по block coverage для агентных систем — поделись, мне бы было интересно почитать.
Да, я согласен: если задача стоит "записать встречу и получить транскрипт без танцев с бубном", то приложение с понятным UI часто лучше, чем сборка пайплайна из консольных утилит.
Мой гайд скорее для тех, кому хочется заглянуть под капот и собрать всё руками — там и про универсальность (любое видео, не только встречи), и про возможность вмешаться в логику (флаги Whisper, VAD-модель против зацикливания, свои промпты для саммари). Это не «лучше», это для другого настроения и другой задачи.
BoringMeeting посмотрел, классно! Понравился подход "полностью локально, без облака»"и явное разделение микрофона и системного звука, сам мучался давно когда пытался скринкастом с корпоративных звонилок записывать. Удачи с развитием!
Вы поймали место, где аналогия честно ломается – и не в пользу статьи. Я веду к "делегируй ИИ так же тщательно, как человеку". А вы показываете обратное: с ИИ можно позволить себе небрежность, которую человек не простит. Итерация ничего не стоит, эго нет, на "сделай на своё усмотрение, дальше разберусь" он не обижается.
С людьми так не очень хорошо – у них итерация не бесплатна: каждый заход стоит времени, труда и капельки самолюбия. Так что да ИИ прощает постановщику то, чего не прощает человек.
Про "сделай проще" против "постарайся получше" – точное наблюдение, оно уточняет мой первый урок. Обе формулировки расплывчатые, но "проще" задаёт вектор, а "получше" – нет, это просто "сделай хорошо" другими словами. Дело не в расплывчатости, а в том, есть ли в формулировке направление. И с человеком даже вектор сработает только при высокой квалификации – ему ещё нужно знать, что в этом контексте считается "проще"
Очень точное разграничение, и вы правы – в статье оно не проговорено, это её честная граница. Соглашусь по первой части полностью: делегирование задачи ресурс не высвобождает, а перекладывает в другую форму — с "придумать решение" на "проверить и поправить" плюс держать в голове список поручений. Проверка становится явным шагом процесса. Облегчение тут не в том, что работа испаряется, а в том, что она перестаёт быть невидимой.
А вот вторая часть, на мой взгляд, не столько "не учтена в статье", сколько в принципе лежит вне её темы – и вы сами на это указали. Делегирование ответственности – это не приём формулировки, это про доверие и про то, что человек растёт и может отвечать за результат. Его нельзя "хорошо сформулировать", его можно только дать тому, кто способен нести. ИИ сюда не помещается не из-за плохого промпта, а потому что ответственность предполагает субъекта, который ею рискует.
Так что да – промптинг даёт язык для первого режима и честно молчит про второй. Спасибо, что подсветили это.
Соглашусь про занятость. Но цена этой сэкономленной минуты просто перекладывается на исполнителя, причём с процентами: переделка стоит дороже, чем нормальная постановка с самого начала. То, что недосформулировано наверху, всё равно будет досформулировано – только ниже и дороже.
Про мини-ТЗ – отличный приём. По сути вы делаете сверку картинок: своё видение задачи и решения кладёте перед постановщиком, и он сразу видит несоответствие – если оно есть – и поправляет на этапе, который дёшев для вас обоих. Плюс мягко приучаете постановщика, что у задачи есть форма.
Спасибо! Про переделку это вы попали в то, что я в статье недокрутил. Там акцент на «исполнитель сделает мимо», а ведь обиднее всего именно ваш сценарий: задача размытая, ты честно вложился в своё видение, оно живое и осмысленное, а потом выясняется, что у постановщика в голове было другое, и всё в корзину. Причём формально к тебе не придраться, ты сделал «как понял».
Похоже, тут напрашивается шестой пункт – про сверку картинок на старте. Не молча "я понял задачу", а проговорить вслух: вот как конечный результат вижу я, вот как его видит постановщик — и убедиться, что это одна картинка, до того как вложено время. По сути это пятый урок про критерий, но повёрнутый: критерий мало записать, его надо ещё и сверить — понимаем ли мы с постановщиком его одинаково.
И да, по поводу "1-2 за двадцать лет" – грустно, но похоже на правду. Подозреваю, отчасти потому, что навык невидимый, хорошая постановка выглядит так, будто задача "сама была простая", и заслуги не видно. А плохую замечаешь только на этапе переделки, когда уже поздно.
Спасибо, поймал реальную нестыковку. «Через месяц» висело без явной точки отсчёта – читалось как «через месяц после мая 2025», хотя я имел в виду «через месяц от дня публикации моей статьи, 16 мая 2026». Сейчас поправлю в тексте, чтобы временные якоря были разведены явно.
Точное наблюдение, оно открывает отдельную целую тему! Согласен, разделение ролей через системный промпт работает на уровне «договорённости», но не на уровне принудительной изоляции. Как только в контекст попадает враждебный tool output или запись из памяти, агент читает её как продолжение своих инструкций – и роль переопределяется снизу вверх.
В статье я разбирал анатомию тела одного агента – то есть что положить внутрь. Security boundary – это уже про архитектуру вокруг агента: песочницы для инструментов, валидация ввода до того, как агент его увидит, разделение прав на уровне runtime. Это смежная дисциплина, которая требует отдельной статьи, и я её обязательно сделаю.
Anthropic, кстати, в последнее время явно идёт именно туда – Computer Use sandboxing, Code Execution with MCP с изоляцией, harness engineering как отдельный паттерн. В пятой статье серии у меня запланирован разбор фронтир-паттернов, security там само-собой будет. Заберу твоё наблюдение про prompt injection через память – это очень крутой пример, который я в свой материал не закладывал.
Спасибо за red-team-перспективу, такой опыт в комментариях ценнее, чем сам разбор. Запишу в полевые заметки к серии.
Спасибо, точное замечание!
Метафора "поводок" – лучше, чем "потолок". Действительно, у LLM нет встроенного механизма остановки: в тренировочных данных "правильный ответ" почти всегда существует, и модель училась его искать, а не отказываться. Бюджет вызовов работает как внешняя обратная связь – то, чего у модели в архитектуре нет.
Anthropic, кстати, в research_subagent.md явно угрожает агенту терминацией, («If you exceed this limit, the subagent will be terminated.») и это работает именно по той же причине: модель должна знать, что её отключат, иначе сама не остановится, но я не одушевляю ). То есть бюджет – это даже не один поводок, а двухуровневая защита: soft budget (рекомендация) + hard cap (явная угроза).
Спасибо за дополнение, забрал в свою заметку для следующей статьи.
Хороший поинт, и для личного использования это действительно так — Claude Code + cron + Telegram бот закрывает сценарий и стоит только подписки.
Разница появляется, если хочется отдать это другим людям как сервис. Тут три момента:
ToS Claude Code явно говорит, что Pro/Max — это «ordinary, individual usage», и что routing запросов через эти credentials «on behalf of their users» не разрешён. Anthropic пишет, что может принимать меры без предупреждения. То есть для своего бота — окей, для чужих — нет.
С 15 июня 2026 Agent SDK и
claude -pна подписках начнут считаться отдельным месячным кредитом, не из интерактивных лимитов. Anthropic постепенно режет use case «подписка как замена API».Managed Agents — это про другое: per-user OAuth-vaults для интеграций, webhooks, versioned agents, permission policies. На Claude Code это всё доделывается руками; на Managed Agents — из коробки.
Короче: для личного автоматизатора Claude Code + cron — рабочее решение и оно дешевле. Для продукта поверх — это история про время до первого бана и про мультитенантность, которую всё равно придётся строить.