Как промпты заменили  разработку слоёв на картах в промышленном IoT. Кейс + немного методологии

Спойлер

Стриминговые сервисы меняют киноиндустрию. Раньше сюжет можно было постепенно разогревать, а теперь все крутые сцены должны быть в начале. (с) Мэтт Деймон

Возможно, Мэтт ничего такого не говорил, Извини, Мэтт!

Пришла идея о том, что простыми промптами можно получать выборки контроллеров по разным условиям и отображать их на карте в нашей проприетарной Цифровой Платформе.

Все сделано все очень просто: интерфейс карты дергает WebHook воркфлоу n8n, AI агенты расшифровывают промпт, запускают соответствующую ветку запросов в API, выдают список объектов для отображения на карте.

Чтобы ускорить работу:

• Сделан проект в Сlaude

• К тому же Сlaude подключен MCP сервер n8n

• Сlaude “научили” делать ноды, чтобы вставлять их в n8n ctrl+V

По ходу работы появилось много инсайтов.

Дальше статья пойдет по классической схеме.

Предметная область

Как было рассказано в предыдущих сериях - мы - продуктовая компания, которая разработала, а теперь производит, внедряет и осуществляет поддержку систем управления освещением. Управления происходит контроллером, устанавливаемым на светильник. Обмен информацией идет по радиоканалу 868 МГц (ISM-диапазон). На 200-300 контроллеров ставится шкаф управления, он же базовая станция. Малая система управления 200 светоточек, средняя - 1 000, максимальная на сегодняшний день - 8 000.

Для простоты можно рассматривать контроллеры и шкафы управления как точки на схеме предприятия или на карте города. И если на схеме для предприятий все просто, размеры цехов до 300-400 метров, установки от 100 до 500 светоточек вполне укладываются в мозг инженеров и пуско-наладчиков.

В городах из-за застройки, больших расстояний, большого количества светоточек - совсем другая история.

Текущая проблема

У нас есть подложка карты от OSM и canvas. Мы рисуем на карте свои слои (рисунок 1). Рисование очередного слоя, во-первых, требует человеко-часов программиста, во-вторых, раздувает кэш на клиенте и делает работу с картой пошаговой стратегией для проектов от 3 000 светоточек и выше. Есть мысли и планы о том как сделать быстро и модно, но рефакторить огромный кусок с кучей слоев (на рисунке они даже не подгружаются) задача, за которую даже браться не хочется. Особенно, если учесть что часть слоев мертва, а часть непонятного статуса и это отдельная организационная история.

В итоге мы “заморозили” слои и учим работать с тем, что есть. Но, в последний месяц, прилетели запросы на то, чтобы отобразить контроллеры с определенным типом светильников и в железе появилась новая функция - таблица соседей, которая позволяет принципиально изменить подход к построению mesh-сети.

Методика решения

Громко назвать методикой подход, который в деталях опишу ниже, видимо, излишне пафосно. Но именно подход и использование новых инструментов, сделавших его, в принципе, возможным, позволил достать с пыльной полки и пустить в работу ряд задач, оказавшихся там из-за своей сложности.

Архитектура

Процесс рисования представляет собой одну петлю:

1. В поле ввода пишется промпт с информацией о том, что показать и с какими параметрами.

2. Промпт, ID обьекта и пользователя отправляется POST запросом в Webhook n8n. Нюанс для n8n: у него есть два типа исполнения воркфлоу - тестовый (для отладки) и публичный. Адреса Webhook у них чуть разные. Поэтому кнопка отправки промпта работает штатно на публичный адрес, с CTRL на тестовый. Отладка божественно упрощается.

3. Воркфлоу n8n выделяет из промпта и истории параметры, классифицирует запрос, выбирает данные и возвращает результат в response

4. Все возвращенные данные отрисовываются на карте.

Схема процесса производства

Мы производим не только контроллеры, но и программное обеспечение как для контроллеров, так и высокого уровня. Процесс производства программного обеспечения не такой многошаговый как в больших IT конторах, но, по сути, похожий.

Очень хочется включить в процесс ИИ, но автоматизация в промке - штука до безумия консервативная. Причем, консервативность наведенная многолетним отрицательным опытом инноваций.

Процесс рисования на карте решили разделить на две части: 1 и 4 - сделали по старинке, а 2 и 3 вынесли в n8n и там возможен не только полный джаз в конфигурации, но и можно заставить играть этот джаз моего личного Добби - программиста на базе Claude.

Обычно, чтобы нарезать код для нод n8n, начинаю новый чат с фразы “консультант n8n”. В этот раз подошел иначе:

1. Создал проект (рисунок 2). В проекте описал архитектуру решения, форматы входа и выхода, нюансы того, как бы я видел адресацию. Добавил пример с удачным JSON, ссылку на документацию по API к нашей Цифровой Платформе.

2. Сделал коннектор к n8n. Теперь Claude видит воркфлоу, и не надо каждый раз забрасывать в него очередную версию.

Первой задачей для Добби было создание JS ноды для генерации тестового JSON чтобы отдать программистам - разработка на java пока еще занимает время.

“Живое” ТЗ

Тема с “живым” ТЗ лично мне заходит. Любая неудачная итерация Claude - повод дописать Instruction:

• Переделали формат выходного JSON - замена раздела.

• Claude изменил вывод, поместив эмодзи на второе место - абзац про это.

То есть, ошибаться можно, но только один раз. Всегда правим первопричину ошибки и едем дальше. В какой-то момент конфигурация из живого ТЗ, проекта Клода и коннектора MCP n8n стала такой, что Добби начал делать сначала две связанные ноды, а потом и три.

В начале процесса освоения n8n каждая нода и взаимодействие между ними - была болью. Потом приноровился, но процесс создания нод ручками - муторный, да и обязательно что-то забудешь, например, execute ones. Теперь ноды, с учетом нюансов, создаются автоматом, щелкать их нужно только в случае ошибок, а, иногда, из интереса и ревью.

Результат

Самая неинтересная часть статьи, на мой взгляд. Все получилось как задумывалось - инструмент с рисованием по промпту заработал. Но это 10% от всей работы, которая задумана. Теперь нужно разработать методики его применения и отдать в массы.

Кратенько по структуре воркфлоу (рисунок 3):

1. Первый агент выделяет параметры, второй классифицирует вопрос, чтобы потом отправить его дальше. Навыки от Anthropic рекомендуют паттерн с одним агентом, но мне очень понравилось с двумя.

2. Нюанс n8n, что он выводит результат с невалидным JSON. Приходится подчищать формат нодами CODE. Вообще, накопилось много подобных нюансов, возможно, не до конца понял концепт авторов.

3. Дальше нода Switch разбивает запрос пользователя на запросы к API с параметрами и формат результата. В ней запрос недостающих параметров и ответ на запрос помощи объединены.

4. Каждая нитка запросов к API заканчивается нодой CODE для форматирования разнородных входных данных в принятый для рисования на карте JSON.

5. Навыки по паттернам работы с n8n выдали красное заключение о том, что нет обработки ошибок. Считаю, раз эти воркфлоу даже не агенты - пока заморачиваться нет смысла. А строить настоящих автономных агентов на n8n - надо в очередной раз вывернуть мозг наизнанку.

Инсайты

Архитектура

Разделение извлечения параметров и классификации

Правильно разбить работу между агентами - отдельный вид искусства. Пока использую простое правило: как только ощущаешь картезианский эффект в промпте - разбивай. Например, изначально был один Агент: Классификация, который проводил классификацию, выбирал из промпта параметры и просил уточнений при недостатке параметров. В какой-то момент промпт начал активно раздуваться, а Агент начал глючить из-за противоречивых инструкций внутри.

Я уже начал прицеливаться Клодом к поиску противоречий, но понял, что надо его попросить разделить функции агентов: Выделение параметров и Классификация, Клод отлично справился (с третьей попытки).

Добавление слоев

Mesh-сеть мы создаем вручную. Давайте оставим за рамками данной статьи причины и детали. Процесс создания итеративен. Если очень грубо:

• Выясняем кого слышит базовая станция в прямой слышимости (0 прыжков)

• У лучших претендентов на ретрансляторы 1 прыжка включаем и смотрим списки соседей

• Анализируем эти списки так, чтобы они перекрывались, но не сильно.

• Ставим ретрансляторы

• Заходим на следующий виток

В результате на карту надо вывести много разных эмодзи, цветов, цифр, собранных в результате разных запросов к API.

Долго прикидывал как мне собирать результаты выполнения воркфлоу и выводить на карту так, чтобы поиграть вариантами. Вывести результаты одного цикла воркфлоу - элементарно. Вывести некое объединение - непосильная задача.

Пришло решение: промпт - слой и пусть живут все результаты. Включаешь/выключаешь слои - играешь. Совсем неудачные - удаляешь. Красивый результат - в работу. А красивый результат - перечень, оставшийся на карте промптов. Его можно отправить пуско-наладчикам. Или роботу (но я этого не говорил).

HELP

По опыту, созданный функционал, всем очевидный сегодня - завтра забыт, непонятен и удивляет. Серфинг по документации решает проблему, но с трудом.

На мой взгляд, добавить в промпт пару фраз о том что если пользователь запутался и просит помощь - расскажи что ты можешь это и то - элегантное решение.

Очевидно, это поможет пользователю освоить инструмент или освежить навыки использования.

Неочевидно - эта, казалось бы, несущественная петелька логики добавляет целый пласт узоров вероятности в мир высокоуровневого ИИ Claude:

• Как проявляется: Клод отразил это, например, в skill.md

• Как повлияет на процесс: пока сложно оценить. Как минимум, теперь Клод будет рекомендовать поддерживать этот help, или делать это сам.

Работа с Claude

Автогенерация нод в n8n

Буду честным - сегодня всего год как задал первый вопросы DeepSeek, всего 3 месяца как использую n8n. А еще я максимально не программист, к примеру, если требуется заменить $input на $first() - вскипает злость, в том числе потому, что надо менять что-то без скобок на что-то со скобками. Дописать строку кода никогда не получалось.

Днями, обратив внимание на много слов про MCP в очередной версии n8n, решил попробовать. Все виделось как фраза “добавь такие-то ноды” на экране с Клодом и появление этих нод на соседнем экране с n8n. Пока подключал коннектор и разбирался в деталях настройки, думал о том какие же ребята из n8n волшебники!

Реальность оказалась печальной, думаю, как и в 95% других MCP серверах. За десятилетия мы научились делать программы удобными для человека, а вот сделать их удобными для ИИ - отдельная своеобразная задача.

Но ребята из n8n - крутые! Воркфлоу - JSON. Когда визуальные ноды копируются в буфере это JSON с кусочком. Осталось попросить Клода сделать ноду в JSON и копипастнуть на холст n8n. Но… нет. Клод упорно генерировал ноды, которые не вставлялись в воркфлоу. Разбираться в причинах не стал.

Помогло то самое живое ТЗ. Копипастнул в него примеры JSON, скопированные из воркфлоу, и попросил делать ноды так.

Случилось ЧУДО - теперь ноды, созданные Клодом, красиво пастятся в воркфлоу.

Документация на API

Подложил этот файл потому что в проекте Клода есть место и файл с примером JSON смотрится одиноко. Немного иррациональности. Но, сразу порадовался:

• Если воркфлоу через MCP коннектор Клод видит то параметры, передаваемые между узлами - для него тема закрытая. Приходилось копировать эти JSON в консоль для итерации со следующей нодой.

• А тут клод попросил уточнить как связать параметры из API и в выходном JSON. Считай, минус итерация а то и две.

Skill.md

У меня уже есть инженеры, которые больше не пишут код. Модель пишет. Они редактируют, направляют, проверяют — но руками кнопки жмут уже не они. Шесть-двенадцать месяцев, и модели будут делать всю работу software engineer от начала до конца. Не ассистировать, а полностью, взаправду делать (С) Амодеи в Давосе по версии с Хабра

Если добавление документации по API дало такой инсайт, то что еще можно подложить? Вопрос Клоду: “Расскажи о skill.md”.

А дальше произошло то (рисунок 4), что в этой статья я не готов оценить.

Коллеги, на мой взгляд, детали в данном случае важны только для погруженного в мой треш. В целом, с точки зрения IT проектного менеджера со стажем в четверть века, Клод в этом файле отразил все болевые точки, которые уже подсвечивались в моем мозгу при создании этого воркфлоу и конструкции вокруг него:

• Одновременное сопровождение двух промптов в разных АИ агентах

• Синхронизация Агента по выделению параметров, Ноды с их форматом и ноды Switch

• Вывел рядом все эмодзи для отрисовки на карте и выглядят они кринжово. А еще написал рекомендацию “подбирайте эмодзи с умом”

Skill.md файл, однозначно, должен быть приложен к проекту, пусть после доработки.

А еще есть библиотека n8n-skills. Отдельная, пока не понятная, история.

n8n-skills

Помните как я научил Клода через системный промпт проекта делать узлы, которые можно копировать прямо в холст вокфлоу. Так вот, подумав про skillы, задал простой вопрос как использовать скилы в проекте. Оказалось, что все о чем подумал - уже сделано: Скачиваем файл n8n-skills.zip, в котором лучше практики работы с n8n от Anthropic (рисунок 5). Навыки можно загружать, а можно создать свой.

Все навыки в ZIP архивах. Видно, что штука сырая, файлы-файлы. Но реактивный двигатель только включился и мы даже не оторвались от стартового стола.

Философия подхода

Отчеты с коротким временем жизни

Стройте “Жидкие” инструменты (c) Альтман

Пока Клод крутил очередную задачу, пришла такая мысль: раньше мы относились к отчетам как к вещам. Так как каждый отчет требует подумать и поработать, то и подход к нему как дорогой вещи:

• Покупается/создается только когда очень нужно

• Потом висит в пунктах меню долгую жизнь, собирая пыль и рантайм ошибки.

Теперь отчет можно создавать если не промптом, то достаточно простой комбинацией инструментов. 20-30 минут диалога с подготовленным Клодом и отчет готов. Также можно пофантазировать о том, как настроить Клода, чтобы он мог сделать любой отчет из промпта. А потом настроить на такой функционал DeepSeek или локальный qwen.

Заключение

Лично для себя делаю открытие за открытием. Какие-то инструменты совсем новые (MCP n8n), что-то уже существовало.

Моя профессиональная жизнь состоит из процесса декомпозиции целей в задачи для коллектива. Сотня-две задач в месяц. Заканчивается блок задач - достигается цель.

Появилась возможность вставить в пул задач исполнителей на базе ИИ. Им нужно ставить задачи немного по другому, но в общую схему они отлично укладываются. И дальше будет только проще.

Пока все что создается даже не автономные агенты. Не укладывается в мозг архитектура того как можно отдать автономным агентам задачи по манипуляциям с промышленной автоматизацией. Однако, присматриваюсь к moltbot.

Планы

Тут планы применительно к статьям. У меня есть два кейса:

• Как мы внедряем Claude code. История о том как удивляет программистов ИИ робот.

• ИИ в музыке. Моя супруга певица, поэт и композитор. И ей в руки дали SUNO

Пишите в комментариях куда вильнуть.