
Комментарии 5
Если задачи разбить по отдельности, то ИИ способен их выполнить. Но опять же ему нужен образец к которому он будет обращаться.
Для изолированных рутинных участков не ловчее ли будет не прикручивать ИИ вовсе, а обойтись скриптом?Я к тому, что сами "3d-модели" это по количеству потраченной "казацкой силы" - ноль целых хрен десятых. А вот некоторые этапы бумажного согласования с 25 важнейшими "нужна подпись этого хрена, который даже глазиком не посмотрит, темой не владеет и вообще говоря вероятно лишний" - вот тут повторяющий инженерный процесс, который занимает слишком много ручного времени.
На текущем этапе, ИИ кажется мог бы быть значительно полезным при работе с тоннами документации и прочими тех.инструкциями, или же быть интегрирован в CAD-систему аки Cursor.
Хорошая архитектура — разделение Python и C# вполне онятно и оправдано, компиляция перед исполнением как фильтр ошибок агента работает элегантно.
Сейчас агент получает выжимку из API-документации вручную. Следующий шаг — сделать этот контекст динамическим: агент сам запрашивает только те методы, которые нужны для текущей задачи, исходя из структуры модели. Это снизит токены и уберёт зависимость от того, насколько точно человек заранее отобрал релевантные куски.
И еще — валидация. Компиляция ловит синтаксические ошибки, но не семантические: агент может построить геометрически корректный объект, который инженерно бессмысленен. Даже простая проверка по справочнику допустимых типоразмеров на выходе сильно повысила бы надёжность.
И kilokanat точно подметил: геометрия — это быстрая часть. Настоящий узкий участок — работа с документацией. Паспорта, исполнительная документация, журналы — всё это существует в нечитаемом виде и не связано с моделью. Агент, который умеет строить геометрию в CAD, но не знает, что за прибор стоит на этой позиции и какой у него регламент обслуживания — решает только половину задачи.
Как мы интегрировали AI агентов с T-FLEX: отказ от абстракций и самопроверка моделей