Рабочий процесс проекта¶
Проект полезен не количеством чатов, а тем, насколько хорошо работа разделена между ними.
На этой странице построим полноценный пример проекта от первого вопроса до финального результата и выработаем правила, которые подходят для длительных технических, аналитических и организационных задач.
Главный принцип¶
Используйте проект как оглавление работы, а не как один бесконечный разговор.
Хороший проект отвечает на вопрос:
«Какие самостоятельные части есть у этой задачи и где находится результат каждой части?»
Пример проекта¶
Создадим проект:
Цель:
Подготовить перенос существующей dev-инфраструктуры в новый каталог Яндекс Облака
с управляемым простоем, расчётом стоимости и планом отката.
Вместо одного чата создадим структуру:
01 — Требования и ограничения
02 — Инвентаризация текущей инфраструктуры
03 — Целевая архитектура
04 — Сети и DNS
05 — Миграция данных
06 — Права и безопасность
07 — Расходы и оптимизация
08 — План переключения
09 — План отката
10 — Проверка после миграции
11 — Эксплуатационная документация
Этап 1. Создайте проект¶
- Откройте Проекты → Все проекты.
- Нажмите Новый проект.
- Назовите его:
- В описании укажите цель и границы проекта.
- Создайте проект.
Подробнее: Создать проект.
Этап 2. Создайте чат «01 — Требования и ограничения»¶
Это фундамент проекта.
Пример первого запроса:
Мы готовим миграцию dev-инфраструктуры в Яндекс Облако.
Известные ограничения:
- простой не более 30 минут;
- данные должны храниться в РФ;
- все изменения должны иметь план отката;
- production в этот проект не входит;
- миграция выполняется поэтапно.
Сформируй список требований, которые нужно зафиксировать до проектирования.
Раздели их на технические, эксплуатационные, безопасность, стоимость и организационные.
Для каждого неизвестного параметра сформулируй вопрос владельцу системы.
Что получить на выходе¶
- подтверждённые требования;
- список неизвестных;
- ограничения;
- критерии успеха.
Не переходите к архитектуре, пока базовые требования не собраны.
Этап 3. Создайте чат «02 — Инвентаризация»¶
Новый разговор не знает предыдущий автоматически.
Поэтому начните с компактного контекста:
Контекст проекта:
- выполняется миграция dev-инфраструктуры;
- простой до 30 минут;
- production не входит;
- нужен обязательный rollback.
На этом этапе необходимо провести инвентаризацию.
Затем приложите доступные данные:
- список VM;
- диски;
- сети;
- базы данных;
- зависимости;
- внешние адреса;
- DNS;
- объёмы хранения.
Если интеграция с Яндекс Облаком уже подключена, ИИ может использовать разрешённые данные только для чтения облака там, где это действительно нужно.
Этап 4. Зафиксируйте устойчивый контекст¶
После первых двух-трёх чатов появляется информация, которую придётся повторять.
Создайте документ:
Пример:
# Проект: миграция dev-инфраструктуры
## Цель
Перенести dev-сервисы в новый каталог Яндекс Облака.
## Ограничения
- простой ≤ 30 минут;
- rollback обязателен;
- production вне scope;
- данные должны оставаться в разрешённом контуре.
## Исходная инфраструктура
- 12 VM;
- PostgreSQL 16;
- 3 VPC-сегмента;
- 4 публичных DNS имени.
## Принятые решения
- пока не зафиксированы; заполняются после принятия решений командой
## Открытые вопросы
- требуют уточнения; перечислите их перед началом следующего этапа
Этот документ становится явным проектным контекстом, потому что сам контейнер «Проект» общей памяти не создаёт.
Этап 5. Используйте документ правильно¶
Есть два варианта.
Если документ короткий¶
Прикладывайте project-context.md к новому чату как текстовый контекст.
Если материалов стало много¶
Создайте базу знаний.
Например:
knowledge/
├── project-context.md
├── current-architecture.md
├── requirements.md
├── network-plan.md
└── rollback-policy.md
Тогда каждый новый специализированный разговор может получать нужные фрагменты через поиск по документам.
Подробнее: Корпоративная база знаний.
Этап 6. Отделяйте исследование от решения¶
Плохой рабочий процесс:
Через несколько дней трудно понять, какой ответ актуален.
Лучше:
Так каждое решение имеет собственный разговор и историю.
Этап 7. Один чат — одна основная цель¶
Не нужно создавать новый чат на каждый вопрос.
Но у разговора должна быть одна понятная тема.
Хорошо¶
Чат: 04 — Сети и DNS
- адресный план;
- подсети;
- маршруты;
- DNS;
- TTL;
- порядок переключения DNS.
Это единая предметная область.
Плохо¶
В том же чате внезапно обсуждать:
- HR-процесс;
- договор;
- стоимость GPU;
- резервное копирование PostgreSQL;
- текст письма клиенту.
Этап 8. Сохраняйте решения, а не только рассуждения¶
ИИ-чат удобен для анализа, но итог проекта должен быть явно зафиксирован.
После важного обсуждения попросите:
Сформулируй только принятые решения этого диалога.
Не включай отвергнутые варианты.
Для каждого решения укажи основание и открытый риск.
Затем перенесите результат в project-context.md или утверждённую документацию.
Так следующий чат получает не десятки страниц обсуждения, а актуальное состояние проекта.
Этап 9. Используйте отдельный чат для рисков¶
Создайте:
Пример запроса:
На основании приложенного project-context.md составь реестр рисков миграции.
Для каждого риска укажи:
1. событие;
2. вероятность;
3. влияние;
4. ранний признак;
5. профилактику;
6. действие при наступлении;
7. условие отката.
Не придумывай факты, которых нет в контексте. Неизвестное помечай как «требует проверки».
Так риск-анализ не теряется внутри общего архитектурного разговора.
Этап 10. Отдельно анализируйте стоимость¶
Создайте чат:
Если доступна интеграция с Яндекс Облаком, используйте фактические данные Billing.
Примеры вопросов:
Не смешивайте финансовые оценки с технической архитектурой без необходимости.
Этап 11. Создайте план переключения¶
Чат:
Передайте только уже утверждённые данные.
Пример:
Используя project-context.md и утверждённую архитектуру, подготовь пошаговый план переключения.
Требования:
- каждый шаг должен иметь владельца;
- у каждого шага должна быть проверка результата;
- изменение без проверки запрещено;
- перед необратимым действием должен быть checkpoint;
- явно укажи точку no-return;
- не выполняй команды, только подготовь план.
Этап 12. Создайте отдельный rollback¶
Даже если откат упоминается в основном плане, вынесите его отдельно.
Почему:
- во время аварии важен короткий документ;
- не нужно искать rollback среди сотен строк основного плана;
- его проще отдельно проверить;
- им можно отдельно поделиться.
Этап 13. Проверка после выполнения¶
Чат:
Сформируйте checklist:
Подготовь post-migration checklist.
Разделы: сеть, DNS, приложение, база данных, мониторинг, резервное копирование,
доступы, производительность, стоимость и журнал ошибок.
Для каждого пункта нужны:
- действие проверки;
- ожидаемый результат;
- признак ошибки;
- что делать при отклонении.
Этап 14. Финальная документация¶
Последний чат:
К этому моменту не просите модель перечитывать весь проект по списку чатов — проект не передаёт их автоматически.
Вместо этого подготовьте набор утверждённых исходников:
И уже по ним формируйте документацию.
Правило «чат → решение → документ»¶
Для серьёзной работы полезен цикл:
обсуждение в чате
↓
проверка человеком
↓
принятое решение
↓
устойчивый документ
↓
следующий чат использует документ
Это надёжнее, чем надеяться, что модель «помнит весь проект».
Как работать с изменением решения¶
Предположим, сначала приняли:
Позже решили:
Не оставляйте оба решения как равноправные.
- Обновите
project-context.md. - Укажите дату изменения.
- Удалите устаревшую формулировку или явно пометьте её отменённой.
- В новых чатах используйте актуальную версию документа.
Так уменьшается риск, что retrieval найдёт старое решение.
Как вести журнал решений¶
Для крупных проектов создайте таблицу:
| ID | Дата | Решение | Основание | Статус |
|---|---|---|---|---|
| ADR-001 | 2026-09-14 | PostgreSQL 16 | совместимость | принято |
| ADR-002 | 2026-09-15 | TTL 300 | окно миграции | принято |
Это не функция проекта как таковая, а хороший организационный шаблон.
Когда использовать ветку, а когда новый чат проекта¶
Ветка¶
Подходит, если хотите проверить альтернативу в рамках того же контекста.
Например:
«А что если вместо двух зон использовать одну?»
Новый чат проекта¶
Подходит, если начинается отдельная предметная работа.
Например:
«Теперь нужно отдельно разработать схему backup/restore PostgreSQL».
Подробнее: Ветвление.
Когда использовать временный чат¶
Не используйте временный чат для основного результата долгого проекта, если этот результат нужно сохранить в истории.
Временный режим подходит для:
- быстрой проверки идеи;
- чувствительного одноразового анализа;
- эксперимента, который не должен засорять историю.
Но если результат оказался важным, перенесите его в постоянный проектный разговор или документ.
Использование специализированного помощника¶
Если проект технический, может быть полезен помощник:
Тогда рабочая схема:
Проект = организация разговоров
Помощник = правила и специализация ИИ
База знаний = устойчивые документы
Память = устойчивые пользовательские предпочтения
Не смешивайте эти роли.
Работа нескольких людей¶
Поскольку личный проект не является общей командной папкой, командный процесс строится вокруг результатов.
Например:
- сотрудник ведёт личный проект;
- готовит утверждённый документ;
- документ публикуется в корпоративной базе знаний;
- отдельным важным разговором можно поделиться по разрешённой ссылке;
- следующий сотрудник создаёт собственный проект или использует общую документацию.
Для постоянной команды лучше опираться на общие корпоративные источники, а не на личные проектные списки.
Шаблон структуры для разработки ПО¶
01 — Требования
02 — Архитектура
03 — Модель данных
04 — API
05 — Безопасность
06 — Реализация
07 — Тесты
08 — Производительность
09 — Документация
10 — Release notes
Шаблон для исследования¶
01 — Постановка вопроса
02 — Критерии оценки
03 — Источники
04 — Факты
05 — Противоречия
06 — Варианты
07 — Вывод
08 — Проверка вывода
Шаблон для подготовки документации¶
01 — Структура
02 — Терминология
03 — Черновик
04 — Проверка функций
05 — Скриншоты
06 — FAQ
07 — Troubleshooting
08 — Редактура
09 — Релиз
Шаблон для аудита инфраструктуры¶
01 — Scope аудита
02 — Инвентаризация
03 — Сеть
04 — IAM
05 — Хранилища
06 — Вычисления
07 — Логи и мониторинг
08 — Резервное копирование
09 — Расходы
10 — Риски
11 — Рекомендации
Признаки плохой организации проекта¶
Пора провести рефакторинг, если:
- 30+ чатов называются почти одинаково;
- один разговор содержит всё подряд;
- важные решения существуют только внутри старых сообщений;
- новый чат постоянно начинается с «как мы обсуждали раньше» без контекста;
- приходится вручную перечитывать пять чатов перед каждым новым вопросом;
- разные разговоры содержат конфликтующие версии требований;
- никто не понимает, какой ответ финальный.
Как исправить запущенный проект¶
- Просмотрите список чатов.
- Переименуйте важные.
- Сгруппируйте их логически в голове по этапам.
- Уберите случайные разговоры.
- Создайте
project-context.md. - Перенесите в него подтверждённые решения.
- Создайте отдельный журнал открытых вопросов.
- Прекратите использовать старые конфликтующие файлы.
- Новый этап начинайте отдельным хорошо названным чатом.
Финальный чек-лист хорошего проекта¶
- название объясняет предмет работы;
- описание фиксирует границы проекта;
- чаты разделены по задачам;
- названия разговоров понятны без открытия;
- принятые решения вынесены из чата в документы;
- есть актуальный проектный контекст;
- устаревшие решения помечены;
- важные документы доступны через правильный механизм знаний;
- секреты не хранятся в названиях и описании;
- пользователь не рассчитывает на несуществующую общую память проекта;
- финальные результаты сохранены в корпоративном месте, а не только в личных чатах.