Проблема, которая съедала 40 часов в неделю
Представьте цех сборки световых контроллеров. Каждый день с конвейера сходит 500 штук. Каждый контроллер нужно проверить по 12 параметрам: напряжение на выходе, корректность ШИМ, работа сенсора освещённости, связь по Modbus. В теории - простая задача для любого электронщика. На практике - адский конвейер человеческих ошибок.
Завод терял 3% продукции из-за брака, который пропускали контролёры. Это 15 контроллеров в день, 300 в месяц. При стоимости одного контроллера в 8 000 рублей - 2,4 миллиона рублей ежемесячных убытков. И это только прямые потери, без учёта репутационных.
Три контролёра работали в три смены. Каждый со своей методикой проверки. Один слишком строгий - бракует рабочие образцы. Другой слишком лояльный - пропускает явный брак. Третий вообще записи в журнал вносит как попало. Стандартизировать их работу пытались годами. Не вышло.
Решение, которое выглядело как фантастика
Когда клиент пришёл к нам, его требование звучало просто: "Сделайте так, чтобы контролёры не ошибались". После недели анализа мы предложили радикальное: убрать контролёров вообще. Заменить их AI-агентом на базе Claude Projects с использованием последней версии Claude 3.7 Sonnet (актуальной на январь 2026).
Архитектура получилась такой: физический стенд проверки с веб-интерфейсом + Claude Project как мозг системы. Стенд сам подключает контроллер, подаёт питание, измеряет параметры. Claude анализирует результаты, принимает решение "брак/не брак", заносит в базу. Весь процесс - 45 секунд вместо 3 минут ручной проверки.
1 Подготовка Claude Project: не просто промпт, а целая система
Первая ошибка, которую совершают 90% инженеров: пытаются запихнуть всю логику в один промпт. Это не работает. Claude Project нужно структурировать как полноценное приложение.
Мы создали три слоя:
- Слой знаний - документация на контроллеры, ГОСТы, технические регламенты. Все в формате .md файлов, загруженных в проект
- Слой логики - пошаговые инструкции проверки каждого параметра с допустимыми отклонениями
- Слой интеграций - настройки для работы с API стенда и производственной БД
| Компонент | Что делает | Технология |
|---|---|---|
| Физический стенд | Подключение контроллера, измерения | Python + FastAPI |
| Веб-интерфейс | Визуализация процесса для оператора | Vue.js + WebSockets |
| Claude Project | Анализ данных, принятие решений | Claude 3.7 Sonnet API |
| База данных | Хранение результатов, статистика | PostgreSQL |
2 Интеграция с физическим миром: где теория встречается с реальностью
Самый сложный момент - заставить Claude работать с "железом". Стенд имеет REST API, но ИИ не понимает, что такое "подать 24В на клемму 5". Нужен переводчик.
Мы создали прослойку - набор Python-функций с чёткими сигнатурами. Claude вызывает их через инструменты (tools) в Projects. Каждая функция имеет:
- Чёткое название на английском (apply_voltage, measure_current)
- Подробное описание параметров
- Обработку ошибок с человекочитаемыми сообщениями
Важный нюанс: Claude 3.7 Sonnet, доступный в январе 2026, имеет значительно улучшенную работу с инструментами по сравнению с предыдущими версиями. Он лучше понимает контекст вызова, правильно формирует JSON и корректно обрабатывает ошибки API.
3 Обучение без обучения: как мы настраивали критерии проверки
Тут многие ждут магии: "загрузите данные, ИИ сам всё поймет". Не поймёт. Нужно явно описать правила.
Мы пошли другим путём: взяли 1000 записей ручных проверок (300 брак, 700 норма) и заставили Claude анализировать их. Не для обучения в ML-смысле, а для выявления паттернов. Claude сам предложил уточнить критерии:
{
"voltage_output": {
"nominal": 24.0,
"tolerance": 0.5,
"measurement_points": [1, 3, 5, 7],
"stability_time_sec": 2
},
"pwm_signal": {
"frequency_hz": 1000,
"duty_cycle_range": [10, 90],
"rise_time_ms_max": 5
}
}После трёх итераций уточнений мы получили критерии, которые покрывали 99% случаев. Оставшийся 1% - пограничные ситуации, которые Claude теперь эскалирует оператору.
Что пошло не так (и как мы это фиксили)
Ошибка №1: Claude слишком буквально понимал инструкции. В документации было: "подать напряжение 24В ±5%". Claude отклонил контроллер с напряжением 24.1В (это 0.4% отклонения). Пришлось явно указывать: "используй здравый смысл, отклонения до 1% игнорируй".
Ошибка №2: задержки в API. Физический стенд иногда отвечал 2-3 секунды. Claude по умолчанию ждал 30 секунд, что замедляло проверку. Настроили таймауты и retry-логику.
Ошибка №3: человеческий фактор никуда не делся. Операторы пытались обмануть систему, подсовывая уже проверенные контроллеры. Добавили уникальные идентификаторы и проверку логов.
Результаты, которые заставили даже скептиков замолчать
Через месяц работы:
- Брак, пропущенный в производство: 0.1% (было 3%)
- Ложные срабатывания (рабочий контроллер забракован): 0.3%
- Скорость проверки: 45 секунд на штуку (было 180)
- Затраты на персонал: 1 оператор вместо 3 контролёров
- Полная трассируемость: каждый контроллер имеет цифровой паспорт со всеми измерениями
Но главное - появилась возможность аналитики. Claude еженедельно генерирует отчёт с анализом частых дефектов, предлагает изменения в производственном процессе. За последний месяц по его рекомендациям изменили пайку одного компонента - количество брака по этому параметру упало на 70%.
Стоило ли оно того?
Разработка системы заняла 72 часа чистого времени. Стоимость - примерно как два месяца зарплаты старшего контролёра. Окупилось за 3 недели.
Но цифры - это только часть истории. Настоящая ценность в другом: теперь у завода есть стандартизированный, повторяемый, документированный процесс проверки. Не зависит от смены, настроения или квалификации конкретного человека. Можно масштабировать на другие линии. Можно тиражировать на другие заводы.
Следующий шаг для этого завода - подключение n8n для мониторига оборудования, который производит эти контроллеры. Полный цикл автоматизации от станка до ОТК. Но это уже другая история.
А пока три бывших контролёра прошли переобучение и теперь работают операторами системы. Один из них сказал мне вчера: "Раньше я боялся пропустить брак. Теперь я бояться не могу - система не даст". Лучшей оценки нашей работе я не придумал.