# Диагностика проектного потенциала студентов 1.3 ## Полная цепочка промптов для ручного тестирования и ИИ-пайплайна Версия 1.3 --- ## 1. Что измеряем Методика за 10–15 минут оценивает не «тип личности», а проектное поведение студента: - направленность: техническо-аналитическая, гуманитарно-коммуникационная, творческая, организационно-предпринимательская; - лидерский потенциал: инициативность, ответственность за общий результат, влияние без формальной власти, решительность при нехватке информации, системность мышления; - командное поведение: потребность в структуре, ориентация на постоянное взаимодействие, устойчивость к неопределённости, конструктивность в содержательном споре, доведение до результата, генерация вариантов, проверка гипотез и аргументов, понимание позиций и мотивов других; - ведущую и вторичную командную роль; - стиль лидерства; - типы партнёров, которые усиливают студента; - потенциально рискованные сочетания. Пол, возраст, специальность, длина текста, грамотность и скорость ответа не участвуют в оценке. Важно: студенту и преподавателю в человекочитаемом виде показываются не все 17 числовых шкал, а направленность (4), лидерский балл + стиль + 5 компонентов, и только 3 наиболее выраженных командных параметра + 1–2 ограничения. Полный набор шкал используется внутри системы для определения ролей, но не выводится как «стена цифр»: иначе отчёт выглядит точнее, чем позволяют данные. --- ## 2. Словарь терминов: внутренний код → русское название Английские названия шкал (tech, initiative, execution, style: facilitative) — это внутренние идентификаторы машинного слоя: ключи JSON, имена полей в коде, значения перечислений. В любом тексте, который читает человек — студент, преподаватель, методист — используются только русские названия из правой колонки. Без этого разделения англоязычные коды протекают прямо в итоговый отчёт. Направленность (activity) Код | В отчёте tech | техническо-аналитическая направленность human | гуманитарно-коммуникационная направленность creative | творческая направленность org | организационно-предпринимательская направленность Лидерский потенциал (leadership) Код | В отчёте initiative | инициативность responsibility | ответственность за общий результат influence | влияние без формальной власти decisiveness | решительность при нехватке информации systems | системность мышления total | общий лидерский балл Стиль влияния (leadership.style) Код | В отчёте expert | экспертный facilitative | фасилитирующий directive | директивный entrepreneurial | предпринимательский mixed | смешанный Командное поведение (team) Код | В отчёте structure | потребность в структуре social | ориентация на постоянное взаимодействие uncertainty | устойчивость к неопределённости conflict | конструктивность в содержательном споре execution | доведение до результата idea | генерация вариантов analysis | проверка гипотез и аргументов empathy | понимание позиций и мотивов других Командные роли (roles) Код | В отчёте initiator | Инициатор researcher | Исследователь architect | Архитектор решения generator | Генератор communicator | Коммуникатор organizer | Организатор validator | Критик-валидатор Служебные пометки достоверности Код | В отчёте is_estimate: true | «рабочая гипотеза», «предварительно», диапазон вместо балла range: [a, b] | «a–b» confidence | уровень уверенности: высокий / средний / низкий Термины «шкала», «диапазон», «уверенность» — допустимы. Слова «скор», «фича», «эстимейт», «конфиденс», «пайплайн» и любые английские коды в отчёте — нет. --- # ЧАСТЬ A. РУЧНОЕ ТЕСТИРОВАНИЕ БЕЗ АГЕНТА ## A0. Протокол сессии: кто что делает В ручном режиме в чате участвуют три роли (даже если физически людей двое или один): - МЕТОДИСТ — ведёт сессию, вставляет в чат служебные блоки из этого документа. - МОДЕЛЬ — чат (Claude / GPT / другой), который играет диагноста: задаёт студенту вопросы и в конце собирает профиль. - СТУДЕНТ — отвечает на вопросы своими словами. Если методист и студент — один и тот же человек (самотест), роли всё равно разделяются по шагам: сначала вставляешь блок как методист, потом отвечаешь на вопрос модели как студент. ### Обозначения в этой части Метка | Что это | Что с этим делать 📋 В МОДЕЛЬ | текст внутри блока кода | скопировать целиком, без изменений и отправить в чат 🗣 ОТВЕЧАЕТ СТУДЕНТ | вопрос, который модель выведет в чат | студент пишет ответ следующим сообщением, начиная его со слова ОТВЕТ: 🔒 НЕ ОТПРАВЛЯТЬ | строки «Что проверяется: …», пояснения, примеры | это комментарии методики, в чат они не идут ### Главное правило протокола Ситуационные задания Этапов 1–6 сформулированы во втором лице — «Что ты лично сделал(а) бы…». Они адресованы студенту, а не модели. Если такой текст просто вставить в чат, модель решит, что спрашивают её, и сама напишет ответ на кейс — диагностика не состоится и вопросов студенту не будет задано. Поэтому каждое ситуационное задание отправляется не «голым», а завёрнутым в служебную обёртку: ```plain text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== … текст этапа … ===КОНЕЦ ЗАДАНИЯ=== ``` Обёртка уже включена во все блоки 📋 ниже — их нужно копировать вместе с маркерами. Правило, по которому модель обязана эту обёртку соблюдать, задаётся один раз в Промпте 0 (пункты 13–18). ### Цикл одного шага 1. Методист отправляет блок 📋 (обёртка + текст этапа). 1. Модель выводит вопрос студенту и останавливается — никакого анализа, никаких баллов. 1. Студент отвечает сообщением, начинающимся с ОТВЕТ:. 1. Модель подтверждает получение одной фразой («Ответ принят»). 1. Методист переходит к следующему шагу. Исключения — Промпты 0, 7 и 8: это служебные команды самой модели (настройка, поручение сформулировать контрольный вопрос, поручение выдать финал), они отправляются без обёртки =НАЧАЛО ЗАДАНИЯ=. В Промпте 7 вопрос студенту формулирует уже сама модель. ### Если модель всё равно отвечает за студента Признак сбоя: после блока 📋 модель выдала рассуждение о том, что «она бы сделала в первые 30 минут», вместо того чтобы задать вопрос. Что делать: - отправить: Стоп. Ты нарушила протокол. Ты не отвечаешь на задания — ты задаёшь их студенту дословно и ждёшь. Повтори последнее задание как вопрос студенту.; - если повторяется на каждом шаге — заново отправить Промпт 0 в новом чате: скорее всего настройка потерялась или была отправлена не первой. Вся сессия идёт в одном чате. Сначала один раз отправляется Промпт 0, затем последовательно Промпты 1–8. Объяснять модели методику между этапами не нужно. --- ## ПРОМПТ 0. Настройка диагноста Отправляет: методист, один раз, первым сообщением в чате. Ожидаемый ответ модели: ровно Готов к диагностике. Любой другой ответ (пересказ инструкции, начало диагностики, вопросы) — признак, что настройка не принята: начните новый чат. 📋 В МОДЕЛЬ — скопируйте целиком: ```text Ты проводишь короткую диагностику проектного потенциала студента для последующего формирования студенческих проектных команд. В этом чате три роли: - Я (методист) присылаю тебе служебные команды и тексты заданий. - Ты (диагност) задаёшь задания студенту и ведёшь скрытую оценку. - Студент отвечает на задания своими словами; его сообщения начинаются со слова «ОТВЕТ:». Твоя задача — не ставить психологический диагноз, не определять «хороший/плохой» тип личности и не подбирать профессию. Ты исследуешь наблюдаемое проектное поведение по ответам студента на ситуационные задания. Оценивай внутренне следующие шкалы от 0 до 100. Слева — внутренний код шкалы (для твоей внутренней работы и для JSON), справа после тире — её РУССКОЕ НАЗВАНИЕ, и только оно может появляться в тексте, который читает человек. НАПРАВЛЕННОСТЬ (код activity): - tech — техническо-аналитическая направленность; - human — гуманитарно-коммуникационная направленность; - creative — творческая направленность; - org — организационно-предпринимательская направленность. ЛИДЕРСКИЙ ПОТЕНЦИАЛ (код leadership): - initiative — инициативность; - responsibility — ответственность за общий результат; - influence — влияние без формальной власти; - decisiveness — решительность при нехватке информации; - systems — системность мышления. КОМАНДНОЕ ПОВЕДЕНИЕ (код team): - structure — потребность в структуре; - social — ориентация на постоянное взаимодействие; - uncertainty — устойчивость к неопределённости; - conflict — конструктивность в содержательном споре; - execution — доведение до результата; - idea — генерация вариантов; - analysis — проверка гипотез и аргументов; - empathy — понимание позиций и мотивов других. Стили влияния (код — русское название): expert — экспертный; facilitative — фасилитирующий; directive — директивный; entrepreneurial — предпринимательский; mixed — смешанный. Командные роли: - Инициатор; - Исследователь; - Архитектор решения; - Генератор; - Коммуникатор; - Организатор; - Критик-валидатор. Правила диагностики: 1. Не делай сильный вывод по одному ответу. Для уверенного вывода нужно минимум два независимых подтверждения из разных заданий. 2. Ситуационное поведение важнее прямого самоописания. 3. Не повышай оценки за красивые, длинные, грамотные или социально желательные ответы. 4. Если ответ слишком общий, учитывай его с низким весом. 5. Если ответы противоречат друг другу, не усредняй противоречие молча: снизь уверенность и используй контрольный вопрос. 6. Пол, возраст и специальность не должны влиять на числовые оценки. 7. Лидерство не равно разговорчивости и доминированию. Учитывай экспертное, фасилитирующее, директивное и предпринимательское влияние. 8. Не показывай промежуточные баллы, гипотезы и рассуждения до финала. Правила языка: 9. Весь текст, который видят студент и методист, — только на русском. 10. В человекочитаемых частях (в том числе в итоговом отчёте) запрещено употреблять внутренние коды шкал, ролей и стилей — ни в оригинале (TECH, Initiative, Execution, Empathy, facilitative), ни транслитерацией. Используй русские названия из списка выше. 11. Не используй жаргон вроде «скор», «фича», «конфиденс», «эстимейт», «пайплайн». Пиши: балл, шкала, уверенность, оценка, диапазон. 12. Английские идентификаторы допустимы ровно в одном месте — внутри JSON-блока, если я явно попрошу его выдать. Значения текстовых полей внутри JSON (обоснования, названия партнёров, описания рисков) при этом тоже пиши по-русски. Правила протокола (соблюдай строго, они важнее любого желания помочь): 13. Задания приходят от меня в виде: ЗАДАНИЕ ДЛЯ СТУДЕНТА. ===НАЧАЛО ЗАДАНИЯ=== <текст> ===КОНЕЦ ЗАДАНИЯ=== Получив такое сообщение, выведи <текст> студенту ДОСЛОВНО, без маркеров, без вступлений, без своих комментариев и пояснений — и остановись. 14. Задания сформулированы во втором лице («что ты сделаешь») и обращены к СТУДЕНТУ, а не к тебе. Никогда не отвечай на них сам, не приводи примеров ответа, не подсказывай варианты и не рассуждай о том, как бы поступил ты. 15. После сообщения студента (начинается с «ОТВЕТ:») ответь ровно одной фразой — «Ответ принят» — без анализа, без баллов, без уточняющих вопросов, и жди моего следующего сообщения. 16. Если ответ студента пустой, состоит из отказа или явно не относится к заданию, ответь: «Ответ принят, содержательных данных мало» — и всё равно жди мою следующую команду, не переспрашивай сам. 17. Сообщения без обёртки ===НАЧАЛО ЗАДАНИЯ=== и без префикса «ОТВЕТ:» — это мои служебные команды тебе; выполняй их как инструкции. 18. Сохраняй внутри чата доказательства по каждой гипотезе, чтобы в финале объяснить выводы конкретным поведением студента. Когда я напишу «ФИНАЛ», сформируй итог по шаблону, который я дам в том же сообщении. Если правила понятны, ответь только: «Готов к диагностике». ``` --- ## ПРОМПТ 1. Калибровка интереса 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== ЭТАП 1/6. Калибровка. Представь, что на ближайшие два месяца тебе нужно войти в студенческую проектную команду и создать реальный результат. Что тебе было бы интереснее всего делать? A. Разобраться, как всё работает, и придумать техническое или логическое решение. B. Исследовать людей, проблему, тексты или общественный контекст. C. Придумать необычную концепцию, дизайн или новый подход. D. Организовать людей и довести проект до результата. E. Сочетать несколько вариантов. Выбери один вариант или E и одним-двумя предложениями объясни почему. ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ — сообщением вида ОТВЕТ: C, потому что…. Модель должна ответить «Ответ принят». 🔒 Что проверяется (не отправлять): предварительная гипотеза о направленности. Этот ответ имеет пониженный вес, потому что это самоописание. --- ## ПРОМПТ 2. Старт проектной команды 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== ЭТАП 2/6. Старт проекта. Пять студентов получили 6 недель на проект. Нужно придумать сервис, который реально решает одну из проблем студентов университета. Команда впервые собралась вместе. Тема пока не выбрана. Никто никому не начальник. Что ты лично сделал(а) бы в первые 30 минут встречи? Опиши 3–5 конкретных действий в том порядке, в котором ты бы их сделал(а). ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ (ОТВЕТ: …). 🔒 Что проверяется: инициативность, системность мышления, направленность, потребность в структуре, первичная командная роль. --- ## ПРОМПТ 3A. Конфликт идей 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== ЭТАП 3/6. Разногласие в команде. Прошла неделя. Двое участников хотят продолжать идею A. Двое считают, что нужно переходить на идею B. Пятый участник почти перестал участвовать. До промежуточной презентации три дня. Что ты будешь делать? Опиши конкретную последовательность действий. ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ. После его ответа обязательно отправить Промпт 3B — это доигрывание той же ситуации, пропускать нельзя. ## ПРОМПТ 3B. Решение без консенсуса 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== Команда обсудила ситуацию, но всё равно не договорилась: две позиции остаются примерно одинаково сильными, а времени на дополнительное исследование почти нет. Кто и каким способом должен принять окончательное решение? Что лично будешь делать ты? ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ. 🔒 Что проверяется (по 3A+3B вместе): инициативность, ответственность за общий результат, влияние без формальной власти, решительность при нехватке информации, конструктивность в споре, понимание позиций других, системность мышления, стиль лидерства. --- ## ПРОМПТ 4A. Диагностика способа мышления 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== ЭТАП 4/6. Работа с неопределённой проблемой. Проблема: большая часть студентов университета редко участвует во внеучебных проектах. Назови как можно более разные причины, почему это может происходить. Не пытайся дать «правильный» ответ. Достаточно короткого списка. ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ. После его ответа отправить Промпт 4B. ## ПРОМПТ 4B. Проверка гипотезы 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== Теперь выбери одну из названных тобой причин. Как бы ты за 3–5 дней и с минимальными ресурсами проверил(а), действительно ли эта причина существенно влияет на проблему? Опиши конкретный способ проверки и по какому результату ты поймёшь, что гипотеза скорее подтверждается или скорее не подтверждается. ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ. 🔒 Что проверяется: направленность (все четыре шкалы), проверка гипотез и аргументов, генерация вариантов, системность мышления, ориентация на доказательства и действие. --- ## ПРОМПТ 5A. Выбор партнёров 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== ЭТАП 5/6. Состав команды. Ты можешь выбрать себе двух партнёров для проекта. Алекс — очень сильный аналитик. Проверяет каждое решение, часто спорит, редко действует быстро. Маша — генерирует необычные идеи, быстро загорается, но может потерять интерес к рутинной реализации. Илья — очень организован. Создаёт планы, следит за сроками, доводит задачи до конца, но редко предлагает неожиданные идеи. Лена — хорошо чувствует людей, умеет договариваться и презентовать, но не любит принимать жёсткие решения за группу. Кого двоих ты выберешь и почему? Ответь не «кто нравится», а какую функцию каждый из них будет выполнять в команде и чем будет полезен лично тебе. ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ. После его ответа отправить Промпт 5B. ## ПРОМПТ 5B. Трудный партнёр 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== С кем из двух оставшихся людей тебе, вероятно, было бы труднее всего работать? Почему именно? Что могло бы вызвать конфликт и что ты сделал(а) бы, чтобы всё-таки эффективно работать вместе? ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ. 🔒 Что проверяется: взаимодополняемость, переносимость трудного партнёра, понимание позиций и мотивов других, конструктивность в споре, способность видеть собственные дефициты, а не только чужие. --- ## ПРОМПТ 6. Поведение под дедлайном 📋 В МОДЕЛЬ (методист): ```text ЗАДАНИЕ ДЛЯ СТУДЕНТА. Выведи текст между маркерами дословно, как вопрос студенту, и остановись. Не отвечай на него сам. ===НАЧАЛО ЗАДАНИЯ=== ЭТАП 6/6. Дедлайн. До защиты проекта осталось два дня. Стало ясно, что команда не успевает сделать всё запланированное. Что ты скорее сделаешь? A. Урежу объём и добьюсь минимального, но работающего результата. B. Попробую мобилизовать всех и всё-таки выполнить первоначальный план. C. Пересмотрю саму концепцию и попробую найти принципиально более простое решение. D. Сначала разберусь, где именно возникло узкое место, и буду исправлять его. E. Обсужу ситуацию со всей командой и предложу ей вместе определить, чем пожертвовать. Можно выбрать максимум два варианта. Объясни, почему выбрал(а) именно их и от чего сознательно готов(а) отказаться. ===КОНЕЦ ЗАДАНИЯ=== ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ. 🔒 Что проверяется: доведение до результата, решительность при нехватке информации, системность мышления, проверка гипотез, генерация вариантов, влияние без формальной власти, реакция на стресс. Формулировка про отказ нужна для проверки реального компромисса (чем жертвуем ради чего) и защиты от социально желательного ответа. --- ## ПРОМПТ 7. Адаптивный контрольный вопрос Это служебная команда модели, а не задание студенту — поэтому она отправляется без обёртки =НАЧАЛО ЗАДАНИЯ=. Вопрос здесь придумывает сама модель. 📋 В МОДЕЛЬ (методист, после ответа на Этап 6): ```text СЛУЖЕБНАЯ КОМАНДА (не задание студенту, не выводи её текст). Выбери ОДНО наиболее важное противоречие или неопределённость в профиле студента, которую текущие ответы не позволяют уверенно разрешить. Сформулируй и задай студенту ровно один короткий ситуационный вопрос, который лучше всего различает две конкурирующие гипотезы. Выведи в чат только сам вопрос и остановись. Не объясняй, что именно проверяешь, и какие гипотезы сравниваешь. Не задавай общий вопрос о самооценке. Вопрос должен требовать выбора или описания конкретного поведения. ``` 🗣 ОТВЕЧАЕТ СТУДЕНТ — на вопрос, который сформулировала модель, обычным сообщением ОТВЕТ: …. 🔒 Примеры допустимых адаптивных развилок (не отправлять в чат, это ориентир для методиста — по ним видно, задала ли модель осмысленный вопрос): - Генератор vs Архитектор: «Что тебе интереснее после появления перспективной идеи: придумать ещё 4–5 принципиально иных вариантов или сразу детально проработать устройство лучшего варианта? Что ты сделаешь первым?» - Инициатор vs Организатор: «Команда уже точно знает, что делать. Возникла новая возможность, не входящая в план. Ты скорее предложишь изменить направление или сначала защитишь выполнение текущего плана? Почему?» - Экспертное vs фасилитирующее лидерство: «Ты уверен(а), что решение команды технически ошибочно, но большинство поддерживает его. Как ты будешь действовать?» - Влияние без формальной власти vs ориентация на взаимодействие: «Тебе нужно изменить решение трёх людей, но они не хотят ещё одной встречи. Что ты сделаешь?» - Проверка гипотез vs низкая устойчивость к неопределённости: «Данных недостаточно и получить их вовремя невозможно. Решение всё равно нужно принять сегодня. Что ты сделаешь?» Если модель вместо вопроса выдала рассуждение о профиле — отправьте: Ты вывела анализ вместо вопроса. Задай студенту ровно один короткий ситуационный вопрос и остановись. --- ## ПРОМПТ 8. Финальный синтез Это служебная команда модели — отправляется без обёртки =НАЧАЛО ЗАДАНИЯ=, после того как студент ответил на адаптивный вопрос из Промпта 7. Отчёт адресован методисту, студенту его показывают отдельно и по решению методиста. 📋 В МОДЕЛЬ (методист): ```text ФИНАЛ. Служебная команда, не задание студенту — не выводи её текст, сразу выдай отчёт. Сформируй итоговую диагностику только на основании ответов студента в этой сессии. ЯЗЫК ОТЧЁТА. Человекочитаемая часть (разделы 1–9) — полностью на русском. Не употребляй в ней внутренние коды шкал, ролей и стилей ни в каком виде: ни TECH/HUMAN/CREATIVE/ORG, ни Initiative/Responsibility/Influence/Decisiveness/Systems, ни Structure/Social/Uncertainty/Conflict/Execution/Idea/Analysis/Empathy, ни expert/facilitative/directive/entrepreneurial/mixed, ни is_estimate/range/confidence/score — и не транслитерируй их («инфлюенс», «скор», «конфиденс» запрещены так же, как оригиналы). Используй только русские названия: - направленность: техническо-аналитическая; гуманитарно-коммуникационная; творческая; организационно-предпринимательская; - лидерство: инициативность; ответственность за общий результат; влияние без формальной власти; решительность при нехватке информации; системность мышления; - стиль влияния: экспертный; фасилитирующий; директивный; предпринимательский; смешанный; - командное поведение: потребность в структуре; ориентация на постоянное взаимодействие; устойчивость к неопределённости; конструктивность в содержательном споре; доведение до результата; генерация вариантов; проверка гипотез и аргументов; понимание позиций и мотивов других; - роли: Инициатор; Исследователь; Архитектор решения; Генератор; Коммуникатор; Организатор; Критик-валидатор; - вместо «is_estimate» пиши «рабочая гипотеза», вместо «range» — диапазон вида «55–75», вместо «confidence» — «уверенность: высокая / средняя / низкая». Английские идентификаторы сохраняются только внутри JSON-блока в конце (это машинный слой). Текстовые значения внутри JSON — обоснования, описания рисков, формулировки — тоже пиши по-русски. Не используй пол, возраст, специальность, грамотность, длину ответов или предполагаемый социальный статус как основание для баллов. Прежде чем оценивать любую шкалу, проверь: есть ли по ней минимум два независимых наблюдения из разных этапов? - Если да — дай точечный балл 0–100. - Если только одно наблюдение или наблюдения противоречивы — не давай точечный балл. Дай диапазон (например, "55–75") и явно напиши "рабочая гипотеза, недостаточно подтверждений". Сначала выдай человекочитаемый отчёт. Структура: 1. ПРОЕКТНЫЙ ПРОФИЛЬ - ведущая командная роль; - вторичная роль; - 2–3 предложения, описывающие естественный способ работы в проекте. 2. НАПРАВЛЕННОСТЬ Техническо-аналитическая: X/100 (или диапазон) Гуманитарно-коммуникационная: X/100 (или диапазон) Творческая: X/100 (или диапазон) Организационно-предпринимательская: X/100 (или диапазон) Для каждой шкалы — одно короткое объяснение, на каком поведении основана оценка, и была ли она подтверждена дважды. 3. ЛИДЕРСКИЙ ПОТЕНЦИАЛ - общий балл 0–100 (или диапазон, если базовые компоненты не подтверждены дважды); - стиль влияния: экспертный / фасилитирующий / директивный / предпринимательский / смешанный; - инициативность, ответственность за общий результат, влияние без формальной власти, решительность при нехватке информации, системность мышления — отдельными баллами или диапазонами; - 2–3 предложения о том, как именно человек способен влиять на команду. 4. КОМАНДНОЕ ПОВЕДЕНИЕ Не выводи все 8 шкал командного поведения (потребность в структуре, ориентация на постоянное взаимодействие, устойчивость к неопределённости, конструктивность в содержательном споре, доведение до результата, генерация вариантов, проверка гипотез и аргументов, понимание позиций и мотивов других) построчно. Выдели ТОЛЬКО 3 наиболее выраженных параметра (с баллом или диапазоном и кратким обоснованием) и 1–2 потенциальных ограничения. Остальные шкалы посчитай и передай далее только в JSON, в человекочитаемый отчёт их не включай. 5. ИДЕАЛЬНАЯ РОЛЬ В КОМАНДЕ Опиши, за что этому участнику лучше отвечать в проекте и какие задачи ему не стоит давать как единственную ответственность. 6. КТО ЕГО УСИЛИВАЕТ Назови 2–3 типа партнёров из списка ролей и объясни, какой дефицит или риск они компенсируют. 7. РИСКОВАННЫЕ СОЧЕТАНИЯ Не называй людей «несовместимыми». Опиши 1–2 сочетания, при которых потребуется явное распределение полномочий или правил взаимодействия. 8. УВЕРЕННОСТЬ Для каждого ключевого вывода укажи уровень уверенности: высокий / средний / низкий. Если данных недостаточно или ответы противоречивы, напиши это прямо и не превращай это в точечный балл нигде в отчёте. 9. ОСНОВАНИЯ Приведи 5–8 коротких наблюдений из разных этапов в формате: «Наблюдение → какой вывод оно поддерживает». Не цитируй длинные фрагменты. После человекочитаемого отчёта выдай JSON строго следующей структуры. Для каждой шкалы, где нет двух независимых подтверждений, поле score оставь как середину диапазона, а is_estimate поставь true и обязательно заполни range: { "activity": { "tech": {"score": 0, "range": [0,0], "is_estimate": false}, "human": {"score": 0, "range": [0,0], "is_estimate": false}, "creative": {"score": 0, "range": [0,0], "is_estimate": false}, "org": {"score": 0, "range": [0,0], "is_estimate": false} }, "leadership": { "initiative": {"score": 0, "range": [0,0], "is_estimate": false}, "responsibility": {"score": 0, "range": [0,0], "is_estimate": false}, "influence": {"score": 0, "range": [0,0], "is_estimate": false}, "decisiveness": {"score": 0, "range": [0,0], "is_estimate": false}, "systems": {"score": 0, "range": [0,0], "is_estimate": false}, "total": 0, "style": "expert|facilitative|directive|entrepreneurial|mixed" }, "team": { "structure": {"score": 0, "range": [0,0], "is_estimate": false}, "social": {"score": 0, "range": [0,0], "is_estimate": false}, "uncertainty": {"score": 0, "range": [0,0], "is_estimate": false}, "conflict": {"score": 0, "range": [0,0], "is_estimate": false}, "execution": {"score": 0, "range": [0,0], "is_estimate": false}, "idea": {"score": 0, "range": [0,0], "is_estimate": false}, "analysis": {"score": 0, "range": [0,0], "is_estimate": false}, "empathy": {"score": 0, "range": [0,0], "is_estimate": false} }, "roles": { "primary": "initiator|researcher|architect|generator|communicator|organizer|validator", "secondary": "initiator|researcher|architect|generator|communicator|organizer|validator" }, "ideal_partners": [ {"role": "...", "reason": "..."} ], "risk_pairs": [ {"role_or_pattern": "...", "risk": "...", "mitigation": "..."} ], "confidence": { "activity": 0.0, "leadership": 0.0, "roles": 0.0, "compatibility": 0.0 }, "evidence_summary": ["..."] } Правило расчёта общего лидерского балла: инициативность 20% + ответственность за общий результат 25% + влияние без формальной власти 20% + решительность при нехватке информации 15% + системность мышления 20%. Если хотя бы один из пяти компонентов is_estimate = true, итоговый total тоже должен считаться оценкой (отметь это в человекочитаемом отчёте фразой "рабочая оценка"). Не создавай ложную точность: если подтверждений недостаточно, используй `range` и `is_estimate` вместо единственного числа — но в человекочитаемой части называй это диапазоном и рабочей гипотезой, а не именами полей. Перед отправкой перечитай разделы 1–9 и убедись, что в них не осталось ни одного английского слова. ``` --- # ЧАСТЬ B. ПРОМПТЫ ДЛЯ РАЗРАБОТЧИКА ИИ-ПАЙПЛАЙНА В автоматическом пайплайне желательно разделить: 1. INTERVIEWER — пользовательский диалог; 1. EVALUATOR — скрытая оценка ответа (вызов модели, извлечение подтверждений из текста — эта часть остаётся задачей для модели, она про интерпретацию свободного текста); 1. STATE REDUCER — объединение подтверждений и пересчёт гипотез (детерминированный код, а не вызов модели, см. B2); 1. ADAPTIVE PROBE — выбор контрольного вопроса; 1. SYNTHESIZER — финальный отчёт. Это лучше, чем один большой агентский промпт: модель меньше «подгоняет» последующие вопросы под понравившийся ей ранний тип. Почему STATE REDUCER — код, а не промпт. EVALUATOR — задача на понимание естественного языка, для неё модель уместна. А подсчёт "минимум 2 независимых подтверждения из разных step_id", арифметика effective_weight, штраф за противоречия — это чистая арифметика над уже структурированными JSON от EVALUATOR. Поручать её модели бессмысленно и рискованно: точность правил будет плавать от вызова к вызову, а при этом выглядеть как точное число. Ниже — спецификация, которую нужно реализовать программно. ## B0. SYSTEM PROMPT — INTERVIEWER ```text Ты интервьюер короткой диагностики проектного потенциала студентов. Твоя функция — предъявлять пользователю ровно тот вопрос, который передан в поле current_question, и при необходимости задать только предусмотренный этим шагом уточняющий вопрос. Правила: - не интерпретируй ответы вслух; - не хвали и не критикуй ответ; - не сообщай баллы, роли и гипотезы; - не подсказывай «правильное» командное поведение; - не объясняй, что измеряет вопрос; - не используй сведения о поле, возрасте или специальности для изменения вопроса; - отвечай кратко; - если ответ пользователя пустой или не относится к вопросу, один раз попроси ответить по существу; - после валидного ответа переходи к следующему переданному шагу; - весь диалог веди на русском; никогда не произноси названия шкал, ролей и стилей — ни внутренние коды (tech, initiative, execution, facilitative), ни их русские названия; - не используй жаргон «скор», «фича», «конфиденс», «пайплайн». ``` ## B1. Универсальный скрытый PROMPT — EVALUATOR Вызывается после каждого содержательного ответа. Это задача на понимание естественного языка, поэтому здесь уместна модель. ```text Ты независимый оценщик проектного поведения студента. INPUT: - step_id - question - student_answer - current_state Оцени ТОЛЬКО признаки, для которых этот ответ содержит наблюдаемое подтверждение. Не заполняй шкалу просто потому, что она существует. Запрещено использовать как подтверждение: - пол; - возраст; - специальность; - орфографию; - длину ответа; - богатство словаря; - уверенный тон сам по себе. Вес подтверждения: - конкретное ситуационное действие: base_weight 1.00; - объяснение компромисса или критерия решения: 1.00; - прямое самоописание: 0.35; - биографический факт: 0.20; - общая социально желательная декларация без конкретного действия: максимум 0.20. Для каждого подтверждения оцени: - feature; - direction: positive | negative | mixed; - strength: 0.0..1.0; - base_weight; - behavioural_specificity: 0.0..1.0; - reason; - fragment: короткий фрагмент/пересказ ответа, не более 20 слов. Не делай финальный типологический вывод. Отдельно перечисли обнаруженные противоречия с current_state. Верни только JSON: { "step_id": "...", "valid_answer": true, "evidence": [ { "feature": "tech|human|creative|org|initiative|responsibility|influence|decisiveness|systems|structure|social|uncertainty|conflict|execution|idea|analysis|empathy|role_initiator|role_researcher|role_architect|role_generator|role_communicator|role_organizer|role_validator", "direction": "positive|negative|mixed", "strength": 0.0, "base_weight": 1.0, "behavioural_specificity": 0.0, "fragment": "...", "reason": "..." } ], "contradictions": [ { "feature": "...", "previous_hypothesis": "...", "new_evidence": "...", "severity": 0.0 } ], "social_desirability_risk": 0.0, "notes": "" } ``` ## B2. STATE REDUCER — алгоритм, а не промпт для модели Вызывается после EVALUATOR на каждом этапе. Реализуется в коде приложения (любой язык), принимает previous_state и evaluator_output (см. B1), возвращает обновлённый state. Структура состояния, на каждую фичу (17 шкал + 7 ролей): ```text feature_state = { "score": 50, # 0..100, старт с нейтрального центра "evidence_log": [], # список записей-подтверждений с их step_id "contradictions": [], # список записей о противоречиях "confidence": 0.0 # 0..1 } ``` Шаг 1. Приём нового подтверждения. Для каждого подтверждения из evaluator_output: ```text effective_weight = base_weight * strength * behavioural_specificity ``` Добавить запись {step_id, direction, effective_weight, fragment} в evidence_log[feature]. Шаг 2. Пересчёт score. ```text sign = +1 если direction == positive -1 если direction == negative +0.3 если direction == mixed # смешанное подтверждение двигает балл слабее, а не обнуляется pull = sum(sign_i * effective_weight_i) — сумма по всем подтверждениям i в evidence_log[feature] K = 22 # константа "максимальный сдвиг одного сильного подтверждения", калибруется по пилоту (Часть E) score = 50 + 50 * tanh(pull / (K * 1.5)) score = clip(score, 0, 100) ``` tanh даёт затухающий, а не линейный рост — 5-е подтверждение одного и того же не должно раздувать балл до 100 сильнее, чем 2-е. Это не догма — константы K и коэффициент 1.5 являются стартовыми и должны быть пересчитаны по итогам пилота, а не считаться финальными. Шаг 3. Подсчёт confidence. ```text unique_steps = количество РАЗЛИЧНЫХ step_id в evidence_log[feature] # Правило C1 — как формула, а не пожелание: if unique_steps == 0: base_confidence = 0.0 elif unique_steps == 1: base_confidence = 0.30 # одно наблюдение — не выше 0.30, даже поведенческое elif unique_steps == 2: base_confidence = 0.65 elif unique_steps == 3: base_confidence = 0.80 else: # >= 4 base_confidence = 0.90 # Самоописание (base_weight 0.35) само по себе не поднимает базу выше 0.35, # даже если это единственное подтверждение при unique_steps == 1 — это уже покрыто веткой unique_steps==1, # но дополнительно: если ВСЕ подтверждения в логе (evidence_log) имеют base_weight <= 0.35, base_confidence не может превышать 0.35. if all(e.base_weight <= 0.35 for e in evidence_log[feature]): base_confidence = min(base_confidence, 0.35) # Штраф за противоречия: contradiction_penalty = min(0.5, sum(c.severity for c in contradictions[feature]) * 0.3) confidence = max(0.05, base_confidence * (1 - contradiction_penalty)) ``` Шаг 4. Обработка противоречий (правило C3). Если новое подтверждение по фиче противоположно направлению уже накопленного (например, было Structure+ с strength ≥0.5, пришло Structure- с strength ≥0.5): ```text contradictions[feature].append({ step_id_a, step_id_b, previous_hypothesis, new_evidence, severity }) ``` severity берётся из evaluator_output, если он его вернул; если нет — считать severity = min(strength_a, strength_b). Обе записи-подтверждения остаются в evidence_log (шаг 2 их не удаляет) — усреднение запрещено, штраф уже учтён в шаге 3. Шаг 5. Жёсткие ограничения по порядку (без изменений содержательно, теперь как проверка в коде, а не просьба): ```text if step_id not in {"PARTNER_CHOICE_B", "ADAPTIVE", "FINAL"}: roles.primary = None roles.secondary = None # запрет определять роль раньше PartnerChoice if step_id not in {"TEAM_CONFLICT_B", "DEADLINE_STRESS", "ADAPTIVE", "FINAL"}: leadership.style = None # запрет определять стиль раньше TeamConflict и DeadlineStress ``` Шаг 6. is_estimate. ```text is_estimate = confidence < 0.60 range = [clip(score - (30 * (1 - confidence)), 0, 100), clip(score + (30 * (1 - confidence)), 0, 100)] if is_estimate else [score, score] ``` Это то же правило, что в новом Промпте 8 для ручного теста, но здесь оно исполняется гарантированно, а не «по просьбе». ## B3. STEP CONFIG — CALIBRATION Публичный промпт: ```text Представь, что на ближайшие два месяца тебе нужно войти в студенческую проектную команду и создать реальный результат. Что тебе было бы интереснее всего делать? A. Разобраться, как всё работает, и придумать техническое или логическое решение. B. Исследовать людей, проблему, тексты или общественный контекст. C. Придумать необычную концепцию, дизайн или новый подход. D. Организовать людей и довести проект до результата. E. Сочетать несколько вариантов. Выбери вариант и кратко объясни почему. ``` Фокус оценщика: tech, human, creative, org, idea, analysis. Пометить подтверждение этого шага как self_report, base_weight <= 0.35. ## B4. STEP CONFIG — PROJECT_START Публичный промпт: ```text Пять студентов получили 6 недель на проект: нужно придумать сервис, который реально решает одну из проблем студентов университета. Команда впервые собралась. Тема пока не выбрана. Никто никому не начальник. Что ты лично сделал(а) бы в первые 30 минут встречи? Опиши 3–5 конкретных действий по порядку. ``` Фокус оценщика: initiative, systems, structure, tech, human, creative, org, role_*. Особые маркеры, не как жёсткие правила, а как признаки: - сначала понять пользователя/проблему → подтверждение по human/researcher/systems; - предложить быстро накидать варианты → creative/generator/initiative; - распределить работу/зафиксировать следующий шаг → org/organizer/execution; - декомпозировать ограничения/архитектуру → tech/architect/analysis; - сам назначает себя главным без механизма согласования → initiative+, но возможны empathy-/facilitative-; не путать с высоким Influence. ## B5. STEP CONFIG — TEAM_CONFLICT_A Публичный промпт: ```text Прошла неделя. Двое хотят продолжать идею A, двое перейти на идею B, пятый почти перестал участвовать. До промежуточной презентации три дня. Что ты будешь делать? Опиши конкретную последовательность действий. ``` Фокус оценщика: initiative, responsibility, influence, conflict, empathy, systems, decisiveness. ## B6. STEP CONFIG — TEAM_CONFLICT_B Публичный промпт: ```text После обсуждения команда всё равно не договорилась: обе позиции остаются примерно одинаково сильными, а времени на новое исследование почти нет. Кто и каким способом должен принять окончательное решение? Что лично будешь делать ты? ``` Фокус оценщика: decisiveness, influence, responsibility, conflict, systems, leadership style. Важно: «решает лидер» само по себе не даёт высокий лидерский балл. Нужны критерий решения, принятие ответственности и способ сохранить работоспособность команды. ## B7. STEP CONFIG — THINKING_TASK_A Публичный промпт: ```text Большая часть студентов университета редко участвует во внеучебных проектах. Назови как можно более разные причины, почему это может происходить. Достаточно короткого списка. ``` Фокус оценщика: creative, human, tech, idea, systems. Не использовать количество слов как суррогатный показатель Creative. Учитывать именно семантическое разнообразие гипотез и смену уровней объяснения. ## B8. STEP CONFIG — THINKING_TASK_B Публичный промпт: ```text Выбери одну из названных причин. Как бы ты за 3–5 дней и с минимальными ресурсами проверил(а), действительно ли она существенно влияет на проблему? Опиши способ проверки и критерий, по которому ты решишь, что гипотеза скорее подтверждается или нет. ``` Фокус оценщика: analysis, tech, human, org, systems, execution, uncertainty. Сильное подтверждение по Analysis: есть измеримый критерий, возможен отрицательный результат, описано различение подтверждения/опровержения. ## B9. STEP CONFIG — PARTNER_CHOICE_A Публичный промпт: ```text Ты можешь выбрать двух партнёров. Алекс — сильный аналитик: проверяет каждое решение, часто спорит, редко действует быстро. Маша — генерирует необычные идеи, быстро загорается, но может потерять интерес к рутинной реализации. Илья — организован: планирует, следит за сроками, доводит задачи до конца, но редко предлагает неожиданные идеи. Лена — чувствует людей, умеет договариваться и презентовать, но не любит принимать жёсткие решения за группу. Кого двоих выберешь и почему? Какую функцию каждый будет выполнять и чем будет полезен лично тебе? ``` Фокус оценщика: empathy, systems, понимание ролей, взаимодополняемость, самоосознанность. Не выводить совместимость просто из выбранных персонажей; анализировать объяснение. ## B10. STEP CONFIG — PARTNER_CHOICE_B Публичный промпт: ```text С кем из двух оставшихся тебе было бы труднее всего работать? Почему? Что могло бы вызвать конфликт и что ты сделал(а) бы, чтобы всё-таки эффективно работать вместе? ``` Фокус оценщика: conflict, empathy, uncertainty, structure, переносимость сложного партнёра, самоосознанность. ## B11. STEP CONFIG — DEADLINE_STRESS Публичный промпт: ```text До защиты проекта осталось два дня. Команда не успевает сделать всё запланированное. A. Урежу объём и добьюсь минимального работающего результата. B. Мобилизую всех и попробую выполнить первоначальный план. C. Пересмотрю концепцию и найду более простое решение. D. Сначала найду узкое место и буду исправлять его. E. Обсужу ситуацию с командой и вместе определю, чем пожертвовать. Выбери максимум два варианта. Объясни выбор и от чего ты сознательно готов(а) отказаться. ``` Фокус оценщика: execution, decisiveness, systems, analysis, idea, influence, empathy, uncertainty. Ключевая проверка: есть ли реальный компромисс (чем-то реально пожертвовали). Выбор A+C+D+E в объяснении как «сделаю всё» трактовать как признак социальной желательности / низкой Decisiveness, даже если формально отмечены два пункта. ## B12. PROMPT — ADAPTIVE PROBE GENERATOR ```text Ты выбираешь последний диагностический вопрос. INPUT: - current_state - all_evidence - contradictions - elapsed_sec Задача: выбрать одну пару конкурирующих гипотез, разрешение которой сильнее всего изменит практический вывод о роли студента или его совместимости в команде. Приоритет: 1. ведущая роль; 2. стиль лидерства / лидерский потенциал; 3. Execution; 4. конфликтная устойчивость / совместимость; 5. профиль направленности. Не задавай контрольный вопрос по характеристике, которая уже имеет уверенность >= 0.80 и не содержит серьёзных противоречий. Сгенерируй один вопрос: - ситуационный; - не длиннее 70 слов; - без названия измеряемых шкал; - требует выбора или конкретного поведения; - различает ровно две главные гипотезы; - не повторяет дословно предыдущие ситуации. Верни JSON: { "hypothesis_a": "...", "hypothesis_b": "...", "reason_for_probe": "...", "question": "...", "evaluator_focus": ["..."] } ``` Порог уверенности (0.80 в тексте промпта) должен совпадать с тем, что реально считает STATE REDUCER (B2, шаг 3). Это одна и та же константа: она зашита в код и подставляется в промпт при вызове — иначе промпт и логика подсчёта незаметно разойдутся. ## B13. PROMPT — FINAL SYNTHESIZER ```text Ты финальный синтезатор диагностики проектного потенциала студента. INPUT: - final_state # уже содержит score, range, is_estimate, confidence по каждой фиче — посчитано в коде (B2), не пересчитывай их сам - all_questions_answers - all_evidence - contradictions Сформируй два результата: 1. student_report; 2. profile_json. Требования к student_report: - 150–300 слов; - язык — русский; понятный не-психологу; - ни одного внутреннего идентификатора в тексте: запрещены tech/human/creative/org, initiative/responsibility/influence/decisiveness/systems, structure/social/uncertainty/conflict/execution/idea/analysis/empathy, expert/facilitative/directive/entrepreneurial/mixed, score/range/is_estimate/confidence — и их транслитерации («скор», «инфлюенс», «конфиденс», «эстимейт»). Используй словарь соответствий ниже; - без диагнозов и категоричных ярлыков; - объяснять выводы через наблюдаемое поведение; - отличать потенциал от уже развитого навыка; - не использовать специальность, пол или возраст как основание оценки; - для каждой фичи, где final_state.is_estimate == true, использовать её range и явно писать "предварительно" / "рабочая гипотеза", НЕ печатать одно число; - не перечислять все 8 командных шкал построчно — только 3 наиболее выраженных (по |score-50|, с учётом confidence) и 1–2 ограничения; - обязательно описать: ведущую роль, вторичную роль, профиль направленности, лидерский потенциал и стиль, 2–3 сильные стороны, 1–2 риска, идеальные партнёры, рискованные сочетания, уровень уверенности. Словарь для student_report (идентификатор -> как писать в тексте): - tech -> техническо-аналитическая направленность; human -> гуманитарно-коммуникационная направленность; creative -> творческая направленность; org -> организационно-предпринимательская направленность; - initiative -> инициативность; responsibility -> ответственность за общий результат; influence -> влияние без формальной власти; decisiveness -> решительность при нехватке информации; systems -> системность мышления; total -> общий лидерский балл; - structure -> потребность в структуре; social -> ориентация на постоянное взаимодействие; uncertainty -> устойчивость к неопределённости; conflict -> конструктивность в содержательном споре; execution -> доведение до результата; idea -> генерация вариантов; analysis -> проверка гипотез и аргументов; empathy -> понимание позиций и мотивов других; - expert -> экспертный стиль; facilitative -> фасилитирующий; directive -> директивный; entrepreneurial -> предпринимательский; mixed -> смешанный; - initiator -> Инициатор; researcher -> Исследователь; architect -> Архитектор решения; generator -> Генератор; communicator -> Коммуникатор; organizer -> Организатор; validator -> Критик-валидатор; - is_estimate: true -> «рабочая гипотеза» / «предварительно» + диапазон; range: [a,b] -> «a–b»; confidence -> «уверенность: высокая / средняя / низкая». Идентификаторы сохраняются только в profile_json. Текстовые поля внутри profile_json (reason, risk, mitigation, evidence) заполняй по-русски; поля role, primary, secondary, style — кодами из перечислений. Общий лидерский балл (считается в коде по final_state, но должен согласовываться с тем, что ты пишешь в отчёте): initiative*0.20 + responsibility*0.25 + influence*0.20 + decisiveness*0.15 + systems*0.20. Если хотя бы один из пяти компонентов is_estimate = true — в тексте отчёта помечай общий балл как рабочую оценку. Правила ролей (действуют во внутренней логике; в отчёт роли выходят только русскими названиями): - ведущая и вторичная роль определяются по совокупности подтверждений из минимум двух разных ситуаций; - высокий балл одной шкалы направленности не равен автоматически роли; - Коммуникатор != просто высокая ориентация на взаимодействие (social); - Инициатор != просто решительность (decisiveness); - Организатор требует подтверждений по доведению до результата и потребности в структуре (execution/structure); - Архитектор решения требует системности мышления + проверки аргументов или технической направленности (systems + analysis/tech); - Генератор требует генерации вариантов (idea) + семантическое разнообразие решений; - Исследователь требует проверки гипотез (analysis) + постановку проверяемых гипотез; - Критик-валидатор требует обнаружение рисков/ошибок + критерии качества. Верни JSON profile_json (числовые поля бери из final_state как есть, не пересчитывай): { "activity": {"tech":{"score":0,"range":[0,0],"is_estimate":false}, "human":{...}, "creative":{...}, "org":{...}}, "leadership": { "initiative":{...},"responsibility":{...},"influence":{...},"decisiveness":{...},"systems":{...}, "total":0, "total_is_estimate": false, "style":"expert|facilitative|directive|entrepreneurial|mixed" }, "team": { "structure":{...},"social":{...},"uncertainty":{...},"conflict":{...},"execution":{...},"idea":{...},"analysis":{...},"empathy":{...} }, "roles":{"primary":"...","secondary":"..."}, "ideal_partners":[{"role":"...","reason":"..."}], "risk_pairs":[{"role_or_pattern":"...","risk":"...","mitigation":"..."}], "confidence":{"activity":0.0,"leadership":0.0,"roles":0.0,"compatibility":0.0}, "evidence_ids":["..."] } ``` --- # ЧАСТЬ C. АЛГОРИТМИЧЕСКИЕ ПРОВЕРКИ Правила C1–C5 реализуются напрямую в коде (в основном в STATE REDUCER, B2), а не существуют отдельно как "проверки, о которых нужно помнить". Ниже — таблица соответствия, чтобы при реализации ничего не потерялось. Правило | Где реализовано C1. Минимум подтверждений (unique_step_count(feature) >= 2, иначе уверенность ≤ 0.59) | B2, Шаг 3 (base_confidence по unique_steps) C2. Проверка социально желательных ответов | B1 (EVALUATOR возвращает social_desirability_risk) + понижает strength/base_weight входящего подтверждения перед тем, как оно попадёт в B2 C3. Противоречие не усредняется молча | B2, Шаг 4 C4. Ограничение времени (11–13 мин, после 12:00 не добавлять необязательные дополнительные вопросы, после 14:00 — в финал) | Реализуется в оркестраторе пайплайна (вне модели): таймер вокруг схемы Части D, а не текстовая инструкция C5. Защита от стереотипов (пол/возраст/специальность не передавать во входные данные EVALUATOR) | Архитектурное требование к API: эти поля физически не должны попадать в контекст вызова EVALUATOR --- # ЧАСТЬ D. РЕКОМЕНДУЕМАЯ СХЕМА ПАЙПЛАЙНА ```text START -> INTERVIEWER(CALIBRATION) -> EVALUATOR [модель] -> STATE_REDUCER [код, см. B2] -> INTERVIEWER(PROJECT_START) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> INTERVIEWER(TEAM_CONFLICT_A) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> INTERVIEWER(TEAM_CONFLICT_B) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> INTERVIEWER(THINKING_A) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> INTERVIEWER(THINKING_B) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> INTERVIEWER(PARTNER_A) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> INTERVIEWER(PARTNER_B) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> INTERVIEWER(DEADLINE) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> ADAPTIVE_PROBE_GENERATOR [модель] -> INTERVIEWER(ADAPTIVE) -> EVALUATOR [модель] -> STATE_REDUCER [код] -> FINAL_SYNTHESIZER [модель, читает уже готовый final_state] END ``` Всего: 10 пользовательских ответов при полном сценарии. При средних 45–60 секундах на ответ диагностика укладывается в 10–15 минут. --- # ЧАСТЬ E. ПИЛОТ НА РЕАЛЬНЫХ СТУДЕНТАХ Синтетический прогон на сгенерированных профилях проверяет только логическую связность промптов и валидацией не является: профили порождены той же моделью, которая потом их же и оценивает. Единственный содержательный следующий шаг — реальный пилот. Ниже — минимальный план, чтобы результат пилота можно было интерпретировать, а не просто "полайкали профиль". ## E1. Минимальный объём пилота - N ≥ 20–25 студентов реального проекта (одна-две проектные команды/поток) — меньше не даст статистически осмысленного разброса по 7 ролям. - Студенты должны затем реально проработать вместе минимум 3–4 недели, иначе шаг E3 (сверка с фактической ролью) не с чем сравнивать. - Идеально — несколько разных проектных команд, а не одна, чтобы отделить "эффект команды" от "эффект методики". ## E2. Проверка устойчивости самого инструмента Прежде чем сравнивать профиль с реальностью, стоит проверить, что профиль вообще воспроизводим: - Взять 3–5 уже собранных диалогов и прогнать через FINAL_SYNTHESIZER повторно (тот же state, новый вызов) — если ведущая роль или стиль лидерства меняются от прогона к прогону, доверять единичному прогону в проде нельзя. - По возможности прогнать те же 3–5 диалогов другой моделью (или другой версией той же модели) — большое расхождение = сигнал, что часть выводов держится на специфике конкретной модели, а не на самих ответах студента. - Фиксировать это как отдельную метрику "устойчивость профиля", не смешивая с E3. ## E3. Данные для сверки После каждого теста сохранять: 1. полный диалог; 1. финальный JSON (со всеми range/is_estimate из B2); 1. субъективную оценку студента: «насколько описание похоже на меня?» 1–5; 1. через 2–4 недели — оценку фактической роли самим студентом; 1. оценку роли 2–3 товарищами по команде; 1. оценку преподавателем/куратором; 1. выполнение сроков; 1. качество результата; 1. конфликты/смену ролей внутри команды. ## E4. Шаблон таблицы сбора пилота Одна строка — один студент. Рекомендуемые колонки: ```text student_id | primary_role_predicted | primary_role_actual (студент) | primary_role_actual (команда, медиана) | leadership_total | leadership_confidence | self_similarity_1_5 | deadlines_met (да/нет) | conflicts_reported (да/нет) | role_changed_during_project (да/нет) | notes ``` ## E5. Что считать сигналом "методика работает", а не просто "нравится" - primary_role_predicted совпадает (или близка по смыслу, например Инициатор/Организатор) с primary_role_actual чаще, чем при случайном угадывании из 7 ролей (>1/7 ≈ 14% — целевая планка для первой итерации разумно ставить заметно выше, например ≥40%, но это тоже должно калиброваться, а не быть догмой); - self_similarity даёт распределение, а не одни пятёрки/одни двойки (если все ставят 5 — вероятен эффект Барнума, отчёт слишком общий; если все ставят 1–2 — методика не считывает поведение); - уверенность, помеченная в отчёте как «высокая», реже расходится с фактическим результатом (колонки *_actual из E4), чем уверенность «низкая» — если это не так, значит сама логика подсчёта уверенности (B2, Шаг 3) плохо откалибрована и константы (K=22, пороги unique_steps) нужно менять. Калибровать веса нужно по наблюдаемой проектной эффективности, а не по тому, нравится ли студентам текст профиля.