ТРИЗ для 1С: как решать противоречия задач, а не искать компромисс
Отчёт по проекту «Генрих» (Heinrich: The Inventing Machine) описывает попытку скрестить советскую ТРИЗ - теорию решения изобретательских задач - с большими языковыми моделями. Сам проект пока не имеет отношения к 1С: это открытый инженерный эксперимент, а не платформенный инструмент. Но методология, которую он пытается автоматизировать, узнаваема - 1С-архитекторы решают точно такие же противоречия каждую неделю, просто не называют их этим словом.
Что такое ТРИЗ и при чём тут 1С
ТРИЗ - теория решения изобретательских задач, метод, который Генрих Альтшуллер собрал ещё в СССР, разобрав тысячи патентов. Идея простая: за сильным техническим решением почти всегда стоит не компромисс между двумя параметрами, а разрешённое противоречие - когда улучшили одно и не потеряли в другом, потому что развели требования во времени, в пространстве или на разных уровнях системы.
1С-специалист формулирует такие противоречия постоянно, просто в других словах: "нужно, чтобы отчёт был быстрым, но при этом детальным", "нужно, чтобы конфигурацию было легко дорабатывать, но при этом легко обновлять". Обычно это решается на глаз, по опыту. ТРИЗ предлагает не гадать, а сначала явно сформулировать противоречие, а потом подбирать под него один из 40 типовых приёмов.
Классическая формула противоречия
Если <параметр A улучшается>, то <параметр B ухудшается>.
Пример:
Если увеличить детализацию отчёта построчно,
то падает скорость его формирования на больших объёмах.Типичные противоречия в задачах 1С
Вот несколько пар, которые легко узнать в текущих задачах:
- Скорость формирования отчёта - против полноты детализации данных.
- Гибкость конфигурации под требования заказчика - против простоты последующих обновлений "на поддержке".
- Автоматическое проведение документов - против контроля пользователя за итоговым результатом.
- Централизация нормативно-справочной информации в распределённой базе - против автономности удалённых подразделений.
- Скорость обмена данными между базами - против полноты проверок на дубли при синхронизации.
Как ТРИЗ предлагает выходить из тупика, а не усреднять
Вместо того чтобы искать "средний вариант, который устроит всех", ТРИЗ разводит противоречие - во времени, в пространстве или через посредника - и решает каждую часть отдельно. На практике 1С-архитекторы часто уже делают что-то похожее интуитивно, вот три знакомых приёма, если назвать их по-тризовски:
- Дробление. Вместо одного тяжёлого регламентного отчёта - промежуточные регистры итогов, а поверх них лёгкая отчётная надстройка. Тяжёлые вычисления вынесены в фоновое задание, пользователь видит только готовый срез.
- Предварительное действие. Проверку на дубли НСИ не обязательно делать синхронно в момент ввода - можно провести её фоновым регламентным заданием. Противоречие "скорость ввода против качества данных" разводится во времени.
- Посредник. Между двумя жёстко связанными базами ставится отдельный обменный слой - шина, формат, очередь. Он и даёт гибкость дорабатывать каждую сторону отдельно, и не ломает обновляемость типовых конфигураций.
AI-эксперимент «Генрих»: попытка автоматизировать этот способ мышления
Именно на этом месте становится интересен отчёт по проекту Heinrich: The Inventing Machine. Это открытый проект на GitHub, который пытается объединить классические 39 параметров и 40 приёмов ТРИЗ с языковой моделью так, чтобы система рассуждала по интерпретируемой логике, а не просто "угадывала" ответ. Заявленная миссия проекта - снять с ТРИЗ статус инструмента для сертифицированных инженеров и сделать его доступным без специальной подготовки.
«Разрушь компромисс. Изобретай с Генрихом.»
Важная оговорка: сам отчёт - это стратегический разбор молодого open-source проекта (сегментация аудитории, гипотезы монетизации, маркетинговые кампании), а не готовый продукт и тем более не инструмент, интегрированный с 1С:Предприятие. Целевые сценарии в документе - инженерное проектирование, патентная работа, продуктовые противоречия стартапов. Прямой связи с платформой 1С в отчёте нет, и выдавать её за существующую было бы нечестно перед читателем.
Что из этого можно взять уже сегодня, без AI-инструмента
Ценность для 1С-архитектора не в конкретном сервисе, а в самой дисциплине: прежде чем реализовывать очередную доработку "по-быстрому", полезно один раз явно записать противоречие по формуле выше и свериться со списком типовых приёмов - дробление, вынесение, предварительное действие, посредник, изменение параметров. Это отдельный шаг ревью архитектурного решения, который не требует никакого ИИ - только полминуты на формулировку.
Заключение
ТРИЗ не про физику и не про изобретения в буквальном смысле - это дисциплина формулировать противоречие честно, а не сразу нырять в компромисс. Проект «Генрих» показывает, что кто-то пытается автоматизировать именно эту дисциплину с помощью LLM - для инженеров и стартапов, не для 1С. Но сам приём - разложить задачу на "если улучшаем A, то ухудшаем B" и разрешить это дроблением, вынесением во времени или посредником - работает и без AI, прямо на следующей архитектурной доработке.
Попробовать НОПик →