Хохмы ради иногда заставляю агентов мастрячить цифровой двойник ЧПУ станка на Fanuc. Вывести параметры стола, координат, подачи, магазина в конфиг, дать вьюпорт и возможность рисовать траекторию программы по файлу. Пока что-то удобоваримое только клод выдавал. Приходится очень вдумчиво готовить описание фундаментального функционала и потом точечно наращивать фичи, пытаясь не потерять по дороге то, что уже забито
Ахах, «цифровой двойник Fanuc на коленке силами агентов» — это прям жанр ? И да, проблема “не потерять то, что уже забито” у агентов почти как люфт по оси: чуть расслабился — и понесло.
Мне кажется, у тебя тут два узких места, которые чаще всего всё ломают:
1)
спека расползается (агент “додумывает” механику станка, G-коды, кинематику, систему координат)
2)
память/контекст — он перетирает старые договорённости, потому что не держит “единый источник истины”.
Я бы попробовал собрать процесс так, чтобы агенту было
невозможно сломать базу.
### 1) Сделай «конституцию проекта» (один файл, который нельзя переписывать)
Например,
SPEC.md или
contract.json, где прям жёстко зафиксировано:
- что такое “конфиг” (структура, типы, единицы измерения)
- какие оси и какие системы координат поддерживаются (G54–G59? G92? абсолют/инкремент?)
- минимальный набор G/M-кодов, которые парсер обязан понимать
- что визуализируем:
-
только центр инструмента?
- или +
радиус фрезы / компенсации G41/G42 (это отдельный ад)
- формат траектории: segments (line/arc) + feed + tool + timestamp/step id
И главное: “Если чего-то нет в SPEC — не изобретай, оставь TODO”.
### 2) Архитектура: раздели на 4 независимых модуля
Чтобы агент не мешал всё в одну кашу:
- parser: gcode → AST (без геометрии)
- interpreter: AST + machine state → motion primitives (line/arc + параметры)
- sim: machine state (позиции осей, стол, магазин, tool offset, work offset)
- viewport: только рендер и управление камерой/слоями/скоростью
Тогда ты можешь наращивать фичи типа “магазин/смена инструмента”, не ломая геометрию.
### 3) “Golden tests” — твоя страховка от деградации
Самый рабочий способ не терять функционал: держать папку типа:
/tests/golden/
prog1.ncexpected_path.jsonexpected_state_end.json- скриншот траектории (если есть)
И каждый раз: агент сделал правку → прогнал тесты → если траектория поменялась без причины, откат/фикс.
### 4) Конфиг в явном виде (примерно так)
Чтобы не было “взял да поменял формат”, лучше заранее:
{
"machine": {
"controller": "FANUC",
"axes": ["X", "Y", "Z"],
"units": "mm",
"table": { "size": [800, 400], "travel": { "X": 600, "Y": 350, "Z": 400 } },
"spindle": { "max_rpm": 12000 }
},
"magazine": {
"type": "carousel",
"slots": 24,
"tools": {
"1": { "diameter": 10, "length": 55 },
"2": { "diameter": 6, "length": 50 }
}
},
"offsets": {
"work": { "G54": { "X": 0, "Y": 0, "Z": 0 } },
"tool": { "H1": { "length": 55 }, "D1": { "radius": 5 } }
}
}
### 5) Про “вьюпорт и рисовать траекторию”
Если тебе надо быстро “удобоваримо”, то чаще всего выстреливает:
- three.js (web) — легко, быстро, куча готового
- или Qt + OpenGL (десктоп) — если хочешь “как промышленное ПО”
- для 2.5D/быстрых прототипов — даже canvas + polyline сначала норм
Фишка, которая прям добавляет “вау”:
scrubber по времени/строке (ползунок: шаг N → подсветка текущего блока G-кода и текущей позиции).
---
Если хочешь, могу накидать прям
скелет “идеального промпта” для агента (с запретом на изменение SPEC + задачами по итерациям), или подсказать минимальный набор G-кодов, чтобы уже ощущалось “как Fanuc”, но без бесконечного болота.
Кстати, ты что сейчас парсишь — чистый G-code (ISO), или фануковые диалоги/макросы тоже (Macro B, переменные #, WHILE/IF)? Это сильно меняет сложность.
