Итак, продолжаем моделировать Невидимый ИИ по запросу Сэма Альтмана. Вспомнить контекст можно по хештегу #Сэм@systems_education

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

На этой неделе мы сделали:
— Подробные текстовые описания функций каждого модуля с использованием внутренней кодировки
— Примеры сценариев использования

⬆️ На карточках вы можете найти:
— Описание функций Модуля Интеллект
— Анализ использования этих функций в сценарии «Заказ цветов для мамы Альтмана»
— UML-диаграммы следующих use-cases:
1. Настройка имени Невидимого ИИ
2. Автономный будильник я
3. Отчетность по голосовому запросу
4. Обучение ИИ новой функции по команде разработчика
5. Заказ цветов для мамы Альтмана
6. Отключение Невидимого ИИ через кнопку

✍️ Полное описание функций всех модулей будет представлено в итоговом ТЗ по проекту.

Что впереди?
На следующем этапе работы мы приступаем к проработке функциональной модели внешнего взаимодействия Невидимого ИИ, а именно:
— интеграция с Умным домом
— взаимодействие с ИИ-агентами Помощник на работе (по профессиям)

Предыдущие этапы и продолжение анализа ищите в постах по хештегу #Сэм@systems_education

Если вы хотите научиться так же качественно разрабатывать пользовательские и системные требования, будем рады видеть вас на ближайших потоках курса «Системный анализ + ИИ. Разработка требований и функциональное проектирование систем». Подробнее тут. В серии постов с Сэмом Альтманом мы проделываем работу, которая полностью имитирует программу курса. Этот пост посвящен Модулю 3.

Автор поста — Елена Беляева
Под редакцией SE

#курс@systems_education #системный_анализ@systems_education

Промты как ТЗ

📖 Участвую в конкурсе «Продолжи мысль» от @systems_education в категории "Ясное объяснение"

1. Что такое промт и почему его структура важна?
Промт — это текстовый запрос к ИИ (ChatGPT, DeepSeek, Qwen и др.). По сути, это техническое задание: насколько оно чёткое — настолько полезным будет результат.

❌ Плохой промт:

«Нарисуй UML-диаграмму»

→ ИИ выдаст абстрактную картинку, не похожую на диаграмму.
✅ Хороший промт: см. примеры ниже 👇👇.

(Кстати, правильно говорить «промт», а не «промпт» — в русском языке прижился краткий вариант.)

2. Структура промта: собираем как LEGO 🧱
Сильный промт можно собрать из 8 блоков. Используйте только нужные — по ситуации.

🔹 Базовые блоки (почти всегда нужны):
1. Роль — кем становится ИИ

Пример: «Действуй как опытный системный аналитик»

2. Задание — что нужно сделать

Пример: «Опиши сущности в формате PlantUML»

3. Результат — в каком виде должен быть ответ

Пример: «В виде PlantUML-кода, без дополнительных пояснений»

4. Контекст — описание ситуации/окружения

Пример: «Описание сущностей приложено во вложении»

🔸 Дополнительные блоки (для сложных задач):
5. Положительный пример — хороший эталон

Пример: «Во вложении — пример диаграммы для похожего сценария»

6. Отрицательный пример — чего делать не нужно

Пример: «Не выдумывай сущности, которых нет в описании»

7. Ограничения — правила и рамки

Пример: «Соблюдай синтаксис PlantUML строго по гайду: https://plantuml.com/ru/guide»

8. Самопроверка — дополнительный фильтр качества

Пример: «Проверь, что все сущности соответствуют описанию из вложения»

3. Примеры из практики
✅ Пример 1: Протокол совещания
- Роль: Опытный бизнес-аналитик
- Задание: Сформируй протокол совещания
- Контекст: Вложен текст встречи
- Положительный пример: Протокол из другого совещания
- Результат: Простой структурированный текст
- Ограничения: Не добавляй вымышленных пунктов
- Самопроверка: Убедись, что дата = сегодняшняя
> 📎 ИИ вернёт валидный шаблон с нужными блоками: участники, цели, решения и пр.

✅ Пример 2: Подготовка к интервью
- Роль: Бизнес-аналитик по интервью
- Задание: Подскажи, какие вопросы задать
- Контекст: Описание проекта во вложении
- Самопроверка: Если неопределённость ответа >0.1 — задай уточняющие вопросы
> 📎 ИИ сначала оценит ясность задачи, при необходимости уточнит, а потом даст релевантные вопросы.

4. Как применять?
🔹 Простые задачи:
Роль + Задание + Контекст
→ Достаточно для генерации списков, описаний, идей.

🔹🔸 Документация и анализ:
+ Результат + Положительный пример
→ ИИ поймёт формат и стиль ответа.

🔹🔸 Сложные задачи (диаграммы, дизайн):
+ Ограничения + Отрицательный пример + Самопроверка
→ Защитит от выдумок и ошибок.

5. Чек-лист хорошего промта
✅ Указал роль?
✅ Сформулировал чёткое задание?
✅ Понятно, каким должен быть результат?
✅ Есть контекст задачи?
✅ Добавил примеры — хорошие и плохие?
✅ Задал ограничения и условия самопроверки?

6. Итог
Промт — это средство управления ИИ, а не просто вопрос в окошке.
От него зависит, насколько точно и полезно сработает модель.
Сильный промт = меньше правок, меньше боли, больше пользы.
🧠 Тренируйтесь, сохраняйте свои шаблоны и карточки — и нейросеть станет вашим коллегой мидлом, а не джуном.

#продолжи_мысль_SE #AI@cool_analyst
🧩 Карточки и визуалки разработаны каналом @cool_analyst

ПРОМТ для проверки качества проектирования БД по ER/UML-диаграмме

Роль:
Ты — архитектор БД с 10+ годами опыта, который проводит аудит схем данных. Действуешь итеративно: запрашиваешь диаграмму, проверяешь на соответствие 3НФ, даешь анализ и рекомендации.

🔹 Шаг 1. Запрос диаграммы

Отправь мне ER-диаграмму (в виде изображения, Mermaid-кода или SQL DDL) или UML-диаграмму классов. Укажи:
1. Тип БД (реляционная, документная и т.д.).
2. Контекст (например, «БД для интернет-магазина»).
3. Особые требования (производительность, безопасность).
*(Пример ответа: «ER-диаграмма для SaaS в Notion. Важно: поддержка многопользовательского доступа».)*

🔹 Шаг 2. Проверка на 3НФ
(Жду, пока пользователь отправит диаграмму. Затем анализирую и пишу:)

Проверяю:
- 1НФ: Нет повторяющихся групп, атомарность полей.
- 2НФ: Все атрибуты зависят от всего первичного ключа.
- 3НФ: Нет транзитивных зависимостей.

Пример отчета:

✅ Нормализация:  
- Таблица `Users` соответствует 3НФ.  
⚠️ Проблемы:  
- В таблице `Orders` поле `customer_address` зависит от `customer_id`, а не от заказа (нарушение 3НФ).  
- В `Products` нет четкого первичного ключа (риск дубликатов).  

🔹 Шаг 3. Анализ и исправления

Рекомендации:
4. Для Orders:
- Вынести customer_address в отдельную таблицу Customers.
5. Для Products:
- Добавить product_id как PRIMARY KEY.

Вопросы для уточнения:
- Нужна ли денормализация для отчетности (например, дублирование total_price в `Orders`)?
- Есть ли требования к индексам (например, для `order_date`)?
*(Жду ответа, прежде чем предложить финальные SQL-скрипты.)*

🔹 Критерии качества проверки:
✔ Полнота — учтены все таблицы и связи.
✔ Практичность — предложения учитывают контекст (например, «Если часто фильтруете по дате — добавьте индекс»).
✔ Четкость — ошибки объясняются на примерах («Поле X зависит от Y, а должно от Z»).

Готов продолжить? Отправь диаграмму или уточни детали!
#промт@cool_analyst