Инженерная ИИ-шница

Anthropic выкатили Claude Fable 5 - это «безопасная» версия той самой Mythos для всех пользователей. Судя по https://www.anthropic.com/news/claude-fable-5-mythos-5, она в разы лучше Opus 4,8 в написании кода, исследованиях и агентстких задачах. В SWE-bench Pro модель набирает рекордные 80,3%. Надеемся, она не сломает интернет. Тестируем здесь: https://claude.ai/new

Какашки поставили видимо те, кто демотивировались 😁

Минутка демотивации. Или наоборот. 19-летний вайбкодер Зак Ядегари продал свой счетчик калорий Cal AI примерно за $100 млн. Теперь он делает стартап для борьбы с думскроллингом. Зак вайбкодил Cal AI в перерывах между уроками. Когда он заканчивал обучение в школе, проект приносил $30 млн в год при 10 млн юзеров. Теперь Зак делает сервис Flow: он умеет блокировать отдельные приложения до тех пор, пока пользователь не отнесет смартфон к док-станции. Отлично помогает при зависимости от соцсетей. ChatGPT, сделай как у него, не совершай ошибок.

Из мира адаптации моделей под стесненные условия в портативке: https://habr.com/ru/companies/yandex/articles/1042706/

Если коротко - вот что выдал ChatGPT в ответ на схему и мою просьбу сделать ревью: Краткое ревью схемы USB-UART на CP2102. Первичное подозрение на перепутанные D+/D- после повторной проверки снято: линии USB данных подключены корректно. Основные вопросы остаются не к USB-паре, а к обвязке CP2102 и оформлению внешних цепей. Что стоит проверить перед разводкой PCB: Питание CP2102 Нужно явно зафиксировать режим: питание от USB через внутренний LDO или внешние 3.3 В. В текущем виде связка VDD/REGIN/VBUS выглядит неоднозначно. Цепь RST/VBUS Узел с R4 и C5 требует перепроверки по datasheet. Номинал C5 = 5.6 пФ выглядит нетипично для RC-сброса или фильтрации VBUS. Индикация TX/RX LED1/LED2, похоже, включены непосредственно в сигнальные линии. Это может нагружать UART/handshake и создавать паразитные подтяжки. Лучше использовать транзисторные ключи или отдельную буферизацию. R5 = 0 Ом в одной USB-линии Для симметрии USB-пары лучше либо убрать перемычку, либо поставить 0 Ом в обе линии, либо использовать согласующие резисторы симметрично. Разъем X1 Не хватает явной подписи pinout: TXD/RXD/RTS/CTS/GND, направление сигналов и уровень 3.3 В CMOS. Это снижает ремонтопригодность и повышает риск ошибки подключения. USB shield и защита питания На схеме не видно политики подключения экрана miniUSB и защиты от обратного питания по USB 5V, если на плате есть другие источники питания. Итог: USB D+/D- выглядят корректно, но схему нельзя считать полностью готовой без проверки питания CP2102, reset/VBUS-цепи, индикации сигналов и оформления внешнего разъема.

Кейс из реальной жизни. Ревью типовой схемы с CP2102. Одна из первых моих прикладных схем от которой рефлекс "рука-лицо". Отправил в ChatGPT5.5-Pro поревьювить её 😁 Ответ вполне себе ничего: https://chatgpt.com/s/t_6a2718f45a688191a3d6b462f7819699 Единственное с пинами D+/D- он запутался. Отправил его посмотреть еще раз: https://chatgpt.com/s/t_6a2719779d9481918689dfcfb861e1d3 Разглядел, снял претензию 😄 Господа схемотехники после легкого ужаса от созерцания данной схемы наверняка подскажут что нужно было еще ему отправить Netlist и прочие артефакты. Но об этом как-то в другой раз :) #пример

Чем я занимаюсь последние полгода 😄

ИИ в обучении начинает давать побочные эффекты: вводный курс по Computer Science в Беркли впервые не сдали 35% студентов. Обычно доля не сдавших была ниже 10%. Источник: https://www.dailycal.org/news/campus/academics/failing-grades-soar-as-professors-see-greater-ai-usage-dwindling-math-skills-in-uc-berkeley/article_16fad0bf-02cb-4b8c-8d88-888ffd9f8608.html Около 30 студентов уличили в списывании с использованием ChatGPT, Claude и Gemini. Однако проблема шире прямого читинга: часть студентов готовилась к экзаменам через чат-боты и в итоге не сформировала собственное понимание материала. Похожая динамика наблюдается и на инженерных курсах: доля студентов, не справившихся с экзаменами, выросла примерно с 5% до почти 17%. Одна из причин, на которую указывают преподаватели, это ослабление базовой математической подготовки. В результате ИИ не столько помогает учиться, сколько иногда маскирует пробелы до момента экзамена.

Почему писать промпты с помощью ИИ - плохая идея и как это исправить? Один из частых советов по работе с ИИ звучит так:

Не пиши промпт сам. Просто объясни ИИ задачу и попроси его написать промпт за тебя.

На первый взгляд совет разумный. И правда, ИИ часто полезен именно там, где человек мыслит слишком узко. Например, вы планируете поездку. Обычно в голове держатся понятные вещи: куда поехать, где жить, что посмотреть, сколько это стоит. Но легко забыть про мелкие и скучные детали, которые потом оказываются критичными: местные правила, особенности транспорта, розетки, страховку, связь, ограничения по багажу, сезон дождей, санитарные требования, локальные платежные системы. Мы можем просто не знать, что в шестой стране окажется важным то, с чем в предыдущих пяти мы не сталкивались. Вот тут ИИ действительно полезен. Он умеет расширять задачу, смотреть на нее шире и превращать сырую идею в более полноценное техническое задание. Но есть проблема. Когда ИИ пишет промпт, он часто ведет себя как очень старательный джун, который боится ошибиться и поэтому вписывает в инструкцию вообще все, что приходит в голову. В результате вместо нормального промпта получается тяжеловесный документ с кучей ограничений, запретов, уточнений и повторов. А иногда и с противоречиями. Почему так происходит? Во многом это наследие старого промптинга. Еще полтора-два года назад модели чаще галлюцинировали, хуже держали задачу и требовали очень подробных инструкций. Поэтому люди писали многоэтажные промпты: сначала роль, потом контекст, потом шаги, потом формат ответа, потом список того, что нельзя делать, потом еще десять страховочных условий. Таких промптов за последние годы написали десятки тысяч. Они попали в обучающие данные новых моделей. И теперь, когда вы просите современную модель вроде GPT-5.5 написать промпт, она часто опирается именно на эти старые паттерны. Проблема в том, что сами модели уже изменились. Современные ИИ-системы намного лучше понимают интеллектуальные задачи. Им уже не всегда нужно подробно расписывать очевидный рабочий процесс. Кроме того, их серьезно тренируют на следование инструкциям. Поэтому они относятся к каждому пункту промпта гораздо внимательнее, чем кажется. И вот здесь появляется парадокс. Чем больше лишних инструкций вы добавили, тем выше шанс не улучшить результат, а ухудшить его. Лишняя детализация начинает не направлять модель, а мешать ей работать. Поэтому я не прошу ИИ просто "написать промпт". Я формулирую задачу иначе: Напиши мне промпт для: [описание задачи]. Сначала задай мне вопросы, которые помогут тебе лучше понять задачу. После моих ответов напиши промпт. Сделай его максимально коротким. Включи только действительно важные инструкции. Оставь ИИ максимум свободы в работе. В большинстве случаев этого достаточно, чтобы модель не уходила в избыточную детализацию. Но хороший промпт - это не статичный текст. Его нужно проверять, сокращать и улучшать. Почти как код. Если промпт распух, его можно прогнать через рефакторинг. Например так: Прочитай этот промпт как исполнитель, которому по нему работать. Ответь коротко на три вопроса: - Что в промпте уже работает хорошо? - Чего тебе не хватает для эффективной работы? - Что в промпте лишнее, дублируется, противоречит друг другу, сбивает с толку или ограничивает тебя без необходимости? После этого дай список предлагаемых улучшений. Это универсальный прием. Он работает с промптами, которые написал ИИ. С промптами, которые написали вы сами. И с промптами, которые вы нашли в интернете. Главная мысль простая: ИИ можно использовать для написания промптов. Но не как генератор огромных инструкций на все случаи жизни. А как инструмент уточнения задачи, выявления слепых зон и последующего сокращения промпта до действительно важных требований.

Если интересен такой формат подачи - ставьте реакции ❤️ под этим сообщением. Если нет - 💩 P.S. Приносите свои кейсы в ЛС или в комментариях

Примеры из реальной жизни. Составление простого pinout для сопряжения двух модулей. Есть дисплейный модуль TFT 4.3" и отладочная плата с ПЛИС. Задача простая по формулировке, но неприятная по времени: быстро понять, как состыковать разъем дисплейного модуля с разъемом на плате. На руках были две схемы: Разъем дисплейного модуля TFT 4.3": и разъем IDC40 на отладочной плате с ПЛИС. Проблема в том, что на одной схеме сигналы подписаны функционально, а на другой - как FPGA bank / ball / net-style имена. Вручную это решается просто: берешь номера контактов и составляешь таблицу соответствия. Но в реальной работе на это легко уходит время, особенно если надо не просто посмотреть, а сразу получить аккуратную таблицу для подключения. Что сделал ИИ: - прочитал обе картинки со схемами; - сопоставил контакты по номерам разъема IDC40; - отдельно выделил SPI-часть; - указал, какие линии соответствуют SCLK, CS, MOSI, MISO, BUSY и IRQ; - отдельно отметил важный момент: SPI DIN и SPI DOUT подписаны, вероятно, со стороны дисплейного модуля, поэтому для внешнего контроллера SPI DIN обычно является MOSI, а SPI DOUT - MISO. Это не заменяет проверку по исходным схемам и мультиметру. Но как первый проход для инженерной работы - очень полезно. Типовая экономия здесь в том что он просто быстро сделал механическую, но внимательную работу: - распознал структуру двух схем; - не перепутал четные и нечетные контакты; - собрал таблицу; - выделил критичные сигналы; - указал неоднозначность по направлению DIN/DOUT. В результате инженер быстрее переходит от чтения схем к реальной проверке подключения, написанию constraints для ПЛИС, настройке SPI и запуску дисплея. На мой взгляд, именно такие задачи хорошо показывают практическую пользу ИИ в разработке электроники. Не вместо инженера, а как инструмент для ускорения черновой аналитики, сверки, подготовки таблиц и снижения количества ручной рутины. Пруфы: - https://chatgpt.com/s/t_6a26a1bd347c819181894f904dd82647 - https://chatgpt.com/s/t_6a26a201549081919469fe4c42704119 #примеры

Автор, а ты сам-то чем пользуешься? Логичный вопрос к автору канала про ИИ в инженерии. И вопрос правильный. Если я пишу про применение ИИ в разработке электроники, embedded, системном ПО и QA, то разумно спросить: а чем я пользуюсь сам? Мой текущий рабочий набор такой: 1. ChatGPT 5.5 Pro Использую его как инженерного ассистента для задач, где важны структура, логика и быстрое превращение сырого материала в рабочий артефакт. Например: - продуктовая аналитика требований рынка к электронике; - подготовка тестовых стратегий; - разработка методик испытаний; - составление тест-кейсов; - разбор стандартов индустрии в части разработки и тестирования электроники; - поиск слабых мест и белых пятен; - подготовка черновиков статей и постов; - построение таблиц, чек-листов, матриц трассировки и мое любимое - схем и диаграмм. Это инструмент, который помогает быстрее пройти путь от неструктурированной задачи до документа, с которым уже можно работать. 2. Cursor IDE Cursor использую там, где начинается код и проектный контекст. В основном это: - embedded/Linux; - C; - Python; - bash/shell; - device tree; - userspace-утилиты; - драйверы; - конфиги; который можно потом обернуть в документацию рядом с кодом. В Cursor у меня доступен Claude Opus 4.8. Для задач с кодом он часто удобен, особенно когда нужно не просто сгенерировать отдельный фрагмент, а пройтись по проекту, понять связи между файлами и предложить аккуратные изменения. Но здесь важный момент. Я не отношусь к ИИ как к магической кнопке. - ИИ не заменяет инженера. - ИИ не заменяет ревью. - ИИ не является источником истины. Он может помочь составить методику, но инженер должен понимать, какие риски она закрывает. Он может помочь написать код, но инженер должен проверить, что этот код реально делает на железе. Он может быстро собрать таблицу требований, но инженер должен проверить полноту, трассировку и критерии приемки. Далее, на этом канале я как раз и хочу разбирать не абстрактное "ИИ меняет все", а практическое применение таких инструментов в инженерной работе: от микроконтроллеров и FPGA до Linux, драйверов, QA-документации, тестирования и системной валидации.

Лауреат Нобелевской премии по физике опубликовал новую научную статью, подготовленную при участии Claude: https://arxiv.org/abs/2606.03300 По сути, ИИ помог авторам найти подтверждение исследовательской гипотезы. В статье прямо указано:

Доказательство было получено в ходе взаимодействия с Claude Sonnet 4.6 и Claude Opus 4.7, после чего было проверено авторами.

Claude анализировал дифференциальные уравнения, написал C++ код для поиска решения, а затем сформировал отчет с логическим обоснованием корректности результата. По словам авторов, для одного из ключевых этапов исследования потребовалось около 40 промтов.

PyVISA: управление приборами как входная точка для ИИ PyVISA - Python-библиотека для управления измерительными приборами через VISA/SCPI. Она не относится напрямую к ИИ, но без такого слоя сложно построить AI-assisted hardware lab. Через PyVISA можно управлять всем стеком КИП если у него есть внешний интерфейс управления. Для high-speed testing это особенно полезно, потому что данные должны собираться автоматически и повторяемо. Где появляется ИИ: PyVISA дает ИИ доступ к измерительной инфраструктуре через контролируемый программный слой. Примеры: - AI выбирает следующий режим измерения; - модель оптимизирует sweep; - алгоритм ищет worst-case combination; - LLM-ассистент анализирует SCPI-логи; - anomaly detector проверяет waveform; - система автоматически маркирует подозрительные результаты. Практический пример: при тестировании питания модель видит резонанс в PDN impedance. Она автоматически запускает дополнительный sweep с более плотной сеткой частот вокруг подозрительной области. Инженер получает детализированный участок, а не общий график с пропущенным пиком. Еще пример: при анализе eye diagram модель может управлять температурой, напряжением питания и режимами DUT, чтобы найти область, где margin минимален. Ограничение: ИИ не должен напрямую управлять опасными режимами без guardrails. Для питания, температуры и предельных режимов нужны жесткие ограничения

OpenSIPI: open-source база для SI/PI automation OpenSIPI - один из наиболее близких open-source проектов к задачам signal integrity и power integrity. Его можно рассматривать не как замену коммерческим пакетам уровня Sigrity, HyperLynx или SIwave, а как открытый инженерный слой для автоматизации SI/PI расчетов и извлечения параметров. Где он полезен: - работа с S-параметрами; - извлечение DCR; - автоматизация повторяемых расчетов; - подготовка данных для анализа каналов; - сравнение вариантов топологии или ревизий платы; - построение воспроизводимого SI/PI workflow. Где здесь появляется ИИ: OpenSIPI может быть источником структурированных данных для ML-моделей. Например, можно собрать множество результатов по разным каналам и обучить модель определять риск еще до полной ручной проверки. Примеры AI-сценариев: - классификация канала как Pass / Marginal / Fail; - поиск аномальных S-параметров; - прогноз проблемного участка интерфейса; - сравнение ревизий платы с автоматическим выделением деградаций; - корреляция SI/PI признаков с реальными отказами в тестах. Практическая ценность OpenSIPI в том, что он может стать частью воспроизводимого процесса. Для QA это особенно важно: результат должен быть не просто "инженер посмотрел график", а "метрика рассчитана, сохранена, сравнена с baseline, получен verdict". Ограничение: сам по себе OpenSIPI не является готовой AI-системой. ИИ нужно добавлять отдельным слоем. https://github.com/rivosinc/opensipi

Где реально применим ИИ в разработке и тестировании железа? ИИ в тестировании железа не заменяет осциллограф, VNA, BERT, тепловую камеру или инженера. Его роль более прикладная: обработка большого объема измерений, поиск аномалий, классификация отказов, прогнозирование риска и автоматизация рутинного анализа. Для high-speed интерфейсов это особенно актуально. PCIe, USB 3.x, DDR, Ethernet, HDMI, DisplayPort и MIPI дают большое количество данных: S-параметры, eye diagram, jitter, BER, TDR, impedance profile, логи equalization, результаты compliance-тестов, дампы ошибок драйвера и firmware. ИИ может использоваться в нескольких задачах: - классификация хороших и плохих каналов по S-параметрам; - поиск резонансов и anti-resonance peaks в PDN; - анализ eye diagram и mask violations; - группировка fail modes по логам; - прогноз pass/fail по ранним измерениям; - автоматическое сравнение ревизий плат; - генерация кратких инженерных отчетов; - поиск причин отказа по истории тестов, errata и datasheet. Важно: большинство open-source инструментов сами по себе не являются "AI tools". Они дают данные, расчетный backend или test framework. ИИ обычно добавляется сверху: Python, ML-модель, anomaly detection, RAG, LLM-ассистент, классификатор или оптимизатор. И практический стек может выглядеть так...

Собираем собственный ИИ-офис: нашли инструмент Agent Teams — позволяет запускать целую команду самостоятельных агентов. Агенты будут сами ставить себе задачи, общаться и ревьюить работы друг друга. Пользователю достаточно раздать роли и принимать или отклонять результаты их работы. Можно запускать через Claude, Codex и OpenCode. Делегируем скучную работу ИИ по ссылке.

Привет. Это канал "Инженерная ИИ-шница". Здесь я буду писать о применении ИИ в реальной инженерной разработке: не в формате абстрактных рассуждений о будущем, а через практические задачи, ограничения, ошибки и рабочие сценарии. Фокус канала - электроника и системно-драйверный слой ПО: - микроконтроллеры, периферия, интерфейсы, протоколы; - embedded Linux, device tree, драйверы, BSP, загрузчики; - FPGA, SoC, платы, стенды, bring-up и отладка; - тестирование, валидация, требования, методики, трассировка; - инженерная документация, ревью, анализ логов, схем, даташитов и кода; - применение LLM и других ИИ-инструментов в задачах, где важны точность, воспроизводимость и технический контекст. Мне интересен не ИИ как модная надстройка, а ИИ как инженерный инструмент: где он реально ускоряет работу, где ошибается, где требует контроля, а где пока создает больше шума, чем пользы. В канале будут разборы практических кейсов: как использовать ИИ при анализе схем, подготовке требований, написании тест-кейсов, поиске дефектов, работе с драйверами, генерации документации, прототипировании и исследовании технических решений. Отдельная тема - качество результата. В инженерии нельзя просто получить красивый текст или правдоподобный ответ. Нужны проверяемость, источники, критерии приемки, воспроизводимые шаги и понимание границ применимости. Поэтому здесь будет много про то, как встроить ИИ в нормальный инженерный процесс, а не заменить им инженерное мышление. Если коротко: канал о том, как применять ИИ в разработке электроники и низкоуровневого ПО от микроконтроллеров до тяжеловесных систем, сохраняя инженерную дисциплину, критичность и контроль качества. Добро пожаловать!