Методическое руководство для учителя¶
0. Как пользоваться этим руководством¶
Руководство написано для учителя информатики или математики, который ведёт курс впервые. Специальной подготовки по машинному обучению не нужно: всё, что требуется на уроках, есть в книге ученика и в учебном комплекте программ starter. Ссылки вида «с. 39» ведут на страницы книги ученика.
В руководстве четыре части: разделы 1–8 — как устроен курс и как его вести; поурочная карта — что происходит на каждом из 34 уроков; конспект глав — одна страница на главу для быстрой подготовки; список фигур — где в книге стоит каждая схема.
Ответы. Ответы на мини-проверки уроков и на вопросы «Проверь себя» напечатаны в самой книге — в разделах «Ответы» сразу после вопросов. Исключение — «Проверь себя» глав 1 и 2: напечатанных ответов там нет. Ответы к главе 1 сверяются по уроку 2 ( ↗– ↗), а к главе 2 — по урокам 3 и 4 ( ↗– ↗); ответы мини-проверки ролей — ↗. Ответ на вопрос-прогноз, с которого начинается глава, — в её конце, где класс возвращается к сцене. Отдельного сборника ответов нет: курс строится на том, что ученик сначала записывает прогноз, а потом проверяет его, поэтому ответ не сообщают раньше механизма.
Слова, которые встретятся в руководстве¶
Точные определения — в Приложении Б книги ученика ( ↗). Здесь — коротко, чтобы читать руководство.
| Слово | Что это простыми словами | Где в книге |
|---|---|---|
| «Дежурный» | учебный проект курса: программа-помощник школьного проектного бюро, которая читает карточки задач и готовит черновик отчёта о состоянии проекта; ученик настраивает её от главы к главе | гл. 1, ↗ |
| starter | учебный комплект: папка с программами на Python, учебными данными и проверками; все команды курса выполняются из неё | Приложение А, ↗ |
| агентный цикл (agent loop) | повторение «состояние → выбор действия → выполнение → наблюдение → решение»; решение определяет, продолжать или остановиться | гл. 2, ↗ |
| терминал | итог запуска: success (готово), needs_input (нужен ответ человека), error (ошибка), limit (исчерпан предел шагов) | гл. 2, ↗ |
| tool | конкретная операция, которую программа умеет выполнять, например прочитать карточки задач | гл. 1, 4, 6 |
| harness | программная среда вокруг модели: организует цикл, выполнение действий, состояние, ограничения, ошибки и участие человека | гл. 3, ↗ |
| Agent Skill | переносимая процедура, записанная в файле SKILL.md, с дополнительными файлами при необходимости | гл. 4 и 9, ↗ |
| заглушка (stub) | маленькая функция на месте модели с заранее заданным поведением | гл. 1–5 |
| replay (воспроизведение) | ответы модели, подготовленные заранее; это сценарий, а не запись живой модели | гл. 2 и 6 |
| bridge-сеанс | единственный обязательный ручной сеанс с живой моделью: человек переносит подготовленный запрос в разрешённый чат и возвращает ответ на проверку | гл. 7, |
| trace | сохранённая запись событий одного запуска: что произошло, кем начато, чем закончилось | гл. 12, ↗ |
| test case, eval | заранее заданная ситуация с ожидаемым результатом; eval — проверка поведения на наборе таких ситуаций | гл. 8 и 11 |
| approval gate | место, где программа останавливается и ждёт решения человека | гл. 14, ↗ |
| checkpoint, handoff | сохранённое состояние, по которому работу можно продолжить, и передача работы следующему запуску или человеку; не путать с контрольной точкой курса (КТ) | гл. 10 и 16 |
| Release candidate | версия проекта, зафиксированная для итоговых проверок перед защитой | гл. 17, ↗ |
| golden | файл с эталонным выводом программы; по нему проверяется, что программа печатает то же, что книга | раздел 4 руководства |
1. Для кого курс и какой результат ожидается¶
Курс рассчитан прежде всего на учащихся 9–10 классов. Он не требует вузовской подготовки по машинному обучению, коммерческого API-ключа, сложной инфраструктуры или уверенного владения Python. Ученик рассматривается как начинающий инженер: он должен различать роли частей системы, читать простые схемы, проектировать ограничения, сравнивать ожидание с наблюдением, находить ошибку и аргументировать решение.
Образовательный маршрут строится как последовательность наблюдаемых действий: понять устройство системы, смоделировать её, собрать учебную версию, проверить, ограничить последствия, улучшить и объяснить другому. Итогом является локальный проект «Дежурный» — программа-помощник школьного проектного бюро, которую ученик настраивает от главы к главе, — и его защита. От ученика не требуется собрать профессиональную автономную систему; требуется показать связную архитектуру, корректные границы, проверяемые результаты и умение объяснить, какие утверждения подтверждены практикой, а какие остаются предположениями.
Руководство не является ключом к заданиям. Сцены, прогнозы и спорные вопросы следует проходить с классом в том порядке, в каком они даны в главах. Учителю важно не сообщать ответ раньше механизма: ценность курса во многом состоит в том, что ученик сначала делает прогноз, а затем сталкивает его с наблюдаемым результатом.
2. Два расписания: 34 и 18 часов¶
Полный маршрут занимает 34 академических часа: 17 глав по два урока. Урок 0 вынесен в Приложение А и является организационной подготовкой рабочего места, а не 35-м часом. Перед главой 1 стоит вводная глава «Экскурсия по AI: что есть что» — два урока-показа Э1–Э2 сверх 34 часов (итого 36): ученик предсказывает, наблюдает и заполняет таблицу наблюдений, практик со starter и шага проекта в них нет; карточки — в поурочной карте ( ↗, ↗). В сокращённом маршруте Экскурсия сжимается до одного урока-показа или выносится в домашний просмотр (строка «Э» таблицы ниже). В полном маршруте главы идут последовательно: от различения модели, приложения и агента к циклу, harness, механизмам взаимодействия, договору задачи, tools, Agent Skill, состоянию, проверкам, traces, версиям, безопасности, долгой работе и итоговой защите.
Сокращённый маршрут занимает 18 занятий по 45 минут. Он объединяет пары уроков, но сохраняет главные понятия, безопасность, проектирование и защиту; какие уроки в какое занятие входят — в таблице ниже. Нельзя исключать точные роли, остановку, договор задачи, tool, SKILL.md, состояние вне чата, три типа проверок, trace, минимальные полномочия и итоговую защиту. Личный skill и реальный bridge-сеанс для трека B также остаются обязательными.
В расширение можно вынести прямое подключение программы к модели через API, настоящее MCP-подключение, автоматический запуск проверок (CI), сложную автоматизацию, дополнительные реализации и часть углубляющих инженерных упражнений. Такое сокращение не должно превращать курс в демонстрацию готового кода. Даже в 18-часовой версии ученик проходит путь «спрогнозировал → проверил → объяснил границу» и предъявляет наблюдаемый продукт.
Сокращённый маршрут: 18 занятий по 45 минут¶
| Занятие | Уроки полного курса | Обязательное | Расширение | с. в книге |
|---|---|---|---|---|
| Э | Э1–Э2 | Один урок-показ: показы 1, 4, 5, 7 (только три роли), 8 и карта «что есть что»; показы 2, 3, 6 — домашний просмотр видео или чтение. Либо вся Экскурсия — домашним просмотром, тогда первые 5 минут занятия 1 — сверка таблиц наблюдений | Второй урок-показ | ↗, ↗ |
| 1 | 1–2 | Роли, одинаковая фраза и различное наблюдение | Правка заглушки | ↗, ↗ |
| 2 | 3–4 | 4 стадии + решение, 4 терминала; показ учителя в конце главы 2 | Пять программных сценариев | ↗, ↗ |
| 3 | 5–6 | Harness, workspace, состояние и права | Реализация проверки пути | ↗, ↗ |
| 4 | 7–8 | Пять механизмов; контроль зависимостей | Учебная MCP-карточка | ↗, ↗ |
| 5 | 9–10 | Договор задачи; когда агент не нужен | Дополнительные кейсы | ↗, ↗ |
| 6 | 11–12 | Чтение без пути от модели; task_id; schema; подготовка bridge | Сложные схемы | ↗, ↗ |
| 7 | 13–14 | Allowlist, retry/error; реальный bridge минимум B | Дополнительный сеанс | ↗, ↗ |
| 8 | 15–16 | Паспорт tool и три проверки | Автовалидатор | ↗, ↗ |
| 9 | 17 | Каталог Agent Skill: описание, инструкции, ресурсы | Лицензия и расширенные поля | ↗ |
| 10 | 18 | Проектный skill и личный skill v1; три проверки | Script после аудита | ↗ |
| 11 | 19–20 | project_state, handoff, отсутствие секретов | RAG-демо | ↗, ↗ |
| 12 | 21–22 | Harness отдельно от model_behavior; критерии | Автоматический eval-runner | ↗, ↗ |
| 13 | 23–24 | Trace: инициатор события, поиск сбоя | Анализатор trace | ↗, ↗ |
| 14 | 25–26 | Личный skill v2, diff, регрессия, keep/revert (КТ 7) | Git | ↗, ↗ |
| 15 | 27–28 | Минимальные права, read-only, approval | Полная матрица угроз | ↗, ↗ |
| 16 | 29–30 | Инъекция и аудит стороннего skill/MCP | Статический сканер | ↗, ↗ |
| 17 | 31–32 | Возобновление и выбор один/несколько/человек | Запуск нескольких агентов | ↗, ↗ |
| 18 | 33–34 | Интеграция, защита, bridge-доказательство B, личный skill | Развёрнутая рефлексия | ↗, ↗ |
| Маршрут | Что сохраняется обязательно | Что можно оставить расширением |
|---|---|---|
| 34 часа | 17 глав, КТ 1–8, три проверочные работы, интеграция, защита | дополнительные реализации и факультативные сервисы |
| 18 часов | понятийное ядро, безопасность, личный skill, bridge B, trace, версии, защита | API/live, настоящий MCP, CI, сложная автоматизация |
При планировании стоит учитывать, что хронометраж отдельных сжатых занятий ещё требует классной проверки. Поэтому 18-часовой маршрут следует вести с запасом на обсуждение ошибок и не компенсировать нехватку времени пропуском безопасности или итогового доказательства.
3. Треки A и B¶
Трек A и трек B равноправны. Трек A использует карточки, схемы, ролевое моделирование, проектирование, анализ и защиту без обязательного программирования. Трек B использует Python и локальный starter. Различается форма практической реализации, но архитектурное понимание и безопасность оцениваются одинаково.
Если на уроке возникает технический сбой, ученик не должен терять содержательную часть занятия. Он начинает с трека A, фиксирует прогноз, строит схему и разбирает границы, а школа организует доступ к треку B позже. Инструкции по установке и подготовке среды не нужно переписывать в это руководство: единственный источник — Приложение А «Урок 0. Готовность рабочего места».
Учителю полезно проверять не объём написанного кода, а качество инженерного объяснения. Ученик должен уметь показать, где выполняется действие, какой результат наблюдаем, что ограничивает последствия и почему один удачный запуск не доказывает устойчивость всей системы. Трек B добавляет программное свидетельство, но не отменяет необходимость объяснения.
4. Какая «модель» работает на уроках и что считать доказательством¶
Режимы модели в курсе: stub — заглушка в обязательных практиках глав 1–5 (в главе 5 модель в практике не участвует); replay — авторский сценарий с указанным происхождением, с главы 6 в практиках и с главы 1 в конструкторе «Дежурного»; bridge — единственный обязательный ручной сеанс с живой моделью (глава 7), его свидетельство — на защите; live/API — факультатив. Replay не оценивает качество живой модели; bridge не закрывается заранее подготовленным ответом.
| Режим | Что это | Где в курсе | Что можно утверждать по результату |
|---|---|---|---|
| заглушка (stub) | функция с заранее заданным поведением на месте модели | практики глав 1–5 | программа вокруг модели работает так, как описано |
| replay | ответы, подготовленные заранее | практики с главы 6; «Дежурный» с главы 1 | программа правильно обрабатывает такой ответ; о живой модели — ничего |
| bridge | человек переносит запрос в разрешённый чат с живой моделью и возвращает ответ на проверку | один раз, глава 7 (); свидетельство — на защите | этот конкретный ответ живой модели прошёл проверки программы |
| live/API | прямое подключение программы к модели | факультатив | в обязательную часть курса не входит |
Это различие нужно проговаривать всякий раз, когда класс видит убедительный текстовый результат. Заглушка и replay позволяют воспроизводить учебные ситуации и проверять harness, формат данных, правила остановки, обработку ошибок и настройки проекта. Они не дают основания утверждать, что живая модель в похожей ситуации ответит так же.
Bridge устроен иначе: код не обязан подключаться к сети. Harness готовит контекст, человек переносит его в доступный живой чат и возвращает структурированный ответ, который проверяется до выполнения. Для курса важен не эффект «мы поговорили с ИИ», а паспорт реального сеанса: происхождение ответа, условия запуска и наблюдаемое продолжение работы. Заранее известный эталонный вывод (в starter такие файлы называются golden) не может быть доказательством такого сеанса.
Платный API и личная регистрация ученика не обязательны. Доступный живой чат для обязательного сеанса организует школа или учитель с соблюдением правил выбранного сервиса. Если такого доступа в момент урока нет, класс продолжает офлайн, а live-доказательство остаётся открытым до организованной школьной сессии. Для сеанса подойдёт любой чат с живой моделью, которым школа разрешает пользоваться. Что перенести в чат и что вернуть, описано в главе 7 (); итог записывается в паспорт по шаблону workspace/ch07/bridge_passport_template.md ().
5. Как устроены главы и контрольные точки¶
Рабочий ритм главы стабилен: сцена проектного бюро → вопрос-прогноз → объяснение механизма → «Проверь себя на ходу» → практика → шаг сквозного проекта → возврат к сцене → мост к следующему вопросу. Эта повторяемость помогает ученику отличать содержание главы от формы работы. Учителю полезно сохранять прогнозы до запуска: после практики их можно сравнить с результатом и увидеть не только ошибку программы, но и ошибку в рассуждении.
Контрольные точки курса привязаны к наблюдаемым продуктам. «КТ курса» — это организационная контрольная точка учебного маршрута; её не следует смешивать с техническим Checkpoint, который появляется позже как часть продолжения долгой работы.
| Урок | Контроль | Что сдаёт ученик | с. в книге |
|---|---|---|---|
| 4 | КТ 1: цикл | программа проходит пять учебных сценариев; получены все четыре итога запуска; ошибка — на втором действии | |
| 8 | КТ 2: архитектура | карта системы: роль каждого механизма и связи между ними | |
| 14 | КТ 3: цикл и bridge | чтение, ошибка и результат в одном запуске; в треке B — паспорт bridge-сеанса | |
| 16 | Проверочная работа 1 | tool, схема параметров (schema), проверка (validator), три теста | |
| 18 | КТ 4: skill | skill проекта и личный skill; три проверки | |
| 20 | КТ 5: состояние | передача работы между запусками (handoff) | |
| 22 | Проверочная работа 2 | проверка программы отдельно от поведения модели; исходный уровень (baseline) | |
| 24 | КТ 6: диагностика | отчёт об инциденте по trace | |
| 26 | КТ 7: версии | личный skill v1 и v2, сравнение (diff), повтор случаев, решение keep или revert | |
| 28 | Проверочная работа 3 | разрешения (permissions) и approval gate | |
| 30 | КТ 8: аудит доверия | внешний аудит skill другой группы: обоснованный отказ или условия подключения | |
| 33 | Интеграция | кандидат проекта для итоговой проверки | ↗ |
| 34 | Итог | защита, свидетельство bridge-сеанса (трек B), личный skill; рубрика — | ↗ |
На защите ценится не количество функций, а связность доказательств. Ученик должен показать архитектуру, договор задачи, качество tools и skill, состояние, проверки, trace, безопасность и решение человека там, где оно требуется. Критическое нарушение — например, произвольное выполнение команды, выход за учебную папку, хранение секрета или значимое изменение без нужного подтверждения — не компенсируется хорошей презентацией. Стобалльная рубрика защиты и правило бонуса приведены в главе 17 () — ученик видит те же критерии.
| Компонент | Баллы |
|---|---|
| Понимание архитектуры | 15 |
| Постановка задачи и критерий готовности | 10 |
| Качество tools | 10 |
| Качество Agent Skill | 10 |
| Состояние и возобновление | 10 |
| Тесты и evals | 15 |
| Trace и обработка ошибок | 10 |
| Безопасность и подтверждения | 15 |
| Документация и защита | 5 |
| Итого | 100 |
Бонус до 5 баллов сверх 100: 2 — измеримое улучшение личного skill на неизменном наборе; 2 — перенос процедуры на другой учебный пример; 1 — воспроизводимые diff/версия/keep-revert. Отчётность: основной результат /100 и бонус /5 отдельно. Бонус не компенсирует нарушения безопасности и не заменяет обязательный bridge-сеанс в треке B.
6. Конструктор «Дежурного»: что ученик накапливает и как это проверить¶
Ученик не пишет заново весь harness. По ходу курса он добавляет настройки в workspace/my_agent/, а «Дежурный» показывает, как они влияют на один и тот же локальный проект. В главах 4 и 6 отдельного файла настройки нет: это намеренно, потому что не каждая тема курса должна превращаться в новую строку конфигурации.
| Глава | Настройка ученика | Что наблюдает учитель |
|---|---|---|
| 1 | 01_goal.md |
цель в строке goal: |
| 2 | 02_stop_policy.json |
предел шагов и повторов |
| 3 | 03_workspace_policy.json |
разрешённая область записи; отказ вне неё |
| 4 | отдельного файла нет | понятийная глава; фиктивная настройка не создаётся |
| 5 | 05_task_contract.md |
contract: ok/violated по «Готово, когда» |
| 6 | отдельного файла нет | вызов операции входит в общий harness |
| 7 | 07_tools.json |
разрешённый список; неизвестный tool отклоняется до диспетчера |
| 8 | 08_my_tool.py |
имя и описание функции; программа читает текст файла, но не запускает его код |
| 9 | 09_skills/<имя>/SKILL.md |
skill ученика в каталоге; загрузка тремя слоями; три проверки главы 9 |
| 10 | 10_state.json |
второй запуск видит сохранённое состояние |
| 11 | 11_evals.json |
случаи ученика и итог result: n/m |
| 12 | 12_trace.json |
запись trace и разбор последнего запуска |
| 13 | 13_versions/ |
снимки конфигурации и сравнение без автоматического изменения файлов |
| 14 | 14_permissions.json |
gate закрыт по умолчанию; изменение не применяется без решения человека |
| 15 | 15_trust.json |
решение аудита для skills; подключение не разрешает scripts автоматически |
| 16 | 16_run_plan.json |
одна команда run = одна Session; предел числа сессий |
| 17 | 17_release_candidate.json |
фиксация одной версии для итоговых проверок; метка не доказывает качество |
Счётчик configured: k/15 относится к пятнадцати реально настраиваемым строкам. Для быстрой проверки удобно идти в порядке status → run → eval, а при разборе конкретного запуска — к последнему trace. Файлы 08_my_tool.py, 09_skills/.../SKILL.md и 05_task_contract.md дополнительно требуют ручного просмотра по правилам соответствующих глав.
Все команды набираются в командной строке, открытой в папке starter — той, где лежит файл dezhurny.py. Строка # запуск из корня starter в примерах напоминает об этом; набирать её не нужно. В примерах написано python; на Windows обычно набирают py -3, на macOS и Linux — python3, как в Приложении А ( ↗).
Прежде чем смотреть настройки учеников, проверь целостность самой поставки — на свежераспакованном starter, до первого запуска. Команда рассчитана на нетронутый комплект: на папке, где уже лежат trace, черновики или файлы учеников в my_agent/, она честно ответит false, хотя starter исправен.
# запуск из корня starter
python scripts/verify_release.py
Команда печатает отчёт в формате JSON и занимает около десяти секунд; смотреть нужно на строку "all_passed": true в конце: starter цел, тесты проходят; о качестве модели это ничего не говорит. Полный вывод здесь намеренно не приводится, потому что технические счётчики меняются вместе с версией starter.
Держите две копии starter. Первая — чистая: её проверяют командой verify_release.py и с неё раздают комплект ученикам; в ней ничего не запускают. Вторая — рабочая: на ней учитель повторяет примеры этого раздела и смотрит работы учеников. Команды run и trace записывают в папку файлы — черновики и trace, поэтому после них verify_release.py на той же папке ответит false. Это не поломка.
Первая команда показывает состав настроек и счётчик. Смотрите на третий столбец (настроено / не настроено / ошибка) и на последнюю строку configured: k/15. Ниже — проверенный пример для базовой учебной конфигурации.
# запуск из корня starter
python dezhurny.py status
dezhurny: status
config: workspace/my_agent
глава 1 | 01_goal.md | не настроено | run: заголовок цитирует первую строку цели
глава 2 | 02_stop_policy.json | не настроено | run: предел шагов и повторов
глава 3 | 03_workspace_policy.json | не настроено | run: сохранение черновика только в разрешённую область
глава 5 | 05_task_contract.md | не настроено | run: contract ok/violated по разделу «Готово, когда»
глава 7 | 07_tools.json | не настроено | run: tool вне списка отклоняется до диспетчера
глава 8 | 08_my_tool.py | не настроено | каталог tools: описание функции ученика
глава 9 | 09_skills | не настроено | каталог skills: skill ученика, три слоя загрузки
глава 10 | 10_state.json | не настроено | run: второй запуск видит первый
глава 11 | 11_evals.json | не настроено | eval: таблица случаев ученика
глава 12 | 12_trace.json | не настроено | run: trace в workspace/traces/dezhurny/; trace --last
глава 13 | 13_versions | не настроено | version save сохраняет снимок конфигурации
глава 14 | 14_permissions.json | не настроено | approval gate закрыт: изменение статуса не применяется
глава 15 | 15_trust.json | не настроено | skills из 09_skills подключаются без записанного решения аудита
глава 16 | 16_run_plan.json | не настроено | run — одна Session без checkpoint
глава 17 | 17_release_candidate.json | не настроено | run: печатает метку Release candidate; изменение любого файла после фиксации делает её недействительной
configured: 0/15
Следующая команда показывает техническую границу записи на заранее подготовленном случае.
# запуск из корня starter
python dezhurny.py run --dir workspace/my_agent/examples/denied
dezhurny: run
goal: не настроено (глава 1)
config: workspace/my_agent/examples/denied
model: replay — авторский сценарий, не запись модели
scenario: success
stop_policy: max_steps 5, max_retries 1 (по умолчанию, глава 2)
tools: allowlist диспетчера (по умолчанию, глава 7)
Шаг 1 | read_task_cards | continue
Шаг 2 | validate_task_card | continue
Шаг 3 | validate_task_card | continue
Шаг 4 | validate_task_card | continue
Шаг 5 | build_status_report | success
Остановка: success
# Черновик статуса проекта
Всего задач: 3.
Незавершённых: 2.
Заблокированных: 1.
## Незавершённые задачи
- `task-002` — Подготовить макет афиши (in_progress)
- `task-003` — Проверить список оборудования (blocked)
## Блокеры
- `task-003`: Нет подтверждённого списка оборудования
Черновик. Отправка и изменение карточек не выполнялись.
contract: не настроено (глава 5)
save: denied | path_not_writable | tasks/dezhurny_report.md
state: не настроено (глава 10)
trace: не настроено (глава 12)
Качество модели не подтверждено этим техническим прогоном.
Здесь наблюдаемо доказан отказ записи вне разрешённой области. Этот прогон не доказывает наличие системной изоляции уровня ОС и сам прямо не подтверждает качество модели.
Ограничение числа шагов можно проверить отдельным подготовленным случаем.
# запуск из корня starter
python dezhurny.py run --dir workspace/my_agent/examples/limit2
dezhurny: run
goal: не настроено (глава 1)
config: workspace/my_agent/examples/limit2
model: replay — авторский сценарий, не запись модели
scenario: success
stop_policy: max_steps 2, max_retries 1
tools: allowlist диспетчера (по умолчанию, глава 7)
Шаг 1 | read_task_cards | continue
Шаг 2 | validate_task_card | limit
Остановка: limit
contract: не настроено (глава 5)
save: не настроено (глава 3)
state: не настроено (глава 10)
trace: не настроено (глава 12)
Качество модели не подтверждено этим техническим прогоном.
Этот вывод доказывает, что настройка предела меняет наблюдаемый терминал на limit. Он не доказывает, что выбранный предел оптимален для всех задач.
Для проверки набора случаев используется eval.
# запуск из корня starter
python dezhurny.py eval --dir workspace/my_agent/examples/full
dezhurny: eval
config: workspace/my_agent/examples/full
case report-on-clean-cards: scenario success | expected success | actual success | pass
case ask-on-ambiguity: scenario needs_input | expected needs_input | actual needs_input | pass
case stop-on-missing-cards: scenario missing_file | expected error | actual error | pass
result: 3/3
evidence: synthetic_script — проверка harness и настроек my_agent, не качество модели
Результат 3/3 доказывает прохождение именно этих подготовленных случаев для harness и настроек. Он не является оценкой поведения живой модели и не заменяет новые случаи, если ученик изменил границы задачи.
Trace пишется, только если в папке workspace/my_agent/ лежит файл 12_trace.json с текстом {"enabled": true}; без такого файла и без предшествующего запуска команда trace --last честно отвечает, что записанных запусков нет. Чтобы повторить пример ниже, создайте этот файл в рабочей копии starter и выполните две команды подряд.
# запуск из корня starter
# фикстура: tests/fixtures/ch12/12_trace.json -> workspace/my_agent/12_trace.json
python dezhurny.py run
dezhurny: run
goal: не настроено (глава 1)
config: workspace/my_agent
model: replay — авторский сценарий, не запись модели
scenario: success
stop_policy: max_steps 5, max_retries 1 (по умолчанию, глава 2)
tools: allowlist диспетчера (по умолчанию, глава 7)
Шаг 1 | read_task_cards | continue
Шаг 2 | validate_task_card | continue
Шаг 3 | validate_task_card | continue
Шаг 4 | validate_task_card | continue
Шаг 5 | build_status_report | success
Остановка: success
# Черновик статуса проекта
Всего задач: 3.
Незавершённых: 2.
Заблокированных: 1.
## Незавершённые задачи
- `task-002` — Подготовить макет афиши (in_progress)
- `task-003` — Проверить список оборудования (blocked)
## Блокеры
- `task-003`: Нет подтверждённого списка оборудования
Черновик. Отправка и изменение карточек не выполнялись.
contract: не настроено (глава 5)
save: не настроено (глава 3)
state: не настроено (глава 10)
trace: workspace/traces/dezhurny/run-001.jsonl
Качество модели не подтверждено этим техническим прогоном.
# запуск из корня starter
python dezhurny.py trace --last
trace: workspace/traces/dezhurny/run-001.jsonl
terminal: success
tool_calls: 5
errors: 0
failure_point: нет наблюдаемого отклонения
Эта команда доказывает, что в сохранённом trace наблюдаемы терминал, число вызовов, ошибки и место отклонения. Она не объясняет причину сама по себе: если отклонение есть, учитель возвращается к событиям запуска и проверяет цепочку по материалу главы 12.
7. Безопасность практикума и Урок 0¶
Рабочее место готовит школа. Python, редактор кода, командная строка и starter должны быть доступны до основного занятия; платный API, Git, pip и локальный сервер не являются обязательными входными требованиями. Если подготовка ещё не завершена, содержательная работа начинается в треке A. Инструкции установки и проверки платформы берутся только из Приложения А и здесь не дублируются.
Основные правила практикума действуют с первого урока: синтетические или обезличенные данные, только чтение по умолчанию (read-only), работа внутри учебной папки, отсутствие секретов в коде и данных, отказ от обхода школьных ограничений, решение человека перед значимым изменением. Внешний документ, skill или подключение не становится доверенным только потому, что внутри содержится убедительная инструкция.
Перед занятием учитель проверяет целостность starter командой из начала раздела 6 — только на свежераспакованном комплекте, до первого запуска.
Эта проверка не отменяет педагогическую подготовку. Даже полностью прошедшие тесты не показывают, сколько времени займёт урок, поймут ли ученики формулировку или будет ли живая модель отвечать устойчиво. Для этого нужны отдельные наблюдения в классе и реальный сеанс там, где он предусмотрен.
8. Что ещё не проверено и как учитель помогает пилоту¶
Программы и тексты курса проверены; не хватает двух свидетельств, которые можно получить только в жизни. Поле classroom_pilot_pending означает, что уроки 1–4 ещё должны пройти классный пилот с наблюдением хронометража и нагрузки. Поле live_model_evidence_pending означает, что требуется подтверждённый ручной сеанс с живой моделью. Пока оба свидетельства не получены, publication_ready остаётся false.
Состояние можно увидеть в кратком отчёте:
# запуск из корня starter
python eval_runner.py --summary
harness: 6/6 passed
model_behavior: not_evaluated (verified_sessions: 0; scripted: 3, excluded from scoring)
publication_ready: false (classroom_pilot_pending, live_model_evidence_pending)
Этот вывод доказывает, что технические проверки harness пройдены и что два внешних свидетельства ещё открыты. Он не означает, что главы книги «не готовы», и не позволяет закрыть эти два пункта текстом, replay-сценарием или дополнительным эталонным выводом. Классный пилот должен дать наблюдение за реальными учениками, а bridge-сеанс — реальное свидетельство работы с живой моделью.
Для подготовки к урокам в этом руководстве есть поурочная карта, конспект глав с одной страницей на каждую главу и список фигур со страницами книги. Они помогают быстро увидеть, что делать на уроке, что вводится, что запрещено, какой наблюдаемый продукт ожидается и где в книге расположена схема. Эти материалы не заменяют текст глав и не создают новых требований к ученику.
Перед стартом класса удобно проверить четыре вещи: рабочее место подготовлено по Приложению А; выбран маршрут 34 или 18 часов; понятно, как класс разделится между треками A и B; для обязательного bridge предусмотрен доступный живой чат или заранее назначена школьная сессия. После этого курс можно вести по единому принципу: каждое сильное утверждение должно опираться на наблюдаемое доказательство, а граница этого доказательства проговаривается так же явно, как сам результат.
Если вы ведёте пилотные уроки 1–4, после каждого урока заполните одну страницу: сколько минут ушло на каждый блок урока против плана; что из практик A и B группы успели, а что нет; на чём ученики споткнулись — какая команда, какая строка вывода, какая фраза книги вызвала вопрос. Нужны факты, а не общие впечатления: по ним авторы исправляют книгу.