Skip to content

Latest commit

 

History

History
576 lines (435 loc) · 24.1 KB

File metadata and controls

576 lines (435 loc) · 24.1 KB

Руководство по использованию режима Dual Design

📋 Оглавление

  1. Введение
  2. Когда использовать
  3. Быстрый старт
  4. Детальное описание процесса
  5. Примеры использования
  6. Структура артефактов
  7. Интеграция с другими режимами
  8. FAQ
  9. Советы и рекомендации

Введение

Dual Design - это режим Kilo Code для коллаборативного проектирования с использованием двух AI-моделей:

  • 🏗️ Модель 1 (Архитектор) - главный дизайнер, формирует основу решения
  • 🔍 Модель 2 (Второй пилот) - критический аналитик, проверяет и улучшает идеи

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

Преимущества подхода

Два взгляда лучше одного - разные модели находят разные аспекты задачи
Структурированный процесс - 9 четких шагов от идеи до требований
Фокус на MVP - акцент на минимальном жизнеспособном продукте
Прозрачность - все промежуточные результаты сохраняются
Автоматизация - минимум ручной работы, максимум качества


Когда использовать

Используйте режим Dual Design когда вам нужно:

  • 📝 Превратить нечеткую идею в структурированные требования
  • 🤔 Получить критический анализ вашей задачи
  • 🎯 Сформулировать MVP для быстрой проверки гипотезы
  • 🔄 Провести мозговой штурм с AI-ассистентами
  • 📊 Создать полноценный BRD (Business Requirements Document)
  • ✨ Проработать детали перед началом разработки
  • 🛡️ Снизить риски через тщательный анализ

НЕ используйте этот режим если:

  • ❌ У вас уже есть готовые детальные требования
  • ❌ Нужно просто написать код без проектирования
  • ❌ Задача простая и не требует анализа

Быстрый старт

Шаг 1: Переключитесь в режим Dual Design

В Kilo Code: переключитесь на режим "Dual Design"

Шаг 2: Опишите вашу потребность

Просто опишите что вам нужно в свободной форме:

Мне нужно создать обработку для автоматической 
синхронизации номенклатуры с Wildberries

Шаг 3: Дождитесь финальных вопросов

Режим автоматически:

  1. Создаст две параллельные задачи для AI-моделей
  2. Проведет 4 раунда обмена мнениями
  3. Подготовит список вопросов для уточнения деталей
  4. Покажет вам эти вопросы

Шаг 4: Ответьте на вопросы

Вы получите список структурированных вопросов:

1. Какие именно данные номенклатуры нужно синхронизировать?
2. Как часто должна происходить синхронизация?
3. Что делать при конфликтах данных?
...

Ответьте на них максимально конкретно.

Шаг 5: Получите бизнес-требования

Режим сгенерирует полный документ с:

  • Описанием проекта
  • Функциональными требованиями (FR-01, FR-02, ...)
  • Сценариями использования
  • Сценариями тестирования
  • Нефункциональными требованиями
  • Диаграммами (если применимо)

Готово! Теперь можно передавать в разработку.


Детальное описание процесса

🔄 9 основных + 1 опциональный шаг

Шаг 1: Инициализация сессии

  • Создается папка artifacts/session_[timestamp]/
  • Сохраняется ваш исходный запрос
  • Инициализируется состояние сессии (state.json)
  • Проверяется доступность MCP-инструментов веб-поиска ⭐ NEW

Что происходит: Подготовка инфраструктуры для сохранения всех артефактов.

Шаг 1.5: Веб-исследование (опционально) ⭐ NEW в v1.1.0

  • Условие активации: Если доступен MCP-инструмент веб-поиска
  • Анализируется запрос пользователя на необходимость исследования
  • Генерируются 2-4 целевых поисковых запроса
  • Выполняется веб-поиск через MCP (Exa, Brave, Tavily)
  • Результаты сохраняются в step1.5_web_research.md

Промт для анализа:

Проанализируй следующий запрос пользователя: [user_request]
Определи, требуется ли веб-исследование для качественного проектирования.
Ответь в формате JSON с полями: needsResearch, reason, searchQueries

Примеры поисковых запросов:

  • "Wildberries API документация seller актуальная"
  • "1C интеграция Wildberries best practices"
  • "Wildberries API лимиты ошибки"

Результат: step1.5_web_research.md с ключевыми находками, рекомендациями и рисками

Что происходит: Сбор актуальной информации для более информированных вопросов от моделей.



Шаг 2: Вопросы Архитектора

  • Создается задача для Модели 1
  • Архитектор анализирует вашу потребность
  • Формулирует свой список вопросов

Промт:

Ты - главный архитектор проекта. Пользователь описал следующую потребность:
[ваш запрос]

Задай все необходимые вопросы для полного понимания и решения этой задачи.

Результат: step2_architect_questions.md


Шаг 3: Вопросы Второго пилота

  • Создается задача для Модели 2
  • Второй пилот независимо анализирует задачу
  • Формулирует свой список вопросов

Промт:

Ты - второй пилот, критический аналитик. 
Задай все необходимые вопросы, сфокусируйся на:
- Пробелах в требованиях
- Потенциальных проблемах
- Edge cases

Результат: step3_pilot_questions.md


Шаг 4: Архитектор анализирует Пилота

  • Архитектор получает вопросы Пилота
  • Сравнивает их со своими
  • Выделяет общее и различия
  • Дает оценку уникальным пунктам Пилота

Промт:

Вот вопросы второго пилота: [questions]
Проанализируй их:
1. Собери то, с чем вы оба согласны
2. Выдели то, что есть только у неё
3. Дай своё мнение по её уникальным пунктам

Результат: step4_architect_analysis.md


Шаг 5: Пилот дает рекомендации

  • Пилот получает вопросы Архитектора
  • Анализирует их критически
  • Дает рекомендации по улучшению

Промт:

Вот вопросы архитектора: [questions]
Проанализируй их и дай рекомендации:
- Что упущено
- Что можно улучшить
- Какие риски не учтены

Результат: step5_pilot_recommendations.md


Шаг 6: MVP-вопросы от Архитектора

  • Архитектор учитывает рекомендации Пилота
  • Формулирует список вопросов для MVP
  • Цель: минимальный рабочий продукт, без переусложнения

Промт:

Вот мнение второго пилота: [recommendations]
Напиши список вопросов для получения самого простого 
минимального рабочего варианта (MVP).

Результат: step6_mvp_questions.md


Шаг 7: Пилот улучшает MVP-вопросы

  • Пилот проверяет MVP-вопросы
  • Предлагает упрощения
  • Убирает лишнее, добавляет важное

Промт:

Вот MVP-вопросы от архитектора: [questions]
Напиши ТОЛЬКО предложения к упрощению/улучшению.
Как сделать их проще и понятнее?

Результат: step7_pilot_improvements.md


Шаг 8: Финальные вопросы

  • Архитектор учитывает все предложения
  • Формирует итоговый список вопросов
  • ЭТИ ВОПРОСЫ ПОКАЗЫВАЮТСЯ ВАМ

Промт:

Вот мнение второго пилота: [improvements]
Напиши итоговый список вопросов. 
Я отвечу на них для формирования бизнес-требований.

Результат: step8_final_questions.mdПОЛЬЗОВАТЕЛЮ


Шаг 9: Генерация бизнес-требований

  • Вы отвечаете на финальные вопросы
  • Архитектор генерирует полный документ требований

Промт:

Вот ответы пользователя: [answers]

Сформируй ПОЛНОСТЬЮ ОПИСАННЫЕ бизнес-требования:
1. Описание проекта
2. Функциональные требования (FR-01, FR-02...)
3. Сценарии использования
4. Сценарии тестирования
5. Нефункциональные требования
6. Технические ограничения
7. Диаграммы (Mermaid)

Результат: business_requirements.mdФИНАЛЬНЫЙ ДОКУМЕНТ


Примеры использования

Пример 1: Синхронизация с маркетплейсом

Входные данные:

Пользователь: Мне нужна обработка для синхронизации 
товаров с Wildberries. Нужно получать остатки, цены 
и обновлять их в 1С.

Что происходит:

  1. ✅ Архитектор спрашивает про API, частоту, формат данных
  2. ✅ Пилот добавляет вопросы про обработку ошибок, логирование
  3. ✅ После 4 раундов обмена мнениями формируется 12 финальных вопросов
  4. ✅ Пользователь отвечает на вопросы
  5. ✅ Генерируется документ на 15 страниц с полными требованиями

Результат: artifacts/session_20251114_091500/business_requirements.md


Пример 2: Отчет для руководства

Входные данные:

Пользователь: Нужен отчет по продажам для директора. 
Должны быть графики и возможность выгрузки в Excel.

Что происходит:

  1. ✅ Модели выясняют какие именно метрики нужны
  2. ✅ Какие периоды анализировать
  3. ✅ Какие визуализации требуются
  4. ✅ Требования к производительности

Результат: Детальные требования с прототипами интерфейса


Пример 3: Автоматизация бизнес-процесса

Входные данные:

Пользователь: Хочу автоматизировать согласование счетов. 
Сейчас все делается вручную через email.

Что происходит:

  1. ✅ Выясняется текущий процесс (as-is)
  2. ✅ Формулируется желаемый процесс (to-be)
  3. ✅ Определяются роли и права доступа
  4. ✅ Планируются уведомления и эскалации

Результат: Полная спецификация workflow с диаграммами


Структура артефактов

После завершения сессии у вас будет:

artifacts/
  session_20251114_091500/
    ├── state.json                        # Состояние сессии
    ├── step1_user_request.md             # Ваш исходный запрос
    ├── step1.5_web_research.md           # 🔍 Веб-исследование (опционально) ⭐ NEW
    ├── step2_architect_questions.md      # Вопросы Архитектора
    ├── step3_pilot_questions.md          # Вопросы Пилота
    ├── step4_architect_analysis.md       # Анализ Архитектора
    ├── step5_pilot_recommendations.md    # Рекомендации Пилота
    ├── step6_mvp_questions.md            # MVP-вопросы
    ├── step7_pilot_improvements.md       # Улучшения от Пилота
    ├── step8_final_questions.md          # Финальные вопросы
    ├── step9_user_answers.md             # Ваши ответы
    └── business_requirements.md          # 🎯 ИТОГОВЫЙ ДОКУМЕНТ

Как использовать артефакты

Для анализа процесса:

# Посмотреть как модели пришли к финальным вопросам
cat artifacts/session_*/step*.md

Для повторного использования:

# Взять вопросы из одной сессии для другой
cp artifacts/session_A/step8_final_questions.md \
   artifacts/session_B/template_questions.md

Для интеграции с другими режимами:

# Передать требования в проектирование
kilocode design-1c-object \
  --input artifacts/session_*/business_requirements.md

Интеграция с другими режимами

Dual Design - это первый шаг в цепочке разработки:

┌──────────────┐
│ Dual Design  │ ← Вы здесь
│ (требования) │
└──────┬───────┘
       │ business_requirements.md
       ▼
┌──────────────────┐
│ design-1c-object │
│ (спецификация)   │
└──────┬───────────┘
       │ design.xml
       ▼
┌──────────────┐
│ plantasks1c  │
│ (план)       │
└──────┬───────┘
       │ TODO.md
       ▼
┌──────────────┐
│ code1c       │
│ (реализация) │
└──────────────┘

Workflow пример

Команда 1: Сформировать требования

В режиме: dual-design
→ Описываете задачу
→ Отвечаете на вопросы
→ Получаете: business_requirements.md

Команда 2: Спроектировать объект

В режиме: design-1c-object
→ Указываете путь к business_requirements.md
→ Получаете: design.xml

Команда 3: Создать план разработки

В режиме: plantasks1c
→ Указываете пути к business_requirements.md и design.xml
→ Получаете: TODO.md

Команда 4: Реализовать

В режиме: code1c
→ Реализуете по TODO.md
→ Получаете: готовый код

FAQ

Q: Сколько времени занимает процесс?

A: 5-15 минут в зависимости от сложности задачи:

  • Шаги 1-8 (автоматические): ~3-5 минут
  • Шаг 9 (ваши ответы): ~2-10 минут в зависимости от количества вопросов

Q: Можно ли прервать процесс и продолжить позже?

A: Да, все состояние сохраняется в state.json. Можно продолжить с любого шага.

Q: Что если мне не нравятся финальные вопросы?

A: Вы можете:

  1. Вручную отредактировать step8_final_questions.md
  2. Попросить Архитектора переформулировать вопросы
  3. Начать новую сессию с более детальным описанием задачи

Q: Можно ли использовать более 2 моделей?

A: В текущей версии - нет. Но это запланировано для будущих версий (комитет экспертов).

Q: Зачем сохранять все промежуточные артефакты?

A: Для:

  • Прозрачности процесса принятия решений
  • Возможности аудита
  • Повторного использования идей
  • Обучения и улучшения промтов

Q: Можно ли изменить промты для шагов?

A: Да, промты встроены в конфигурацию режима в .kilocodemodes. Вы можете их редактировать.


Советы и рекомендации

💡 Как получить лучшие результаты

1. Будьте конкретны в исходном запросе

  • ❌ Плохо: "Нужна обработка"
  • ✅ Хорошо: "Нужна обработка для автоматической синхронизации остатков товаров с Wildberries через их API"

2. Отвечайте на вопросы подробно

  • Не ограничивайтесь "да/нет"
  • Приводите примеры
  • Указывайте размерности (количество записей, частота выполнения)

3. Думайте о MVP

  • Фокусируйтесь на минимальном наборе функций
  • Откладывайте "nice to have" на потом
  • Приоритизируйте критичные функции

4. Используйте артефакты

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

5. Интегрируйте с другими режимами

  • После Dual Design сразу идите в design-1c-object
  • Создавайте полный цикл от идеи до кода
  • Сохраняйте связи между документами

⚠️ Типичные ошибки

1. Слишком общее описание задачи

❌ "Нужен отчет"
✅ "Нужен отчет по продажам за последние 12 месяцев 
   с разбивкой по менеджерам и регионам"

2. Игнорирование вопросов

❌ Пропускать вопросы или отвечать односложно
✅ Отвечать развернуто с примерами

3. Попытка сразу реализовать все

❌ Включать в MVP все возможные функции
✅ Фокус на ключевом функционале

4. Не сохранять артефакты

❌ Удалять папку с сессией после получения требований
✅ Сохранять для истории и повторного использования

Заключение

Режим Dual Design - это мощный инструмент для превращения идей в структурированные бизнес-требования через коллаборативный процесс с двумя AI-моделями.

Ключевые преимущества:

  • ✅ Автоматизация мозгового штурма
  • ✅ Критический анализ с разных точек зрения
  • ✅ Фокус на MVP
  • ✅ Полная прозрачность процесса
  • ✅ Интеграция с другими режимами разработки

Следующие шаги:

  1. Попробуйте режим на простой задаче
  2. Изучите сгенерированные артефакты
  3. Используйте результат в design-1c-object
  4. Поделитесь feedback для улучшения

Удачного проектирования! 🚀


Дополнительные ресурсы

Обратная связь

Если у вас есть идеи по улучшению режима или вы нашли проблему:

  1. Опишите ваш use case
  2. Приложите примеры артефактов
  3. Предложите улучшения

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