В инженерных компаниях есть особый тип информации, который редко попадает в регламенты и почти никогда не называется базой знаний. Он существует в форме коротких фраз: «спроси у Сергея», «Марина делала похожий объект», «Петрович помнит, почему тогда приняли именно такое решение». И самое интересное в том, что Петрович действительно помнит. Он помнит старое техническое условие, фамилию согласующего, причину изменения схемы, замечание, которое пришло после выпуска, и ещё несколько деталей, которых в официальных документах уже давно нет. В проекте осталось решение.

В голове специалиста сохранилась история того, как к нему пришли. Мне давно кажется, что именно в этой разнице и спрятана большая часть реального опыта компании. Документы фиксируют результат. Опыт фиксирует путь. Иногда именно путь оказывается ценнее. Если открыть старый проект через пять лет, можно увидеть кабель, аппарат, трассу, параметры оборудования. Намного сложнее понять, почему выбрали именно этот вариант, какие альтернативы рассматривались, что не прошло согласование, где пришлось уступить требованиям заказчика, какой нюанс обнаружился уже на стройке.

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

В инженерном бизнесе это особенно чувствительно, потому что хорошая работа почти всегда накапливается слоями. Формальная методика дополняется практикой. Практика дополняется опытом конкретных объектов. Опыт объектов постепенно превращается в привычку, а привычка через несколько лет уже выглядит как профессиональная интуиция. Хороший инженер открывает схему и иногда сразу видит странность. Не всегда может мгновенно объяснить, почему она его зацепила. Потом смотрит расчёт, проверяет аппарат, возвращается к исходным данным и находит несоответствие. Молодой специалист в тот же момент видит обычный лист.

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

До появления современных ИИ-систем такая часть профессионального опыта очень плохо поддавалась цифровизации. Можно было написать инструкцию. Можно было собрать шаблоны. Можно было хранить лучшие проекты. Всё это полезно, но в инструкцию трудно поместить мысль «если здесь получилось слишком красиво, я бы перепроверила исходные данные». Сейчас ситуация становится интереснее, потому что ИИ умеет работать с естественным языком и довольно сложным контекстом. Благодаря этому можно постепенно разбирать профессиональную практику не только как набор документов, но и как способ действия.

Когда я начала делать skills для повторяющихся задач, именно это оказалось для меня самым любопытным. Сначала кажется, что нужно просто описать последовательность. Например, как проверить кабельную линию. Потом начинаются детали. Какие исходные данные обязательны? Что делать, если одного параметра нет? Какие условия считать пограничными? В каком случае стоит пересчитать вторым способом? Какие источники имеют приоритет? Когда система должна остановиться и передать вопрос инженеру?

И вот здесь происходит интересная вещь. Ты уже не просто пишешь инструкцию для ИИ. Ты вытаскиваешь наружу то, что раньше делала автоматически. Профессиональный опыт начинает приобретать форму. Мне нравится думать о skill именно так. Это не набор красивых промптов и не ещё одно модное слово из мира ИИ. Это маленький кусок рабочей методики, который компания смогла описать достаточно хорошо, чтобы система могла воспроизводить его снова. В одном месте это может быть проверка расчёта. В другом анализ замечаний. В третьем первичная сверка проекта с техническими условиями.

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

И вот тогда обычный архив документов уже перестаёт быть достаточным. Представим проектную организацию, в которой за десять лет накопились сотни проектов. Формально это огромный объём знаний. На практике в архиве одновременно лежат хорошие решения, устаревшие решения, компромиссные решения, проекты под разные требования, старые редакции нормативов и материалы, которые никто давно не открывал. Если просто дать ИИ доступ ко всему массиву, он действительно прочитает очень многое. Вопрос в другом: что он должен считать правильным?

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

Именно поэтому хорошая корпоративная база знаний для инженерной компании быстро становится чем-то большим, чем папка с PDF. Нужно понимать происхождение документа, его актуальность, область применения, связь с конкретным объектом, статус решения. Иногда важно знать, почему документ вообще оказался в базе. Это напоминает ситуацию с технической документацией на объект. Сам факт наличия чертежа ещё не говорит о том, что это последняя рабочая версия. Иногда рядом лежит ещё три, и каждая называется примерно одинаково. Компания может годами жить с такой системой, потому что опытные сотрудники знают, куда смотреть.

ИИ таких договорённостей не знает. И это очень полезно. Он заставляет их сформулировать. Как определить актуальную версию? Какой источник важнее? Можно ли использовать этот документ как пример? Какие материалы считаются эталонными? Что делать с устаревшими решениями? Где хранится история изменений? В какой-то момент создание базы знаний превращается в ревизию самой корпоративной памяти. И это один из тех процессов, где технология неожиданно начинает задавать организации неудобные, но полезные вопросы.

Я вообще всё больше думаю, что главная ценность базы знаний находится не в количестве загруженных файлов. Она находится в связях между ними. Технические условия связаны с проектом. Проект связан с расчётом. Расчёт связан с принятым решением. Решение связано с замечанием. Замечание связано с ответом и последующей корректировкой. Через год похожая ситуация возникает на другом объекте. Если система способна видеть эту цепочку, компания начинает пользоваться прошлым опытом иначе. Тогда старый проект становится не просто аналогом.

Можно увидеть, в каких условиях он появился, что в нём сработало, что пришлось менять и какие последствия возникли позже. Это уже похоже на память. Архив хранит прошлое. Память помогает принимать решения в настоящем.

И здесь становится понятнее, зачем вообще нужны ИИ-агенты. Само слово сейчас слегка перегрето. Агентом называют очень разные вещи, поэтому я стараюсь смотреть на него через конкретную работу. Допустим, в компанию приходит замечание. Система может определить, какой объект и раздел оно затрагивает, найти связанные материалы, поднять исходные данные, проверить похожие ситуации в предыдущих проектах, показать применявшиеся решения и подготовить контекст для инженера. Если в корпоративной базе уже зафиксировано, что определённый подход раньше создавал проблему, это тоже может появиться в анализе.

Человек начинает работу не с поиска по папкам, а с уже собранной историей вопроса. Это довольно серьёзное изменение. Особенно если таких маленьких эпизодов в день десятки.

Со временем сама компания начинает накапливать опыт иначе. Новый проект оставляет после себя не только комплект документации. Он может оставить ещё и новую проверку, новое правило, зафиксированное исключение, объяснение принятого решения. Если на стройке обнаружилась ошибка, можно просто исправить её в текущем проекте. Можно ещё задать вопрос: что в нашем процессе позволило этой ошибке пройти? Ответ иногда превращается в новую контрольную точку. Следующий проект уже получает дополнительную защиту. Так постепенно формируется система, которая действительно учится на собственной практике.

Не в красивом рекламном смысле, где «ИИ обучился на всех проектах компании», а гораздо приземлённее. Люди обнаружили новый паттерн, поняли его значение и встроили в рабочую методику. Мне этот вариант нравится больше. Потому что он сохраняет происхождение знания. Инженер понимает, откуда появилось правило и зачем оно существует. Это особенно важно в технической среде. Когда система просто говорит «обычно делают так», мне всегда хочется узнать, кто эти загадочные «обычно» и насколько их объект похож на мой.

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

Есть здесь ещё одна сторона, которая мне кажется важной. Когда компания начинает формализовать знания опытных сотрудников, очень легко увлечься идеей, что теперь можно перенести человека в систему целиком. Я бы относилась к этому осторожно. У опытного специалиста есть способность работать с новой ситуацией, которой раньше не было. Есть чувство последствий. Есть ответственность. Есть понимание среды, людей, ограничений и вещей, которые сложно описать заранее. Формализованная методика сохраняет только ту часть опыта, которую мы смогли увидеть и сформулировать. И этого уже очень много.

Мне не требуется цифровой Петрович, который во всём заменит настоящего. Мне гораздо полезнее, если через несколько лет компания сможет понять, почему Петрович когда-то сказал: «Вот здесь лучше сделать иначе». Возможно, именно такая постановка и делает работу с корпоративным знанием более реалистичной.

ИИ даёт возможность сохранить значительно больше контекста, чем мы сохраняли раньше. Связать документы с решениями. Связать решения с причинами. Превратить часть повторяемой практики в skills. Дать сотрудникам инструмент, который умеет быстро поднять накопленный опыт и показать его там, где он действительно нужен. А дальше начинается уже другой вопрос. Если компания действительно сможет помнить не только то, что она сделала, но и чему научилась по дороге, насколько изменится ценность каждого следующего проекта? На него я бы пока не спешила отвечать.

Мне гораздо интереснее посмотреть, что компании начнут делать с такой памятью, когда она у них наконец появится.