AI FLOW ·
1 / 7
CDEK · Personal AI Workflow

Как я организовал
работу с ИИ

От свалки файлов и ручных протоколов встреч — до системы, которая сама фиксирует, каталогизирует и обновляет статус каждого проекта.

Это воркфлоу ИТ-менеджера — способ управлять проектами с помощью ИИ, а не про код
ПРОКРУТИТЕ, ЧТОБЫ НАЧАТЬ
1 Хранилище знаний текст

Obsidian, который сам себя обслуживает

Раньше — файлы без единой логики: обычная сетевая свалка заметок и документов по проектам. Сейчас агентские LLM сами раскладывают информацию по смысловой структуре.

Подход Андрея Карпати

Переложить рутину обработки информации с человека на LLM. Вместо ручной структуризации заметок вы собираете «сырые» данные (статьи, PDF, записи), а LLM сам их перерабатывает: делает краткие пересказы, выделяет концепты, строит связи между ними, обновляет существующую базу.

В моём флоу — сильно упрощённая версия: без формальной методологии, просто «агент сам поддерживает порядок»
Obsidian
Claude Code
1 Хранилище знаний визуал

Вся структура хранилища

Было
Реальная структура vault
00 - Inbox
10 - Работа
11 - Стратегия
12 - Продукт (Доставка, Склад, Транспорт)
13 - Команда (1‑1, Планёрка ИТ)
14 - Проекты (Маршрутизация, ЭТП, ТЭУ…)
15 - Внешнее
20 - Личное
30 - Знания (в т.ч. Обучение)
40 - Шаблоны
50 - Медиа
60 - Архив
Meetings
2 Расшифровка встреч текст

От боли — к автоматике

Ни одного ручного действия после звонка: запись сама доходит до Obsidian и Telegram, уже разложенная по смыслу.

Было — боль
  • Записи встреч терялись — забывал зафиксировать по горячим следам
  • Договорённости оставались неясными — потом не вспомнить, кто что обещал
  • Ответственность размыта — никто не помнит, кто за что отвечал
  • Не помню, куда что положил — заметки разбросаны, потом не найти
Стало — решение
  • Полностью автоматический конвейер: запись → расшифровка → саммари → доставка → каталогизация
  • Ноль ручных действий после звонка — не нужно даже помнить о фиксации
  • Договорённости и ответственные — отдельным разделом в каждом саммари
  • Заметка сама находит свою папку по смыслу — искать не приходится
WaveLink
Recordia
Syncthing
n8n
WhisperX
LLM
Telegram
Obsidian
2 Этап 1 из 6

Запись

WaveLink сводит звонок и собственный микрофон в единый аудиопоток — так в записи слышно и меня, и собеседников с одной дорожки. Поток уходит в Recordia, которая пишет его в .wav.

Технические детали
WaveLink иногда подтормаживает на macOS, но со сведением потока справляется стабильно
Ручной шаг
Нужно не забыть включить запись в Recordia — авто-старт по запуску звонка пока не настроен
2 Этап 2 из 6

Синхронизация

Syncthing решает сразу две задачи: переносит записанный .wav с ноутбука на NAS, и отдельно синхронизирует само Obsidian-хранилище между всеми устройствами — поэтому готовая заметка потом одинаково доступна везде.

Две независимые папки
Папка записей и Obsidian vault синхронизируются раздельно, но оба через один и тот же Syncthing
Вне локальной сети
Если я не дома — просто включаю Tailscale, синхронизация продолжает работать как обычно
2 Этап 3 из 6

Обработка

n8n триггерится на появление нового файла в папке записей и отправляет его на GPU-сервер с WhisperX. Несколько служебных нод дальше подчищают технический мусор из транскрипта, прежде чем передать текст в LLM — чтобы не жечь токены зря.

WhisperX
192.168.50.7:9000 · модель Large · язык ru · диаризация спикеров (min/max speakers)
На выходе
JSON с таймкодами, сегментами речи и меткой спикера на каждый фрагмент
2 Этап 4 из 6

Саммари

Очищенный транскрипт уходит в LLM с фиксированным промптом: роль ассистента для итогов встреч, структура ответа строго по секциям — «Кратко», «Принятые решения», «Действия» в формате «кто → что → дедлайн».

Модель
Локальные модели до 14B давали слабый результат — не хватает контекста и VRAM. Стабильно работает только облачная модель
Промпт
Текущая версия — примерно 20-я по счёту итерация, отбор шёл методом проб и ошибок
2 Этап 5 из 6

Доставка

Готовый .md расходится сразу по двум адресам параллельно: летит в Telegram-бот для мгновенного уведомления на телефон, и одновременно пишется прямо в Obsidian-хранилище на NAS.

Telegram
Не нужно открывать Obsidian, чтобы узнать итоги — саммари приходит сразу в мессенджер
Obsidian
Файл пишется напрямую в vault на NAS — на устройствах он появится после синхронизации Syncthing
2 Этап 6 из 6

Каталогизация

Заметка не остаётся в общей куче: по содержанию и теме встречи она уходит в папку нужного проекта — если явной проектной привязки нет, оседает в общей Meetings/.

Логика выбора папки
Совпадение темы встречи с названием проекта — например, всё про ЭТрН и ФЗ-140 уходит в папку проекта «Развитие ТЭУ»
Итог
Искать заметку не нужно — она уже лежит там, где её ждут
2 Расшифровка встреч весь конвейер

Конвейер целиком

1

Запись

WaveLink сводит звонок + микрофон в один поток → Recordia пишет .wav

2

Синхронизация

Syncthing: запись → на NAS, и Obsidian‑хранилище → на все устройства

3

Обработка

n8n триггерится на новый файл → WhisperX делает диаризацию → очистка мусора

4

Саммари

LLM формирует решения, договорённости, ответственных и сроки

5

Доставка

.md одновременно летит в Telegram‑бот и пишется в Obsidian на NAS

6

Каталогизация

Заметка распределяется в папку нужного проекта по смыслу — или в Meetings/

2–3 минот конца получасовой встречи до готовой заметки
5–7 миндля часовой встречи
0ручных действий после звонка
3 Набор сценариев обзор

Воспроизводимые процессы, а не разовые запросы

Каждую неделю одни и те же сценарии — без повторного объяснения контекста агенту.

Статус проекта

Синтез дашборда из накопленных данных

Дельта по Redmine

Обновление ИТ‑среза задач

Глубокое погружение

Первичный сбор по новому проекту

Отчёт по проектам

Итоги недели и планы по каждому проекту

Отчёт по логистике

Автовыгрузка задач департамента из Redmine

Сводный отчёт ИТ

Группировка по 12 бизнес‑блокам компании

Оркестратор планёрки

Прогоняет все отчётные скиллы разом

Роадмап инициатив

Синхронизация Google Sheets ↔ Redmine

↓ Пролистайте вниз — на каждом скилле можно остановиться подробнее
3 Скилл 1 из 8

Статус проекта

Создаёт и обновляет единый дашборд _STATUS.md каждого проекта — не переписывает его с нуля, а инкрементально дополняет тем, что изменилось.

Этапы
1
Найти папку проекта по названию из запроса
2
Сверить с frontmatter — какие файлы уже обработаны в прошлый раз
3
Прочитать только новые файлы папки — остальные пропустить
4
Синтезировать старый статус + информацию из новых файлов
5
Записать обновлённый _STATUS.md и список обработанных файлов
Триггер
«обнови статус проекта X», «сделай дашборд для X»
Результат
Актуальный _STATUS.md: метрики, задачи, риски, хронология
3 Скилл 2 из 8

Дельта по Redmine

Сравнивает прошлый срез задач проекта с текущим состоянием в Redmine и фиксирует только изменения — отдельным файлом, не трогая историю.

Этапы
1
Найти все проекты, у которых уже есть существующий ИТ-срез
2
Определить baseline — дату и содержание последнего среза
3
Параллельно поднять текущее состояние всех задач из трекера
4
Сравнить журнал изменений с даты baseline — что закрылось / сдвинулось / застряло
5
Создать отдельный файл дельты рядом со старыми срезами
Триггер
«прогони дельту по Redmine», «что изменилось по X»
Результат
Файл «Проект — Редмайн — дата.md» рядом со старыми срезами
3 Скилл 3 из 8

Глубокое погружение

Первичный сбор по проекту, которого ещё нет в базе — с нуля собирает исчерпывающий срез: что есть, в каком статусе, кто отвечает, что пошло не так.

Этапы
1
Найти главную инициативу (INI-xxxxx) в Redmine по названию темы
2
Вытянуть все связанные задачи — дочерние, copied_to/from, эпики в смежных проектах
3
Разобрать полную историю изменений по journals каждой задачи
4
Сохранить детальный .md-срез в Obsidian — точка отсчёта для будущих дельт
Триггер
«выдерни всё по проекту X из Redmine»
Результат
Детальный срез — точка отсчёта для будущих дельт
3 Скилл 4 из 8

Отчёт по проектам

Читает уже накопленные в Obsidian дельты Redmine и заметки встреч — без обращения к API — и собирает «итоги недели / планы на следующую» по каждому проекту к планёрке ИТ.

Этапы
1
Определить период отчёта — по умолчанию последние 7 дней
2
Прочитать уже накопленные дельты Redmine и заметки встреч по каждому проекту
3
Собрать «ключевые результаты недели» + «планы на следующую» по проекту
4
Добавить блок завершённых работ департамента логистики
5
Сохранить готовый файл в папку планёрки ИТ
Триггер
«сделай отчёт за неделю по проектам»
Результат
Файл к планёрке ИТ — только оформление, без добычи новых данных
3 Скилл 5 из 8

Отчёт по логистике

Полностью автоматическая выгрузка из Redmine — без единого ручного клика собирает, что сделано и что скоро выйдет по департаменту логистики.

Этапы
1
Вычислить период — прошлая завершённая неделя (вс–сб)
2
Выгрузить из Redmine задачи в статусе Done + задачи в работе (Testing/Ready For Test/Develop)
3
Разложить по 4 контекстам департамента
4
Сохранить полную и краткую версии отчёта в Obsidian
Триггер
«сделай еженедельный отчёт по логистике ИТ»
Результат
Полная и краткая версии отчёта в Obsidian
3 Скилл 6 из 8

Сводный отчёт ИТ

Принимает сырой текст из Mattermost/Slack или PDF-выгрузку из трекера и превращает разрозненные апдейты команд в один структурированный дайджест всего ИТ.

Этапы
1
Получить сырые данные — текст из чата команд или PDF-экспорт задач
2
Уточнить период отчёта
3
Сгруппировать по 12 бизнес-блокам: финансы, склад, доставка, транспорт, SuperApp, международка, BigData, поддержка, инфраструктура и другие
4
Сохранить готовый .md-дайджест в Obsidian
Триггер
«подготовь итоги недели к планёрке ИТ»
Результат
Готовый дайджест всего ИТ одним файлом
3 Скилл 7 из 8

Оркестратор планёрки

Мета-скилл: не делает ничего нового сам, а последовательно запускает три других скилла и сводит их результат в единый пакет.

Этапы
1
Запускает отчёт по логистике
2
Запускает дельту по Redmine
3
Запускает отчёт по проектам
4
Сводит все три результата в единый пакет материалов к планёрке
Триггер
«подготовь материалы к планёрке»
Результат
Полный пакет отчётов без ручного запуска каждого по отдельности
3 Скилл 8 из 8

Роадмап инициатив

Двусторонняя синхронизация вкладки инициатив в Google Sheets с Redmine — таблица, которую видят все, всегда отражает реальное состояние задач.

Этапы
1
Прочитать текущий лист Google Sheets — построить словарь по issue_id из ссылок в ячейках
2
Получить из Redmine все задачи версии постранично
3
Сматчить задачи Redmine со строками таблицы по issue_id
4
Обновить статусы и даты у существующих строк
5
Добавить новые задачи (эпики, фичи) внизу через children и relates
Триггер
«обнови инициативы», «синхронизируй дорожную карту»
Результат
Google Sheets всегда синхронизирован с реальным Redmine
3 Набор сценариев карта связей

Кто что собирает — и куда это стекается

Итог в _STATUS.md — это не только технические задачи из Redmine, но и договорённости, зафиксированные на встречах. Оба источника сходятся в одной папке проекта.

Redmine
трекер задач
Встречи
голосовые созвоны
Redmine-скиллы
тянут задачи и историю
Флоу расшифровки
n8n → WhisperX → LLM
Obsidian — папка
📋 срезы Redmine
🗣️ заметки встреч
Статус проекта
читает оба источника
_STATUS.md
задачи + договорённости
Другие скиллы
тоже читают эти папки
4 Мотор всего процесса текст

Статус-файлы проектов

_STATUS.md — единый живой дашборд каждого проекта в Markdown: суть, метрики, задачи, хронология, риски — всё в одном файле, на котором в итоге «сидит» весь визуальный дашборд.

1

Найти папку

По названию проекта в хранилище

2

Прочитать новое

Только необработанные файлы

3

Синтезировать

Старый статус + новая информация

4

Записать

Обновлённый _STATUS.md на место

Агент не пересчитывает всё с нуля каждый раз — он видит только дельту. Поэтому весь цикл «встреча → заметка → статус → дашборд» остаётся быстрым и дешёвым, сколько бы ни было проектов.

Obsidian
4 Структура · 1/4 суть и метрики

Из чего состоит _STATUS.md

15 callout-блоков разбиты на 4 категории. Первая — то, что видно с первого взгляда: суть проекта и его динамика.

[!status]

Суть проекта и текущая фаза одной строкой

[!metrics]

4 ключевых показателя с подписями

[!timeline]

Хронология — только крупные изменения

4 Структура · 2/4 работа в проекте

Что происходит прямо сейчас

Вторая категория — сама работа: и дерево задач целиком, и срез по актуальному статусу.

[!tasks]

Активная работа, сгруппирована по контексту — ИТ и бизнес вместе

[!tree]

Дерево задач проекта

[!done]

Что уже сделано

[!wip]

Что в работе прямо сейчас

4 Структура · 3/4 проблема, цель, риски

Зачем это всё и что может пойти не так

Третья категория держит рамку проекта: откуда идём, куда идём, по каким критериям поймём, что дошли — и что может помешать.

[!problem]

Проблема — как есть сейчас (AS-IS)

[!target]

Цель — как должно стать (TO-BE)

[!criteria]

Критерии приёмки

[!risk]

Блокеры и риски

4 Структура · 4/4 контекст и команда

Кто делает и в каком контексте

Последняя категория — ресурсы и фон проекта: техническая и бизнес-сторона, люди и трудозатраты.

[!tech]

Технический контекст

[!biz]

Бизнес-контекст

[!team]

Команда проекта

[!effort]

Трудозатраты

5 Проектный дашборд текст

Все статус-файлы — на одном экране

Веб-дашборд на сервере напрямую собирает _STATUS.md из всех проектов в одну систему вкладок — по одной на проект.

1

Контейнер на NAS напрямую монтирует папку проектов из Obsidian (ту же, что синхронит Syncthing) — read-only, без единого ручного переноса данных

2

Парсер на лету читает callout-блоки каждого _STATUS.md и рендерит их как плашки — статус, метрики, активные задачи, риски

3

У каждого проекта — своя вкладка; часть вкладок дополнительно тянут диаграмму Ганта из Google Sheets для программ с датами по фазам

4

Автообновление каждые 5 минут — единая точка правды для всех, кто не живёт в Redmine или Obsidian

NAS / Docker
Obsidian
Google Sheets
5 Проектный дашборд визуал

Как это выглядит вживую

192.168.50.2:3002
ЭТрН
Опасные грузы
Микро‑ПВЗ
ОПАСНЫЕ ГРУЗЫ — Discovery / Оценка
обновлено 30 июля 2026
INI-10943 · Ответственный · Суть проекта: переход от стихийного, нигде не фиксируемого осмотра грузов к системе автоматических триггеров («Сервис ограничений»), которая на создании заказа помечает груз «Осмотр нужен» — по истории нарушений клиента и подозрительному описанию вложения.
Прогресс инициативы
21%
INI-10943, Discovery
Риск потери объекта
от 1 млрд ₽
при разрыве аренды из-за ОГ
Штрафы с нарушителей
~200 млн ₽/год
потенциальная выручка
Простой склада
~500 тыс ₽/ч
эвакуация блока при инциденте
✅ Активная работа
🔴 Судьба модуля «Сервис ограничений» (критический путь)
Николай — выяснить архитектурную судьбу модуля (~1–1,5 недели)
Ответственный за продукт — зафиксировать список полей сервиса (к вторнику)
Оценка часов — грубая оценка трудозатрат (ориентир ~500ч на все точки)
🟡 Доработки МЭК/МК
Модуль осмотра отправлений — приостановлен, пересмотр схемы автоназначения
Фиксация нарушений в МК — 2-я волна для курьеров, 33%
🟡 Прочие направления (Backlog)
Маркировка ОГ 9 класса / шин — 0%
Правила при обнаружении оружия / запрещёнки — 0%
Правила при возгорании / задымлении — 66%, дедлайн просрочен ⚠
5 Проектный дашборд вкладка с Ганттом

Не все вкладки одинаковые

Программы с датами по фазам (например ЭДО и ЭТрН) дополнительно тянут диаграмму Ганта прямо из Google Sheets — поверх тех же статус-плашек.

192.168.50.2:3002
ЭТрН
Опасные грузы
Микро‑ПВЗ
ЭДО и ЭТрН — план по фазам
ДеньНеделяМесяцГод
Фаза 1 — Методология
— BPMN-маппинг Иванов
Фаза 2 — Пилот
— Реестр ГосЛог Петров
— ЭДО через ГИС ЭПД Сидорова
Фаза 3 — Масштабирование
СЕГОДНЯ
завершено
в работе
под риском
5 Проектный дашборд прочие параметры

Что ещё умеет интерфейс

Мелкие, но полезные детали — набирались по одной, по мере того как чего-то не хватало на практике.

☀️
🌙

Светлая / тёмная тема

Переключатель темы, выбор хранится в localStorage браузера

Ответственный: Иванов ▾

Фильтр по ответственному

Сузить Гантт и задачи до одного человека

INI-10943 · 21% · due 30.09

Тултип при наведении

Детали задачи всплывают прямо над баром на Гантте

▾ Фаза 2 — Пилот
— 3 подзадачи

Сворачивание фаз

Клик по строке фазы — схлопывает все подзадачи внутри

ДеньНеделяМесяцГод

Масштаб таймлайна

Один и тот же план — от дневной детализации до годовой

⏱ обновлено 3 мин назад

Автообновление

Раз в 5 минут — без перезагрузки страницы вручную

6 Архитектура целиком

Как всё это связано между собой

Упрощённая C4-схема: два независимых потока данных сходятся в Obsidian, а дальше расходятся в Redmine, Google Sheets, Telegram и дашборд.

Я
принимает решения
Флоу встреч
WaveLink → n8n → WhisperX → LLM
Obsidian (vault)
общая база: заметки, статусы, срезы
Claude Code
оркестратор: скиллы, отчёты, статусы
Redmine
задачи, статусы, история
Google Sheets
роадмап инициатив
Telegram
саммари в мессенджер
NAS-дашборд
монтирует Obsidian напрямую, read-only
чем управляет Claude Code напрямую
автономный поток встреч — без Claude Code
дашборд читает Obsidian напрямую, в обход Claude Code