Немного обо мне.
Я не профессиональный разработчик. Последние несколько лет занимаюсь электрикой в разных её проявлениях: от различного монтажа до сборки промышленных шкафов. Мой IT‑стек до недавнего времени это: микроконтроллеры ESP32, прошивки, которые помогал писать искусственный интеллект, чтение Хабра и статьи на Лурке. Но одна производственная задача постепенно заставила меня разобраться в Python, библиотеках, фреймворках, интерфейсах, деплое и публикации кода. Речь о маркировке проводов,кабелей и приборов по конструкторской документации.
С чего все началось.
Однажды я попал на сборку шкафов автоматизации где сборка велась по бумажной конструкторской документации (далее КД) и был приятно удивлен когда маркировочный материал для всего многообразия обозначений нужно было набивать вручную. Спасал Excel макрос, который помогал расставлять разделители и переворачивать бирку для «обратно гнездовой маркировки»
Оператор по очереди вводил прибор, контакт и вторую сторону соединения. На одном адресе всё выглядит просто. На нескольких сотнях ручной ввод превращается в отдельную производственную операцию и в некоторых сборочных командах за это отвечал специально обученный человек.
Когда бирки понадобились снова.
Немного поупражнявшись на сборке меня отправили на интеграцию этих шкафов на производство где происходила финальная подгонка шкафа под задачи производства. Где‑ то приходилось менять внутришкафную коммутацию, ставить новые приборы, менять клеммные группы и для всего этого снова понадобилась маркировка!
Печатать нужно было на разных принтерах, которые принимали каждый свой формат данных: csv или excel. И монтажник однажды сев набивать бирки за рабочий ноутбук просидел там 3 дня. На ноутбуке, помимо рабочих программ, были установлены такие важные приложения, как Heroes of Might and Magic III и Counter‑Strike 1.6. Эти дни пришлось обходиться без них. Тогда я окончательно понял, что с этим надо что‑то делать! Не обязательно автоматизировать весь процесс. Даже сокращение числа ручных действий уже дало бы заметный результат.
Первая попытка научить ии понимиать КД.
Сначала я попробовал самое очевидное: скармливал ИИ небольшие фрагменты конструкторской документации. Убирал лишнюю информацию, прикладывал пример готовых бирок и объяснял, какой результат хочу получить.
Идея была простой: модель увидит фрагмент схемы и по аналогии разберёт остальные. На практике надёжного результата не получилось. ИИ находил отдельные надписи, приборы, клеммы и контакты, но не всегда понимал, что именно с чем соединено. Я даже думал о дообучении модели. Потом DeepSeek предложил более приземлённый вариант: написать специализированный парсер на Python.
Python. Начало.
Я сначала засомневался ведь мой it стек был минимальным, но решил попробовать. В чате с DeepSeek появилась первая версия кода которую я пересохранил в файл, докачал библиотеки и в какой то момент она заработала!
Программа извлекала данные, расставляла двоеточия и косые черты, экспортировала результат в Excel и CSV для двух принтеров. Заодно она выдавала много чепухи. Но код запускался, интерфейс реагировал, а результат формировался хоть и не тот. Для человека, который недавно почти не представлял, как устроено Python‑приложение, это было сильное впечатление. Тогда же я познакомился со Streamlit. После запуска программа открывалась в браузере и выглядела как сайт. Для прототипа это оказалось удобно: можно быстро добавить загрузку файлов, кнопки, поля и отображение страниц PDF, не создавая отдельный оконный интерфейс. Позже приложение так же быстро удалось запустить на VPS.
У удобства была цена. Streamlit — не графический редактор. Свободное перемещение схемы мышью, привычное масштабирование колёсиком, drag‑and‑drop и постоянно закреплённую панель управления реализовать так и не получилось. Пришлось использовать ползунки масштаба и перемещения и искать иные обходные пути.
Синергия.
Я никак не мог получить желаемый результат и вдруг понял что хочу от программы слишком много. Я пытался заставить её самостоятельно понять PDF, найти элементы, восстановить связи и сразу подготовить правильный результат. И тут я понял что забыл об операторе, которого можно немного нагрузить для помощи машине. Связать интеллект и машину в одно целое тем самым давая пинок в правильном направлении. Пусть оператор сам выбирает прибор и его клеммы на чертеже в нужном порядке, а машина соберет из этого то что нужно. Это оказалось практичнее полной автоматизации. Программе не обязательно понимать весь чертёж. Достаточно быстро и без ошибок сделать то, что раньше сотни раз повторялось вручную.
Первая рабочая версия
С этой идеей я пришёл в бесплатный чат Claude, передал ранние наработки и описание задачи. Довольно быстро появился интерфейс с отображением чертежа и обработкой кликов. Можно было открыть схему, выбрать на ней обозначения и получить собранный адрес в поле ввода.
Дальше началась обычная итерационная разработка. Днём я гонял приложение на рабочих схемах, записывал проблемы и новые идеи. Вечером возвращался к проекту и прорабатывал балансируя на грани лимитов бесплатных тарифов.
Функции появлялись не потому, что хорошо смотрелись в описании проекта, а потому, что экономили действия. Если часть адреса повторяется, её надо сохранить. Если для сохранения приходится каждый раз тянуться к кнопке, пригодится двойной клик. Если одна бирка — обратная сторона другой, вводить её второй раз незачем.
В результате RapidTag научился:
-
показывать страницы PDF‑схемы
-
собирать адреса кликами по обозначениям
-
автоматически формировать обратную бирку
-
работать с парными и одиночными бирками
-
создавать серии повторяющихся бирок в пакетном режиме
-
запоминать общие части адреса
-
редактировать результат прямо в интерфейсе
-
экспортировать данные в форматы для разных принтеров
-
отсекать артефакты
Я с самого начала понимал, что программа не будет идеальной. В PDF встречаются необычные символы, нестандартные разделители и сочетания, которые невозможно предусмотреть заранее. Поэтому сформированную бирку можно исправить прямо в окне RapidTag.
Проскролив вниз видим сохраненные позиции и можем выбрать формат для скачивания.
В настройках можно выставить разделители внутри бирки под задачи проекта. «Автоподсказка второго конца» и «Игнор лист» это тестовые функции не проявившие себя но оставленные.
Вот один из вариантов готовых бирок. В начало добавляется название КД с которой печатался массив (тут шкаф PD-1001) для удобства ориентирования.
Какую роль сыграл ИИ.
Основную. На разных этапах я использовал несколько инструментов. DeepSeek помог обсудить задачу, собрать первые варианты парсера и искать причины ошибок. Claude — перейти к рабочему интерфейсу с отображением схемы и кликами. Позже я работал в Visual Studio Code с Cline: вносил изменения в файлы, отлаживал приложение, приводил проект в порядок и готовил публичную версию. Но сказать, что ИИ самостоятельно создал RapidTag, было бы неправильно. Модель не знала, как монтажник читает схему, какие бирки нужны на производстве, какие форматы принимают принтеры, где ошибка недопустима и какие действия на самом деле отнимают время. Даже подходящую задержку двойного клика пришлось определять на практике.
В итоге.
RapidTag — не промышленная система, которая без участия человека распознаёт любую электрическую схему. Это рабочий MVP: оператор показывает нужные связи, а приложение забирает себе рутину вокруг них.
У текущей версии есть ограничения. Результат зависит от устройства PDF, доступности текстового слоя, шрифтов и графики. Некоторые обозначения приходится исправлять вручную. Из‑за Streamlit нет идеального масштабирования мышью, полноценного drag‑and‑drop и графического интерфейса того уровня, который можно было бы получить на другом стеке.
Публичная версия.
Я подготовил публичную копию проекта для локального запуска. Исходный код RapidTag v2.1.0 опубликован на GitHub.
Проект распространяется под лицензией MIT. Его можно скачать, запустить на Windows и попробовать на своих PDF предварительно установив python.
Заключение.
Я начинал не с желания стать программистом. Мне просто надоело повторять одну операцию тем более имея на руках электронные версии КД.
Сначала я пытался заставить ИИ полностью разобраться в схеме с помощью промптов‑ не получилось. Затем написал парсер — волшебной кнопки тоже не появилось. Рабочим оказался человеко‑машинный вариант: оператор принимает решения, программа выполняет рутину.
Для меня ИИ прежде всего снизил порог входа в разработку. Я не стал профессиональным программистом, но смог сформулировать требования, собрать прототип, проверить его на реальной задаче, отладить и опубликовать.
Теперь специалист, который хорошо знает свою предметную область, может сделать узкий инструмент под собственную работу, даже если раньше его it опыт ограничивался чтением технических статей. Но думать и проверять результат всё равно придётся.
Автор: ProtonFrog
