Red Hat уже четыре года помогает факультету информатики Университета Масарика в Брно готовить технических писателей — и на практике убедилась, что ИИ в техдокументации пока скорее помощник, чем автор. Студенты обходили запрет на LLM, а профессиональные техписатели на Open Source Summit EU признали: модели полезны для рутины, но плохо создают и рецензируют документацию. Для российских команд, где документация почти всегда отстаёт от продукта, это важное разделение задач.
О результатах проекта рассказал старший сотрудник документационной команды Red Hat в Брно Йиржи Херрманн. Как сообщает The Register, компания сотрудничает с факультетом информатики Masaryk University в рамках учебного модуля PV177 Technical Writing. Запуск курса планировали раньше, но его отложила пандемия 2020 года; впервые обучение прошло в 2023-м.
Задача курса шире, чем научить студентов аккуратно расставлять запятые в руководстве по API. Red Hat хочет закрыть сложную часть профессии: общение с разработчиками, менеджерами и другими авторами. В финале студенты разыгрывают сценарий в духе настольной ролевой игры: будущему техписателю нужно пройти через кросс-функциональную команду, подготовить release notes, технические заметки и документацию по самому процессу. Материалы курса открыты, поэтому у выпускников остаётся публичный FOSS-след работы, который можно показать работодателю.
Практика быстро разрушила несколько привычных представлений об обучении IT-специалистов. Задания, завязанные на консольные инструменты, оказались недоступны части аудитории: кто-то никогда не работал с командной строкой, кто-то приходил с чужим ноутбуком без прав администратора, а кто-то — только со смартфоном. Взаимное ревью работ тоже не взлетело в исходном виде: студенты не успевали качественно оценивать друг друга. Вместо этого преподаватели добавили отдельный навык — как давать обратную связь коллегам и не превращать ревью в личный конфликт.
Запретить LLM оказалось проще, чем сделать вид, что их нет
Главной проблемой стал запрет на большие языковые модели. Студентам нельзя было использовать LLM, но они всё равно это делали. У преподавателей получилась неприятная петля: похвалишь сильную работу, созданную с помощью модели, — поощришь новые нарушения; жёстко отругаешь — снизишь мотивацию и подтолкнёшь скрывать использование. В итоге команда Red Hat не стала строить курс вокруг бесполезной охоты за следами генерации и переключилась на обучение работе с такими инструментами.
Это, пожалуй, наиболее прикладной вывод истории. Политика «ИИ запрещён» в разработке и документации часто существует лишь в регламенте. Если сотруднику нужно быстро разобраться в изменениях большого продукта, собрать заметки со встречи или найти похожую статью в разросшейся базе знаний, у него уже есть соблазн открыть чат-бот. Рабочая альтернатива — не молчаливый запрет, а понятные границы: какие данные нельзя передавать модели, какие результаты требуют ручной проверки и кто отвечает за итоговый текст.
На отдельной встрече Technical Writing in the Age of AI Херрманн спросил аудиторию, пользуются ли техписатели ИИ. По его словам, положительно ответило подавляющее большинство. При этом участники довольно единодушно описали слабые места моделей: они плохо пишут документацию, не справляются с диаграммами и их проверкой, а при рецензировании слишком склонны хвалить текст. Особенно плохо они оценивают, понятна ли структура пользователю и ведёт ли документ к реальному решению задачи.
Зато ИИ в техдокументации нашёл применение на периферии авторской работы. Участники называли управление изменениями и поиск фрагментов, которые нужно обновить после правок в коде. Модели используют для фиксации решений из заметок встреч, первичного сбора материалов, поиска уже существующих документов и анализа кода, чтобы понять его замысел. В условиях, когда команды документации хронически меньше команд разработки, желание автоматизировать хотя бы этот слой вполне рационально.
Риск прячется в задачах, которые никто не проверяет
Но именно здесь возникает неприятный перекос. Техписатель способен заметить слабый черновик инструкции, потому что знает предмет и регулярно рецензирует тексты. Гораздо сложнее оценить, верно ли модель определила затронутые изменением компоненты, ничего ли не потеряла при группировке заметок и не пропустила ли важный документ при поиске. Аудитория также упоминала суммаризацию материалов конференций и встреч — задачу, где сокращённый текст легко принять за содержательное резюме, хотя существенные условия и контекст уже исчезли.
Для разработчиков и руководителей отсюда следует простое правило: генерацию финального документа и контроль его качества нельзя считать одной задачей. Модель может подсветить diff, собрать черновой список ссылок или разложить сырые заметки по темам. Но решение о том, что именно изменилось для пользователя, какие ограничения появились и достаточно ли инструкция объясняет путь от проблемы к результату, остаётся за человеком. Иначе команда ускорит выпуск текста, но замедлит поддержку, внедрение и расследование инцидентов.
Курс Red Hat интересен не геймификацией с баллами, мемами и секретными призами, а честной постановкой вопроса: ИИ в техдокументации нужно оценивать не по скорости первого черновика, а по цене ошибки после публикации. Открытые материалы и архив студенческих работ позволяют посмотреть, как этот подход выглядит на практике, на . Следующим дефицитным навыком техписателя, похоже, станет не владение промптами, а умение доказать, где автоматизации нельзя доверять без проверки.