Скилл multisim-scheme собирает файлы NI Multisim 14 по картинке. Мы его писали и проверяли вместе с сильной моделью, и всё работало. Потом пользователь открыл чат в claude.ai с Claude Haiku — самой быстрой и самой слабой моделью — и попросил мостовой усилитель. Эта статья о том, что пошло не так и как мы переделали скилл, чтобы по нему справлялась и слабая модель.
Мостовой усилитель на 19,5 В
Haiku собрал схему, прислал файл, описание и таблицу ожидаемых значений. Всё выглядело убедительно. В файле оказалось вот что:
- Питание 5 В вместо 19,5 В. Источник VCC в скилле без явного напряжения даёт 5 В, и модель напряжение не указала.
- Цифры не из файла. Ожидаемые значения Haiku посчитал по netlist, который написал сам. Там питание было 19,5 В, а в файле — 5 В.
- Разметка текстом. В описании схемы заголовки
###вышли как есть, символами. - «Косметические» наложения. Отчёт сборки показал 10 наложений, и модель назвала их косметическими. Пользователь сдаёт схему такой, какая она есть.
Ни одна из этих ошибок не была «багом» в коде. Все инструкции в скилле были, но сильная модель их находила, а слабая — нет.
Методичка Anthropic
У Anthropic есть руководство Skill authoring best practices. Мы сверили с ним скилл, и вот что взяли:
SKILL.md— меньше 500 строк;- поле
description— не длиннее 1024 символов. У нас было 1206; - чек-лист, который модель копирует в свой ответ и отмечает по ходу работы;
- подробности — в отдельных файлах, на один уровень вглубь от
SKILL.md; - проверка скриптом, а не на словах;
- тесты на Haiku, Sonnet и Opus: то, что понятно Opus, может быть непонятно Haiku.
Что сделали
- Сократили
SKILL.mdс 362 до 110 строк. В нём остались чек-лист из девяти шагов, обязательные правила, быстрый старт и карта папкиreference/. Подробности переехали в шесть файлов по темам: API, детали, раскладка, анализы, описание, формат. Полеdescriptionужали до 797 символов. - Написали контролёр
check.py. Любой файл перед отдачей получает вердикт READY или NOT READY. Он ловит наложения, переменные анализов с несуществующими цепями и источниками, разметку, оставшуюся текстом в описании, и питание 5 В по умолчанию. Файл с NOT READY отдавать нельзя: это правило, а не совет. - Ожидаемые значения — только из готового файла.
spice.runзапускает ngspice на netlist, собранном из того самого.ms14: с его питанием, деталями и параметрами. - Завели сценарии evals/. Каждый взят из настоящей ошибки: мостовой усилитель,
усилитель на TL072, КМОП-элемент ИЛИ-НЕ. После каждого изменения скилла сценарий прогоняется заново, а каждый промах становится
шагом чек-листа, правилом в
reference/или тестом вcheck.py.
Результат на версии 11
Мы снова дали задания Haiku.
- Остановился сам. Схема не заработала: пропадала отрицательная полуволна. Haiku не стал отдавать файл «как есть», а остановился, объяснил причину и спросил, что делать.
- Всё запрошенное — переменными анализов. Каждая величина из задания попала в Batched, а не в формулу в описании.
- Не тронул чужую схему. Во втором задании нужно было только добавить анализы в готовый файл. Схему Haiku не изменил: netlist совпал.
Что ещё нашли тесты
Самое ценное: тесты на слабой модели нашли ошибки не модели, а самого скилла. Сильная модель обходила их, не заметив.
- Русское имя параметра под меткой
&ASC. Перебор по параметруUвхрисовал пять одинаковых кривых. Строки с кириллицей скилл записывал под меткой&ASC, и Multisim не узнавал параметр. Теперь такие настройки идут под меткой&UNI, аcheck.pyловит старый вариант. db()на оси в децибелах. Если на АЧХ с осью в дБ ещё и взятьdb(…), выходит «дБ от дБ»: 20,8 дБ показывались как 26,4. Теперь это ошибка контролёра, а вSKILL.mdзаписано, как правильно.
Обе ошибки исправлены и проверены в Multisim 14.3.
Вывод
Слабая модель — лучший тестировщик скилла. Она делает ровно то, что написано, и не додумывает за автора. Поэтому каждая её
ошибка показывает место, где инструкция неясна или проверка держится на честном слове. Короткий SKILL.md, чек-лист
в ответе и контролёр, который нельзя уговорить, помогают всем моделям, не только слабым.