В embedded-разработке модель может с первого раза сгенерировать прошивку, которая компилируется без ошибок, а потом тихо уводит дисплей на 34 пикселя, ломает ADC2 под Wi‑Fi или ставит GPIO туда, где их физически нет. На Habr вышел разбор о том, как закрыть этот разрыв не новым туториалом, а открытой коллекцией board-specific skills для Claude Code.
Суть события
Автор Habr-сообщения собрал открытую коллекцию <em>skills</em> для Claude Code — по одному скиллу на конкретную плату. Идея не в том, чтобы научить модель «вообще писать прошивки», а в том, чтобы подсунуть ей ровно тот контекст, которого у неё обычно нет: как реально разведены пины, где сидит дисплей, какие линии делят SPI и какие ошибки на этой плате выглядят как магия, а на деле являются банальной невнимательностью к железу.
Внутри репозитория уже есть восемь плат: несколько STM32 и ESP32, Raspberry Pi Pico, Arduino Nano на ATmega328P и другие варианты. Для embedded это звучит почти скучно, но именно в этом и смысл: одна и та же модель может уверенно написать код, который «вроде» работает, а потом на конкретной ревизии платы всё разваливается из-за смещения дисплея, конфликта шин или пина, которого нет на разъёме.
Детали
У скилла три слоя. В <strong>SKILL.md</strong> лежит короткая выжимка, которую модель читает всегда: карта пинов, характеристики чипа и жёсткие правила, чтобы не повторять дорогие ошибки. В <strong>reference/</strong> живут глубокие детали — полная разводка, альтернативные функции, подводные камни. В <strong>template/</strong> — уже рабочий проект, который можно собрать и прошить, а не текст, написанный по памяти. Это важная разница: модель перестаёт импровизировать там, где импровизация стоит вечера отладки.
В самом тексте автор перечисляет типичные фейлы: ST7789 с матрицей 240×320 и обрезанным стеклом 172×320, Waveshare ESP32-C6-LCD-1.47, где дисплей и microSD сидят на одном SPI, Raspberry Pi Pico с GPIO, которые есть в коде, но отсутствуют на 40-пиновом разъёме, ESP32, где ADC2 занят Wi‑Fi, и STM32F411, который легко положить неправильной частотой или забытым SysTick. Именно такие вещи LLM обычно не знает — и именно они съедают больше всего времени.
Контекст
Это очень похоже на <a href=»https://ai-digest.ru/pochemu-production-llm-inferens-degradiruet-kv-cache-oom-i-hvost-p99/»>ту же проблему, о которой мы писали в разборе про production LLM-инференс</a>: модель не ломается потому, что она «глупая», она ломается потому, что ей не хватает контекста о реальных ограничениях среды. В embedded это особенно заметно: даташит один, вики производителя другой, алиэкспресс-мануал третий, а реальная плата живёт по четвёртому сценарию, который узнаёшь уже на столе с паяльником.
Из-за этого обычные туториалы быстро превращаются в ловушку. Они описывают идеальный мир, а плате нужен не идеальный, а конкретный: с этой ревизией, этим тактированием, этой разводкой и этим набором занятых ресурсов. Поэтому скилл здесь выглядит не как модная обёртка вокруг ИИ, а как инженерный артефакт — маленький контракт с железом, который можно хранить рядом с кодом и версионировать вместе с проектом.
Что дальше
Самое полезное в этой идее — она масштабируется на длинные проекты. Скилл можно положить в .claude/skills/ рядом с прошивкой, дописать новые грабли по мере их появления и передать их всей команде, а не держать в голове у одного человека или в переписке. Для команд это означает более быстрый онбординг, меньше случайных конфликтов ресурсов и меньше тех самых «почему оно компилируется, но не работает».
При этом автор честно отделяет плату от архитектуры приложения: проектные правила всё равно живут в AGENTS.md, а скилл отвечает только за железо. Именно в этом, кажется, и главный вывод новости: у ИИ не отнимают право писать код, ему просто дают нормальный контекст. А в embedded это уже почти половина победы.
