Сначала схема, потом код: как Method Diagram готовит задачу для ИИ-агента

ИИ-агент соберёт прототип быстро — но по тому, что написано в задаче, а не по тому, что вы имели в виду. Method Diagram сначала раскладывает задачу в схему и находит дыры в постановке.

Коротко

  • mDm строит схему системы по методу функций и объектов: между функциями всегда объект, на уровне не больше девяти функций. Правила держит редактор, а не человек.
  • Из описания словами или ТЗ в Word, Excel, PDF ИИ-агент выписывает требования, строит схему, находит недоработки и составляет план MVP с критериями «готово».
  • Claude Code или Codex получают проект компактным файлом и MCP-сервером: берут задачи по плану, отмечают сделанное, а непонятное записывают вопросом заказчику.
  • Агент работает через DeepSeek и другие API или с моделью на вашем компьютере — тогда ТЗ никуда не уходит. Демо-редактор открывается в браузере, без регистрации.

Попросите ИИ-агента сделать систему учёта заказов — и получите работающий прототип: форма заявки, кнопки, база данных. А вместе с ним — десяток решений, которые агент принял молча. Что делать, если оплата пришла не вся. Бывает ли оплата при получении. Откуда берётся номер накладной. Кто отмечает, что посылку вручили.

Это не придуманные вопросы. Их записал кодовый агент, когда собирал прототип по схеме из mDm, — вместо того чтобы ответить за заказчика (пример ниже). Без схемы те же решения тоже были бы приняты — только в коде, и узнали бы вы о них на приёмке.

ИИ-агенты удешевили код, но не постановку задачи. Ошибку в ТЗ агент воспроизводит так же быстро и аккуратно, как всё остальное. Method Diagram (mDm) — наш редактор схем для этого участка: от задачи словами или документа ТЗ до плана, по которому Claude Code или Codex пишут код. Рассказываем, что он умеет сейчас и чего не умеет.

Схема из двух фигур и трёх правил

В основе mDm — метод функциональных схем. Элементов два:

  • Функция — что делается: глагол и над чем. «Принять заказ», «Проверить комплектность». На схеме — синий прямоугольник с номером.
  • Объект — над чем работают и что получается: документ, данные, изделие, решение. «Заказ клиента», «Оплаченный счёт». На схеме — зелёная капсула.

Схема читается слева направо: вход, функция, выход, следующая функция. Правил три, и редактор держит их сам.

  1. На уровне не больше девяти функций. Десятую mDm не поставит и предложит разложить сложную функцию на подфункции.
  2. Из функции не вытекает функция. Между ними всегда объект — то, что первая передаёт второй. Свяжете две функции напрямую — редактор вставит между ними объект и попросит его назвать.
  3. У каждого объекта одна функция-владелец — та, что его выпускает. Объект без владельца проверка назовёт ничьим, с двумя владельцами — попросит разделить.

Звучит как формальность, но именно эти правила вытаскивают недосказанное. Нельзя нарисовать «Принять заказ → Собрать заказ», не сказав, что передаётся между ними. Нельзя оставить «Счёт», который выпускают и менеджер, и бухгалтерия.

Выполнение заказа

  1. Объект: Заказ клиента
  2. Функция 1: Принять заказ
  3. Объект: Счёт на оплату
  4. Функция 2: Получить оплату
  5. Объект: Оплаченный счёт
  6. Функция 3, разложена ниже: Собрать заказ
  7. Объект: Собранная посылка
  8. Функция 4: Доставить
  9. Объект: Вручённая посылка

Собрать заказ — внутри: подфункции

  1. Объект: Оплаченный счёт
  2. Функция 3.1: Подобрать товары
  3. Объект: Набор товаров
  4. Функция 3.2: Проверить комплектность
  5. Объект: Проверенный набор
  6. Функция 3.3: Упаковать
  7. Объект: Собранная посылка
Рис. 1 — Схема «Выполнение заказа»: функции и объекты чередуются, функция 3 разложена

Сложную функцию раскладывают прямо на листе: «3 Собрать заказ» → 3.1 Подобрать товары, 3.2 Проверить комплектность, 3.3 Упаковать. Разложение — один уровень: глубже схема перестаёт читаться, и редактор это не пропустит. Панель «Ход схемы» пересказывает схему словами — что приходит, что получается и куда уходит дальше. Её удобно читать вместе с заказчиком: не нужно объяснять, что значат стрелки.

У каждого элемента — карточка с наводящими вопросами. У функции: кто выполняет, какой результат, по каким правилам, за какое время. У объекта: что это, где хранится, какие поля. Вопрос без ответа виден точкой прямо на элементе.

Если в компании свои стандарты, их задают «Методом проектирования»: другой предел функций на уровне (от 3 до 15), до трёх уровней разложения, обязательные свойства вроде «Роль» или «SLA» и правила словами — например, «каждое решение — отдельная функция». Их соблюдают редактор, проверка и ИИ-агент.

Схему можно нарисовать руками, собрать мастером — он спрашивает, что приходит на вход, что с этим делают и что получается, — или взять шаблон: продажа, закупка, обращение клиента, найм, выпуск доработки, выполнение заказа. Большую схему собирают из готовых: схемы-модули стыкуются сами по объектам с одинаковыми названиями. Всё это работает на правилах, без ИИ и ключей.

От задачи словами до плана MVP

Главное в полной версии — ИИ-агент. Ему пишут задачу словами или диктуют голосом: «нарисуй процесс найма», «разложи третью функцию», «проверь схему и исправь нарушения». Агент строит и правит схему теми же инструментами, что и человек, поэтому обойти правила не может: десятую функцию инструмент не добавит, функцию с функцией без объекта не свяжет. Все правки одной задачи отменяются одним нажатием ⌘Z.

Для проекта по техническому заданию путь такой.

  1. Загрузить ТЗ. Word, Excel, PDF, текст, Markdown, CSV, RTF — файл перетаскивают в окно. Текст ложится в проект с заголовками и таблицами, агент читает его частями. Документа нет — хватит описания задачи словами.
  2. Разобрать ТЗ. Агент выписывает требования — обязательные и желательные, каждое со ссылкой на раздел ТЗ, — строит схему, связывает требования с функциями и описывает поля объектов.
  3. Найти недоработки. Часть видит сама программа, без ИИ: требование, которое не выполняет ни одна функция; функция, которой не требует ни один пункт; объект без полей; круг в зависимостях задач. Отдельная проверка сверяет схему с текстом ТЗ и находит объект, о котором в ТЗ ни слова, и пункт ТЗ, не ставший требованием. Остальное агент записывает вопросами заказчику.
  4. Составить план MVP. План строится из самой схемы, без догадок: сначала модель данных, потом по задаче на функцию в том порядке, в каком идут данные, в конце — сквозной сценарий. Критерий «готово» у задачи — результат функции, её вход и выход, обязательные требования. Агент может уточнить критерии, но порядок задач не трогает.
  1. Задача или ТЗWord, Excel, PDF или словами
  2. Требования и схемаR1… со ссылкой на ТЗ, функции
  3. Недоработки (главный шаг)G1… и вопросы заказчику
  4. План MVPT1… с критериями «готово»
  5. Пакет для агентаPROJECT.mdm и MCP-сервер
Рис. 2 — Путь проекта в mDm: от ТЗ до пакета для кодового агента

Требования, недоработки и план лежат списками на вкладке «Проект». Ссылка «→ 2.1» показывает функцию на листе, на вопрос заказчика отвечают прямо в списке, статус задачи меняется нажатием на квадратик.

Вопрос, заданный на схеме, не всплывёт на приёмке.

Три списка вкладки «Проект». Требования R1–R4 со ссылками на разделы ТЗ и функции. Недоработки: две найдены проверкой без ИИ, две — вопросы заказчику, например «Бывает ли оплата при получении?». План MVP из семи задач: три отмечены готовыми, у задачи T5 «Проверить комплектность» зависимости T3 и T4.
Рис. 3 — Вкладка «Проект»: требования со ссылками на ТЗ, недоработки и план MVP, пример

Пакет для Claude Code и Codex

Схема хороша для людей, а кодовому агенту нужен текст — однозначный и короткий, чтобы не тратить токены. mDm выгружает весь проект одним файлом PROJECT.mdm: одна строка — один факт, ссылки — номерами. Он примерно в пять раз короче файла схемы и вдвое короче того же проекта в Markdown. Вот фрагмент:

mdm 1# Выполнение заказа> Чтобы заказ дошёл до клиента целым и вовремя, а деньги — до магазина​## Функции2 Получить оплату · кто: Бухгалтерия · результат: деньги пришли на счёт  из: Счёт на оплату  в: Оплаченный счёт3 Собрать заказ · кто: Склад · время: 2 часа  из: Подтверждённый заказ, Оплаченный счёт  в: Собранная посылка  3.2 Проверить комплектность · кто: Старший смены    из: Набор товаров, Оплаченный счёт    в: Проверенный набор​## ПланT5 [ ] Проверить комплектность ← T3, T4 → 3.2 | готово: без оплаченного счёта проверка недоступна​## ПробелыG5 ? Бывает ли оплата при получении? По схеме комплектность проверяют только с оплаченным счётом → 2, 3.2
Рис. 4 — Фрагмент PROJECT.mdm проекта «Выполнение заказа»

[ ] — задача не начата, ← — от каких задач зависит, → — каких функций касается, ? — открытый вопрос.

Пакет для агента — архив в корень репозитория. В нём PROJECT.mdm; AGENTS.md с правилами метода и порядком работы — Codex читает его сам; CLAUDE.md и команды для Claude Code: /mdm-build собирает весь MVP подряд, /mdm-build прототип — быстрый прототип, /mdm-next делает одну задачу. Рядом — техническое описание и схема для людей и MCP-сервер на Python без зависимостей. Сервер отдаёт агенту не весь проект, а срез: на запрос следующей задачи — задачу с готовыми зависимостями вместе с её функциями, полями объектов, требованиями и вопросами.

Порядок работы агента простой: взять задачу, сделать, проверить критерий «готово» тестом или запуском, отметить. Нашлась дыра в постановке — записать вопрос и отметить, что задача ждёт ответа, а не придумывать ответ. Отметки забирают обратно в mDm одной командой: статусы, новые задачи и вопросы. Схему и требования агент не меняет — их правит человек.

Живая связь и приложение для Mac

В приложении mDm для Mac Claude Code или Codex подключаются прямо к открытой схеме — кнопкой в окне «Подключить Claude Code и Codex». Агент берёт задачи из открытого проекта, а его отметки — «задача готова», новый вопрос — сразу появляются во вкладке «Проект», и каждую можно отменить ⌘Z. Схему видят только программы на этом Mac.

Слева — окно кодового агента: он берёт задачу T4 «Подобрать товары», запускает тесты и отмечает задачу готовой. Справа — план в mDm: задача T4 становится готовой, а внизу появляется уведомление «Claude Code: T4 → готова» с кнопкой «Отменить».
Рис. 5 — Живая связь: отметка агента сразу видна в mDm, пример

Полная версия есть и приложением mDm для Mac — это тот же редактор в окне macOS:

  • ничего не нужно ставить: подключение к моделям встроено в приложение;
  • родное меню, ⌘S сохраняет в тот же файл, схемы открываются из Finder — и файлы mDm, и GraphML из yEd;
  • диктовку по-русски распознаёт сама macOS, на этом же Mac;
  • живая связь с Claude Code и Codex — только здесь;
  • одна программа для Apple Silicon и Intel, macOS 14 и новее.

На Windows и Linux mDm работает в браузере.

Схема и код: Method Project Map

Со временем код расходится со схемой: кто-то добавит вызов «по-быстрому», и запись клиентов начнёт ходить прямо в оплату. Чтобы это было видно, у каждой функции агент записывает строку код: — в каких файлах она сделана:

2 Подобрать слот  из: Заявка, Расписание мастера  в: Бронь  код: app/booking/slots/
Рис. 6 — Строка «код:» связывает функцию схемы с папкой в репозитории

Дальше работает Method Project Map — наша статическая карта кода: без ИИ и интернета, десять языков, открытый код по лицензии MIT. Она читает PROJECT.mdm как карту архитектуры: разрешено то, что соединено на схеме. Команда pmap check . показывает расхождения — связи в коде, которых нет на схеме, с файлом и строкой. mDm отвечает, что делает система, карта — где это в коде.

Карта экономит и токены: агент задаёт точечные вопросы вместо того, чтобы читать файлы целиком. В испытании, о котором мы писали в статье про токены, агент с картой прочитал 0,55 от объёма кода, который читал без неё. В приложении для Mac карту находит и подключает к агентам то же окно, что подключает mDm.

Блок-схемы по ГОСТ 19.701 и свободные схемы

Метод функций и объектов хорош для систем и процессов, но не для алгоритма сортировки или карты понятий. Для таких задач в mDm ещё два набора — и ИИ-агент работает с обоими.

Блок-схема алгоритма по ГОСТ 19.701 — чёрно-белая, линии строго по горизонтали и вертикали. Агент пишет алгоритм псевдокодом, а «Начало» и «Конец», ветки «да» и «нет», возвраты циклов и схождение веток расставляет программа: небольшой модели стрелки даются плохо, а код она пишет уверенно. Псевдокод понимается в разных видах: Python, школьный алгоритмический язык, паскалевский стиль, русские и английские слова. Правят тоже кодом — «добавь проверку на пустой массив», — и блоки с прежним текстом сохраняют свои карточки. Блок-схему бинарного поиска модель на 8 миллиардов параметров строит одним запросом за 18–31 секунду.

Слева — псевдокод бинарного поиска на школьном алгоритмическом языке. Справа — блок-схема по ГОСТ 19.701: «Начало», присваивание границ, условие «lo ≤ hi», вычисление середины, два условия сравнения с ветками «да» и «нет», возврат цикла и два выхода «Вернуть mid» и «Вернуть −1» к блоку «Конец».
Рис. 7 — Блок-схема бинарного поиска по ГОСТ 19.701 и псевдокод, из которого она построена

Свободная схема — устройство системы, карта понятий, оргструктура: элементы и подписанные связи плавными кривыми. Агент ставит новые элементы рядом со связанными и не трогает то, что вы расставили сами. Схему магазина та же модель строит одним запросом за 27 секунд.

Какая модель нужна

Агенту нужна языковая модель, которая умеет вызывать инструменты. Вариантов два.

Модель по API. Рекомендуем DeepSeek: вставили ключ — агент работает. Подходят и ключи Anthropic, OpenAI, OpenRouter, Gemini, Groq, xAI или любой OpenAI-совместимый сервер. Ключ хранится только на вашем компьютере и уходит только своему провайдеру. Как из запросов складывается счёт, мы разбирали в статье про токены.

Модель на своём компьютере. Ollama или LM Studio и модель вроде qwen3:8b — агент найдёт её сам. Тогда ТЗ, схема и разговор с агентом не покидают компьютер — для документов под NDA это часто решающий довод. Как выбирать между своим сервером и облаком, — в статье «Локальная модель или API».

Модель на 8 миллиардов параметров длинную задачу не удерживает: забывает пункты ТЗ, путает связи, бросает работу на середине. Поэтому для неё в mDm конвейер. Программа делит задачу на короткие шаги — каркас схемы, разложение, требования, исполнители, вопросы заказчику. Модель решает по одному шагу, а программа проверяет каждый без ИИ и при ошибке просит переделать, называя точную причину. Связи между функциями и объектами прокладывает программа, а не модель. Что не вышло и после повторов, попадает в недоработки — молча не пропадает.

Панель агента на модели qwen3:8b: пять этапов конвейера — каркас схемы и разложение готовы, идут требования, полоска заполняется, рядом время до конца; исполнители и вопросы заказчику ждут. На листе у функции «3 Собрать заказ» — отметка, что агент над ней думает.
Рис. 8 — Агент на локальной модели: этапы конвейера и время до конца, пример

С крупной моделью по API конвейер не нужен: она держит задачу целиком, и агент работает обычным диалогом. Ответ виден по мере того, как модель пишет, а разговор продолжается: «а теперь добавь согласование».

Документация и ТЗ по ГОСТ 34.602

Из схемы и проекта mDm собирает документ в Word или Markdown по одному из двух шаблонов:

  • Техническое описание: назначение, функции по уровням (вход, выход, исполнитель, итог, правила, срок), данные — объекты и их поля, требования, открытые вопросы, план MVP, схема со штампом.
  • ТЗ по ГОСТ 34.602-2020: десять разделов стандарта. Требования к функциям берутся из схемы, информационное обеспечение — из объектов, состав работ — из плана, порядок приёмки — из критериев «готово».

Чего в данных нет, в документе помечено «Заполнить: …», а в mDm видно одной строкой: сколько разделов не заполнено. Кнопка «Дописать с агентом» заполняет их тем, что есть в ТЗ и на схеме, а остальное записывает вопросами заказчику: чего нет в исходных данных, становится вопросом, а не догадкой.

Страница ТЗ по ГОСТ 34.602-2020 «Выполнение заказа»: разделы с текстом из схемы и три выделенные строки «Заполнить». После «Дописать с агентом» две из них заполняются из ТЗ, а третья становится вопросом заказчику; счётчик незаполненных разделов уменьшается до нуля.
Рис. 9 — ТЗ по ГОСТ 34.602-2020 из схемы: «Дописать с агентом» заполняет пропуски, пример

Схему отдельно выгружают картинкой PNG или SVG — в рамке со штампом, как чертёж: название, уровень, состав, итог проверки, дата. Для тех, кто работает в yEd, есть GraphML: схема открывается в yEd с группами и свойствами и возвращается в mDm без потерь — проверено на yEd 3.25.1.

Чего mDm не делает и кому подойдёт

Чего mDm не делает

  • Не распознаёт сканы. У PDF нужен текстовый слой. Старые .doc и .xls тоже не читаются — их нужно пересохранить в новый формат.
  • Не даёт рисовать как угодно. Цвета и фигуры задаёт метод: синее — функции, зелёное — объекты. Это сделано нарочно: так схемы разных людей можно сравнивать.
  • Не требует ИИ. Без модели редактор, проверка, мастер и шаблоны работают полностью; агент — дополнительный путь.

Кому подойдёт и как попробовать

  • Аналитику и руководителю проекта — разобрать ТЗ заказчика до оценки и прийти на встречу со списком вопросов, а не с догадками.
  • Владельцу бизнеса с идеей сервиса — описать её словами и получить схему, которую можно обсудить, план, который можно отдать разработчикам, и прототип, который можно показать.
  • Команде, которая пишет код с Claude Code или Codex, — чтобы агент работал по плану с критериями «готово», а не по абзацу в чате, и чтобы код не расходился со схемой.
  • Разработчику, который ведёт проект, — схема вместо многостраничного ТЗ: функции, данные и план на одном листе, а вопросы к заказчику — списком рядом.
  • Преподавателю и студенту — блок-схемы по ГОСТ 19.701 из псевдокода.

Демо работает в браузере, без регистрации. В нём весь редактор без ИИ-агента: схема, карточки, разложение, мастер, шаблоны, проверка, выгрузка в PNG, SVG, текст и GraphML для yEd. Схема хранится только у вас в браузере — на сервер ничего не уходит. Полная версия — с ИИ-агентом, проектом по ТЗ, документацией и пакетом для кодовых агентов — в разработке.

Правка на схеме стоит минуту. Та же правка в готовом коде — переделку.

Читать дальше

Все статьи