# Aналитический отчёт Paideia v2.3-RC2

**AnalysisRun:** `ar-f9859e0e20`  
**Lineage:** `lin-d5c94da23e` — Инвестиционный симулятор рынка недвижимости  
**Mode:** SEMINAR_PREP  
**Rendered at:** 2026-08-22T19:52:10+00:00  
**Versions in scope:** 4 · **Discussion units:** 0 · **Recommendation fates:** 0 · **Mutation side effects:** 0 · **Lab status:** `NO_BUILD`

---

## 2. Шапка

| Поле | Значение |
| :--- | :--- |
| **Проект** | Инвестиционный симулятор рынка недвижимости |
| **Автор** | Вилков И.Н. |
| **Институция** | [требует проверки — не указана в материалах] |
| **Дисциплина** | Экономика и управление недвижимостью (общеуниверситетский электив) |
| **Дата версии** | [требует проверки — не указана в метаданных документов] |
| **Тип проекта** | Проект педагогического эксперимента |
| **Версия отчёта** | Paideia v2.3-RC2 |

## 3. Аннотация

Проект предлагает внедрить в учебный курс «Экономика и управление недвижимостью» инвестиционный симулятор, построенный на гибридной архитектуре. Гибридная архитектура — это система, где детерминированная модель (формулы расчёта) сочетается с генеративной моделью (ИИ-агент на базе большой языковой модели), выполняющей роль тьютора. Цель — преодолеть разрыв между теоретическими знаниями студентов об оценке активов и их неспособностью применять эти знания в динамичной, рискованной среде. Проблема в том, что стандартные кейсы статичны и не моделируют ключевые особенности рынка недвижимости: длинный горизонт планирования, инерционность, чувствительность к макроэкономическим шокам (изменение ставок, инфляция, кризисы). В рамках квазиэксперимента студенческие команды (2-4 человека) проходят 10 раундов симуляции, где каждый раунд равен одному году. Они управляют инвестиционным портфелем, принимая решения о покупке, продаже и аренде реальных объектов, взятых с ЦИАН и Авито, в условиях меняющихся макроэкономических сценариев. Исследовательский вопрос сфокусирован на том, как использование такого симулятора влияет на способность студентов обосновывать решения, оценивать риски и прогнозировать результаты.

Сильное ядро проекта — методологически корректный ответ на образовательный дефицит. Десятилетняя петля обратной связи, характерная для реальных инвестиций в недвижимость, сжимается до нескольких практических занятий. Это позволяет студентам увидеть долгосрочные последствия своих решений, сохраняя при этом причинно-следственные связи. Заземление симуляции на реальные, пусть и зафиксированные в моменте, объекты с открытого рынка защищает от обучения на абстрактных, «идеальных» моделях. Теоретическая рамка (деятельностный подход, ситуационное обучение, теория когнитивной нагрузки) не декоративна: она прямо обосновывает симулятор как инструмент, опосредующий деятельность, реалистичную среду как условие обучения, а автоматизацию рутинных расчётов — как способ высвободить когнитивный ресурс для стратегического мышления. Множественные метрики (экспертный балл за обоснование, точность прогноза, итоговый капитал) не позволяют студентам оптимизировать поведение под один-единственный показатель.

Несущий разрыв проекта заключён в его технологической реализации. Симулятор, который достоверно моделирует динамику рынка недвижимости со всеми его факторами (арендные ставки, вакантность, налоги, амортизация, ликвидность), — это самостоятельный, ресурсоёмкий R&D-проект, выходящий за рамки одного преподавателя и одного семестра. С другой стороны, чрезмерное упрощение модели превращает симулятор в игру, где студенты учатся не понимать рынок, а «взламывать» заложенные в него примитивные правила. Проект пытается построить авиасимулятор, но сталкивается с выбором: либо писать с нуля полноценный физический движок, что является отдельным R&D-проектом, либо показывать студентам заранее отрисованный мультфильм про полёт. Первое — невозможно в рамках курса, второе — не учит пилотированию. Этот разрыв также проявляется в работе с данными: реальные объявления с ЦИАН устаревают, что делает эксперимент трудновоспроизводимым.

Первый осмысленный эксперимент должен быть направлен не на полномасштабное внедрение, а на проверку ключевой педагогической гипотезы в облегчённых условиях. Для этого необходимо принять решение о технологической платформе симулятора. Наиболее прагматичный путь для пилота — использование легковесной версии на базе большой языковой модели (LLM) с жёстко заданными сценарными карточками и фиксированным на момент старта набором («снэпшотом») объектов недвижимости. Это позволит проверить, действительно ли циклы «решение → последствие → рефлексия с ИИ-тьютором» приводят к росту качества аргументации и точности прогнозов, не увязая в разработке сложной экономической модели.

Текущая готовность проекта — концептуальная. Педагогический дизайн, теоретическое обоснование, исследовательский вопрос и метрики проработаны на достаточном уровне для обсуждения. Главный барьер для перехода к пилотному запуску — отсутствие решения по технологической реализации симулятора. Проект находится в точке бифуркации: либо он движется в сторону прагматичного, быстро реализуемого пилота для проверки педагогической ценности, либо рискует застрять на этапе проектирования из-за несоответствия амбиций (полноценная модель рынка) и ресурсов (один преподаватель, один семестр).

## 4. Состав и статус источников

Анализ основан на пакете документов, включающем текстовое описание проекта (`Инвестиционный симулятор рынка недвижимости.docx`) и презентацию (`Инвестиционный симулятор рынка недвижимости.pptx`). Эти материалы рассматриваются как основное и верифицированное предъявление авторского замысла. Анализ также учитывает эволюцию проекта через несколько версий, что указывает на стабильность его защищённого ядра и ключевых идей.

В представленных материалах отсутствует ряд критически важных для оценки и воспроизводимости эксперимента компонентов:

1.  **Техническая спецификация симулятора.** Неясно, является ли симулятор готовым продуктом, собственной разработкой или конфигурацией на базе LLM. От этого напрямую зависит реалистичность модели и, как следствие, то, чему именно научатся студенты — понимать рынок или обходить ограничения конкретного инструмента.
2.  **Источник и модель макроэкономических данных.** Не указано, используются ли прогнозы ЦБ РФ, Росстата, или авторская модель. Отсутствие информации о валидации этих данных не позволяет оценить, насколько симулируемые «шоки» соответствуют реальной экономической логике.
3.  **Рубрикатор для экспертной оценки.** Заявлена метрика «экспертный балл» за аргументированность, но отсутствуют чёткие критерии (рубрика) для его выставления. Без этого оценка становится субъективной, а результаты эксперимента — невоспроизводимыми и статистически недостоверными. Невозможно обеспечить согласованность оценок между разными экспертами (inter-rater reliability).
4.  **Механизм обеспечения сопоставимости кейсов.** Не описано, как обеспечивается эквивалентность по сложности и содержанию кейсов, используемых для пред-теста (T0) и пост-теста (T1), особенно с учётом использования разных рыночных данных.

Отсутствие этих элементов не позволяет перейти к полноценному пилотированию, так как ключевые части измерительного инструмента и самого воздействия не определены. Диагностика проекта с позиций функциональной архитектуры и педагогического дизайна дополнительно выявила, что не формализован полный человеко-машинный цикл (кто какую операцию выполняет, где точки передачи ответственности) и не определён наблюдаемый след деятельности студента, который должен меняться в результате эксперимента.

---

## 5. Буквальная реконструкция

### 5.1 Что заявлено

Автор представляет проект «Инвестиционный симулятор рынка недвижимости» для общеуниверситетского элективного курса «Экономика и управление недвижимостью». Проект нацелен на устранение разрыва между теоретическими знаниями студентов и их практическим применением.

**Проблема:** В описании проекта указано, что студенты, освоив теорию и алгоритмы оценки, не способны применять их в динамичной, рисковой среде. Статичные кейсы не отражают влияние макроэкономических шоков (инфляция, изменение ставок), не дают опыта управления портфелем и выбора между стратегиями (флиппинг, аренда), а также не позволяют увидеть долгосрочные (5-10 лет) последствия принятых решений.

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

**Исследовательский вопрос:** «Как использование ИИ-симулятора инвестора на рынке недвижимости (с загрузкой реальных макроэкономических данных и сценариев) влияет на способность студентов обоснованно принимать инвестиционные решения, оценивать риски и прогнозировать финансовые результаты в условиях неопределённости?».

**Гипотеза:** «Внедрение симулятора приводит к статистически значимому повышению качества обоснования решений и точности прогнозирования».

**Вмешательство (интервенция):** Внедрение в учебный процесс «гибридного ИИ-симулятора с макроэкономическими сценариями и ИИ-тьютором (LLM)». Симулятор моделирует рыночную динамику, а ИИ-тьютор обеспечивает «аналитическую обратную связь, рефлексию и поддержку в процессе обучения».

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

**Заявленная функция ИИ:** Описана «гибридная архитектура», включающая:
1.  Симулятор с моделью динамики рынка и формулами изменения цен.
2.  Агентный пайплайн для управления процессом симуляции.
3.  Аналитику макроэкономических сценариев.
4.  ИИ-персону (тьютора) на базе LLM для персонализированной обратной связи.

**Теоретическая рамка:** Автор ссылается на деятельностный подход (Леонтьев, Энгстрём), теорию ситуационного обучения (Лэйв, Венгер), теорию когнитивной нагрузки (Свеллер) и конструктивизм.

### 5.2 Что показано в артефактах

Предъявлены документы «Инвестиционный симулятор рынка недвижимости.docx» и «Инвестиционный симулятор рынка недвижимости.pptx». На их основе реконструируется следующий дизайн эксперимента:

**Формат:** Квазиэксперимент со смешанным дизайном (pre/post-тестирование) на одном потоке студентов (20-30 человек), работающих в командах по 2-4 человека. Заявлена возможность выделения контрольной и экспериментальной подгрупп.

**Этапы эксперимента:**
1.  **T0 (Pre-test):** Студенты решают стандартный кейс и проходят анкетирование.
2.  **Обучение:** Проводится инструктаж по работе с симулятором.
3.  **Симуляция:** Команды проходят 10 раундов симуляции, где каждый раунд эквивалентен одному году. В процессе используются реальные объекты, взятые с платформ ЦИАН и Авито.
4.  **T1 (Post-test):** Студенты решают аналогичный кейсу T0, но с новыми данными. Проводится защита инвестиционной стратегии и повторное анкетирование.

**Метрики оценки:**
*   **Экспертный балл:** Оценивается «аргументированность выбора, источники данных, альтернативные стратегии, риск кредитного плеча» в финальной защите.
*   **Точность прогноза:** Сравнение заявленной командой доходности с фактической доходностью, полученной в симуляторе.
*   **Финансовый результат:** Итоговый капитал команды после 10 раундов симуляции.
*   **Вовлечённость:** Измеряется через опросник.

**Статистический анализ:** Для оценки изменений заявлено использование t-критерия для зависимых выборок и качественный анализ презентаций по итогам защиты.

### 5.3 Что осталось не проговорено

На основе представленных материалов невозможно сделать однозначные выводы по ряду критических моментов.

**Реализация симулятора:**
*   **Техническая основа:** Неясно, является ли симулятор собственной разработкой, готовым коммерческим продуктом или конфигурацией на базе большой языковой модели (LLM). От этого выбора напрямую зависит реалистичность модели, её предсказуемость и затраты на поддержку.
*   **Модель рынка:** Не раскрыто, насколько полно и адекватно макроэкономические сценарии моделируют реальные рыночные условия. Неизвестны конкретные формулы и правила, по которым изменяются цены на объекты, арендные ставки, вакантность, налоги и прочие параметры.
*   **Источники данных:** Не указан источник макроэкономических прогнозов (ЦБ РФ, Росстат, Дом.РФ или собственная модель) и процедуры их валидации.

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

**Дизайн эксперимента:**
*   **Сравнимость кейсов:** Не описан механизм обеспечения сравнимости кейсов на этапах T0 (до) и T1 (после) при использовании разных исходных данных.
*   **Распределение на группы:** Не определены критерии разделения студентов на контрольную и экспериментальную группы, если такое разделение будет проводиться. Альтернатива — сравнение с результатами предыдущего потока — также не детализирована.
*   **Оценка:** Не представлена рубрика или чёткие критерии для операционализации «обоснованности» и «точности» в экспертной оценке. Также не затронут вопрос согласованности оценок между разными экспертами (inter-rater reliability).
*   **Проблема устаревания данных:** Не решён вопрос с тем, что реальные объявления с ЦИАН и Авито быстро теряют актуальность, что затрудняет воспроизводимость эксперимента и сравнение результатов между разными потоками курса.

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

## 6. Сильнейшая благожелательная реконструкция

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

#### Что автор предъявил

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

#### Reformulation

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

#### Критика

**Утверждение:** В проекте заявлена «гибридная архитектура», объединяющая симулятор и ИИ-тьютора.

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

**Аналогия:** Это не гибридный двигатель, а двигатель внутреннего сгорания (симулятор) и пристёгнутый к нему скотчем навигатор (ИИ-тьютор). Они не образуют единой системы тяги. Навигатор может давать советы, куда ехать, но он не управляет подачей топлива. Поломка навигатора не остановит двигатель, а ошибка в расчётах двигателя сделает советы навигатора бесполезными. Проект должен описывать не «гибрид», а протокол взаимодействия между водителем (студент), двигателем (симулятор) и навигатором (тьютор).

#### Альтернативные объяснения / гипотезы

Даже если эксперимент покажет положительную динамику, это не обязательно будет следствием заявленного механизма. Возможны иные объяснения:

-   **Альтернатива A: Эффект новизны и внимания (Эффект Хоторна).** Студенты показывают лучшие результаты просто потому, что участвуют в новом, интересном формате обучения, который подразумевает повышенное внимание со стороны преподавателя. Сам факт участия в «эксперименте с ИИ» мотивирует их работать усерднее, независимо от реальной эффективности симулятора.
-   **Альтернатива B: Эффект геймификации и научения инструменту.** Студенты учатся не понимать рынок недвижимости, а «обыгрывать» конкретную модель симулятора. Они находят её уязвимости, паттерны и упрощения, оптимизируя свои действия под правила игры, а не под рыночную логику. Навык, который они приобретают, — это навык прохождения данной конкретной игры, который не обязательно переносим на реальные задачи.
-   **Альтернатива C: Эффект социального конструирования знания.** Основной прирост в качестве решений происходит не из-за взаимодействия с ИИ, а благодаря работе в команде и необходимости готовить финальную защиту. Обсуждение стратегий, споры, совместный поиск информации и подготовка аргументов для презентации — вот настоящий механизм обучения. Симулятор в этой схеме выступает лишь как общий объект, вокруг которого строится коммуникация.

#### Пересборка

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

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

#### Педагогическая гипотеза

Основной учебной единицей является цикл рефлексивного анализа. Этот цикл не зависит от технологии и может быть воспроизведён с преподавателем или даже с помощью бумажных карточек. Он состоит из пяти шагов:
1.  **Прогноз:** Перед каждым раундом команда письменно фиксирует свой прогноз по ключевым параметрам (цена, аренда) для своих объектов и рынка в целом, основываясь на макроэкономической сводке.
2.  **Решение:** На основе прогноза команда принимает и обосновывает инвестиционное решение (купить, продать, держать, рефинансировать).
3.  **Результат:** Симулятор обрабатывает решение и показывает фактический финансовый результат по итогам «года».
4.  **Фиксация разрыва:** Команда сравнивает свой исходный прогноз с фактическим результатом и количественно оценивает расхождение.
5.  **Атрибуция:** Команда должна письменно объяснить причину разрыва. Что было не учтено в прогнозе? Какое макроэкономическое событие оказало ключевое влияние? Была ли ошибка в расчётах или в самой модели мира?

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

#### ИИ/технологическая гипотеза

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

**Гипотеза о симуляторе (детерминистичная часть):** Автоматизация расчёта последствий и скрытие будущих состояний рынка позволяют реализовать честный цикл «решение-результат» в масштабе целой группы, освобождая когнитивный ресурс студентов и преподавателя от рутинных вычислений для фокусировки на стратегии.

**Гипотеза об ИИ-тьюторе (вероятностная часть):** LLM-агент может обеспечить масштабируемую и персонализированную поддержку рефлексии, недоступную одному преподавателю. Его функции и проверяемые гипотезы:
1.  **Политика отказа:** Тьютор должен отказывать в ответах на прямые вопросы о будущем («Что будет с ценами в следующем раунде?») или о лучшей стратегии («Что нам лучше купить?»), переформулируя их в вопросы к самому студенту («Какие факторы вы учитываете, чтобы ответить на этот вопрос?»). **Гипотеза:** Отказ от прямых ответов стимулирует самостоятельное мышление, а не поиск подсказок.
2.  **Детектор слабых мест:** Тьютор автоматически анализирует разрыв между прогнозом и фактом и задаёт целенаправленные вопросы. Если прогноз по аренде разошёлся с фактом на 30%, тьютор спросит: «Ваш прогноз по аренде оказался сильно завышен. Какие три фактора из макро-сводки вы могли недооценить?». **Гипотеза:** Целенаправленные вопросы более эффективны для коррекции ментальных моделей, чем общая обратная связь.
3.  **Дозирование помощи:** Тьютор отслеживает качество атрибуций. Если команда два раунда подряд не может объяснить причину своего провала, тьютор может предложить ей фреймворк для анализа (например, «Проанализируйте ваше решение с точки зрения PEST-анализа»). Если команда успешна, тьютор снижает свою активность. **Гипотеза:** Адаптивное дозирование помощи удерживает студента в зоне ближайшего развития.

Эксперимент должен быть построен так, чтобы можно было попытаться разделить эти эффекты.

#### Требует решения автора

1.  Что является главным результатом обучения: финансовый успех в симуляторе или способность студента написать качественный аналитический отчёт, объясняющий причины (в том числе и проигрышной) динамики своего портфеля?
2.  Какая операция для вас важнее: точный расчёт доходности (функция симулятора) или качественная рефлексия о причинах ошибок (функция тьютора)? От этого зависит, куда направлять основные усилия по разработке.
3.  Готовы ли вы в рамках эксперимента ввести три группы: (А) контрольная, без симулятора, (Б) только симулятор, (В) симулятор + ИИ-тьютор? Это единственный способ доказать уникальную ценность именно тьютора.
4.  Какова должна быть политика ИИ-тьютора, если он обнаружит, что студенты пытаются не моделировать рынок, а «взломать» механику симулятора? Должен ли он сообщить об этом преподавателю, или попытаться вернуть их к учебной задаче?

## 7. Онтологическая и предметная постановка

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

#### Что автор предъявил

Автор заявляет, что проект формирует у студентов способность «принимать инвестиционные решения в условиях неопределённости». Предметом является рынок недвижимости, а объектом изменения — навыки студентов.

#### Reformulation

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

#### Критика

**Утверждение:** Проект использует «гибридную архитектуру» и «ИИ-симулятор».

**Возражение:** Эти термины создают онтологическую путаницу, представляя систему как единого «знающего» субъекта. На самом деле, в проекте сосуществуют как минимум три разных типа «знания» и три разных носителя:
1.  **Знание-как-формула:** Зашито в коде симулятора. Это жёсткие, детерминированные правила. Симулятор «знает», как изменится цена при росте ставки на 1%, потому что это прописано в его алгоритме. Это знание негибкое и полное в пределах своей модели.
2.  **Знание-как-статистика-языка:** Находится в весах LLM-тьютора. Тьютор «знает», как строить грамматически верные и релевантные диалоговые ходы. Он не понимает экономику, но может мастерски имитировать разговор о ней, опираясь на поданный ему контекст.
3.  **Знание-как-ментальная-модель:** Формируется в голове у студента. Это гибкое, неполное, постоянно уточняемое представление о том, как устроен рынок. Это единственное знание, которое может быть перенесено за пределы симулятора.

Проект в его текущем виде не проводит чёткой границы между этими тремя сущностями. Это приводит к риску подмены: можно принять способность тьютора красиво формулировать выводы за реальное понимание студента.

**Аналогия:** Представим экзамен по вождению, где инструктор (ИИ-тьютор) даёт голосовые подсказки, а педали и руль (симулятор) частично автоматизированы и реагируют на его команды. Студент сидит в кресле и комментирует происходящее. Если машина успешно проехала маршрут, кто на самом деле сдал экзамен: студент, инструктор или автоматика? Проект должен быть устроен так, чтобы было однозначно понятно, кто «крутит руль».

#### Альтернативные объяснения / гипотезы

В зависимости от того, что мы считаем реальным «предметом» в этой системе, можно выдвинуть разные гипотезы о том, что на самом деле происходит.

-   **Альтернатива A: Предмет — это интерфейс (инструментальная онтология).** Студенты на самом деле учатся работать с конкретным программным продуктом: симулятором. Они осваивают его кнопки, меню, логику отчётов. Носителем компетенции становится человек, умеющий эффективно «кликать» и извлекать данные из данного конкретного инструмента. Этот навык полезен, но он не является навыком инвестиционного анализа.
-   **Альтернатива B: Предмет — это аргументация (социальная онтология).** Реальный предмет конструируется в диалоге между студентами в команде и в их финальной защите перед преподавателем. Симулятор и тьютор — это лишь «поставщики фактуры», поводы для разговора. Носителем компетенции является команда, способная выработать и защитить согласованную позицию.
-   **Альтернатива C: Предмет — это личная эвристика (когнитивная онтология).** Предметом является набор личных правил и «чуйки» («rules of thumb»), которые студент вырабатывает в процессе игры. Например: «если ставка ЦБ растёт, надо избавляться от ипотечных квартир». Носителем компетенции является студент, а симулятор — это среда для быстрой проверки и фальсификации этих эвристик.

#### Пересборка

Сильная версия проекта должна явно определить онтологию своей предметной области. Для этого необходимо различить следующие сущности и их роли:

1.  **Рынок-в-Модели:** Детерминированный мир симулятора. У него есть свои «законы физики» (формулы), которые могут быть известны студентам или нет. Его функция — быть предсказуемым, но не тривиальным полигоном.
2.  **Рынок-в-Данных:** Поток информации о макроэкономике (сводки ЦБ, Росстата) и микроуровне (объявления с ЦИАН). Это «сырьё», которое студент должен интерпретировать.
3.  **Стратегия-как-План:** Исходный документ, который команда готовит перед началом симуляции. Это их гипотеза о том, как они будут действовать.
4.  **След-в-Системе:** Лог всех решений, прогнозов, финансовых результатов и диалогов с тьютором. Это объективный цифровой отпечаток деятельности команды.
5.  **Рефлексия-о-Разрыве:** Аналитическая записка или устная защита, где команда объясняет расхождение между Планом, Следом и итоговым результатом, апеллируя к Данным.

В этой онтологии **носителем итоговой компетенции является студент (или команда), способный произвести качественную Рефлексию-о-Разрыве**. Не тот, кто больше всех заработал, а тот, кто может наиболее полно и аргументированно объяснить, почему он заработал или потерял.

Роль симулятора — генерировать След и разрывы. Роль ИИ-тьютора — быть катализатором Рефлексии, задавая вопросы, которые помогают связать все пять сущностей в единое повествование. Это переводит фокус с «игры на деньги» на «работу с моделями».

#### Требует решения автора

1.  Кто является носителем «памяти» о прошлых раундах и принятых решениях? Должен ли студент сам вести учёт, или это делает за него система (ИИ-тьютор)? Ответ на этот вопрос определяет, тренируем ли мы организационные навыки или только аналитические.
2.  Что является первичным «предметом» оценки на финальной защите: финансовый результат или качество анализа причин, которые к нему привели?
3.  Если студент нашёл эксплойт в логике симулятора (например, обнаружил, что покупка любого объекта в первом раунде и продажа в пятом всегда даёт максимальную прибыль) и выиграл, но не может объяснить это с точки зрения рыночной логики, — это учебный успех или провал?
4.  Должен ли ИИ-тьютор «знать» о реальном рынке за пределами симулятора, или его мир должен быть строго ограничен миром Рынка-в-Модели и Рынка-в-Данных?

## 8. Что действительно сильное

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

1.  **Фокус на реальном образовательном дефиците.** Проект атакует не надуманную, а остро стоящую проблему разрыва между академическим знанием и способностью действовать в динамической, непредсказуемой среде. Это запрос от реальной практики.

2.  **Корректный временной масштаб симуляции.** Выбор структуры «10 раундов по 1 году» является методологически верным. Более короткий горизонт не позволил бы проявиться макроэкономическим эффектам и последствиям долгосрочных стратегий, превратив симуляцию в простую тактическую игру.

3.  **Заземление на реальных данных.** Использование актуальных на момент старта объектов с ЦИАН и Авито, а также реальных макроэкономических сценариев, предотвращает отрыв упражнения от наблюдаемой реальности и обучение на абстрактных, «сферических» примерах.

4.  **Имитация реальной практики через командную работу.** Формат работы в малых группах (2-4 человека) моделирует деятельность инвестиционных комитетов или партнёрств, где решения требуют обсуждения, согласования позиций и разделения ответственности.

5.  **Механизм принудительной рефлексии.** Требование финальной защиты стратегии — это сильный ход, который заставляет студентов не просто «кликать» по кнопкам в погоне за результатом, а вербализовать, структурировать и обосновывать логику своих действий за весь период симуляции.

6.  **Защита от одноклеточной оптимизации.** Использование множественных метрик (экспертный балл за аргументацию, точность прогноза, итоговый капитал) не позволяет студентам свести всю стратегию к бездумному риску ради максимальной прибыли, игнорируя качество анализа.

7.  **Функциональная теоретическая рамка.** Упомянутые теории (деятельностный подход, ситуационное обучение, когнитивная нагрузка) используются не как декорация, а для обоснования ключевых элементов дизайна: симулятор как опосредующий инструмент, среда как аутентичное «сообщество практики», автоматизация рутины для высвобождения ресурса на стратегическое мышление.

8.  **Прозрачный и воспроизводимый дизайн эксперимента.** Схема pre/post-теста с понятными этапами и метриками является стандартным и адекватным способом оценки эффекта образовательного вмешательства, понятным для академического сообщества.

---

## 9. Несущий разрыв

### 9.1 Симптом

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

### 9.2 Наблюдаемый дефицит

В представленных материалах отсутствует описание того, как эти два компонента связаны и как между ними разделена ответственность. Не определена природа их взаимодействия:
1.  **Дефицит модели рынка:** Нет описания математической модели, по которой «симулятор» обсчитывает последствия решений. Неясно, как макроэкономические сценарии (изменение ставки, инфляция) транслируются в конкретные изменения цен на объекты, арендных ставок, сроков экспозиции. Без этого модель — «чёрный ящик».
2.  **Дефицит модели тьютора:** Не определены принципы работы «ИИ-тьютора». Неясно, на какие данные он опирается для своей обратной связи: только на текст, который пишет ему команда, или он имеет доступ к «мыслям» симулятора (внутренним переменным модели)? Не определена его политика: он должен быть «добрым» наставником, «злым» критиком, или нейтральным зеркалом?
3.  **Дефицит связи:** Отсутствует протокол взаимодействия между моделью и тьютором. Если тьютор хвалит команду за «хорошую» стратегию, а модель показывает убыток, — кто прав? Чьей логике должен научиться участник: логике рынка (зашитой в модель) или логике убеждения (зашитой в тьютора)?

### 9.3 Организационный разрыв

Автор проекта выступает одновременно в трёх ролях, которые находятся в конфликте:
1.  **Предметный эксперт (экономист):** Определяет, какие рыночные механизмы важны.
2.  **Педагог:** Проектирует учебный опыт, который должен привести к изменению способностей обучающихся.
3.  **Архитектор гибридной системы:** Решает, какие функции отдать человеку, какие — вычислительной модели, а какие — диалоговому агенту.

Разрыв возникает из-за того, что роль архитектора не отрефлексирована как отдельная. Решения о дизайне системы принимаются из педагогической или предметной логики, игнорируя технические и функциональные противоречия. Например, желание дать «персонализированную обратную связь» (педагогика) приводит к идее «ИИ-тьютора», но не отвечает на вопрос, на каком основании (data foundation) этот тьютор будет генерировать свои суждения, чтобы они не противоречили «правде» симулятора.

### 9.4 Reformulation — более сильная формулировка проблемы

Более сильная проблема такова: проект пытается одновременно решить две разные задачи, упаковав их в один термин «гибридный симулятор». Первая задача — **создание калькулятора последствий** (детерминированной или стохастической модели рынка). Вторая — **создание рефлексивного партнёра** (диалогового агента для развития аргументации). Проект неявно предполагает, что это части одного целого, в то время как они функционально, технически и педагогически раздельны. Их смешение создаёт фундаментальную двусмысленность: чему учатся участники — моделировать рынок или договариваться с интерфейсом?

Это как если бы в автошколе инструктор по вождению и спидометр были объединены в один говорящий прибор. И этот прибор говорил бы: «Вы хорошо едете, мне нравится ваш стиль», — но при этом его стрелка показывала бы превышение скорости на 100 км/ч. Ученик оказывается в шизофренической ситуации: кому верить и чьи правила выполнять? Цель обучения размывается.

### 9.5 Воспроизводящий механизм

Разрыв воспроизводится совокупностью следующих факторов:
*   **Терминологическая ловушка:** Термин «ИИ» позволяет упаковать под одну этикетку и вычислительную модель на формулах, и большую языковую модель, создавая иллюзию единой технологии.
*   **Фокус на интерфейсе:** Привлекательность диалогового интерфейса (тьютора) заслоняет необходимость в проработке «скучной» математической модели рынка под капотом.
*   **Педагогический идеализм:** Вера в то, что «рефлексивный диалог» сам по себе является ценностью, вне зависимости от того, насколько он привязан к объективной реальности (в данном случае — к модели рынка).
*   **Иллюзия «реальных данных»:** Использование объектов с ЦИАН создаёт ощущение аутентичности, но это аутентичность входных данных, а не модели их обработки. Это как если бы для прогноза погоды использовали самые точные термометры, но забыли про уравнения гидродинамики.
*   **Неявное наследование:** Проект наследует популярный паттерн «RAG-чат по документам», где языковой модели скармливают некую базу знаний. Но здесь база знаний — это не статические тексты, а динамическая, работающая модель мира. Попытка применить тот же паттерн напрямую приводит к разрыву.

### 9.6 Онтологический слом

#### Что автор предъявил
Автор заявляет, что участники учатся «обоснованно принимать инвестиционные решения». Носителем этой способности в итоге должен стать выпускник курса.

#### Reformulation
Проблема в том, что в гибридной сцене, описанной в проекте, неясно, кто или что является носителем «обоснованности». Если «ИИ-тьютор» помогает сформулировать аргументы, а «симулятор» рассчитывает результат, то когнитивная работа распределена между тремя акторами: человеком, тьютором и симулятором. После окончания курса у человека забирают двух его «когнитивных протезов». Останется ли у него способность действовать самостоятельно? Проект не даёт ответа, потому что не определяет, какая именно часть работы должна быть интериоризирована (присвоена) человеком.

#### Критика
Утверждение: «*ИИ-тьютор организует рефлексивный диалог, повышая качество аргументации*».
Возражение: Это утверждение смешивает средство и цель. Диалог с тьютором может повысить качество *текста* с аргументацией, который увидит преподаватель. Но он не гарантирует повышения качества *мыслительного процесса*, который стоит за этим текстом. Участник может научиться генерировать правдоподобные на вид обоснования для тьютора, не имея реальной модели в голове. Это обучение «прохождению собеседования», а не инвестиционному анализу.

#### Альтернативные объяснения / гипотезы
- **Альтернатива A (Инструментальная):** Участники не осваивают «обоснованность», а учатся эффективно пользоваться конкретным программным комплексом (симулятор+тьютор). Их результат непереносим в среду без этого комплекса.
- **Альтернатива B (Социальная):** Ключевой эффект даёт не взаимодействие с машиной, а работа в команде. Участники учатся договариваться и аргументировать свою позицию друг другу, а машина — лишь повод и декорация.
- **Альтернатива C (Риторическая):** Участники учатся «языку инвестиций». Они осваивают правильные термины и структуры аргументации, чтобы выглядеть убедительно. Это навык риторики, а не финансового анализа.

#### Пересборка
Сильная версия такова: необходимо явно разделить две функции и два этапа обучения.
**Этап 1: Освоение модели мира (Калькулятор).** На этом этапе участники работают только с «симулятором» без «тьютора». Их задача — понять его логику, «прощупать» его законы. Они строят гипотезы («если ставка ЦБ вырастет на 2%, то мои квартиры в спальном районе подешевеют на 5%») и проверяют их на модели. Цель — построить у себя в голове работающую ментальную модель рынка, аналогичную той, что зашита в симулятор. Метрика успеха — точность прогнозирования результатов следующего раунда.
**Этап 2: Освоение рефлексивной практики (Партнёр).** На этом этапе подключается «тьютор». Но его роль — не давать советы и не оценивать решения. Его роль — задавать вопросы *о разрыве между прогнозом и реальностью*. Например: «Вы прогнозировали доходность 15%, а получили 5%. Какие три фактора, которые вы не учли, могли к этому привести?». Тьютор работает не с решением, а с ошибкой прогноза. Он тренирует не аргументацию «за», а анализ «почему не сбылось».

#### Требует решения автора
1.  Какая из двух способностей является приоритетной для курса: способность прогнозировать рыночные следствия (работа с моделью) или способность формулировать и защищать свою стратегию (работа с аргументацией)?
2.  Допустимо ли, чтобы «ИИ-тьютор» давал советы, которые могут противоречить объективным результатам, выдаваемым «симулятором»? Чьё слово является финальной «правдой» в учебной вселенной?
3.  Что является минимальной единицей освоения: способность действовать в одиночку, или способность эффективно работать в гибридной команде «человек+машина»?
4.  Если модель рынка будет сильно упрощённой (из-за ресурсных ограничений), готовы ли вы явно сообщить об этом участникам и сфокусировать обучение на осознании границ и допущений любой модели?

---

## 10. Перечень критических дефектов

Дефекты сгруппированы по приоритету: P0 — блокирующие, требуют немедленного решения до начала пилота; P1 — критические, существенно влияют на достоверность результатов; P2 — важные, снижают качество, но не блокируют; P3 — желательные улучшения.

**Приоритет P0**

*   **P0.1. Дефект: Неопределенность архитектуры вычислительной модели.** Отсутствует описание формул и логики, по которым работает модель рынка.
    *   *Reformulation:* Проект предлагает измерять температуру несуществующим термометром.
    *   *Вопрос автору:* Можете ли вы на бумаге, в виде блок-схемы или псевдокода, описать, как изменение 1-2 макропараметров (ставка, инфляция) повлияет на цену и доходность одного типового объекта?
*   **P0.2. Дефект: Смешение функций вычислительной модели и педагогического агента.** Неясно, как разделены роли и данные между «симулятором» и «тьютором».
    *   *Reformulation:* Не определено, кто в этой системе «физик», а кто «лирик», и могут ли они сверять часы.
    *   *Вопрос автору:* Если тьютор и симулятор дадут противоречивые оценки одного и того же решения, какой из сигналов является для участника правильным?
*   **P0.3. Дефект: Отсутствие функциональной схемы человеко-машинного цикла.** Не описана последовательность операций, передача данных и ответственности между участниками, моделью и тьютором.
    *   *Reformulation:* Описаны детали автомобиля, но не процесс вождения.
    *   *Вопрос автору:* Можете ли вы нарисовать схему одного раунда, где будут показаны все акторы (команда, тьютор, модель) и стрелками — кто кому какую информацию и в какой форме передает?

**Приоритет P1**

*   **P1.1. Дефект: Неоперационализированные критерии оценки.** Критерии «обоснованность выбора», «качество аргументации» заявлены, но не переведены в конкретную рубрику или чек-лист.
    *   *Reformulation:* Экспертам предлагается оценивать «красоту» решения без спецификации, что считать красивым.
    *   *Вопрос автору:* Какие 3-5 конкретных признаков в тексте защиты стратегии будут отличать «обоснованное» решение от «необоснованного»?
*   **P1.2. Дефект: Несоответствие заявленного масштаба и доступных ресурсов.** Создание полноценной, реалистичной модели рынка — задача для команды разработчиков на месяцы, что не соответствует ресурсам одного преподавателя.
    *   *Reformulation:* Заявлена постройка небоскрёба силами одного прораба с лопатой.
    *   *Вопрос автору:* Каков ваш «план Б», если разработка собственной модели окажется невозможной в рамках семестра? Готовый продукт, упрощение до Excel, отказ от идеи?
*   **P1.3. Дефект: Смешение педагогических интервенций.** Дизайн не позволяет отделить эффект от работы с моделью рынка от эффекта работы с рефлексивным агентом.
    *   *Reformulation:* Участникам дают сразу два новых лекарства и пытаются понять, какое из них помогло.
    *   *Вопрос автору:* Готовы ли вы в пилоте разделить группы: одна работает только с моделью, вторая — с моделью и тьютором, чтобы измерить добавочную ценность тьютора?
*   **P1.4. Дефект: Неопределенность источника и валидации макросценариев.** Заявлено использование прогнозов (ЦБ, Росстат), но неясно, как они интегрируются и как проверяется их адекватность.
    *   *Reformulation:* В двигатель собираются заливать топливо из разных канистр без проверки октанового числа.
    *   *Вопрос автору:* Кто и по какой процедуре будет отбирать и адаптировать макроэкономические прогнозы для загрузки в модель?
*   **P1.5. Дефект: Проблема «протухания» данных.** Использование реальных объектов с ЦИАН делает эксперимент невоспроизводимым, так как объявления исчезают.
    *   *Reformulation:* Эксперимент проводится на тающем льду.
    *   *Вопрос автору:* Какова процедура фиксации (snapshot) данных на старте курса, чтобы обеспечить их сохранность и доступность на протяжении всего эксперимента?
*   **P1.6. Дефект: Неопределенность дизайна эксперимента.** Заявлена возможность КГ/ЭГ, но не определены критерии разделения и протокол сравнения.
    *   *Reformulation:* Заявлен забег, но неясно, все ли бегут одну дистанцию и с одного старта.
    *   *Вопрос автору:* Как вы планируете обеспечить сопоставимость контрольной и экспериментальной групп, если они формируются из одного потока? Рандомизация, парный отбор?
*   **P1.7. Дефект: Неясная модель переноса навыка.** Проект не объясняет, как навык, полученный с помощью когнитивных протезов (модели и тьютора), будет перенесен в реальную жизнь без них.
    *   *Reformulation:* Человека учат плавать с надувным кругом, но не проверяют, сможет ли он плыть без него.
    *   *Вопрос автору:* Планируется ли в финальном контроле (кейс T1) задание, которое участники должны будут решить полностью самостоятельно, без доступа к программному комплексу?

**Приоритет P2**

*   **P2.1. Дефект: Отсутствие метрик для оценки самого программного комплекса.** Нет критериев, по которым можно будет оценить качество работы модели и тьютора как инструментов.
*   **P2.2. Дефект: Риск обучения «игре в симулятор».** Участники могут научиться эксплуатировать артефакты и упрощения модели вместо того, чтобы понимать реальные рыночные принципы.
*   **P2.3. Дефект: Неясная роль преподавателя в гибридной сцене.** Если тьютор дает обратную связь, а модель считает результаты, что делает преподаватель во время практических занятий?
*   **P2.4. Дефект: Недооценка сложности командной динамики.** Проект предполагает, что работа в команде — это плюс, но не учитывает возможные проблемы (социальная леность, конфликты, неравномерное участие).
*   **P2.5. Дефект: Отсутствие политики отказа у тьютора.** Не определено, в каких случаях диалоговый агент должен отказаться отвечать или помогать (например, при попытке получить прямой ответ «что купить?»).
*   **P2.6. Дефект: Неопределенность в обеспечении сравнимости кейсов T0 и T1.** Заявлено, что кейсы «аналогичные», но критерии аналогичности не заданы.
*   **P2.7. Дефект: Статистическая мощность.** Выборка в 20-30 участников, разделенная на команды, может быть недостаточной для получения статистически значимых результатов с помощью t-критерия.
*   **P2.8. Дефект: Субъективность экспертной оценки.** Без жесткой рубрики и калибровки оценка защиты стратегий рискует быть крайне вариативной и ненадежной.

**Приоритет P3**

*   **P3.1. Дефект: Отсутствие анализа логов.** В проекте не заложено, как будут использоваться цифровые следы (логи действий участников) для анализа их поведения и стратегий.
*   **P3.2. Дефект: Ограниченная теоретическая рамка.** Теории (Леонтьев, Lave/Wenger) заявлены, но не используются для генерации конкретных проектных решений или гипотез о механизмах обучения.

---

## 11. Карта ключевых утверждений

- **Утверждение 1:** Существующая практика обучения (статичные кейсы) не формирует у обучающихся способность действовать в динамичной, рисковой среде.
    - **Что есть в источнике:** «*студенты усваивают теорию и алгоритмы оценки, но не умеют применять их в динамичной, рисковой среде; макроэкономические шоки... не отражаются в статичных кейсах*».
    - **Статус:** Правдоподобная реконструкция (широко разделяемое мнение в педагогической практике).
    - **Что усилит основание:** Ссылки на учебно-методические работы, подтверждающие этот разрыв, или данные с предыдущих потоков курса (например, анализ типичных ошибок в итоговых работах).

- **Утверждение 2:** Предлагаемая интервенция (10-раундовая симуляция с макро-шоками) адекватно моделирует ключевые аспекты реальной инвестиционной деятельности.
    - **Что есть в источнике:** «*Симулятор с 10 раундами по году каждый — методологически правильный ответ: ускоряет цикл обратной связи с ~10 лет реальности до 2-3 практических занятий*».
    - **Статус:** Проектное требование.
    - **Что усилит основание:** Экспертное заключение 2-3 внешних специалистов по рынку недвижимости, подтверждающее, что выбранные для моделирования факторы (макро-шоки, стратегии) и временной горизонт являются репрезентативными и достаточными.

- **Утверждение 3:** Гибридная архитектура, состоящая из вычислительной модели и рефлексивного агента, является эффективным инструментом для достижения образовательных целей.
    - **Что есть в источнике:** «*Гибридная архитектура: симулятор с моделью динамики рынка... и ИИ-персона (тьютор) на базе LLM для персонализированной обратной связи и рефлексии*».
    - **Статус:** Гипотеза.
    - **Что усилит основание:** Функциональная схема, четко разделяющая роли, операции и потоки данных между человеком, вычислительной моделью и рефлексивным агентом. Это превратит декларацию в проверяемую архитектурную гипотезу.

- **Утверждение 4:** Использование программного комплекса приведёт к статистически значимому росту качества обоснования решений и точности прогнозирования.
    - **Что есть в источнике:** «*Гипотеза: внедрение симулятора приводит к статистически значимому повышению качества обоснования решений и точности прогнозирования*».
    - **Статус:** Целевой критерий, не факт. Это центральная проверяемая гипотеза эксперимента.
    - **Что усилит основание:** Детально прописанная рубрика для оценки «качества обоснования» и точная формула для расчета «точности прогнозирования». Без этого гипотеза нефальсифицируема.

- **Утверждение 5:** Выбранный набор метрик (экспертный балл, точность прогноза, финансовый результат) является достаточным и сбалансированным для оценки эффекта.
    - **Что есть в источнике:** «*множественная метрика (экспертный балл + точность прогноза + финансовый результат) — защита от single-metric оптимизации студентами*».
    - **Статус:** Предъявлено декларативно.
    - **Что усилит основание:** Описание возможных сценариев, когда эти метрики могут войти в противоречие. Например, стратегия с максимальным риском может привести к лучшему финансовому результату у одной команды и к банкротству у другой. Как будет оцениваться такая стратегия? Описание правил «игры» с метриками усилит их валидность.

- **Утверждение 6:** Теоретические рамки (деятельностный подход, ситуационное обучение, теория когнитивной нагрузки) лежат в основе дизайна проекта.
    - **Что есть в источнике:** «*Теоретическая рамка (Леонтьев + Lave/Wenger + Sweller) — не декоративная*».
    - **Статус:** Правдоподобная реконструкция.
    - **Что усилит основание:** Для каждой теории показать, какое конкретное проектное решение из неё следует. Например: «Теория когнитивной нагрузки (Sweller) обосновывает решение автоматизировать рутинные расчеты в модели, чтобы высвободить когнитивный ресурс участников для стратегического мышления».

---

## 12. Диагностическая матрица (20 полей)

| Поле | Предъявлено | Основание | Статус | Разрыв / Вопрос автору |
| :--- | :--- | :--- | :--- | :--- |
| **1. Проблема** | Статичные кейсы не учат действовать в динамике и риске. | Описание проекта | Чётко | Нет. Проблема ясна и релевантна. |
| **2. Целевая аудитория** | Участники электива по экономике недвижимости, разнородный состав. | Описание проекта | Чётко | Как будет учтена разная подготовка участников? |
| **3. Предмет изменения** | Поведение и умения в принятии инвест. решений. | Защищаемое ядро | Чётко | Что именно в поведении должно измениться? (см. Несущий разрыв) |
| **4. Педагогическая гипотеза** | Циклы «решение-последствие-рефлексия» в моделируемой среде улучшают качество решений. | Реконструкция | Неявно | Смешана с технологической гипотезой. Требует разделения. |
| **5. Технологическая гипотеза** | «Гибридный агент» (модель+тьютор) обеспечивает эффективную среду и поддержку. | Описание проекта | Декларативно | Неясно, что делает каждый компонент. (см. Несущий разрыв) |
| **6. Дизайн эксперимента** | Квазиэксперимент pre/post, возможно с КГ/ЭГ. | Описание проекта | Неполно | Критерии формирования групп и сопоставимости условий не определены. |
| **7. Ключевая практика** | 10 раундов командной работы в программном комплексе, защита стратегии. | Описание проекта | Чётко | Практика ясна, но её содержание зависит от решения по п.4 и п.5. |
| **8. Архитектура решения** | «Гибридная архитектура» с моделью рынка и LLM-тьютором. | Описание проекта | Не определена | **P0.1, P0.2.** Отсутствует функциональная схема и мат. модель. |
| **9. Роль человека** | Принимает решения, аргументирует, работает в команде. | Реконструкция | Неполно | Неясно, какая часть когнитивной работы должна остаться у человека. |
| **10. Роль машины** | Моделирует последствия, дает рефлексивную обратную связь. | Описание проекта | Смешанно | Роли «калькулятора» и «собеседника» не разделены. |
| **11. Источники данных** | ЦИАН/Авито для объектов, макропрогнозы (ЦБ, Росстат). | Описание проекта | Неполно | Неясен механизм интеграции и обновления макро-данных. |
| **12. Метрики (участника)** | Экспертный балл, точность прогноза, финансовый результат. | Описание проекта | Неоперационализи-ровано | **P1.1.** Требуется детальная рубрика для экспертного балла. |
| **13. Метрики (проекта)** | Статистически значимый прирост по метрикам участника. | Гипотеза | Чётко | Достаточна ли стат. мощность для t-критерия на малой выборке? |
| **14. Риски и ограничения** | Ресурсные ограничения, устаревание данных. | Реконструкция | Частично | Недооценен риск обучения «игре в симулятор». |
| **15. Теоретическая рамка** | Деятельностный подход, ситуационное обучение, когнитивная нагрузка. | Описание проекта | Декларативно | Связь с конкретными проектными решениями не показана. |
| **16. Воспроизводимость** | Низкая из-за использования «живых» данных с ЦИАН. | Анализ | Низкая | Требуется решение о создании фиксированного «снимка» данных. |
| **17. Масштабируемость** | Не обсуждается. | Анализ | Низкая | Зависимость от уникальной, не описанной модели делает перенос невозможным. |
| **18. Этика и границы** | Не обсуждается. | Анализ | Отсутствует | Какова политика отказа у тьютора? Как предотвращается списывание? |
| **19. Следующий артефакт** | Пилотный запуск. | Готовность | Преждевременно | Требуется сначала **функциональная схема** и **описание модели**. |
| **20. Ключевое решение** | Выбор реализации программного комплекса (готовый / свой / LLM-карточки). | Готовность | Требуется | **Разделить решение:** 1) Какова будет мат. модель рынка (хотя бы на бумаге)? 2) Какова будет роль тьютора? Только после этого выбирать технологию. |

---

## 13. Экспериментально-исследовательская модель

Проект заявлен как квазиэксперимент со смешанным дизайном (pre/post на одном потоке). Цель — измерить влияние ИИ-симулятора на способность студентов принимать инвестиционные решения. Однако текущий дизайн не позволяет изолировать переменные и с высокой долей уверенности приписать наблюдаемые изменения именно педагогическому механизму симулятора.

### 13.1. Диагностика текущего дизайна

#### Что автор предъявил
В документах указан квазиэксперимент: T0 (начальный кейс и анкета) → Интервенция (10 раундов симулятора) → T1 (финальный кейс и анкета). Метрики: экспертный балл за защиту стратегии, точность прогноза, итоговый капитал. Статистика: t-критерий для зависимых выборок для сравнения T0 и T1. Заявлена гипотеза: «внедрение симулятора приводит к статистически значимому повышению качества обоснования решений».

#### Reformulation
Более сильная проблема такова: автор предлагает измерить эффект от «чёрного ящика». Интервенция — это не одна переменная («симулятор»), а конгломерат из минимум четырёх:
1.  **Модель рынка:** детерминированная часть симулятора, его «физика».
2.  **ИИ-тьютор:** рефлексивный диалог с LLM.
3.  **Командная работа:** обсуждение и принятие решений в группе 2-4 человека.
4.  **Эффект новизны и вовлечённости:** сам факт использования нового технологического инструмента.

Текущий дизайн с t-критерием может показать, что *что-то* изменилось между T0 и T1. Он не может показать, *что именно* вызвало изменение. Если студенты покажут рост, мы не будем знать, благодаря чему: они научились понимать рынок (1), их научили рефлексировать (2), они научились договариваться в команде (3) или просто были более мотивированы (4).

#### Критика
Утверждение: «внедрение симулятора приводит к статистически значимому повышению качества обоснования решений и точности прогнозирования».

Возражение: этот дизайн не доказывает причинно-следственную связь, а лишь фиксирует корреляцию во времени. Статистике выдали пятерых подозреваемых (модель, тьютор, команда, новизна, само обучение) и один отпечаток пальца (рост метрик). T-критерий подтвердит, что отпечаток есть, но не скажет, чей он. Любой положительный результат можно будет с равным успехом приписать любому из этих факторов. Это не проверка педагогической гипотезы, а аудит суммарного эффекта, который невозможно воспроизвести, не скопировав всю конструкцию целиком, включая личность преподавателя и состав группы.

#### Альтернативные объяснения / гипотезы
Даже если гипотеза автора подтвердится и метрики вырастут, это может быть объяснено не заявленным механизмом, а другими факторами:

-   **Альтернатива A: Эффект тьютора, а не симулятора.** Основной обучающий эффект даёт не сама симуляция рыночной динамики, а рефлексивный диалог с ИИ-тьютором. Студенты учатся лучше аргументировать, потому что их заставляют это делать в диалоге. Сама симуляция может быть заменена набором статичных сценариев без потери эффекта.
-   **Альтернатива B: Эффект Хоторна и геймификации.** Студенты демонстрируют лучшие результаты не из-за освоения компетенции, а из-за повышенного внимания к ним в рамках эксперимента и использования новой, увлекательной технологии. Они не столько учатся инвестировать, сколько стараются «пройти игру» и показать себя. Эффект исчезнет, как только симулятор станет рутиной.
-   **Альтернатива C: Эффект командной динамики.** Ключевой механизм — не взаимодействие с машиной, а необходимость договариваться, аргументировать свою позицию и приходить к общему решению внутри команды. Симулятор выступает лишь поводом и общей средой для этой социально-когнитивной работы. Тот же эффект можно было бы получить, дав командам задачу совместно написать аналитический отчёт.
-   **Альтернатива D: Эффект опредмечивания и ускоренной обратной связи.** Сам факт того, что нужно принять формализованное решение (купить/продать), а затем немедленно увидеть числовой результат (пусть даже от упрощённой модели), является мощным обучающим фактором. Это не про реализм модели, а про сам цикл «действие-результат», который в реальной жизни растянут на годы.

### 13.2. Пересборка исследовательской модели

#### Пересборка
Сильная версия исследовательской модели должна быть направлена на фальсификацию альтернативных гипотез и выявление действующего механизма. Это требует перехода от простого pre/post дизайна к факторному эксперименту. Минимально жизнеспособный дизайн для проверки ключевых гипотез (эффект симулятора vs эффект тьютора) требует разделения потока на четыре группы:

1.  **Группа КГ (Контрольная):** Стандартное обучение, кейсы на бумаге. Базовая линия.
2.  **Группа ЭГ-1 (Только Симулятор):** Студенты работают с симулятором (модель рынка), но без ИИ-тьютора. Обратная связь — только числовые результаты раунда. Это проверяет гипотезу о ценности самой модели и ускоренной обратной связи.
3.  **Группа ЭГ-2 (Только Тьютор):** Студенты работают со статичными сценариями (аналогичными тем, что в КГ), но их решения и рефлексия сопровождаются ИИ-тьютором. Это проверяет гипотезу об эффекте рефлексивного диалога.
4.  **Группа ЭГ-3 (Полная сборка):** Студенты используют и симулятор, и ИИ-тьютора. Это полная версия интервенции.

Сравнение результатов между группами позволит сделать выводы о вкладе каждого компонента:
-   (ЭГ-1 > КГ) → есть эффект от самой симуляции.
-   (ЭГ-2 > КГ) → есть эффект от тьютора.
-   (ЭГ-3 > ЭГ-1) и (ЭГ-3 > ЭГ-2) → есть синергетический эффект, компоненты усиливают друг друга.
-   (ЭГ-1 ≈ КГ) и (ЭГ-2 > КГ) → работает только тьютор, симулятор — дорогостоящий фон.

Такой дизайн превращает проект из демонстрации технологии в полноценное педагогическое исследование, способное дать ответ на вопрос «почему это работает». Да, он сложнее в реализации, но только он может дать масштабируемое знание, а не локальный успешный кейс. Если разделение на 4 группы невозможно, минимальным шагом будет сравнение двух групп: «Только Симулятор» и «Симулятор + Тьютор». Это позволит хотя бы оценить добавленную стоимость LLM-компонента.

#### Требует решения автора
1.  Какова основная исследовательская цель: доказать, *что* предложенный инструмент в целом полезен (для этого хватит и текущего дизайна), или понять, *как и почему* он работает (для этого нужна пересборка)?
2.  Какой из компонентов — симулятор динамики рынка или рефлексивный тьютор — является ядром педагогической гипотезы? Что автор считает главным «действующим веществом»?
3.  Готов ли автор пожертвовать частью учебного времени или усложнить администрирование курса ради получения более достоверных исследовательских данных (например, разделив поток на группы с разным инструментарием)?
4.  Что является более ценным результатом для автора: статистически значимый рост метрик у одной группы или понимание дифференцированного эффекта разных инструментов на разные аспекты обучения?

---

## 14. Архитектурная пересборка

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

### 14.1. Диагностика текущей архитектуры

#### Что автор предъявил
В описании проекта упомянуты:
-   «Симулятор с моделью динамики рынка и формулами изменения цен».
-   «Агентный пайплайн для управления процессом симуляции».
-   «Аналитика макроэкономических сценариев».
-   «ИИ-персона (тьютор) на базе LLM для персонализированной обратной связи и рефлексии».

Это описывает набор желаемых функций, но не их взаимосвязь, иерархию и границы ответственности.

#### Reformulation
Более сильная проблема такова: в проекте отсутствует различение между детерминированной моделью мира (симулятор), языковым интерфейсом к этой модели (LLM-тьютор) и управляющей логикой (оркестратор). Все они свалены в кучу под названием «гибридный ИИ». Это приводит к фундаментальной путанице: языковой модели неявно приписываются свойства и знания, которыми она не обладает (например, понимание каузальности внутри симулятора), а симулятору — способность к гибкому диалогу.

#### Критика
Утверждение: «Гибридная архитектура: симулятор... агентный пайплайн... ИИ-персона на базе LLM».

Возражение: это не архитектура, а список пожеланий к функциональности. Ключевая ошибка — смешение онтологии и интерфейса. Симулятор — это онтология, модель мира со своими законами (пусть и упрощёнными). LLM-тьютор — это интерфейс, который может генерировать текст *о* событиях в этой онтологии. Когда эти роли не разделены, возникает иллюзия, что LLM «понимает» экономику симуляции. Это не так. LLM понимает структуру языка и шаблоны в данных, на которых он обучался. **RAG с выгрузкой из базы данных симулятора не становится экономистом от того, что его ответы обёрнуты в JSON.** Он не может вывести новый закон из данных симуляции или объяснить *причину* события, если эта причина не была явно заложена в его промпт и контекст. Надеяться, что LLM сам «разберётся» в происходящем в симуляторе — это как надеяться, что автоматическая коробка передач без датчика скорости будет переключать передачи на слух. Это не архитектура, а надежда.

#### Альтернативные объяснения / гипотезы
Такое смешение ролей в описании может быть следствием:
-   **Альтернатива A: Проектирование «от интерфейса».** Автор сначала представил себе желаемый диалог со студентом (общение с умным тьютором), а теперь пытается «подвесить» под этот интерфейс сложную механику симуляции, не разделяя их функционально.
-   **Альтернатива B: Технологический карго-культ.** Включение в описание модных терминов («агентный пайплайн», «ИИ-персона») без чёткого определения их роли и места в системе. Архитектура строится не из необходимости, а из доступного лексикона.
-   **Альтернатива C: Недооценка сложности.** Автор полагает, что современная LLM достаточно «умна», чтобы одновременно выполнять функции модератора диалога, аналитика данных и отчасти даже компонента симуляции, что является фундаментальным заблуждением относительно текущих возможностей технологии.

### 14.2. Контр-предложение: функционально-слоистая архитектура

#### Пересборка
Сильная версия архитектуры такова: необходимо строго разделить систему на функциональные слои, каждый из которых имеет одного «хозяина» и чётко определённые входы и выходы. В системе должны быть выделены акторы (принимающие решения), операторы (выполняющие детерминированные или языковые операции) и актанты (пассивные объекты).

**Предлагаемая архитектура:**

*   **Слой 0: Детерминированный симулятор (ML-оператор).** Это ядро, «физический движок» мира. Он представляет собой набор математических формул и правил. На вход он получает: 1) решения команд (купить объект X, взять кредит Y), 2) параметры текущего раунда (макроэкономический сценарий: ставка ЦБ, инфляция). На выходе он выдаёт *только* структурированные данные (числа): новая стоимость портфеля, полученная арендная плата, начисленные проценты. Этот слой не содержит языка, не имеет «мнения». Его поведение полностью детерминировано и предсказуемо. Ответственность за его адекватность лежит на преподавателе-дизайнере.

*   **Слой 1: Оркестратор (Программный агент).** Это простой скрипт, управляющий ходом игры. Его задачи: 1) управлять сменой раундов, 2) собирать решения от команд, 3) передавать их в Слой 0, 4) забирать результаты из Слоя 0, 5) передавать результаты командам и в Слой 2. Это не «агент» в смысле ИИ, а обычный event-менеджер.

*   **Слой 2: Тьютор-рефлексолог (LLM-оператор).** Это и есть «ИИ-персона». Его функция строго ограничена. На вход он получает: 1) структурированные результаты раунда из Слоя 0, 2) текст решения и обоснования от команды, 3) жёсткий системный промпт, написанный преподавателем. Его задача — на основе этих данных сгенерировать рефлексивные вопросы по шаблону: «Вы прогнозировали доходность X, а получили Y. Какие факторы, по-вашему, привели к этому расхождению?», «В вашем решении вы упомянули риск Z, как он проявился в этом раунде?». LLM-оператор *не имеет права* давать советы, оценивать решение или предсказывать будущее. Он — зеркало, которое помогает студентам отрефлексировать *свои* действия в свете *объективных* (в рамках симуляции) результатов.

*   **Слой 3: Студенческая команда (Актор).** Единственный субъект, принимающий ответственные инвестиционные решения в рамках игры.

*   **Слой 4: Преподаватель (Супервизор и Оценщик).** Главный актор системы. Он: 1) проектирует и калибрует Слой 0, 2) пишет и отлаживает промпты для Слоя 2, 3) наблюдает за ходом симуляции, 4) вмешивается в исключительных случаях, 5) проводит итоговую оценку, используя все данные (решения, диалоги с тьютором, итоговые результаты).

Такое разделение делает систему прозрачной, управляемой и диагностируемой. Если студенты учатся плохо, мы можем точно определить, где проблема: в модели мира (Слой 0), в качестве рефлексивных вопросов (Слой 2) или в дизайне заданий (Слой 4).

#### Требует решения автора
1.  Какова политика отказа для LLM-тьютора? В каких случаях он должен прямо сказать «я не могу ответить на этот вопрос» (например, при просьбе дать совет)?
2.  Кто несёт ответственность за «педагогический брак», если модель симулятора (Слой 0) окажется неадекватной и научит студентов неверным эвристикам?
3.  Должен ли LLM-тьютор (Слой 2) иметь «память» о предыдущих раундах и диалогах с командой? Если да, то как эта память структурируется и используется?
4.  Каков протокол вмешательства преподавателя (Слой 4) в работу системы? Может ли он «на лету» корректировать параметры симуляции или промпты тьютора?

---

## 15. Полный граф движения ролей

Проект предполагает сложную деятельность, в которой участники (студенты, преподаватель, ИИ-компоненты) постоянно меняют свои роли. Непонимание этих переходов — источник путаницы и потенциальных сбоев в педагогическом процессе.

### 15.1. Ролевые переходы в цикле симуляции

**Фаза 1: Подготовка (до первого раунда)**
-   **Преподаватель:** выступает в роли `Архитектора` (задаёт правила симулятора, пишет промпты для тьютора) и `Инструктора` (объясняет правила студентам).
-   **Студент:** находится в пассивной роли `Слушателя`.
-   **Симулятор/Тьютор:** `Инструменты`, пассивные артефакты.

**Фаза 2: Игровой раунд (цикл из 10)**
-   **Шаг 2.1: Анализ.**
    -   **Студент:** переходит в роль `Аналитика`. Он изучает макроэкономический сценарий раунда, доступные объекты, состояние своего портфеля.
    -   **ИИ-Тьютор (возможная роль):** может выступать в роли `Поставщика данных` или `Саммаризатора`, если он предоставляет аналитические обзоры. Здесь первая точка ролевой путаницы: это помощь или костыль?
-   **Шаг 2.2: Принятие решения.**
    -   **Студент (команда):** переходит в роль `Коллективного актора` или `Инвестиционного комитета`. Внутри команды происходит борьба ролей: `Генератор идей`, `Критик`, `Хранитель стратегии`.
    -   **Преподаватель:** `Наблюдатель` (если имеет доступ к логам решений в реальном времени).
-   **Шаг 2.3: Расчёт и получение результата.**
    -   **Симулятор (движок):** становится `Оракулом` или `Средой`, которая объективно (в рамках своей модели) реагирует на действия актора.
    -   **Студент:** переходит в роль `Получателя обратной связи`.
-   **Шаг 2.4: Рефлексия.**
    -   **ИИ-Тьютор:** активируется в роли `Собеседника-рефлексолога` или `Сократического диагноста`. Его задача — инициировать метакогнитивные процессы у студента.
    -   **Студент:** переходит в роль `Рефлексирующего практика`.
    -   **Преподаватель:** скрытая роль `Аудитора`, который позже может просмотреть логи диалогов и оценить их качество.

**Фаза 3: Финальная защита**
-   **Студент:** переходит в роль `Защищающегося` или `Докладчика`, который должен ретроспективно обосновать всю цепочку своих решений.
-   **Преподаватель:** переходит из роли `Наблюдателя` и `Архитектора` в роль `Экзаменатора` или `Оценщика`.
-   **ИИ-Тьютор:** может быть использован в роли `Свидетеля` (предоставляя логи диалогов) или даже `Ассистента экзаменатора` (если он готовит саммари по каждой команде).

### 15.2. Ключевые точки ролевой путаницы

1.  **Преподаватель → Ассистент LLM:** Если преподаватель тратит большую часть времени на «допиливание» промптов, исправление ошибок LLM и ручную интерпретацию его выводов для студентов, он из `Архитектора` превращается в низкоквалифицированного ассистента языковой модели. Его педагогическая экспертиза тратится на техническое обслуживание.
2.  **Студент-Аналитик → Студент-Оператор:** Если интерфейс симулятора и тьютора слишком сложен или требует специфических навыков для получения информации (например, сложный промптинг), студент вместо анализа рынка недвижимости будет учиться «правильно нажимать на кнопки». Произойдёт подмена предметной деятельности деятельностью по обслуживанию инструмента.
3.  **ИИ-Тьютор-Рефлексолог → ИИ-Консультант:** Самый опасный сдвиг. Если промпты тьютора будут недостаточно жёсткими, он из инструмента рефлексии превратится в источник «правильных» ответов или рыночных прогнозов. Студенты быстро научатся аутсорсить ему мышление, что полностью уничтожит педагогическую цель проекта. Граница между «помочь отрефлексировать» и «подсказать» — критически важна и должна быть защищена архитектурно.

---

## 16. Распределение функций и ответственности

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

| Функция | Инициирует | Исполняет | Проверяет | Отвечает за результат |
| :--- | :--- | :--- | :--- | :--- |
| **1. Проектирование модели симулятора** | Преподаватель | Преподаватель (или разработчик под его руководством) | Преподаватель (через тестовые прогоны) | **Преподаватель** (за адекватность модели и её педагогическую ценность) |
| **2. Сбор и подготовка данных** | Преподаватель | Преподаватель (пилот) / Скрипт (масштаб) | Преподаватель (выборочно) | **Преподаватель** (за релевантность и чистоту данных) |
| **3. Проектирование диалога с тьютором** | Преподаватель | Преподаватель (пишет системный промпт) | Преподаватель (тестируя LLM на крайних случаях) | **Преподаватель** (за педагогическую эффективность и безопасность диалога) |
| **4. Проведение раунда симуляции** | Оркестратор (Слой 1) | Оркестратор (Слой 1) | Система (логи) | **Система** (за техническую безошибочность выполнения цикла) |
| **5. Принятие инвестиционного решения** | Оркестратор (объявляя раунд) | **Студент (команда)** | Другие члены команды | **Студент (команда)** (за качество и последствия своего решения в игре) |
| **6. Расчёт результатов раунда** | Оркестратор (Слой 1) | Симулятор (Слой 0) | Система (внутренние тесты) / Преподаватель (при аномалиях) | **Система** (за корректность расчётов по заданным формулам) |
| **7. Генерация рефлексивного диалога** | Оркестратор (Слой 1) | LLM-Тьютор (Слой 2) | Преподаватель (просматривая логи) | **Преподаватель** (за качество промпта, который порождает диалог) |
| **8. Проведение рефлексии** | LLM-Тьютор (задавая вопрос) | **Студент (команда)** | LLM-Тьютор (формально) / Преподаватель (содержательно) | **Студент (команда)** (за глубину и честность своей рефлексии) |
| **9. Итоговая оценка деятельности** | Преподаватель | Преподаватель | Другой преподаватель (для калибровки) | **Преподаватель** (за объективность и справедливость оценки) |

**Ключевые выводы из таблицы:**

-   **Ответственность за ИИ:** За все действия ИИ-компонентов (Слой 0 и Слой 2) в конечном счёте отвечает **Преподаватель**. Он отвечает за дизайн модели и за дизайн промптов. ИИ здесь — молоток, а преподаватель — плотник. Ответственность за удар по пальцу лежит на плотнике.
-   **Ответственность студента:** Ответственность студента чётко локализована в двух областях: принятие решений и осуществление рефлексии. Он не отвечает за сбои симулятора или странные ответы тьютора.
-   **Скрытая работа преподавателя:** Таблица явно показывает огромный пласт работы преподавателя, который остаётся «за кулисами»: проектирование, тестирование, аудит логов, калибровка. Эта работа должна быть учтена при планировании ресурсов.

---

## 17. Зона ближайшей деградации

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

-   **L0: Ожидаемое поведение (Идеальный сценарий)**
    Студенты используют симулятор как «песочницу» для проверки своих гипотез о рынке. Они формулируют стратегию, совершают осмысленные действия, получают результаты, анализируют расхождения между прогнозом и фактом в диалоге с тьютором, корректируют свою ментальную модель рынка и стратегию на следующий раунд. Они учатся системному мышлению и оценке рисков.

-   **L1: Первый уход от нормы (Геймификация)**
    Студенты перестают думать о реальном рынке недвижимости и начинают думать о «прохождении игры». Они ищут не экономические закономерности, а уязвимости и паттерны в модели симулятора. Их рассуждения меняются с «в текущей макроэкономической ситуации логично инвестировать в коммерческую недвижимость» на «в этой игре на третьем раунде всегда выгодно покупать „двушки“ в спальных районах». Обучение подменяется поиском эксплойтов. Это первый признак того, что модель симулятора слишком проста или её закономерности слишком легко считываются.

-   **L2: Систематическая ошибка (Аутсорсинг мышления)**
    Студенты начинают использовать ИИ-тьютора как костыль, а не как зеркало. Вместо того чтобы сначала думать самим, а потом идти к тьютору для рефлексии, они начинают «спрашивать у тьютора», как поступить, или промптят его так, чтобы он сгенерировал им красивое обоснование для их интуитивного решения. Диалог из сократического превращается в консультационный. Студенты перестают нести когнитивную нагрузку по анализу и аргументации, делегируя её LLM.

-   **L3: Тихая замена компетенции (Мастерство промптинга вместо анализа)**
    Это терминальная стадия деградации. Студенты вообще не осваивают навык инвестиционного анализа. Вместо этого они осваивают другой, нецелевой навык: как, манипулируя входными данными и формулировками, заставить связку «Симулятор + Тьютор» выдать результат, который будет высоко оценен преподавателем. Они могут показывать отличные финансовые результаты в симуляции и вести безупречные с формальной точки зрения диалоги с тьютором, но при этом их собственная способность к анализу и принятию решений в реальной ситуации (без этих инструментов) будет нулевой или даже отрицательной. Произошла тихая подмена: вместо компетенции «аналитик рынка недвижимости» сформировалась компетенция «оператор ИИ-симулятора».

**Превентивные меры:**
-   Против L1: Усложнение и внесение стохастических элементов в модель симулятора. Введение «чёрных лебедей» — событий, не выводимых из предыдущей динамики.
-   Против L2: Жёсткие, «непробиваемые» промпты для тьютора, которые архитектурно запрещают ему давать советы и оценки. Мониторинг логов на предмет попыток «разговорить» тьютора.
-   Против L3: Введение в итоговую оценку заданий, которые нужно решать «с чистого листа», без помощи симулятора и тьютора (например, анализ кейса в реальном времени на экзамене). Это проверяет, произошёл ли перенос навыка вовне инструментальной среды.

---

## 18. Функционально-стоимостная и ресурсная карта

Оценка ресурсов для проекта должна разделять затраты на пилотный запуск (цель — проверка гипотезы) и на масштабирование (цель — внедрение в регулярный учебный процесс). Разрыв между этими двумя сценариями часто недооценивается.

### 18.1. Ресурсы для пилотного запуска (1-2 группы, 1 семестр)

| Ресурс | Функция | Ориентировочная стоимость |
| :--- | :--- | :--- |
| **Человеческие (Преподаватель)** | Проектирование симулятора, написание промптов, сбор данных, проведение, анализ результатов | ~80-120 часов сверх основной нагрузки. Основная, но скрытая стоимость пилота. |
| **Технологические (API)** | API-вызовы к LLM (например, GPT-4) для тьютора. | Низкая. ~5000-10000 вызовов на курс. При текущих ценах это $50-150. |
| **Технологические (Хостинг)** | Размещение простого веб-приложения или скрипта для симулятора и оркестратора. | Очень низкая, ~$10-20 в месяц. Может быть развёрнуто на университетских ресурсах. |
| **Данные** | Ручной сбор «снэпшота» объявлений с ЦИАН/Авито, поиск макропрогнозов в открытых источниках. | Включено во время преподавателя. |
| **Поддержка** | Отсутствует. Все проблемы решает преподаватель в ручном режиме. | 0. |

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

### 18.2. Ресурсы для масштабирования (общеуниверситетский электив, >3 потоков)

| Ресурс | Функция | Ориентировочная стоимость |
| :--- | :--- | :--- |
| **Человеческие (Команда)** | 1 Методист (адаптация под новые курсы), 1 Тех. специалист (поддержка платформы), N Преподавателей (требуют обучения). | Высокая. ~1.5 FTE на поддержку и развитие. Плюс затраты на обучение преподавательского состава. |
| **Технологические (Платформа)** | Разработка или покупка лицензии на стабильную, многопользовательскую платформу. Мониторинг, бэкапы, безопасность. | Очень высокая. Десятки тысяч долларов на разработку или годовую подписку. |
| **Технологические (API)** | API-вызовы к LLM в промышленном масштабе. | Средняя. Стоимость растёт линейно с числом студентов, может достигать нескольких тысяч долларов в год. |
| **Данные** | Автоматизированные парсеры, подписка на API агрегаторов недвижимости, покупка коммерческих макроэкономических прогнозов. | Средняя. От $500 до нескольких тысяч долларов в год за подписки на данные. |
| **Поддержка** | Техническая и методическая поддержка для студентов и преподавателей. Service Desk. | Высокая. Требует выделенного человека или отдела. |

**Ключевой разрыв (Scaling Gap):**

Проект в его пилотной версии — это «ручная работа» преподавателя. Масштабирование требует превращения этой ручной работы в промышленный процесс. Главные скрытые затраты при переходе:
1.  **Отчуждение экспертизы:** Знания автора о том, как должна работать модель и тьютор, нужно формализовать в виде ТЗ, документации и методичек для других преподавателей. Это огромная работа.
2.  **Поддержание актуальности:** Рынок недвижимости меняется. Модель симулятора и данные нужно будет постоянно обновлять. То, что в пилоте можно было сделать раз руками, в масштабе потребует автоматизированного конвейера данных (CI/CD for data).
3.  **Воспроизводимость и справедливость:** Как гарантировать, что студенты в разных потоках у разных преподавателей находятся в равных условиях? Это требует стандартизации и централизованного управления платформой, что убивает гибкость пилота.

Проект как «локальный инструмент» и проект как «масштабируемый паттерн» — это два разных проекта с разной экономикой и требованиями к команде.

---

## 19. Суждение по позиции Ульяны

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

#### Что уже собрано

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

*   **Проблема определена как разрыв в деятельности:** Не «студенты не знают X», а «студенты не умеют применять X в Y условиях». Это правильная постановка, нацеленная на практику, а не на эрудицию.
*   **Выбран адекватный инструмент опосредования:** 10-раундный симулятор — это не просто упражнение, а инструмент, сжимающий временные циклы рынка (10 лет) в управляемое учебное время (несколько занятий). Это позволяет обучающимся увидеть долгосрочные последствия своих решений, что невозможно в статичных кейсах.
*   **Заземление в реальности:** Использование реальных, пусть и зафиксированных во времени, объектов с досок объявлений (ЦИАН, Авито) и макроэкономических сценариев создаёт необходимый уровень аутентичности. Это защищает от формирования «игрового» мышления, оторванного от настоящих рыночных механизмов.
*   **Корректный дизайн измерения:** Схема pre/post-тестирования (T0/T1) с защитой итоговой стратегии — это стандартный и надёжный способ зафиксировать сдвиг. Множественность метрик (экспертный балл, точность прогноза, финансовый результат) защищает от одноклеточной оптимизации (например, «просто заработать больше денег любой ценой»).
*   **Теоретическая рамка не для вида:** Связка Леонтьев-Lave/Wenger-Sweller используется по назначению. Деятельностный подход оправдывает сам симулятор как орудие, ситуационное обучение — его реалистичность, а теория когнитивной нагрузки — перенос рутинных расчётов на машину, чтобы освободить мышление для стратегии.

#### Что здесь недостроено

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

1.  **«Чёрный ящик» решения:** Заявлено, что измеряется «обоснованность выбора». Но что происходит *внутри* команды между раундами — неизвестно. Какие гипотезы они строят? Какие расчёты ведут? Как разрешают разногласия? Без фиксации этого процесса мы измеряем только вход и выход, а сам процесс обучения остаётся невидимым. Мы не знаем, они научились думать как инвесторы или просто нашли выигрышную тактику для этой конкретной модели симулятора.
2.  **Смешение эффектов:** В проекте два мощных вмешательства: сам симулятор (динамическая модель рынка) и ИИ-помощник (рефлексивный диалог). Их эффекты слиты воедино. Если мы увидим рост метрик, мы не сможем сказать, что сработало: возможность «проигрывать» сценарии или диалог с машиной, который заставил отрефлексировать эти сценарии. Педагогическая гипотеза раздваивается и теряет доказуемость.
3.  **Неопределённая роль ИИ-помощника:** Заявлено, что он «организует рефлексивный диалог». Это слишком общая формулировка. Какова его педагогическая функция? Он задаёт открытые вопросы? Указывает на ошибки в расчётах? Предлагает альтернативные сценарии? Оспаривает аргументы? Без чёткой спецификации его действий «рефлексивный диалог» рискует превратиться в чат-бот, который хвалит за хорошие решения и сочувственно вздыхает при плохих, не меняя сути деятельности обучающегося.
4.  **Отсутствие «критерия отпускания»:** Хороший наставник знает, когда нужно перестать помогать. В проекте не определено, когда ИИ-помощник должен уменьшать свою поддержку или вовсе отключаться. Если он помогает все 10 раундов, мы рискуем вырастить не самостоятельных специалистов, а операторов ИИ-помощника, которые без него не смогут сделать и шага. Освоение — это способность действовать *без* костыля.

#### Критика

*   **Утверждение автора (из описания):** «ИИ-тьютор организует рефлексивный диалог, повышая качество аргументации и выявление рисков».
*   **Возражение:** Это утверждение смешивает наличие инструмента с результатом его применения. Организация диалога — это функция. Повышение качества аргументации — это педагогический результат. Между ними нет автоматического знака равенства. Механизм ошибки здесь — подмена педагогической гипотезы технологической. Мы не знаем, *какой именно* диалог и при каких условиях ведёт к росту качества аргументации. Без этого ИИ-помощник — это «чёрный ящик» внутри другого «чёрного ящика». Это всё равно что утверждать: «наличие в комнате рояля повышает музыкальность присутствующих». Нет, повышает не рояль, а система упражнений, выстроенная вокруг него. Здесь же система упражнений для рефлексии не описана.

#### Главный вопрос автору

Какой минимально достаточный набор наблюдаемых действий или артефактов (записей, расчётов, версий стратегии), созданных командой *без помощи ИИ-помощника*, позволит вам с уверенностью сказать: «Да, эта команда освоила принцип X (например, оценку риска ликвидности) и больше не нуждается в подсказках по этому поводу»?

#### Обязательное решение

Автор должен выбрать одну из двух моделей поведения ИИ-помощника:
1.  **Модель «Сократ»:** Помощник никогда не даёт прямых ответов или оценок, а только задаёт вопросы, вскрывающие противоречия в рассуждениях команды. Он работает на метакогнитивном уровне.
2.  **Модель «Мастер-подмастерье»:** Помощник на ранних этапах (раунды 1-3) демонстрирует образцы рассуждений, исправляет ошибки, активно помогает. Затем его помощь постепенно затухает (scaffolding), и к последним раундам он лишь молча наблюдает.

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

#### Следующий артефакт

**Карта учебных операций и их цифровых следов.** Это таблица, где в строках — ключевые навыки (например, «оценка кредитного плеча», «прогноз арендного потока», «учёт макро-риска»), а в столбцах — раунды симуляции. В ячейках — описание того, какой именно артефакт (фрагмент лога чата, версия расчётной таблицы, пункт в письменном обосновании) будет считаться доказательством освоения или неосвоения этого навыка на данном этапе.

#### Критерий готовности

Проект готов к пилоту с точки зрения педагогического дизайна, когда для как минимум 3-х ключевых навыков из Карты учебных операций определены: а) как ИИ-помощник реагирует на ошибку в этом навыке на раунде N; б) как он реагирует на правильное действие на раунде N+k; в) при каком условии помощь по этому навыку отключается.

#### Плотный вердикт

Проект в текущем виде — это отлично спроектированный стадион, на котором пока неясно, в какую именно игру будут играть и кто будет тренером. Заложен прочный фундамент в виде деятельностного подхода, аутентичной среды и адекватной схемы измерения. Однако сердцевина учебного процесса — то, как именно происходит переход от «не умею» к «умею», — остаётся непрозрачной. Деятельность обучающегося не операционализирована, а функции симулятора и ИИ-помощника смешаны, что делает гипотезу нефальсифицируемой. Проект готов не к пилотированию с замером метрик, а к проведению «режиссёрской» сессии, где автор должен будет раскадровать учебный процесс: вот студент делает ошибку X, вот так её видит система, вот так реагирует ИИ-помощник, и вот такой след мы ожидаем увидеть в следующем действии студента. Без этой детализации мы рискуем измерить лишь способность обучающихся адаптироваться к интерфейсу, а не их профессиональный рост. Готовность к пилоту: 4/10. Готовность к обсуждению педагогического механизма: 9/10.

---

## 20. Суждение по позиции Тимура

Позиция Тимура анализирует проект как человеко-машинную систему. Вопросы здесь не «чему научатся», а «как это работает». Кто какую функцию выполняет, где проходят границы ответственности, как устроены потоки данных и управления, что происходит в точках отказа.

#### Что уже собрано

С точки зрения системной архитектуры, в проекте есть несколько сильных и нетривиальных решений:

*   **Разделение «физики» и «рефлексии»:** Архитектурное решение выделить «симулятор с моделью динамики рынка» и «ИИ-персону (тьютор) на базе LLM» — это фундаментально верный шаг. Это позволяет независимо развивать и настраивать детерминированную, основанную на формулах, часть (рынок) и вероятностную, семантическую часть (диалог).
*   **Гибридность как принцип:** Автор не пытается решить всю задачу одной большой языковой моделью. Он понимает, что для расчёта доходности нужны формулы, а для диалога — семантика. Это признак архитектурной зрелости.
*   **Использование внешних данных как источников истины:** Опора на макроэкономические сценарии и данные с реальных площадок (пусть и в виде «снимка») — это правильный способ заземлить систему и вынести часть сложной логики за её пределы. Система не пытается *изобрести* рынок, она его *интерпретирует*.
*   **Определён полный цикл использования:** Описана последовательность T0 → обучение → 10 раундов → T1. Это задаёт верхнеуровневый сценарий работы системы, в который можно погружаться для детализации.

#### Что здесь недостроено

Проект описан на уровне компонентной схемы, но не функциональной архитектуры. Мы видим «что», но не «как».

1.  **Неописанный человеко-машинный цикл:** Кто инициирует какой шаг? Команда вводит решение в форму? Или в свободном чате? Как система понимает, что решение принято и пора запускать следующий раунд? Как ИИ-помощник «узнаёт», что пора вмешаться — по таймеру, по ключевому слову, по запросу? Полная схема потока управления и данных от входа пользователя до выхода системы отсутствует.
2.  **Политики ответа и отказа не определены:** Что произойдёт, если команда задаст ИИ-помощнику вопрос за пределами его компетенции («А какой будет курс доллара через год?»)? Что будет, если он сгенерирует фактически неверный или вредный совет? Какова политика системы в случае, если данные с ЦИАН устарели или макро-прогноз оказался радикально неверным? Эти пограничные случаи и составляют суть надёжной архитектуры.
3.  **Размытая граница ответственности:** Если команда, следуя совету ИИ-помощника, принимает катастрофическое инвестиционное решение и «банкротится» в симуляции, кто несёт за это ответственность в рамках педагогического процесса? Студенты, которые «слепо доверились»? ИИ, который «дал плохой совет»? Преподаватель, который «внедрил сырой инструмент»? Этот вопрос не является философским — от ответа на него зависит, как будут настроены ограничения и права ИИ-помощника.
4.  **«Слепые» логи:** В описании упоминается сбор данных, но не указано, как эти данные связаны с точками принятия решений в системе. Собирать логи чатов и кликов без привязки к конкретным функциям и операциям — это как устанавливать камеры в городе без понимания, где находятся перекрёстки и криминогенные зоны. Данные есть, но actionable insights из них получить невозможно.

#### Критика

*   **Утверждение автора (из описания):** «Гибридная архитектура: симулятор с моделью динамики рынка и формулами изменения цен, агентный пайплайн для управления процессом симуляции, аналитика макроэкономических сценариев и ИИ-персона (тьютор) на базе LLM...»
*   **Возражение:** Это не описание архитектуры, а инвентарный список запчастей. Архитектура — это не то, *что* есть в системе, а то, *как* эти части связаны, как они обмениваются данными и управлением, и как система в целом реагирует на внешние и внутренние события. Механизм ошибки здесь — принятие списка технологий за системный дизайн. Это как если бы на вопрос «Как устроен автомобиль?» инженер ответил: «Двигатель, четыре колеса, руль, кузов». Это правда, но это ничего не говорит о том, как именно вращение коленвала превращается в движение по дороге. Здесь мы не видим, как «агентный пайплайн» управляет связью между «моделью динамики» и «ИИ-персоной», и кто является главным в этом цикле.

#### Главный вопрос автору

Представьте, что на 5-м раунде симуляции система даёт сбой: макроэкономический сценарий загрузился с ошибкой, и все активы внезапно подешевели на 90%. Команда в панике. Опишите по шагам, что происходит дальше: что видит команда на экране, какие опции ей доступны, может ли она «откатить» раунд, вмешивается ли ИИ-помощник, и если да, то с каким сообщением, и какие действия должны предпринять вы как оператор системы?

#### Обязательное решение

Автор должен определить и зафиксировать «политику эскалации» для ИИ-помощника. Необходимо выбрать один из трёх путей:
1.  **Полная автономия (высокий риск):** ИИ-помощник действует самостоятельно в рамках своих промптов. Все его советы и ошибки — часть учебного опыта.
2.  **Человек-в-цикле (human-in-the-loop):** Все «нестандартные» или «высокорисковые» ответы ИИ-помощника (например, прямой совет купить актив) перед отправкой команде попадают на утверждение преподавателю.
3.  **Жёсткие «рельсы»:** ИИ-помощник не может генерировать свободный текст, а лишь выбирает одну из заранее заготовленных реплик или задаёт вопрос из утверждённого списка, возможно, подставляя в них данные из симуляции.

**Риск неверного выбора:** Путь (1) может привести к неконтролируемому педагогическому хаосу и потере доверия к инструменту. Путь (2) создаёт огромную нагрузку на преподавателя и убивает масштабируемость. Путь (3) может сделать помощника слишком примитивным и бесполезным. Выбор определяет реальную архитектуру и стоимость поддержки системы. Для пилота наиболее безопасным и информативным является путь (3), возможно, с элементами (2).

#### Следующий артефакт

**Функциональная схема человеко-машинного цикла (диаграмма последовательности UML или BPMN).** На диаграмме должны быть отражены все акторы (Команда, Симулятор, ИИ-помощник, Преподаватель), основные операции (ввод решения, расчёт раунда, генерация отчёта, запрос к помощнику, ответ помощника) и потоки данных/управления между ними.

#### Критерий готовности

Проект готов к передаче в разработку (или к детальной настройке no-code инструментов), когда на Функциональной схеме нет ни одного «висящего» процесса, для каждой стрелки понятно, что является триггером и какие данные передаются, а для каждого действия ИИ-помощника определена его «политика эскалации».

#### Плотный вердикт

Проект представляет собой набор хорошо продуманных, но пока не соединённых друг с другом технологических идей. Разделение на детерминированный симулятор и семантического помощника — сильный ход, но их взаимодействие, управление и политика поведения в нештатных ситуациях не проработаны. Это создаёт риск построить не единую систему, а два отдельных инструмента, работающих в одной оболочке, что породит проблемы с интерпретацией данных и ответственностью. Текущее состояние — это не «гибридный двигатель», а скорее «двигатель и электромотор, лежащие рядом на складе». Проект готов не к разработке, а к архитектурной сессии, где на доске нужно будет нарисовать полную карту функций, ролей и потоков данных. Без этой карты любая попытка реализации приведёт к созданию хрупкой, непредсказуемой и сложной в поддержке системы. Готовность к пилоту: 2/10. Готовность к архитектурному проектированию: 10/10.

---

## 21. Простой канвас

| Категория | Содержание |
| :--- | :--- |
| **1. Проблема** | Студенты-экономисты знают теорию оценки недвижимости, но не умеют применять её в динамичной, неопределённой среде с макроэкономическими шоками. Статичные кейсы не формируют навык управления портфелем и оценки долгосрочных рисков. |
| **2. Потребительские сегменты** | Студенты общеуниверситетского электива «Экономика и управление недвижимостью» (20-30 человек). Аудитория разнородная, не только профильные финансисты. Работают в командах по 2-4 человека. |
| **3. Уникальное ценностное предложение** | «Проживите» 10 лет на рынке недвижимости за 3 занятия. Получите опыт принятия инвестиционных решений в реалистичной, но безопасной среде, где ваши ошибки ведут к обучению, а не к финансовым потерям. |
| **4. Решение** | Гибридный симулятор: 10 годовых раундов, реальные объекты с ЦИАН/Авито (snapshot), макроэкономические сценарии (инфляция, ставки). Интегрированный ИИ-помощник для рефлексивного диалога и обратной связи. |
| **5. Каналы** | Встроен в учебный процесс практических занятий курса. Прямое взаимодействие преподавателя со студентами. |
| **6. Потоки поступления дохода** | (Неприменимо для внутреннего учебного проекта). Косвенный доход — повышение качества выпускников, публикация результатов исследования. |
| **7. Структура издержек** | Время преподавателя на разработку и проведение. Возможные затраты на платформу/API для симулятора и LLM. Затраты на сбор и разметку данных (объекты, сценарии). |
| **8. Ключевые метрики** | **Результат:** Экспертный балл за обоснованность стратегии, точность прогноза доходности, итоговый финансовый результат. **Процесс:** Вовлечённость (опросник). Статистическая значимость роста метрик (t-критерий). |
| **9. Нечестное преимущество** | Уникальный набор данных (snapshot объектов + макро-сценарии), недоступный в готовых симуляторах. Экспертиза автора в предметной области (недвижимость) и педагогическом дизайне. Доступ к целевой аудитории (студенты). |

---

## 22. Расширенный канвас

| Категория | Содержание |
| :--- | :--- |
| **Объект изменения** | Способность студентов (команд) принимать обоснованные инвестиционные решения в условиях неопределённости. Переход от теоретического знания к практическому действию, опосредованному симуляцией. |
| **Ключевая практика** | Цикл «Анализ → Решение → Симуляция последствий → Отчёт → Рефлексия с ИИ-помощником → Корректировка стратегии». Повторяется 10 раз. |
| **Педагогическая гипотеза** | Ускоренный цикл обратной связи (10 лет → 10 раундов) в сочетании с рефлексивным диалогом, инициируемым ИИ-помощником, формирует у студентов более сложные ментальные модели рынка, что проявляется в росте качества аргументации и точности прогнозов. |
| **Технологическая гипотеза** | Гибридная архитектура (детерминированный симулятор + LLM-помощник) позволяет создать достаточно реалистичную и педагогически эффективную среду, где рутинные расчёты автоматизированы, а фокус смещён на стратегию и рефлексию. |
| **Источники данных** | **Входные:** Snapshot объявлений с ЦИАН/Авито; макроэкономические прогнозы (ЦБ РФ, Росстат, Дом.РФ). **Генерируемые:** Решения команд по раундам; результаты симуляции (финансовые показатели); логи диалогов с ИИ-помощником; итоговые презентации. |
| **Дизайн эксперимента** | Квазиэксперимент, pre/post-тест на одной группе. T0: решение кейса. Вмешательство: 10 раундов симуляции. T1: решение аналогичного кейса + защита стратегии. Сравнение результатов T0 и T1. |
| **Критерии успеха (внутренние)** | Статистически значимый рост метрик (экспертный балл, точность прогноза) между T0 и T1. Качественное подтверждение (анализ защит) усложнения стратегий и аргументации. Положительная обратная связь по вовлечённости. |
| **Критерии успеха (внешние)** | Возможность тиражирования методики на другие потоки/курсы. Публикация результатов в педагогическом/отраслевом издании. Создание прототипа, который можно показать для получения гранта на полномасштабную разработку. |
| **Ключевые риски и их митигация** | **1. Модель симулятора слишком проста:** Студенты «взламывают» её, а не учатся. → *Митигация:* Использовать реальные макро-сценарии, добавить случайные события. **2. ИИ-помощник бесполезен/вреден:** Генерирует банальности или ошибки. → *Митигация:* Начать с жёстких «рельсов» (предопределённые вопросы), постепенно усложняя. **3. Невозможно разделить эффекты:** Неясно, что сработало — симулятор или помощник. → *Митигация:* В будущих итерациях предусмотреть КГ (только симулятор) и ЭГ (симулятор + помощник). **4. Техническая сложность:** Разработка занимает больше семестра. → *Митигация:* Для пилота использовать максимально простые инструменты (Google Sheets + API к LLM). |
| **Границы ответственности** | **Автор:** Отвечает за педагогический дизайн, контент (сценарии), критерии оценки, интерпретацию результатов. **Система (Симулятор):** Отвечает за детерминированный расчёт последствий решений по заложенным формулам. **Система (ИИ-помощник):** Отвечает за ведение диалога в рамках заданной политики. **Студент:** Отвечает за принятие финального решения и его последствия внутри симуляции. |

---

## 23. Разбор структуры предъявления

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

#### Слайд/Раздел 1: Проблема и Контекст

*   **Что предъявлено:** Студенты знают теорию, но не умеют применять её в динамике и риске. Статичные кейсы не работают. Курс — общеуниверситетский электив.
*   **Что упущено:** Не показана цена этой проблемы. Почему это плохо? Они не могут найти работу? Они допускают ошибки на стажировках? Университет теряет репутацию? Без этого проблема звучит как локальная академическая задача, а не как реальный вызов. Также не раскрыта специфика «общеуниверситетского электива» — это значит, в одной команде могут оказаться будущий филолог и математик? Это критически важно для дизайна командной работы и роли ИИ-помощника.
*   **Пересборка:** Начать с короткой истории-архетипа: «Наш выпускник на собеседовании блестяще рассчитывает NPV для одного здания, но впадает в ступор от вопроса „А что вы будете делать, если ЦБ поднимет ставку на 2 пункта?“». Это немедленно делает проблему осязаемой. Явно указать на разнородность аудитории как на вызов и возможность (междисциплинарные команды).

#### Слайд/Раздел 2: Решение — Симулятор

*   **Что предъявлено:** 10 раундов по году, реальные объекты (ЦИАН), макро-шоки.
*   **Что упущено:** Механизм симуляции. Это «Excel на стероидах», где подставляются числа в формулы? Или это агентная модель, где виртуальные покупатели и арендаторы создают спрос? От этого зависит уровень реализма и то, чему на самом деле научатся студенты. «Макро-шоки» — это просто изменение одной переменной (например, `inflation = +5%`) или комплексное событие, влияющее на разные параметры (ставка растёт → спрос на ипотеку падает → цены на эконом-жильё стагнируют → аренда дорожает)?
*   **Пересборка:** Вместо термина «симулятор» показать один экран/фрагмент интерфейса и один пример: «Раунд 4. Событие: „Правительство ввело льготную ипотеку“. Ваши объекты класса „комфорт“ подорожали на 12%, но операционные расходы на их содержание выросли из-за инфляции. Ваши действия?». Это мгновенно объясняет суть происходящего лучше, чем любая блок-схема.

#### Слайд/Раздел 3: Решение — ИИ-Тьютор

*   **Что предъявлено:** «Аналитическая обратная связь, рефлексия, поддержка», «ИИ-персона на базе LLM».
*   **Что упущено:** Правила игры с этим тьютором. Он проактивен или реактивен? Он всезнающий или у него есть слепые зоны? Он может отказать в помощи? Сейчас он выглядит как волшебный помощник, что вызывает скепсис.
*   **Критика:** Формулировка «организует рефлексивный диалог» — это пример подмены механизма желаемым результатом. Это всё равно что в презентации телескопа написать «организует открытие новых галактик». Нет, он собирает свет по определённым законам. Так и здесь: нужно показать, по каким законам тьютор строит диалог.
*   **Пересборка:** Показать два примера диалога. **Пример 1 (плохой):** `Студент: Мы решили всё продать. Тьютор: Хорошее решение, смелый шаг!` **Пример 2 (хороший):** `Студент: Мы решили всё продать. Тьютор: Интересная стратегия. На каких данных вы основываете прогноз, что рынок в следующем раунде упадёт? Рассмотрели ли вы альтернативу — не продавать, а взять кредит под залог для покупки недооценённого актива?` Это показывает его реальную функцию, а не магию.

#### Слайд/Раздел 4: Дизайн и Метрики

*   **Что предъявлено:** Квазиэксперимент pre/post, t-критерий, метрики (экспертный балл, точность, финансы).
*   **Что упущено:** Операционализация метрик. Что такое «обоснованность» в баллах? Это чек-лист (упомянул инфляцию, учёл ставку, сравнил 3 альтернативы)? Или субъективная оценка? Как измеряется «точность прогноза», если будущее в симуляторе многофакторное? Сравнение с чем? С наивной моделью? С результатом самой симуляции (что тавтологично)?
*   **Пересборка:** Представить рубрикатор для оценки. Даже если он черновой. Например: «Обоснованность стратегии (0-5 баллов): 0 — нет обоснования; 1 — есть ссылка на общие тренды; ...; 5 — есть численный расчёт с учётом 3+ факторов, рассмотрены 2+ альтернативы, оценены риски». Это переводит абстрактную метрику в конкретный инструмент измерения.

#### Итоговая структура предъявления:

Текущая структура логична (проблема → решение → доказательство), но слишком абстрактна. Она рассказывает «о чём» проект, но не «как» он работает. Каждый раздел останавливается ровно в тот момент, где начинается самое интересное — конкретные механизмы. В результате у слушателя остаётся ощущение добротного, но «воздушного» концепта, который может рассыпаться при соприкосновении с реальностью. Необходимо насытить презентацию конкретными примерами, артефактами (скрины, диалоги, рубрикаторы) и сценариями, даже если они пока гипотетические.

---

## 24. Рекомендуемый первый пилот

#### 24.1 Название и исследовательский вопрос

**Название пилота:** «Разделение эффектов: влияние динамической модели рынка и рефлексивного диалога на качество инвестиционных решений».

**Основной исследовательский вопрос (RQ):** Какой из компонентов гибридного симулятора — (А) динамическая модель рыночных последствий или (Б) рефлексивный диалог с ИИ-тьютором — вносит основной вклад в рост качества обоснования инвестиционных решений, точности прогнозирования и итогового финансового результата у студентов? Второстепенный вопрос: сохраняется ли и переносится ли полученный навык на новые задачи через 3-4 недели после окончания симуляции?

Этот вопрос переформулирует исходный «влияет ли симулятор?» в более сильную и диагностически ценную форму. Он позволяет не просто зафиксировать наличие или отсутствие эффекта, а определить его источник. Проект в текущем виде смешивает два разных педагогических вмешательства:
1.  **Тренажёр последствий:** среда, где можно безопасно увидеть результат своих действий в ускоренном времени.
2.  **Рефлексивный партнёр:** собеседник, который заставляет вербализовать и критиковать собственную логику принятия решений.

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

#### 24.2 Основной outcome и способ измерения

Основным результатом является «способность принимать обоснованные инвестиционные решения в условиях неопределённости». Это комплексное понятие раскладывается на три измеряемых компонента:

1.  **Качество обоснования решения (Primary Outcome):** Оценивается на основе артефактов — финальной презентации стратегии и промежуточных обоснований каждого раунда. Измерение производится по заранее разработанной рубрике с оценкой от 1 до 5 по следующим критериям:
    *   **Полнота анализа:** Учтены ли макроэкономические факторы (ставка ЦБ, инфляция), характеристики объекта (локация, состояние), операционные расходы (налоги, ремонт, вакантность)?
    *   **Работа с источниками:** Приведены ли ссылки на данные (ЦИАН, Росстат, прогнозы ЦБ) или это умозрительные заключения?
    *   **Рассмотрение альтернатив:** Проанализирована ли хотя бы одна альтернативная стратегия (например, не покупка, а аренда; не флиппинг, а долгосрочная сдача)?
    *   **Оценка рисков:** Явно ли названы и оценены ключевые риски (риск ликвидности, процентный риск, риск падения рынка)?
    *   **Логическая связность:** Является ли итоговое решение логическим следствием проведённого анализа?
    Оценка проводится двумя независимыми экспертами (автор курса + приглашённый практик) для обеспечения надёжности.

2.  **Точность прогнозирования (Secondary Outcome):** Измеряется как отклонение прогнозируемой командой доходности от фактической доходности, полученной в симуляторе по итогам раунда. Формула: `| (Прогнозная_Доходность - Фактическая_Доходность) / Фактическая_Доходность | * 100%`. Меньшее значение указывает на более высокую точность.

3.  **Финансовый результат (Tertiary Outcome):** Итоговый размер капитала команды после 10 раундов симуляции. Эта метрика важна, но является вторичной, так как высокий результат может быть следствием удачи, а не системной стратегии. Она должна анализироваться только в связке с качеством обоснования.

#### 24.3 Аудитория и тема

*   **Аудитория:** 20-30 студентов общеуниверситетского электива «Экономика и управление недвижимостью». Уровень подготовки предполагается разнородным. Студенты делятся на команды по 2-4 человека.
*   **Тема:** Инвестиции в жилую и коммерческую недвижимость на российском рынке.
*   **Материал:** Фиксированный на момент старта пилота «снимок» рынка: 20-30 реальных объектов с ЦИАН/Авито с полным описанием, ценами и фотографиями. Три макроэкономических сценария на 10 лет вперёд: «Базовый» (на основе прогнозов ЦБ), «Кризисный» (рецессия, рост ставок), «Рост» (экономическое оживление, снижение ставок).

#### 24.4 Дизайн: intervention / control / order

Для ответа на поставленный RQ необходим дизайн с несколькими сравнительными группами, а не простое сравнение «до/после». Предлагается квазиэксперимент с четырьмя группами, сформированными случайным образом.

*   **T0 (Pre-test):** Все участники получают одинаковый стартовый кейс (описание рыночной ситуации и одного объекта) и за 1 час готовят письменное инвестиционное решение. Это замеряет базовый уровень.
*   **Intervention (10 раундов):**
    *   **Группа A (Full Treatment): Симулятор + ИИ-Тьютор.** Команды взаимодействуют с симулятором, который рассчитывает последствия их решений, и с ИИ-тьютором, который задаёт рефлексивные вопросы до и после каждого раунда («Почему вы выбрали именно этот объект?», «Какие риски вы видите в текущем раунде?», «Ваш прошлый прогноз не сбылся. Что вы упустили в анализе?»).
    *   **Группа B (Active Control 1): Только Симулятор.** Команды взаимодействуют с тем же симулятором, но без ИИ-тьютора. Обратная связь — только числовые данные: изменение стоимости активов, денежный поток, итоговый капитал. Это позволяет измерить чистый эффект от наличия динамической модели последствий.
    *   **Группа C (Active Control 2): Только ИИ-Тьютор.** Команды не используют динамический симулятор. Вместо этого они работают со статичными «карточками сценариев». Каждый раунд они получают описание рыночной ситуации («Год 2. Инфляция выросла до 10%, ключевая ставка 12%...») и принимают решение. После этого они обсуждают своё решение с ИИ-тьютором, который работает по той же логике, что и в группе А. Результат их решения (прибыль/убыток) им не сообщается, фокус — на процессе рассуждения. Это позволяет измерить чистый эффект рефлексивного диалога.
    *   **Группа D (Baseline Control): Стандартное обучение.** Команды работают по старой методике: разбирают статичные кейсы, аналогичные по содержанию, но без симуляции и без ИИ-тьютора. Обсуждение ведут с преподавателем в обычном режиме. Эта группа служит точкой отсчёта.
*   **T1 (Post-test):** Все участники получают новый, более сложный кейс (аналогичный T0, но с другими данными) и готовят финальную презентацию с защитой своей инвестиционной стратегии. Результаты оцениваются по той же рубрике, что и на T0.

#### 24.5 Трейсы и артефакты

Для глубокого анализа необходимо собрать исчерпывающий набор данных о деятельности студентов:
1.  **Артефакты решений:**
    *   Письменные решения по кейсу T0 (все группы).
    *   Финальные презентации и видеозаписи защиты стратегии на T1 (все группы).
    *   Для групп A, B, C: лог решений по каждому из 10 раундов (что купили/продали/оставили, какой прогноз дали).
2.  **Логи взаимодействия:**
    *   Для групп A и C: полные тексты диалогов команд с ИИ-тьютором.
    *   Для групп A и B: полные логи состояния симулятора для каждой команды после каждого раунда (активы, пассивы, денежный поток, капитал).
3.  **Опросники:**
    *   Опросник вовлечённости и восприятия сложности после T1.
    *   Анкета на старте для сбора демографических данных и самооценки знаний.

#### 24.6 Самостоятельная проба и отсроченный срез

Ключевой тест на реальное научение — это способность применить навык в новой ситуации без поддержки.
*   **T2 (Отсроченный срез):** Через 3 недели после окончания симуляции и защиты T1 всем участникам индивидуально (не в командах) предлагается решить новый, незнакомый кейс повышенной сложности. Например, требующий анализа портфеля из нескольких объектов с разными характеристиками в условиях неожиданного макроэкономического «шока». Задание выполняется в ограниченное время (90 минут) без доступа к симулятору или тьютору.
*   **Цель среза:** Проверить, произошёл ли перенос навыка с командной работы в симуляторе на индивидуальную аналитическую работу. Сравнение результатов между группами A, B, C и D на этом этапе покажет, какой из методов обучения даёт наиболее устойчивый и переносимый результат. Отсутствие значимых различий на T2 при их наличии на T1 будет означать, что эффект был ситуативным и не превратился в реальную компетенцию.

#### 24.7 Критерии успеха и остановки

*   **Критерий минимального успеха:** Статистически значимое (p < 0.05) превосходство Группы А (полное вмешательство) над Группой D (контроль) по метрике «Качество обоснования решения» на T1.
*   **Критерий полного успеха:** Получение статистически значимых и интерпретируемых различий между группами A, B и C. Например, если `A > B > D` и `A > C > D`, это позволит сделать вывод о том, что и симулятор, и тьютор вносят свой вклад, и их комбинация даёт синергетический эффект. Если же `A ≈ B > C ≈ D`, это будет означать, что основной эффект даёт симулятор, а тьютор в его текущей реализации бесполезен.
*   **Критерий устойчивости:** Сохранение значимых различий между группами на отсроченном срезе T2.
*   **Критерии остановки пилота:**
    *   **Технический провал:** Инструменты (симулятор, тьютор) неработоспособны более чем для 25% участников.
    *   **Педагогический провал:** Более 50% участников в экспериментальных группах не могут выполнить задание первого раунда после инструктажа, что свидетельствует о неадекватной сложности или плохом дизайне.
    *   **Отсутствие вовлечённости:** Массовый отказ участников от выполнения заданий или формальное отношение, зафиксированное в логах и опросниках.

#### 24.8 Исключённые функции

Для обеспечения реализуемости пилота в рамках одного семестра необходимо радикально сократить сложность симулятора по сравнению с полномасштабной версией:
*   **Исключить сложные финансовые инструменты:** Оставить только покупку за полную стоимость и ипотеку с фиксированной ставкой. Убрать рефинансирование, инвестфонды, сложные деривативы.
*   **Фиксированный набор объектов:** Использовать «снимок» рынка из 20-30 объектов, который не меняется на протяжении всей симуляции. Новые объекты не появляются.
*   **Упрощённая модель операционных расходов:** Использовать фиксированный процент от стоимости для расчёта налогов и ремонта вместо детальной сметы. Вакантность моделировать как бинарное событие (сдаётся / не сдаётся) с заданной вероятностью.
*   **Сценарные макро-данные:** Не использовать живые данные или сложные эконометрические модели. Использовать 3 заранее прописанных сценария (базовый, кризис, рост), которые назначаются группам.

#### 24.9 Риски и как их закрыть

**Основной риск:** Разработка даже упрощённого программного симулятора (ядра расчётов) и интерфейса к нему может занять месяцы и сорвать сроки проведения пилота в рамках учебного семестра.

**Метод закрытия риска: «Человек за занавеской» (Wizard-of-Oz).**
Вместо разработки программного симулятора его роль выполняет человек (преподаватель или ассистент), действующий по строгому алгоритму.
*   **Механизм:**
    1.  Команды из Групп A и B отправляют свои решения за раунд (например, «Покупаем объект №5 в ипотеку, продаём объект №2, прогноз доходности +15%») в простой гугл-форме или чате.
    2.  «Волшебник» получает эти данные, вносит их в заранее подготовленную Excel-таблицу. Таблица автоматически рассчитывает все финансовые показатели по заложенным формулам (изменение стоимости активов согласно сценарию, арендный доход, платежи по ипотеке, налоги и т.д.).
    3.  «Волшебник» копирует итоговые данные (новый состав портфеля, финансовый результат за раунд, итоговый капитал) и отправляет их обратно команде.
*   **Преимущества:**
    *   **Нулевое время на разработку ядра симулятора.** Пилот можно запустить через неделю после финализации правил игры.
    *   **Тестируется именно педагогическая гипотеза.** Проверяется ценность цикла «решение → обратная связь», а не качество интерфейса или производительность кода.
    *   **Гибкость.** Правила можно корректировать «на лету», если в первых раундах обнаружатся проблемы в модели.
*   **Реализация ИИ-Тьютора:** В отличие от симулятора, прототип ИИ-тьютора можно реализовать быстро с помощью API современных LLM и простого чат-интерфейса (даже в Telegram). Это не требует значительных инженерных ресурсов. Таким образом, пилот в дизайне A/B/C/D полностью реализуем.

#### 24.10 Ресурсы и график

*   **Ресурсы:**
    *   **Человеческие:** 1 преподаватель (автор проекта) в роли руководителя пилота и «волшебника»; 1 ассистент для помощи в сборе данных и коммуникации с группами; 2 независимых эксперта для оценки T0/T1/T2 (один из них — автор).
    *   **Технические:** Google Workspace (Forms, Sheets) или аналоги; доступ к API LLM (YandexGPT, GigaChat и т.п.); мессенджер для коммуникации.
*   **График (16 недель):**
    *   **Неделя 1-2 (Подготовка):** Финализация дизайна пилота. Разработка рубрик оценки, кейсов T0/T1/T2. Подготовка Excel-модели для «волшебника».
    *   **Неделя 3 (Запуск):** Проведение T0. Разделение на группы. Инструктаж.
    *   **Неделя 4-8 (Проведение):** Проведение 10 раундов симуляции (по 2 раунда в неделю). Сбор логов и промежуточных артефактов.
    *   **Неделя 9 (Завершение):** Проведение T1 (финальные защиты). Сбор опросников.
    *   **Неделя 10-11 (Анализ 1):** Оценка работ T0 и T1 экспертами. Первичный анализ данных.
    *   **Неделя 12 (Отсроченный срез):** Проведение T2.
    *   **Неделя 13-14 (Анализ 2):** Оценка работ T2. Комплексный анализ всех собранных данных, написание отчёта по итогам пилота.
    *   **Неделя 15-16 (Резерв):** Резервное время на случай непредвиденных задержек.

---

## 25. Прототип ТЗ для лаборатории

**Статус:** NO-BUILD (Разработка не может быть начата).

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

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

Прежде чем формулировать ТЗ, автор проекта должен провести работу по спецификации, ответив на ряд принципиальных вопросов. Результаты пилота, описанного в разделе 24, являются необходимым источником данных для этой спецификации.

Ниже представлены четыре блока работ, которые должны быть выполнены автором **до** формирования запроса в лабораторию.

#### 25.1 Разделение педагогической и технологической гипотез

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

*   **Педагогическая гипотеза (сильная версия):** «Последовательное прохождение 10 циклов "анализ → решение → числовая обратная связь о последствиях" на реалистичных, но детерминированных сценариях приводит к росту качества анализа рисков и рассмотрения альтернатив в итоговой работе. Добавление к этому циклу рефлексивного диалога, где участника принуждают вербально обосновывать каждый шаг и соотносить его с предыдущими ошибками, даёт дополнительный, измеримый прирост в качестве обоснования».
    *   **Проверка:** Эта гипотеза полностью проверяется в ходе пилота «Человек за занавеской».

*   **Технологическая (ИИ) гипотеза (сильная версия):** «Автоматизация расчёта последствий (функция Симулятора) и ведения рефлексивного диалога (функция Тьютора) не просто экономит время преподавателя, но и позволяет достичь образовательных результатов, недоступных в ручном режиме. Например: (А) Тьютор может отслеживать десятки логических ошибок у 10 команд одновременно и адаптировать вопросы под конкретный тип ошибки; (Б) Тьютор может обеспечить анонимность и психологическую безопасность для рефлексии, которую не всегда обеспечивает живой преподаватель; (В) Симулятор может вводить стохастические (случайные) элементы, которые человеку-“волшебнику” сложно администрировать».
    *   **Проверка:** Эта гипотеза может быть проверена только после создания MVP (минимально жизнеспособного продукта) и его сравнения с ручным режимом.

**Требуемый результат от автора:** Документ, где эти две гипотезы разделены и для каждой прописаны свои критерии проверки.

#### 25.2 Функциональная карта человеко-машинного цикла

Необходимо описать полный цикл работы в симуляторе не как набор экранов, а как последовательность операций, выполняемых разными акторами (студент, команда, симулятор, тьютор, преподаватель).

#### Что автор предъявил
В описании есть этапы: «T0 → обучение → 10 раундов → T1». Это временная, а не функциональная структура. Неясно, кто и что делает внутри раунда.

#### Reformulation
Более сильная проблема такова: архитектура системы не может быть спроектирована, пока не определены функции и потоки данных между ними. Нужно описать систему как конвейер по обработке информации и принятию решений.

#### Пересборка
Сильная версия такова: автор должен предоставить диаграмму или таблицу, описывающую один раунд симуляции по следующей схеме для каждой операции (например, «Анализ рынка», «Выбор объекта», «Обсуждение с тьютором», «Расчёт последствий»):
*   **Операция:** Название шага.
*   **Актор:** Кто выполняет (Команда, ИИ-Тьютор, Ядро Симулятора, Преподаватель).
*   **Входные данные:** Какую информацию актор получает для выполнения операции? (Например, для «Анализа рынка» входом являются «данные макро-сценария на текущий год» и «состояние портфеля команды»).
*   **Действие:** Что конкретно делает актор? (Например, «Команда изучает данные и формулирует 2-3 варианта действий»).
*   **Выходные данные (артефакт):** Что является результатом операции? (Например, «Текстовое описание выбранного варианта с обоснованием»).
*   **Handoff:** Кому и в каком виде передаётся этот результат? (Например, «Обоснование передаётся ИИ-Тьютору в виде текстового промпта»).

Только такая карта позволит инженерам понять, какие сервисы, API и базы данных им нужно создать.

#### Требует решения автора
1.  Кто инициирует диалог с тьютором: студент по желанию или тьютор принудительно после каждого решения?
2.  Имеет ли преподаватель возможность вмешиваться в симуляцию или диалог с тьютором в реальном времени? Если да, то как?
3.  Что происходит, если команда не принимает решение в отведённое время?
4.  Как система хранит «память» о предыдущих решениях команды и использует её в последующих раундах?

#### 25.3 Спецификация ИИ-Тьютора

«ИИ-Тьютор на базе LLM» — это не спецификация. Необходимо определить его поведение, границы и источники знаний.

#### Критика
Утверждение «ИИ-тьютор организует рефлексивный диалог» не определяет его функцию. Это может быть что угодно: от простого чат-бота, отвечающего на вопросы, до проактивного агента, который ведёт студента по методологии рефлексии. Без спецификации лаборатория, скорее всего, реализует простейший вариант, который не будет иметь педагогической ценности. Это как нанять репетитора, не сказав ему, по какому предмету и какой теме нужно заниматься.

#### Пересборка
Минимум нужно различить и специфицировать следующие компоненты Тьютора:
*   **Политика инициации:** Когда и как Тьютор начинает диалог? (Например: «Автоматически после каждого хода команды, с фиксированного вопроса: "Обоснуйте ваш выбор, ссылаясь на данные этого раунда"»).
*   **База знаний (контекст):** К какой информации Тьютор имеет доступ для ведения диалога? Только к последнему ходу? Ко всей истории ходов команды? К теоретическим материалам курса? К данным других команд?
*   **Промпт-инжиниринг:** Какова его «роль» и «инструкция»? (Например: «Ты — скептичный инвестиционный аналитик. Твоя задача — не давать ответы, а находить слабые места в аргументации студентов. Задавай вопросы, начинающиеся с "Почему вы уверены, что...", "А что если...", "Какие данные подтверждают ваше предположение о..."»).
*   **Политика оценки и эскалации:** Как Тьютор оценивает ответ студента? Если ответ нерелевантен или слаб, что он делает? Повторяет вопрос? Переформулирует? Предлагает подсказку? Сигнализирует преподавателю?
*   **Политика отказа (Refusal Policy):** В каких случаях Тьютор должен категорически отказать в помощи? (Например: «При прямом вопросе "Что нам купить?" Тьютор отвечает: "Моя задача — помочь вам научиться принимать решения, а не принимать их за вас"»).

#### 25.4 Спецификация ядра Симулятора

Симулятор — это детерминированная или стохастическая модель. Её правила должны быть описаны математически.

#### Критика
Утверждение «симулятор с моделью динамики рынка и формулами изменения цен» скрывает всю сложность. Какие именно формулы? Как они связаны? Если автор не может записать их на бумаге, лаборатория не сможет их запрограммировать. Это приведёт либо к отказу от разработки, либо к созданию «чёрного ящика», который автор не сможет ни контролировать, ни объяснить студентам.

#### Пересборка
Сильная версия такова: автор должен предоставить документ «Математическая модель симуляции», содержащий:
*   **Перечень всех сущностей:** Объект, Портфель, Рынок, Кредит и т.д.
*   **Перечень всех переменных состояния:** Для Объекта это `цена`, `арендная_ставка`, `состояние`; для Рынка — `ключевая_ставка`, `инфляция`, `уровень_риска` и т.д.
*   **Формулы перехода:** Набор уравнений, которые описывают, как переменные состояния изменяются от раунда `N` к раунду `N+1`. Например:
    *   `Цена_объекта(N+1) = Цена_объекта(N) * (1 + %_роста_рынка(N)) * (1 - %_амортизации(N))`
    *   `%_роста_рынка(N) = f(ключевая_ставка(N), инфляция(N))`
    *   `Денежный_поток(N) = (Арендный_доход(N) - Платеж_по_ипотеке(N) - Налоги(N) - Расходы_на_ремонт(N))`
*   **Источники данных:** Для каждой экзогенной переменной (которая не рассчитывается внутри модели, а приходит извне, как `ключевая_ставка`) должен быть указан источник — один из трёх заранее заданных сценариев.

Только после предоставления этих четырёх блоков спецификаций можно будет составить осмысленное ТЗ для лаборатории на разработку MVP.

---

## 26. Первый инженерный вертикальный цикл

Этот цикл описывает последовательность шагов от текущего состояния (концепция проекта) до работающего MVP (минимально жизнеспособного продукта) и решения о его дальнейшей судьбе. Цикл основан на результатах пилота «Человек за занавеской», так как именно он даёт недостающие данные для спецификации.

**Шаг 1: Финализация дизайна и материалов для ручного пилота**
*   **Что делается:** Автор проекта, совместно с аналитиком, утверждает дизайн пилота (раздел 24), разрабатывает рубрики оценки, кейсы T0/T1/T2, три макро-сценария и Excel-модель для расчёта последствий.
*   **Кто исполняет:** Автор проекта, аналитик.
*   **Что на выходе:** Пакет документов «Материалы для пилота v1.0». Excel-файл с работающими формулами.
*   **Критерий перехода:** Все материалы готовы и протестированы на 1-2 «пробных» прогонах самим автором.

**Шаг 2: Проектирование и тестирование прототипа ИИ-Тьютора**
*   **Что делается:** На основе спецификаций (раздел 25.3) создаются системные промпты для LLM. Прототип тестируется в чат-интерфейсе на нескольких типовых диалогах, проверяется его адекватность и следование инструкциям.
*   **Кто исполняет:** Автор проекта, возможно, с помощью инженера по промптам.
*   **Что на выходе:** Документ с 3-5 версиями системных промптов. Логи тестовых диалогов.
*   **Критерий перехода:** Выбрана версия промпта, которая наиболее стабильно выполняет педагогическую задачу.

**Шаг 3: Проведение пилота в режиме «Человек за занавеской»**
*   **Что делается:** Проводится полный цикл пилота со студентами (T0, 10 раундов, T1). Автор или ассистент выполняет роль ядра симулятора, используя Excel. ИИ-Тьютор используется в группах A и C.
*   **Кто исполняет:** Автор проекта, ассистент, студенты.
*   **Что на выходе:** Полный набор сырых данных: работы T0/T1, логи чатов, Excel-файлы с историей ходов каждой команды.
*   **Критерий перехода:** Пилот завершён, данные собраны и архивированы.

**Шаг 4: Анализ данных пилота и формулирование выводов**
*   **Что делается:** Проводится оценка работ по рубрикам, статистический и качественный анализ данных. Формулируются ответы на исследовательские вопросы пилота.
*   **Кто исполняет:** Автор проекта, аналитик.
*   **Что на выходе:** Отчёт по итогам пилота с выводами о вкладе симулятора и тьютора.
*   **Критерий перехода:** Отчёт утверждён. Принято принципиальное решение о целесообразности автоматизации.

**Шаг 5: Формализация математической модели и логики**
*   **Что делается:** На основе успешных правил из Excel-модели и выводов пилота создаётся финальная, формальная спецификация ядра симулятора и ИИ-тьютора (документы из разделов 25.2, 25.3, 25.4).
*   **Кто исполняет:** Автор проекта.
*   **Что на выходе:** Документы «Функциональная карта v1.0», «Спецификация ИИ-Тьютора v1.0», «Математическая модель симуляции v1.0».
*   **Критерий перехода:** Документы проходят проверку инженером на полноту и непротиворечивость.

**Шаг 6: Написание ТЗ и разработка MVP ядра Симулятора**
*   **Что делается:** На основе формальных спецификаций пишется ТЗ для лаборатории. Инженеры разрабатывают «безголовое» ядро симулятора — сервис, который по API принимает на вход состояние раунда и возвращает результат.
*   **Кто исполняет:** Автор проекта (пишет ТЗ), инженеры лаборатории (разрабатывают).
*   **Что на выходе:** Работающий API-endpoint ядра симулятора. Документация к API.
*   **Критерий перехода:** API проходит набор автоматических тестов, которые эмулируют ходы из ручного пилота и показывают идентичные результаты.

**Шаг 7: Разработка MVP интерфейсов и интеграция**
*   **Что делается:** Создаются минималистичные интерфейсы: для студента (простой веб-интерфейс для ввода решения и чата с тьютором) и для преподавателя (панель для мониторинга). Ядро симулятора и сервис LLM-тьютора подключаются к этим интерфейсам.
*   **Кто исполняет:** Инженеры лаборатории.
*   **Что на выходе:** Работоспособный веб-прототип MVP.
*   **Критерий перехода:** Прототип успешно проходит полный цикл одного раунда в тестовом режиме.

**Шаг 8: Проведение второго, автоматизированного пилота**
*   **Что делается:** На новой группе студентов (или на той же, если прошло достаточно времени) проводится повторный пилот, но уже с использованием MVP. Дизайн эксперимента сохраняется.
*   **Кто исполняет:** Автор проекта, студенты.
*   **Что на выходе:** Новый набор данных, аналогичный собранному на Шаге 3.
*   **Критерий перехода:** Пилот завершён, данные собраны.

**Шаг 9: Сравнительный анализ двух пилотов**
*   **Что делается:** Сравниваются результаты ручного и автоматизированного пилотов. Оценивается, не потерялись ли педагогические эффекты при автоматизации. Собирается обратная связь от студентов по юзабилити MVP.
*   **Кто исполняет:** Автор проекта, аналитик.
*   **Что на выходе:** Отчёт о сравнительном анализе. Список багов и предложений по доработке MVP.
*   **Критерий перехода:** Отчёт утверждён.

**Шаг 10: Принятие решения о развитии продукта**
*   **Что делается:** На основе всех собранных данных принимается решение о дальнейшей судьбе проекта: (А) закрыть как неэффективный, (Б) оставить в виде MVP для использования на курсе, (В) выделить ресурсы на полноценную разработку с расширением функционала.
*   **Кто исполняет:** Автор проекта, руководство.
*   **Что на выходе:** Дорожная карта развития продукта на 1-2 года или решение о его консервации/закрытии.
*   **Критерий перехода:** Решение зафиксировано и доведено до команды.

---

## 27. Следующий пакет материалов

1.  **Детализированная модель симулятора.** Автор должен выбрать один из трёх путей реализации симулятора (покупка готового решения, собственная разработка, упрощённая модель на базе LLM и сценарных карточек) и предоставить его описание.
    - **Владелец:** Вилков И.Н.
    - **Критерий готовности:** Предъявлен документ на 1-2 страницы, где описаны: а) ключевые формулы расчёта (изменение цены объекта, арендной ставки, стоимости кредита); б) источники макроэкономических данных и триггеры их влияния на модель (например, «рост ключевой ставки на 1% → рост ипотечной ставки на 1.5% → снижение спроса на 5%»); в) перечень случайных событий («ремонт», «проблемный арендатор») и их последствий.

2.  **Карта логики и промптов ИИ-тьютора.** Необходимо операционализировать роль тьютора, перейдя от общей идеи рефлексивного диалога к конкретным правилам.
    - **Владелец:** Вилков И.Н.
    - **Критерий готовности:** Представлена схема или таблица, где для каждого этапа симуляции (до раунда, после раунда, защита стратегии) указаны: а) триггеры для вмешательства тьютора (например, «команда берёт кредит с плечом > 80%»); б) примеры промптов, инициирующих диалог; в) политика отказа (в каких случаях тьютор не даёт прямой ответ, а возвращает вопрос команде).

3.  **Рубрикатор для экспертной оценки.** Для измерения метрики «экспертный балл» требуется формализованный инструмент оценки, исключающий субъективность.
    - **Владелец:** Вилков И.Н.
    - **Критерий готовности:** Предъявлена таблица с критериями оценки финальной защиты стратегии. Для каждого критерия («аргументированность выбора», «анализ рисков», «использование источников») приведены описания уровней (например, 0 — не сделано, 1 — упомянуто, 2 — раскрыто с примерами, 3 — проанализированы альтернативы).

## 28. Таблица готовности

| Измерение | Оценка | Обоснование |
| :--- | :--- | :--- |
| **Концептуальная зрелость** | Высокая | Проблема чётко определена, теоретическая рамка релевантна, образовательный разрыв реален и значим. |
| **Дидактическая проработка** | Средняя | Структура симуляции (10 раундов) и формат (команды, защита) сильные, но педагогическая функция ИИ-тьютора не операционализирована. |
| **Экспериментальный дизайн** | Высокая | Квазиэксперимент pre/post с множественными метриками является методологически корректным и достаточным для проверки гипотезы. |
| **Архитектура ИИ-решения** | Низкая | Заявлена «гибридная архитектура», но её составные части (модель рынка, логика тьютора) не спроектированы; это «чёрный ящик». |
| **Ресурсная обеспеченность** | Низкая | Существует сильное противоречие между амбицией создать реалистичную модель рынка и ресурсами одного преподавателя в рамках семестра. |
| **Проработка рисков** | Средняя | Риск устаревания данных с ЦИАН осознан, но главный риск — нереализуемость самого симулятора в заявленном виде — не проработан. |

## 29. Главный внутренний вывод

Проект представляет собой методологически грамотно спроектированный педагогический эксперимент, нацеленный на решение реальной проблемы: неспособности участников применять теоретические знания об экономике недвижимости в динамической, неопределённой среде. Его ядро — ускорение цикла обратной связи с десяти лет реального инвестиционного горизонта до нескольких практических занятий, что является сильным дидактическим ходом. Заявленные теоретические основания (деятельностный подход, ситуационное обучение) адекватны и функциональны, а не декоративны.

Несущий разрыв проекта находится в его технологическом ядре. Заявленный «гибридный ИИ-симулятор» — это пока что не архитектура, а название для двух разных, нерешённых проблем: **1) проблема модели мира** (каковы законы и события симулируемого рынка?) и **2) проблема педагогического агента** (каковы правила вмешательства ИИ-тьютора для стимуляции рефлексии?). Без решения этих проблем проект похож на детально проработанный план полёта и прекрасно оборудованную кабину пилота для авиасимулятора, у которого отсутствует физический движок. Студенты могут нажимать на кнопки, но самолёт никуда не полетит, потому что законы аэродинамики и гравитации не определены.

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

## 30. Один несущий вопрос на следующий семинар

Предположим, на разработку сложного программного симулятора нет ни времени, ни ресурсов. Ваша задача — провести эксперимент, используя только бумажные карточки с описанием объектов, калькулятор и большую языковую модель в роли «Духа Рынка». Какие три-пять незыблемых правил вы бы задали этой модели для её ответов командам, чтобы ваша ключевая педагогическая гипотеза о развитии навыка принятия обоснованных решений всё ещё могла быть проверена?

## 31. Контекстное сплетение

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

Прежде всего, это эталонный пример **«Малого эксперимента в поле большой модели»** (`CM-U2`). Проект является локальным пилотом, проверяющим гипотезу в рамках одного курса. Его успех не гарантирует переносимости: `scaling gap` (разрыв масштабирования) здесь заключается в сильной зависимости от сиюминутных данных с ЦИАН и потенциально уникальной, невоспроизводимой логики симулятора. Условием переноса (`transfer condition`) становится не просто доказательство эффективности, а создание воспроизводимой «коробки» — пакета из модели симулятора, промптов тьютора и рубрикаторов, который другой преподаватель сможет развернуть у себя.

Во-вторых, проект напрямую апеллирует к **«Функционально-архитектурной модели»** (`CM-T1`), заявляя «гибридную архитектуру». Сейчас это утверждение не подкреплено схемой. Диагностика в этой рамке требует от автора провести различение между `ролью` («ИИ-тьютор») и конкретными `функциями` («задать вопрос о кредитном плече при превышении порога», «сгенерировать саммари по итогам раунда»). Ключевой вопрос модели — «какой полный цикл существует без ИИ?» — позволяет отделить базовую деятельность участников (расчёты, обсуждения в команде) от той добавленной стоимости, которую привносит автоматизация и агентность. Различение `AI capability ≠ assigned edu function` (возможность ИИ не равна назначенной ему образовательной функции) здесь критично: способность LLM вести диалог на любую тему не означает, что он выполняет педагогическую задачу; для этого ему нужна жёсткая политика вмешательства.

Наконец, проект затрагивает модель **«Гибридного исследовательского интеллекта»** (`CM-HYBRID-R`), хотя и менее явно. Команда студентов, симулятор и ИИ-тьютор вместе образуют систему распределённого познания (`distributed cognition`). Возникает важный вопрос о двойном результате: участники учатся анализу рынка недвижимости (`subject capability`) или они учатся оперировать этой конкретной гибридной системой (`orchestration capability`)? Проект нацелен на первое, но по факту может формировать второе. Осознание этого двойного результата позволяет точнее спроектировать финальную оценку: нужно проверять не только способность работать внутри симулятора, но и способность решать аналогичную задачу без него, чтобы доказать перенос навыка за пределы инструмента.

---


---

## Rendering metadata

- Clusters rendered: 7 · Sections: 30
- Model: `gemini-2.5-pro`
- Total output tokens: 67239
- Total output chars: 142870
- Elapsed: 681.3s