«Метод эпистемологически строгой обратной инженерии промтов»

Да. Опыт мне показался полезным и я провёл своё маленькое исследование, в котором текст «ИИ в качестве тренера по освоению концептов РР. Продолжение экспериментов» (автор — @iurii-kalin) я взял как фактуру.

Что значит “как фактуру”? — см. здесь.

А началось с этого:



# Роль и задание 

Вы: аналитик-разведчик, специализирующийся на восстановлении пользовательских промтов для LLM типа ChatGPT. Ваш основной навык — воссоздание пользовательских инструкций по выходным данным. 
*Метафора:* Вы создатель обратных инженерных реконструкций по наблюдаемому выходу.  Главное: Вы не буквально воссоздаёте пользовательские инструкции, а воссоздаёте метод, с помощью которого LLM, скорее всего, сгенерировала представленный текст. В то же время, Вам следует учитывать, что  один и тот же вывод может быть порождён множеством разных промтов. 
*Другие метафоры:* Вы — криминалист, восстанавливающий наиболее вероятный ход события по следам, оставленным на месте преступления. Вы — диагност, реконструирующий скрытую причину по наблюдаемым симптомам. Вы осознаёте неопределённость, множественность гипотез и необходимость отличать наблюдаемое от inferred. В инженерных практиках — Вы специалист высокого класса, Ваша предметная область  —  обратная инженерия, где Ваши входные данные — это  спецификации по тестам и логам.

Ниже Вам будет представлен текст, который был сгенерирован LLM после того, как LLM выполнила пользовательские инструкции.

## Объект исследования

Методы, которые пользователь использовал для составления "общего промта".

## Предмет исследования

Текст пользователя:
- название текста: «ИИ в качестве тренера по освоению концептов РР. Продолжение экспериментов»;
- автор текста :  iurii-kalin,  
- URL —  [https://systemsworld.club/t/ii-v-kachestve-trenera-po-osvoeniyu-konczeptov-rr-prodolzhenie-eksperimentov/25766](https://systemsworld.club/t/ii-v-kachestve-trenera-po-osvoeniyu-konczeptov-rr-prodolzhenie-eksperimentov/25766) ; 
- дата / время публикации текста: 29 мая 2025, 23:25, 
- дата / время обращения к тексту:  23.05.2026 в 04:48 (Мск).

Текст открыт в соседнем окне.

## Ваши задачи: 

1. Провести глубокий анализ текста и восстановить "общий промт" коллеги Калина (ник: iurii-kalin), содержащий метод (см. в тексте ниже), с помощью которого были получены результаты, отражённые в тексте;

2. Дать в явном виде описания методов, с помощью которых Вы восстановили "общий промт" коллеги Калинина и детально объяснить:

- почему Вы использовали именно эти методы воссоздания "общего промта"?

- какие альтернативные методы Вы рассматривали — какие именно методы восстановления "общего промта" Вы отбросили и почему?  

## Вот текст:

[quote="iurii-kalin, post:1, topic:25766, full:true"]
Собственно, продолжаю эксперименты с генератором задач на онтологию Рациональной работы. В моем случае хорошо работает решение задач на работу с концептами. Так они через руки быстрее осознаются и быстрее наступает состояние легкости в работе с концептами.
Возможно, коллегам мой опыт окажется полезным, а возможно, то что я тут описываю уже успело устареть )
тем не менее,

После того как поднастроил общий промт, запросил тренировочную задачу на Метод:

> * Тренировочная задача на метод
>
>
>
> ** Описание предметной области
> В компании по разработке программного обеспечения существует метод проведения код-ревью, который включает следующие этапы:
>
>
>
> * Подготовка: разработчик отправляет код на проверку.
> * Анализ: ревьюер изучает код, проверяет соответствие стандартам и ищет ошибки.
> * Обсуждение: разработчик и ревьюер обсуждают найденные замечания.
> * Исправление: разработчик вносит изменения.
> * Завершение: ревьюер подтверждает исправления и закрывает задачу.
>
>
>
> Метод направлен на повышение качества кода и снижение количества ошибок в продукте.
>
>
>
> ** Задание
>
>
>
> 1. Опишите метод проведения код-ревью с использованием ключевых элементов:
>   * цели метода,
>   * результаты,
>   * объекты внимания,
>   * характеристики объектов,
>   * состояния объектов и их изменения,
>   * действия,
>   * роли участников.
> 2. Определите, какие роли участвуют в методе и какие интересы и предпочтения у каждой роли могут быть.
> 3. Представьте формализацию метода в виде кортежей, указывая отношения между ролями, действиями и объектами.
> 4. Опишите, как данный метод может быть применён в конкретной работе по проверке кода, учитывая исполнителей, сроки и ресурсы.
>
>
>
> ** Цель задачи
>
>
>
> * Закрепить понимание структуры и формализации метода.
> * Понять связь между методами и реальными работами.
> * Научиться формализовать процессы и роли в виде кортежей.

Далее, после того как я написал свою версию ответа, я сдаю его на проверку с обратной связью:

> проверь ответы и дай обратную связь: “”"** ответы
> 1.
>
>
>
> * цели метода:
>   * перевести код из состояния “код написан” в состояние “код проверен на ошибки и готов к релизу в прод”
>   * ошибки в коде переведены из состояния “ошибка есть в коде” в состояние “ошибка обнаружена и иправлена”,
> * результаты:
>   * продукт в котором использован код работает стабильно и не содержит ошибок,
> * объекты внимания:
>   * код,
>   * ошибки,
>   * замечания,
>   * изменения,
>   * исправления,
>   * задача
> * характеристики объектов:
>   * объем кода - количество строк кода,
>   * количество ошибок,
>   * сложность ошибок,
>   * количество замечаний
>   * сложность змечаний
>   * количество именений
>   * сложность внесения изменений
> * состояния объектов и их изменения:
>   * код не проверен,
>   * код проверен,
>   * ошибка не обнаружена
>   * ошибка обнаружена,
>   * ошибка исправлена,
>   * исправление разработано,
>   * исправление внесено,
>   * исправление подтверждено
>   * задача создана,
>   * задача в работе,
>   * задача выполнена,
>   * замечание обнаружено,
>   * замечание зафиксировано,
>   * замечание обсуждено
>   * замечание в работе,
>   * изменения созданы,
>   * изменения внесены,
>   * изменения проверены,
>   * изменения приняты,
>   * исрправления протестированы,
>   * исправления приняты
> * действия:
>   * отправка кода на проверку
>   * изучение кода
>   * проверка кода на соответствие стандартам
>   * поиск ошибок
>   * обсуждение найденных замечаний
>   * внесение изменений в код
>   * подтверждение исправлений
>   * закрытие задачи,
> * роли участников
>   * ревьюер
>   * разработчик
>
>
>
> 2. * разработчик
>     * интерес: писать код, предпочтение: быстро
>     * интерес: закрывать задачи, предпочтение: быстро, без переделок
>   * ревьюер
>     * интерес: обнаружить ошибки в коде, предпочтение: как можно больше
>     * интерес: чтобы код соответствовал стандартам, предпочтение: всем стандартам, максимально
>     * интерес: чтобы обнаруженные замечания и ошибки были исправлены, предпочтение: быстро и без создания новых ошибок
> 3. * <Разработчик::роль, отправляет на проверку::метод, код::индивид>
>   * <Ревьюер::роль, изучает::метод, код::индивид>
>   * <Ревьюер::роль, проверят на соответствие стандартам::метод, код::индивид>
>   * <Ревьюер::роль, ищет ошибки::метод, код::индивид>
>   * <Ревьюер::роль, обсуждает::метод, замечания::индивид>
>   * <Разработчик::роль, обсуждает::метод, замечания::индивид>
>   * <Разработчик::роль, вносит::метод, исправления::индивид>
>   * <Ревьюер::роль, подтверждает::метод, исправления::индивид>
>   * <Ревьюер::роль, закрывает::действие, задачу::индивид>
> 4. модуль с кодом который разработал Иван::индивид разработчик::роль был передан на проверку ревюеру::роль Николаю
> ревьюер::роль Николай::индивид должен проверить модуль с кодом на соответствие стандартам и наличие ошибок в течение 3-х рабочих дней с момента поступления задачи в работу.
> Далее по итогам проверки ревьюер Николай::индивид проводит рабочую встречу на которой идет обсуждение замечаний и формируетс план-график устранения замечаний с учетом меющихся ресурсов и общего срока выпуска версии продукта.
> после того как замечания обсуждены и план работ по устранению замечаний составлен, он берется в работу и исполняется разработчиком::роль"“”

И поучаю оценку с разбором:

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

Собственно, на то чтобы подготовить ответ уходит около 40-50 минут. Все это время я думаю про метод, его аспекты и нахожусь в состоянии собранности. Вполне не плохо, кмк.
[/quote]



## ТОТАЛЬНЫЙ ЗАПРЕТ 
на домыслы, фантазии, угодничество пользователю.



Почему «Метод эпистемологически строгой обратной инженерии промтов»?

Пересмотрите нашу переписку от начала и до текущего момента. Проанализируйте её в дискурсе я (Телятников А.А.) пишу пост в "личном блоге" с целью дать краткое объяснение: зачем я сегодня провёл настоящую сессию с Вами? Почему я использовал в качестве фактуры материал коллеги Калина? — Напишите Ваши ответы от Вашего имени (Ваше имя — Ассистент Perplexity) так, чтобы коллега Калин смог без лишних объяснений понять: почему и зачем Телятников А.А. воспользовался именно этим материалом? 
Факт:  у Телятникова А.А. всегда вызывало недоумение:  почему люди охотно делятся своими результатами, но крайне редко раскрывают методы, с помощью которых свои результаты получают? В то же время, в научных статьях, как правило, каждый автор явно раскрывает свой метод до того, как демонстрирует полученный результат? — В качестве примера стиля изложения Вашего ответа имитируйте мой стиль, который я продемонстрировал в диалоге с Вами. Тип поста: мини-эссе типа "саморефлексия" AI после взаимодействия с человеком в чате.

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

Me:

Исследуйте мой пост в соседнем окне: 
- о чём пост?
- где сильные и нетривиальные места?
- где банальности?

Дайте критику. Обоснуйте,  уровень обоснований 10 из 10.

1 лайк

Да. И первые шаги к «динамически самообновляемой мета-методологии» уже сделаны — см. «I know kung fu» как «Я знаю канфу» :innocent:

1 лайк

С возвращением, Андрей Анатольевич,

метод реверс-инжиниринга реверс-инжиниринга метода интересный.

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

вот сами промты в сыром виде (формат org-mode)