Как мы перестроили процесс создания контента для школьной платформы

Я строю образовательную платформу для дочери. Сербская школьная программа с первого по восьмой класс — математика, язык, природа и общество, всё что входит в основную школу. Начала с математики четвёртого класса. Стек — Next.js 15, Supabase, Tailwind, KaTeX для формул. Claude — соавтор контента: теория, упражнения, тесты, подсказки, переводы на русский.

За три дня в начале марта мы создали семнадцать навыков по трём темам — уравнения, умножение, деление. Каждый навык включает секции теории, несколько тестов и по двадцать с лишним упражнений. Всё это хранится в Supabase и попадает туда через SQL seed-файлы. Выглядело это вполне рабочим — пока я не начала смотреть на результаты внимательнее.

Что пошло не так

Проблемы оказались двух видов: технические и педагогические.

Технические были однотипными. В seed-файлах использовались E-строки с буквальными \n вместо chr(10) — это работало, но нарушало формат, который мы к тому моменту уже зафиксировали как эталонный. Поля media содержали NULL вместо пустого JSON-массива '[]'. Для чисел больше тысячи мы не прописали варианты ответа с разделителем-точкой (в сербской записи 1.000 вместо 1000) — ребёнок мог ввести правильный ответ и получить ошибку.

Педагогические проблемы были серьёзнее. Теория каждого навыка начиналась с абстрактного определения: «Једначина је…». Четвероклассник не начинает с определений — он начинает с ситуации: на полке стояли книги, несколько забрали, сколько осталось? Подсказки к упражнениям были дежурными — «Размисли поново» вместо конкретного указания на ошибку. Упражнения не были связаны с теорией: в теории фигурировали одни числа и примеры, а в упражнениях совершенно другие.

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

Почему модель ни при чём

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

А впереди — ещё семь классов и несколько предметов. Если процесс не работает на пяти темах по математике, он не выдержит масштаб всей программы.

Вопрос был не в том, чтобы найти модель получше, а в том, чтобы дать существующей модели рабочую среду — справочники, источники, алгоритм и контроль качества.

Что мы перестроили

Перестройка заняла один день и затронула три вещи.

Библиотека источников. Мы спроектировали систему из двух файлов. Первый — reference.md — содержит терминологию (около восьмидесяти математических терминов на сербском с переводом на русский), правила и свойства из учебника в точных сербских формулировках, и фразеологический блок: шаблоны типовых фраз для условий задач, инструкций, теории, подсказок. Второй — index.md — карта всех тем учебника с привязкой к файлам-источникам и статусом покрытия.

Все источники (PDF учебников, документы с задачами) конвертируются в Markdown и складываются в папку converted/. Claude читает их напрямую — без промежуточных шагов, без потери контекста на распаковку PDF каждый раз.

Паттерн спроектирован так, чтобы переноситься на другие предметы: у каждого будет свой reference.md с терминологией и свой index.md с источниками.

Это решение мы выработали в ходе брейнсторм-сессии. Я задавала вопрос за вопросом: кто основной потребитель файла — ты или я? один файл или несколько? что фиксировать о каждом источнике? Claude предлагал варианты, я просила его перепроверить каждый, и он сам находил слабые места в своих предложениях. Например, изначально он предполагал, что страницы в книге решений совпадают с учебником, — а когда мы проверили PDF, оказалось, что нумерация полностью своя.

Специализированный скилл. Вместо генерации контента «на лету» мы создали school-create-math — формализованный алгоритм из пяти шагов. Нулевой шаг — загрузка контекста: справочник терминологии, эталон SQL-формата, текущее состояние платформы. Первый — поиск источников по теме и анализ концепций. Второй — написание теории по 5-шаговой логике: зацепка из жизни, разобранный пример, правило, контрпример, проверка понимания. Третий — генерация SQL (отдельно от текста, чтобы не смешивать). Четвёртый — самопроверка по чеклисту.

Между шагами стоят жёсткие блокировки: нельзя перейти к SQL, пока текст теории не прошёл проверку на AI-паттерны. Нельзя смешивать написание текста и генерацию кода в одном шаге. Эти ограничения появились из конкретного опыта: когда Claude пишет теорию и SQL одновременно, качество текста падает.

Цепочка контроля качества. Два дополнительных скилла: school-reviewer для регрессионной проверки и накопления паттернов, и school-qa — обязательный чеклист перед каждым коммитом. Ни один навык не попадает в базу данных, не пройдя оба.

Результат

Семнадцатый навык — «Деление с остатком» — мы создали уже по новому процессу. Теория начинается с ситуации: дети делят яблоки, и одно остаётся. Каждое упражнение связано с теорией по примерам. Подсказки конкретные: «Подели 47 на 8. Сколько целых восьмёрок помещается? Умножь обратно и найди остаток». Терминология единообразная, потому что Claude читает справочник в начале работы, а не вспоминает по памяти.

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

Что из этого следует

Три вещи, которые переносятся на любой проект, где AI генерирует контент.

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

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

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

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