ИИ-помощники и GPT: учимся думать вместе с моделью

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

Коротко

GPT — это языковая модель, которая формирует ответ по запросу и доступному контексту. Используйте её как помощника для идей, объяснений и поиска возможных причин ошибки. Решение принимает человек после проверки по документации, коду, симуляции или измерениям.

Зачем это нужно

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

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

Работа с ИИ развивает инженерные навыки, когда ученик:

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

Главная идея

Относитесь к ответу модели как к черновику для проверки, а не как к доказанному факту.

задача -> контекст -> точный запрос -> черновик модели -> проверка -> решение ученика

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

Что делает языковая модель

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

Но связный текст и верный факт — не одно и то же. Модель может:

• неверно понять неполное описание;
• придумать несуществующую функцию, параметр или ссылку;
• пропустить условие, которое не было явно указано;
• предложить код, который компилируется, но работает не по замыслу;
• уверенно повторить ошибку из вопроса.

NIST называет уверенно сформулированный ошибочный результат генеративной модели confabulation — конфабуляцией. В разговоре также встречается слово «галлюцинация». Для ученика практический вывод один: уверенный тон ответа не заменяет проверку.

Контекст

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

Из чего собрать точный запрос

Удобный запрос содержит пять частей. Необязательно оформлять их как анкету, но каждая часть снимает отдельную неопределённость.

Часть запроса	Что сообщить	Пример для робототехники
Цель	Какой результат нужен	понять причину дрожания сервопривода
Контекст	Плата, среда, схема, условия опыта	Arduino Uno, питание сервопривода отдельно, общий GND
Наблюдения	Что произошло на самом деле	дрожание начинается после команды поворота
Ограничения	Что нельзя менять или выдавать готовым	не переписывать весь скетч, сначала дать план диагностики
Формат	Как представить ответ	три гипотезы, у каждой признак и способ проверки

Вместо короткого вопроса:

Почему сервопривод дергается?

можно написать:

Я исследую дрожание сервопривода в учебном роботе.
Плата: Arduino Uno. Среда: Arduino IDE.
Сервопривод получает отдельное питание, земля источника и платы общая.
Дрожание начинается после команды поворота и продолжается в покое.
Сначала перечислите не более трех возможных причин.
Для каждой укажите наблюдение, которое ее подтвердит или опровергнет.
Не пишите новый скетч целиком и не придумывайте отсутствующие измерения.

Во втором запросе модель лучше понимает границы задачи. Она должна не угадать одну «правильную» причину, а помочь построить диагностику.

Просите помогать учиться, а не подменять работу

Один и тот же помощник можно использовать по-разному. Запрос «сделайте задание» скрывает рассуждение и затрудняет проверку. Запрос «дайте первую подсказку и задайте вопрос» оставляет следующий шаг ученику.

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

Если объяснение непонятно, не просите «объяснить ещё раз» без уточнения. Укажите, на каком шаге потерялась связь: «Я понимаю, что digitalRead возвращает состояние входа, но не понимаю, почему условие с ! меняет поведение. Разберите только эту строку на двух наборах входных данных».

Диалог как серия коротких опытов

Первый ответ редко должен становиться последним. Полезный диалог движется небольшими итерациями:

1. Опишите наблюдаемую проблему без догадки о причине.
2. Попросите несколько гипотез и способ различить их.
3. Выберите безопасную проверку, которая меняет только один фактор.
4. Передайте модели фактический результат проверки.
5. Попросите обновить гипотезы и объяснить, почему одна стала вероятнее.
6. Зафиксируйте подтверждённое изменение в проекте.

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

Как проверять ответы

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

Что предложила модель	Как проверить	Признак проблемы
объяснение функции библиотеки	открыть официальную документацию нужной версии	функции или параметра нет в справочнике
фрагмент программы	прочитать каждую строку, скомпилировать, проверить на заданных входах	код не покрывает крайний случай или меняет другую часть проекта
причина неисправности	провести опыт, меняя один фактор	вывод сделан без измерений и наблюдений
схема подключения	сверить выводы и ограничения по документации компонентов	модель путает назначение контактов или не учитывает питание
ссылка или цитата	открыть первоисточник и найти подтверждающий фрагмент	страница не существует либо говорит о другом

Для ответа по проекту удобно применять правило «прочитайте — предскажите — проверьте — объясните»:

1. Прочитайте предложение модели и отметьте незнакомые места.
2. Предскажите, что должно произойти после изменения.
3. Проверьте прогноз компиляцией, симуляцией или контролируемым испытанием.
4. Объясните результат своими словами. Если объяснить не получается, решение ещё не стало вашим знанием.

NIST рекомендует оценивать точность и надёжность результатов генеративных систем по известным эталонным данным, использовать проверку человеком и применять техники фактчекинга. Для учебного проекта «эталоном» может быть документация, заранее составленная таблица входов и выходов или измерение исправным прибором.

Код тоже требует испытания

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

Как применять ИИ при правке этой базы знаний

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

Перед тем как принять текст от модели, проверьте:

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

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

Пример: проверяем логику объезда препятствия

Пусть робот должен остановиться, когда расстояние меньше заданного порога. Ученик просит модель упростить условие, а в ответ получает новую функцию. До загрузки программы полезно составить таблицу ожидаемого поведения:

Ситуация	Вход программы	Ожидаемое действие
препятствие далеко	значение больше порога	движение разрешено
препятствие близко	значение меньше порога	остановка
значение равно порогу	граничный случай	действие определяет автор алгоритма
датчик не вернул корректное значение	ошибочный или специальный результат	безопасное поведение задаётся отдельно

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

Защищаем личные и проектные данные

Запрос отправляется внешнему сервису, если помощник работает в облаке. До отправки проверьте, разрешено ли передавать эти данные правилами школы, кружка, команды и самого сервиса. UNESCO в руководстве по генеративному ИИ для образования отдельно обращает внимание на защиту приватности и использование технологии с сохранением роли человека.

Не вставляйте в запрос:

• пароли, коды подтверждения, токены и ключи API;
• ключи Wi-Fi, закрытые адреса и учётные данные устройств;
• персональные данные одноклассников, клиентов или участников проекта;
• закрытый исходный код и документы, на передачу которых нет разрешения;
• фотографии и журналы работы, если в них видны имена, адреса или другие лишние сведения.

Перед отправкой оставьте только сведения, необходимые для задачи. Имена замените ролями, секреты — метками вроде <API_KEY>, длинный проект — минимальным фрагментом, на котором воспроизводится ошибка. Если для диагностики нужен конфигурационный файл, сделайте копию и удалите секретные значения.

В проектах с API ключ нельзя помещать в клиентское приложение или коммитить в репозиторий. Официальные рекомендации OpenAI предлагают хранить такие ключи вне исходного кода, например в переменных окружения. Эта мера относится не только к ИИ: так же защищают токены облачных платформ, ботов и систем автоматизации.

Рабочий цикл: модель предлагает, инженер подтверждает

Запомните семь действий:

1. Сформулируйте результат, который можно наблюдать или измерить.
2. Передайте минимальный достаточный контекст без секретов.
3. Укажите ограничения и формат ответа.
4. Получите объяснение, гипотезы или небольшой фрагмент решения.
5. Найдите утверждения, от которых зависит результат.
6. Проверьте их по первоисточникам и испытаниям.
7. Зафиксируйте подтверждённое решение и сумейте объяснить его без подсказки модели.

Так ИИ ускоряет поиск и обсуждение вариантов, а обучение не превращается в копирование готового текста.

Практика

Задание 1. Улучшите запрос

Преобразуйте фразу «робот не едет, исправьте код» в диагностический запрос. Укажите цель, плату или симулятор, наблюдения, небольшой фрагмент контекста, ограничения и желаемый формат ответа. Не просите готовую программу целиком.

Задание 2. Составьте план проверки

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

Задание 3. Проверьте ответ по источнику

Попросите помощника объяснить одну функцию из используемой вами библиотеки. Выпишите три проверяемых утверждения из ответа, найдите официальную документацию и отметьте результат сверки. Если версии документации различаются, укажите версию проекта.

Задание 4. Подготовьте безопасный контекст

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

Задание 5. Объясните решение самостоятельно

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

Проверьте себя

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

Ориентиры для самопроверки

Сначала ответьте без подсказки. Ответ можно считать полным, если вы:

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

Если один из пунктов объяснить не получается, найдите соответствующую главу статьи, перечитайте её и повторите ответ.

Словарь статьи

• ИИ-помощник — программа на основе модели искусственного интеллекта, которая отвечает на запросы и помогает выполнять отдельные операции.
• GPT — тип генеративной предварительно обученной языковой модели на архитектуре Transformer.
• Промпт, или запрос — инструкция и контекст, которые пользователь передаёт модели.
• Контекст — сведения о задаче, доступные модели при формировании ответа.
• Гипотеза — возможное объяснение, которое ещё требуется проверить.
• Конфабуляция — уверенно сформулированный, но ошибочный или ложный результат генеративной модели.
• Первичный источник — исходная документация, стандарт, спецификация или публикация автора сведений.
• Фактчекинг — проверка утверждений по надёжным источникам и данным.
• Персональные данные — сведения, которые относятся к определённому или определяемому человеку.
• Ключ API — секретная строка, которая разрешает программе обращаться к сервису от имени проекта или пользователя.

Связанные темы

• Git — как сохранить рабочее состояние и отдельно зафиксировать проверенное изменение.
• Arduino IDE — где компилировать скетчи и читать сообщения об ошибках.
• Tinkercad — как проверять часть схемы и программы в симуляторе.
• Visual Studio Code и PlatformIO — как работать с многофайловыми проектами, библиотеками и разными платами.

Источники

• NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1): https://doi.org/10.6028/NIST.AI.600-1
• UNESCO. Guidance for generative AI in education and research: https://www.unesco.org/en/articles/guidance-generative-ai-education-and-research
• OpenAI. Prompt engineering best practices for ChatGPT: https://help.openai.com/en/articles/10032626-prompt-engineering-best--practices-for-chatgpt
• OpenAI. Best Practices for API Key Safety: https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety