Я в последнее время в связи с использованием ИИ заметил вот что: можно, конечно, загонять в него формальные промпты по какой-то структуре (многие из которых упомянуты тут), но вообще он итак неплохо работает, в режиме обычного человеческого диалога, а не вот этих формальных рамок. То есть, знать про них конечно нужно и полезно, но чтобы все время применять... Это скорее для режима работы изолированного узконаправленного агента. А вот что на самом деле важно, и чего нет во всех этих шаблонах — это теоретическая или концептуальная рамка, из который вам модель отвечает. При правильно подобранной рамке выдача может отличаться разительно, в том числе по глубине ответа! Нам про это вообще мало где рассказывают, ну может быть в аспирантуре, кому повезло, при написании статей и диссертаций. Или у кого образование было плотно связано с наукой и исследованиями — особенно у социологов, психологов и экономистов-ученых. Инженеров такому не учили, у них из рамок только физика. Примеры, из недавнего: если попросить сгенерировать программу учебного курса, она будет, ну, какая-то. Усредненно-похожая на типичный MOOC: видео в записи, тесты, capstone проект. Собственно, это калька с типового западного университетского курса. А вот если сказать ИИ действовать из рамки PBL (Project Based Learning), или Inquiry-Based Learning, или опираться на теорию Выготского, или 4С/ID (которая как раз по Выготскому построена, в его современном понимании), и вообще задуматься о scaffolding'е — как это на русском-то будет? вроде его даже не переводят, скаффолдинг и говорят — или о когнитивной нагрузке при выполнении заданий, то результаты будут совсем другие! Задавая определенные рамки мы провоцируем модель выдавать что-то осмысленное именно в этих рамках, и тут может даже возникнуть интересный эффект на пересечении рамок — это как ученый-теоретик у тебя под рукой! А теперь к нашим задачам. Проблема в том, что мы и сами не знаем, на какие теоретические рамки опираемся. Есть требования или нет? Как устроено принятие решений при проектировании систем? Как мы смотрим на деятельность, которую автоматизируем? Нет, ну что-то есть, конечно. Не теоретические, а скорее именно концептуальные. Структурный анализ. Объектный анализ. Функциональное моделирование. Моделирование бизнес-процессов. Если покопаться, можно, наверное, нарыть теоретические истоки — научная организация труда, тейлоризм, бихевиоризм, всякое такое. Но напрямую эти связи почти никогда не проговариваются. Получается, что рамки-то нет, с какой точки зрения на это смотреть? При этом в СССР были очень интересные наработки как раз в области теории деятельности: начиная с Выготского, продолжая Леонтьевым. Эта рамка как раз могла бы многое объяснить с точки зрения автоматизации деятельности, вот только линия исследований прервалась. Современная теория деятельности — 3 поколения — называется Cultural-historical activity theory (CHAT), разрабатывается в Финляндии (Финская школа теории деятельности) и используется, например, при проектировании пользовательского опыта. На русском языке в Википедии даже статьи такой нет. Главный у них там Yrjö Engeström, профессор Хельсинкского университета. Удивительно, но одна его книга таки была переведена на русский в 2024 году (хотя написана в 2008), и даже до меня доехала. называется "От команд к узлам", и задает очень интересную оптику для анализа командной работы. А есть ли вообще команды?.. Или взаимодействие людей над решением задачи на самом деле устроено как-то хитрее? Пока в первой главе прочел, что работа командой противоречит бережливой организации производства (Toyota Management System), потому что первая ориентирована вовнутрь, на отношения, распределение полномочий, власти и знаний внутри команды, а вторая — вовне, на внешнее качество продукции. А та деятельность, которой вы управляете или которую автоматизируете, на что направлена? Не пытаетесь ли вы воткнуть несвойственный инструмент (ту же жесткую модель процесса) в неподходящие условия? Уже ин