Лишнее обозначение — и снова проверять каждый лист.
Заказчик исправлял спецификации в nanoCAD вручную. Я подготовил LISP-скрипт для согласованных изменений конкретного DWG и подробную инструкцию для новичка. На работу ушло восемь активных часов за два календарных дня. Комплект приняли 30 сентября 2026 года.
Главная деталь обнаружилась в устройстве чертежа: легенда состояла из текста, блоков и геометрии. Обычной таблицы там не было. Как убрать из спецификации лишнее и добавить недостающее, если сначала ещё нужно установить, что относится к каждому листу?
В спецификации должны остаться обозначения своего листа
Ко мне пришли с повторяющейся ручной операцией. Спецификации приходилось исправлять лист за листом: сверять содержимое, убирать лишние обозначения, добавлять отсутствующие. При таком обходе легко пропустить лист.
Если коротко, от меня требовалось:
- Проверить, какие обозначения действительно есть на каждом листе.
- Оставить в его спецификации только относящиеся к нему позиции и добавить недостающие.
- Подготовить подробную пошаговую инструкцию, с которой сможет работать новичок.
Последний пункт влиял на состав сдачи. Одного текста программы заказчику было недостаточно: требовалось объяснить запуск и последующую проверку. Это отдельная часть работы, которую легко не заметить за коротким словом «скрипт».
В разработке под конкретную рабочую операцию мне важно сначала определить, какое действие человек повторяет. Здесь оно было вполне предметным: сопоставить лист и его спецификацию. Но из этого ещё не следовало, что все решения можно принять автоматически.
Для согласованных правок выбрали один из двух DWG
29 сентября я получил два реальных DWG: первоначальный чертёж и образец. Затем именно образец выбрали целевым файлом. Это существенно для всей истории: работа шла с определённым документом, устройство которого я разбирал.
На исходной модели листа A1 видна схема газопровода с выносками. По такому материалу можно разбираться, как связаны обозначения и содержимое листа. Но сам вид схемы ещё не отвечает на вопрос, какие позиции нужно оставить в спецификации.
Я начал с легенд, блоков и обозначений, затем сопоставил их с листами. Здесь название «спецификация» описывало назначение фрагмента чертежа, а не гарантировало удобный формат данных.
После уточнений объём работы ограничили согласованными изменениями выбранного DWG. Универсальное распознавание любых чертежей в него не входило. Поэтому я мог опираться на разобранную структуру этого документа и решения заказчика, не обещая, что тот же подход без изменений подойдёт другому проекту.
Легенду пришлось разбирать как набор объектов, а не таблицу
Внутри легенды были объекты TEXT, блоки и геометрия. Для ручной правки они находятся в одном рабочем контексте. Для программы это разные сущности, связь между которыми нужно установить до изменения документа.
Из-за этого работа не сводилась к удалению строк по готовому списку. Сначала требовалось сопоставить обозначения с листами и отделить понятные позиции от неоднозначных. Если пропустить этот этап, программа просто повторит неверно выбранное правило.
Я подготовил диагностические пилоты, которые не вносили изменений в чертёж. Их роль была подготовительной: разобраться в содержимом перед правками. Подготовка этих пилотов зафиксирована, но отдельная отправка заказчику не подтверждена. Поэтому я не считаю их самостоятельными раундами сдачи.
Спорные позиции я вынес на уточнение. Здесь полезно различать два вопроса: «что находится в DWG» и «как заказчик хочет это исправить». Разбор объектов помогает ответить на первый. Для второго понадобились решения человека, который задавал требования к документу.
Согласование определило правки по В2, Г2 и Д1
30 сентября я продолжил аудит. В 19:41 были зафиксированы решения заказчика. После этого внёс в LISP согласованные изменения по В2, Г2 и Д1.
Точного перечня удалённых и добавленных позиций в доступных материалах нет. Поэтому я могу назвать эти обозначения как часть согласования, но не могу достоверно расписать, что именно изменилось в каждом случае.
Лист, по которому ответа не было, я оставил без изменений. Это и был рабочий компромисс: выполнить подтверждённую часть, сохранив неопределённую. Отсутствие ответа не становилось разрешением выбрать вариант на своё усмотрение.
В скрипте я предусмотрел UNDO для отмены изменений и контроль целевого файла. Обе меры соответствовали масштабу заказа. Мы договорились о правках конкретного DWG, поэтому инструменту требовалось учитывать именно эту границу и давать возможность отмены.
Детали реализации этих проверок я здесь не восстанавливаю: сам сданный комплект недоступен для повторного изучения. По рабочим записям подтверждено наличие этих мер, а не точный текст каждой проверки.
На проверку ушёл один подтверждённый комплект со скриптом и руководством
В доступной истории есть один подтверждённый раунд отправки актуального комплекта. Это первая ревизия: LISP и подробное руководство для новичка, собранные в ZIP. Я передал её 30 сентября примерно в 19:51–19:52.
Перед отправкой проверил структуру LISP и состав архива. Все согласованные правки вошли в комплект. Инструкция входила в сдачу вместе со скриптом: заказчику нужны были и сами изменения, и понятный порядок работы с инструментом.
В записях также отмечен ранний архив, который был отменён. Причина отмены, его содержимое и отдельная реакция заказчика не раскрыты. Я не могу превратить одно упоминание в рассказ о дополнительном цикле правок. Актуальной сдачей была первая ревизия.
После неё в 19:59 заказчик подтвердил положительный результат. В 20:01 заказ был закрыт. Последующие исправления после этой отправки в источниках не описаны.
Так выглядит подтверждённая последовательность: разбор исходников, уточнение спорных позиций, внесение согласованных решений, отправка комплекта и приёмка. Количество промежуточных сообщений и пересылок из этих данных восстановить нельзя.
Приёмка подтверждена, отчёта о запуске нет
У себя я проверил структуру программы и состав архива. Это статическая проверка. В nanoCAD скрипт я у себя не запускал: проверка в самой программе оставалась за заказчиком.
Его положительный ответ и закрытие работы — факты приёмки. Но воспроизводимого отчёта запуска нет. По ним нельзя установить, какие команды он выполнил, сколько листов проверил и как именно оценивал изменения.
Поэтому я не заявляю, что лично прогнал скрипт в nanoCAD на всех листах или доказал его работу на любых DWG. В этой истории подтверждены согласованный объём, передача комплекта и положительный ответ заказчика. Для более широких утверждений потребовались бы другие данные.
Две картинки выше показывают исходную модель и исследование легенды. Они помогают понять материал, с которым я работал. Снимка готового чертежа после обработки среди доступных материалов нет, как нет и самого сданного архива для повторной проверки. Показывать эти изображения как «до и после» было бы неверно.
Есть и граница по эффекту: данных о замерах ручной обработки до заказа и после него у меня нет. Я не могу назвать подтверждённое число сэкономленных часов, снижение ошибок или частоту использования скрипта. О завершённом заказе я могу говорить увереннее, чем о его дальнейшей эксплуатации.
Восемь часов включали разбор, согласование и инструкцию
Оценка активной работы — восемь часов. Она распределилась так:
- Около трёх часов — разбор нетиповой легенды и листов.
- Ещё три — диагностика и LISP.
- Два — уточнённые правки, упаковка и инструкция.
Это оценка работы, а не поминутный хронометраж. Календарно заказ занял 29 и 30 сентября: в этот промежуток входило ожидание исходников и решений заказчика. Восемь часов не означают восемь часов подряд от первого сообщения до приёмки.
В этих восьми часах написание программы было только частью работы. Сначала я разбирался в документе, потом уточнял допустимые изменения и готовил инструмент под согласованные решения. Руководство и упаковка тоже входили в сдачу.
Неотвеченный вопрос стал границей автоматической правки
Для меня ценность этого кейса — в том, где удалось провести границу. В спецификациях была повторяющаяся работа. При этом некоторые позиции требовали решения заказчика. Я автоматизировал согласованную часть и сохранил лист без ответа.
В портфолио такой заказ полезен своей конкретикой: можно показать исходный материал, объяснить устройство легенды, восстановить согласование и назвать пределы проверки. При этом не приписывать небольшому инструменту универсальность или экономию без подтверждающих замеров.
Самой показательной деталью для меня остался неизменённый лист. Скрипт готовился для правок, а в одном месте правильным действием было дождаться определённости и ничего не менять.
больше разборов в канале t.me/botvinovprod напишите мне в тг @botvinov