Использование возможностей искусственного интеллекта (ChatGPT, DeepSeek) в обучении: риски и точки роста

Автор: Жилина Анна Юрьевна

Организация: ГБПОУ «СГКК»

Населенный пункт: Челябинской область, г. Сатка

Четыре года я преподаю профильные дисциплины — «Архитектуру аппаратных средств», «Операционные системы», «Компьютерные сети» и «Системное программирование» — студентам второго курса, обучающимся по специальностям, связанным с программированием. За это время через мои пары прошло несколько групп, и я успела увидеть, как меняется аудитория: сегодняшние студенты приходят с ноутбуками, в которых уже открыты десятки вкладок, и с привычкой искать ответ мгновенно.

Когда я только начинала вести эти дисциплины, разговоры вокруг ИИ уже шли полным ходом, но моё собственное отношение к ChatGPT и DeepSeek было скорее скептическим. Признаюсь честно: поначалу хотелось просто закрыть на них глаза или даже запретить. Но очень быстро стало очевидно — ребята не собираются расставаться с этими инструментами ни при каких условиях. Просто перешли бы в режим «тайного пользования», и всё. Тогда я сосредоточилась на другом вопросе: как встроить эти технологии в учебный процесс так, чтобы был толк?

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

Группы у меня среднестатистические — без звёздных олимпиадников, но и без тех, кто надолго «зависает» на первом курсе. За четыре года расклад по предметам вырисовался понятный. «Архитектура аппаратных средств» — всегда самая тяжёлая борьба: абстракции вроде организации памяти или кэширования ставят студентов в тупик, оценки «отлично» появляются редко, большинство кое-как продирается до тройки. «Операционные системы» — теорию усваивают, но когда доходит до реализации или диагностики процессов в реальном коде, начинается отставание. «Компьютерные сети» идут лучше: часть группы всерьёз увлекается темой, многие справляются уверенно. А «Системное программирование» оказалось удивительно живым предметом — те, кто понял механику работы с памятью и системными вызовами, начинают быстро расти.

Ощущения глобального отсутствия мотивации или нехватки способностей нет. Куда сложнее то, что у каждого затык случается в своём месте, а объяснять персонально каждому времени банально не хватает. Классическая ситуация массового обучения: ты как дирижёр в оркестре из инструментов разной настройки.

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

Второй пример из жизни — работа с ошибками компиляции и программными багами, особенно на системном программировании. Раньше на практике я бегала между студентами-«пожарниками», решая одни и те же грабли по несколько раз за пару: «ошибка сегментации», «утечка памяти» и так далее. Теперь многие сначала советуются с ИИ: расшифровывают природу ошибки через диалоговый запрос, приходят ко мне либо почти с готовым исправлением, либо хотя бы со сформулированным вопросом. Это разгружает обстановку — вместо потока однотипных консультаций появляется время на действительно интересные инженерные задачи.

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

И наконец, если посмотреть вокруг, любая современная команда разработчиков уже не мыслит себя без ассистентов наподобие Copilot или ChatGPT. Было бы странно делать вид, что студенты никогда этим пользоваться не будут. Напротив — нужно учиться правильно ставить задачи для модели, видеть нюансы системного кода в разных реализациях Linux и Windows. Это отдельная профессиональная компетенция XXI века, и наша задача — не игнорировать этот факт, а встраивать его в подготовку.

Но есть и другая сторона. Главная ловушка — знание понарошку. Студент может честно принести блестяще выглядящий лабораторный отчёт, только вот объяснить по сути ничего не может: «этот кусок кода я скопировал по совету модели — вообще не знаю, зачем он нужен». Легко свалиться к имитации знаний, и на третий курс такие искусственные успехи бьют особенно больно, потому что именно сейчас закладываются механизмы самостоятельного мышления.

Вторая проблема знакома всем системщикам старшего поколения: если за пару лет привыкнуть искать любой ответ через ИИ-запросы, теряется навык работы с первоисточником — официальной документацией Linux, спецификациями RFC, man-страницами. В «боевой» разработке такие умения окупаются многократно; без них специалист превращается во «вторичника», который знает решение ровно до первой нестандартной ситуации.

Третья опасность — ошибочные или устаревшие подсказки. Модель иногда путает библиотеки, особенно если задача пограничная, неверно пишет синтаксис ключей команды или вообще фантазирует новые опции gcc. И если базиса для проверки у студента нет, он принимает выдуманную рекомендацию на веру: «ну ведь умная машина сказала». Неоднократно разбирали на занятии причины загадочных багов именно такого происхождения.

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

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

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

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