Интерактивный урок · средний

Управление ИИ-агентами: Модульный подход Мэтта Пакока

Этот урок посвящен изучению модульного подхода Мэтта Пакока к управлению ИИ-агентами, который позволяет эффективно доводить проекты до рабочего состояния. Вы узнаете о преимуществах использования небольших, независимых скиллов по сравнению с крупными фреймворками, а также о том, как преодолеть проблему непредсказуемости результатов ИИ.

6 разделов3 заданий6 вопросов теста

Что вы получите

01Объяснять проблему случайности результатов ИИ и пути её контроля.
02Различать принципы работы последовательных фреймворков и модульных скиллов.
03Использовать четыре основных паттерна скилла Grill-Me для уточнения задач.
04Формулировать спецификации и разбивать задачи на тикеты, применяя методы Мэтта Пакока.
05Применять TDD и двухсторонний код-ревью для обеспечения качества разработки.
06Оптимизировать архитектуру проекта и писать эффективную документацию для ИИ-агентов.

Карта знаний

Весь урок одной картой

Нажмите ветку, чтобы перейти к разделу.

01Раздел

Проблема непредсказуемости ИИ и её решение

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

Для контроля этой случайности уже существуют крупные фреймворки, такие как G-Stack и Superpowers, которые предлагают структурированный подход к работе с ИИ. Эти фреймворки за счет своей сложности и наличия множества инструментов пытаются нивелировать непредсказуемость, предлагая разработчикам цепочки шагов и проверок. Несмотря на свою популярность, эти инструменты имеют свои ограничения, особенно когда речь заходит о гибкости и возможности быстрых изменений.

Главное

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

02Раздел

Модульный подход Мэтта Пакока против последовательных фреймворков

Крупные фреймворки для вайб-кодинга, такие как G-Stack и Superpowers, построены на жесткой последовательной цепочке шагов. Типичный процесс включает брейншторминг, автопланирование, разработку и код-ревью. Результат каждого этапа становится входными данными для следующего, формируя неразрывную цепочку. Проблема возникает, когда на середине этой цепочки требуется изменить решение, ведь это означает, что все последующие этапы придется перезапускать заново, что приводит к значительным временным затратам и переделкам.

Мэтт Пакок предлагает принципиально иной подход, основанный на модульных скиллах. Его скиллы спроектированы так, чтобы быть независимыми друг от друга, позволяя вызывать их в любом порядке. Такая модульность исключает жесткую связанность, характерную для больших фреймворков. Если в процессе разработки возникает необходимость изменить какое-либо решение, достаточно перезапустить только соответствующий скилл или вернуться к предыдущему этапу без необходимости переделывать весь проект. Это значительно повышает гибкость и скорость разработки, что делает процесс менее затратным и более адаптируемым к меняющимся требованиям.

Схема — нажмите узел

Сравнение последовательных и модульных подходов

Главное

Жесткие последовательные фреймворки приводят к большим переделкам при изменении требований, в то время как модульные скиллы Мэтта Пакока обеспечивают гибкость и независимость этапов разработки, позволяя адаптироваться к изменениям без полной перезагрузки.

03Раздел

Скилл Grill-Me: уточнение задачи через диалог

Скилл Grill-Me является самым популярным в репозитории Мэтта Пакока и предназначен для глубокого и настойчивого интервьюирования пользователя или агента для уточнения плана, решения или идеи. Его логика строится на четырех ключевых паттернах, которые обеспечивают всесторонний подход к пониманию задачи и предотвращают недопонимания.

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

01 Интервьюирует настойчиво — ИИ не останавливается, пока вы оба не придете к общему пониманию задачи.
02 Работает по дереву решений — Задает все вопросы одного уровня, не перепрыгивает, пока уровень не закрыт.
03 У каждого вопроса есть рекомендованный ответ — Модель сразу предлагает свой вариант и дает возможность выбрать другой.
04 Не действует без подтверждения — Модель ждет вашего 'да', прежде чем что-то реализовать.

Схема — нажмите узел

Рабочий процесс скилла Grill-Me

Главное

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

04Раздел

Скиллы To-Spec и To-Tickets: от диалога к задачам

После того как через диалог с Grill-Me достигнуто общее понимание задачи, эти договоренности необходимо зафиксировать. Для этого служит скилл /to-spec, который преобразует диалог в документ со спецификацией — детальный план реализации задачи. Важный аспект этого скилла заключается в жестком правиле: в спецификации запрещено размещать блоки кода. Это правило введено для того, чтобы модель не следовала устаревшему или неоптимальному коду, а вместо этого сверялась с актуальным кодом проекта, напрямую адаптируя решения под текущее состояние кодовой базы.

Далее спецификацию нужно превратить в конкретные задачи (тикеты), которые ИИ-модель сможет выполнить. Скилл /to-tickets делает это, но иначе, чем большинство фреймворков. Традиционно тикеты разбиваются по слоям (отдельно на базу данных, API, интерфейс), что не позволяет протестировать полную функциональность до закрытия всех слоев. Подход Мэтта Пакока заключается в создании тикетов по функциональным возможностям: один тикет охватывает полностью рабочую функцию, например, "вход в приложение", от базы данных до интерфейса. Это позволяет тестировать функциональность целиком сразу после закрытия тикета, что делает разработку более гибкой итеративной, особенно при меняющихся требованиях.

Схема — нажмите узел

От диалога к реализации: To-Spec и To-Tickets

Главное

Скиллы To-Spec и To-Tickets помогают перевести диалог с ИИ в четкую спецификацию без кода, а затем разбить её на функциональные тикеты, что обеспечивает гибкость и возможность тестирования функциональности на каждом этапе.

05Раздел

Скиллы Implement и Code-Review: разработка и контроль качества

Когда тикеты готовы, наступает фаза разработки, которую запускает скилл /implement. Он активирует подход Test-Driven Development (TDD), при котором тесты пишутся раньше кода. Агент сначала создает тесты, описывающие ожидаемый результат работы функциональности, и, естественно, эти тесты изначально "падают", так как код еще не написан. Затем агент поэтапно реализует функциональность, постоянно прогоняя тесты, пока они не станут "зелеными", что гарантирует строгое соответствие изначальным требованиям. Такой подход предотвращает создание кода, который просто "проходит" тесты на уже увиденных сценариях, а не на заранее определенных требованиях.

После реализации кода необходим его перепроверка, и для этого у Мэтта есть отдельный скилл /code-review. Этот скилл уникален тем, что проверяет код сразу по двум независимым осям, используя двух параллельных субагентов, а не одну модель. Первый субагент оценивает код на соответствие стандартам проекта (например, отсутствие "неясных названий" или "дублированного кода"). Второй субагент проверяет, соответствует ли код изначальной задаче или спецификации. Такая двойная проверка позволяет обнаружить "разрывы" – ситуации, когда код может быть чистым и аккуратным, но при этом не выполнять поставленную задачу. Для проверки стандартов качества используются 12 терминов рефакторинга из книги Мартина Фаулера, которые модель уже знает, что избавляет от необходимости каждый раз расписывать эти понятия заново.

01 Test-Driven Development (TDD) — Тесты пишутся до написания кода, фиксируя ожидаемое поведение.
02 Итеративная разработка — ИИ реализует функциональность, пока все тесты не станут "зелеными" строго по требованиям.
03 Двухсторонний код-ревью — Проверка кода одновременно по двум осям: стандартам проекта и соответствию спецификации.
04 Стандарты качества кода — Использование 12 терминов Фаулера для оценки качества кода (например, Shotgun Surgery, Feature Envy, Data Clumps).

Схема — нажмите узел

TDD и процесс Code-Review

Главное

Скилл Implement запускает TDD, где тесты пишутся раньше кода для строгого соответствия требованиям, а Code-Review использует два независимых субагента для проверки кода на стандарты и соответствие спецификации, выявляя расхождения даже в чистом коде.

06Раздел

Улучшение архитектуры и оптимизация коммуникации с ИИ

Для поддержки и улучшения архитектуры проекта существует скилл /improve-codebase-architecture. Он сканирует репозиторий, анализируя историю изменений в Git, чтобы выявить часто изменяемые файлы – потенциальные "горячие точки" кода. Затем он прогоняет "тест на удаление" по всей кодовой базе: для каждой функции проверяется, что произойдет, если её удалить. Если тесты все еще проходят, значит функция была не нужна, и её можно удалить, тем самым уменьшая "разбросанную логику". Результатом работы скилла является HTML-отчет, который предоставляет обзор архитектуры проекта с рекомендациями по удалению ненужного кода и рефакторингу дублирующих модулей.

Проблема "разбросанной логики" (когда одна функция вызывает множество мелких функций, разбросанных по разным файлам) увеличивает потребление контекста ИИ-моделью, так как ей приходится "прыгать" через все эти вызовы, чтобы понять общую картину. Решение Мэтта заключается в инкапсуляции: каждая мелкая функция остается в своем файле, но для модели и программиста создается одна главная "дверь входа" – функция-обертка, которая координирует все мелкие вызовы. Это значительно сокращает объем контекста, который ИИ-модель должна обрабатывать для понимания задачи.

Эффективность работы ИИ-агентов также сильно зависит от качества документации и инструкций, что освещает скилл /writing-for-agents. Основные принципы: сжимать все, что тратит контекст впустую (если инструкцию можно сказать короче без потери смысла, её сокращают), и использовать термины с готовым значением. Модель уже знает многие профессиональные термины (например, из книги Фаулера по рефакторингу), поэтому нет нужды каждый раз объяснять их заново. Использование общепринятых терминов экономит токены и улучшает понимание модели.

01 Анализ Git-истории — Сканирование Git-лога для выявления часто изменяемых файлов.
02 Тест на удаление — Запуск тестов на удаление для выявления ненужных функций.
03 Архитектурный отчет — Генерация HTML-отчета с рекомендациями по улучшению архитектуры.
04 Инкапсуляция логики — Каждая функция в своем файле, но для модели и программиста – одна точка входа, что снижает потребление контекста ИИ.
05 Короткие инструкции — Сжимать все инструкции, которые тратят контекст впустую.
06 Использование готовых терминов — Использовать термины с уже готовым значением, известные ИИ из обучения (например, 12 терминов Фаулера).

Главное

Скилл Improve-Codebase-Architecture улучшает архитектуру, выявляя и устраняя разбросанную логику через анализ Git-лога и тесты на удаление, а Writing-For-Agents оптимизирует коммуникацию с ИИ, предписывая краткие инструкции и использование общепринятых терминов для экономии контекста.

Термины

Словарь урока

Grill-Me: Самый популярный скилл Мэтта Пакока, предназначенный для настойчивого и структурированного интервьюирования пользователя или агента с целью глубокого уточнения плана или задачи, используя дерево решений и рекомендуемые ответы.
To-Spec: Скилл, который преобразует диалог с ИИ-агентом (например, после использования Grill-Me) в документ со спецификацией — подробный план того, как будет реализована задача, без включения в него блоков кода.
To-Tickets: Скилл, который разбивает спецификацию проекта на функциональные тикеты, где каждый тикет представляет собой полностью рабочую функцию (от базы данных до интерфейса), что позволяет тестировать её целиком и обеспечивает гибкость разработки.
Implement: Скилл, запускающий процесс разработки с использованием Test-Driven Development (TDD), при котором тесты пишутся раньше кода, а функциональность реализуется и проверяется итеративно до успешного прохождения всех тестов.
Code-Review: Скилл, выполняющий двухстороннюю проверку кода двумя параллельными субагентами: один проверяет код на соответствие стандартам проекта, другой — на соответствие изначальной спецификации, что позволяет выявлять как стилистические, так и функциональные расхождения.
Improve-Codebase-Architecture: Скилл, который анализирует кодовую базу и историю Git для выявления проблемных мест (часто изменяемые файлы, разбросанная логика) и предлагает рекомендации по улучшению архитектуры, включая удаление ненужных функций с помощью теста на удаление.
Test-Driven Development (TDD): Методология разработки, при которой сначала пишутся автоматизированные тесты, описывающие желаемое поведение кода, а затем создается сам код, проходящий эти тесты. Это обеспечивает высокое качество и соответствие требованиям.
Shotgun Surgery: Один из "запахов кода" (Code Smells), описывающий ситуацию, когда одно логическое изменение в системе требует внесения множества небольших изменений в разных, разрозненных местах кода, что увеличивает риск ошибок.
Feature Envy: Один из "запахов кода" (Code Smells), описывающий ситуацию, когда метод или функция в одном модуле проявляет избыточную "зависть" к данным или функциональности другого модуля, часто обращаясь к ним больше, чем к своим собственным данным.
Data Clumps: Один из "запахов кода" (Code Smells), описывающий ситуацию, когда группа из нескольких значений (например, имя, телефон, город) постоянно передается вместе как отдельные параметры через множество функций, вместо того чтобы быть объединенными в одну сущность (объект).

Карточки

Запомните главное

Нажмите карточку — она перевернётся.

Grill-Me Самый популярный скилл Мэтта Пакока, предназначенный для настойчивого и структурированного интервьюирования пользователя или агента с целью глубокого уточнения плана или задачи, используя дерево решений и рекомендуемые ответы.

To-Spec Скилл, который преобразует диалог с ИИ-агентом (например, после использования Grill-Me) в документ со спецификацией — подробный план того, как будет реализована задача, без включения в него блоков кода.

To-Tickets Скилл, который разбивает спецификацию проекта на функциональные тикеты, где каждый тикет представляет собой полностью рабочую функцию (от базы данных до интерфейса), что позволяет тестировать её целиком и обеспечивает гибкость разработки.

Implement Скилл, запускающий процесс разработки с использованием Test-Driven Development (TDD), при котором тесты пишутся раньше кода, а функциональность реализуется и проверяется итеративно до успешного прохождения всех тестов.

Code-Review Скилл, выполняющий двухстороннюю проверку кода двумя параллельными субагентами: один проверяет код на соответствие стандартам проекта, другой — на соответствие изначальной спецификации, что позволяет выявлять как стилистические, так и функциональные расхождения.

Improve-Codebase-Architecture Скилл, который анализирует кодовую базу и историю Git для выявления проблемных мест (часто изменяемые файлы, разбросанная логика) и предлагает рекомендации по улучшению архитектуры, включая удаление ненужных функций с помощью теста на удаление.

Test-Driven Development (TDD) Методология разработки, при которой сначала пишутся автоматизированные тесты, описывающие желаемое поведение кода, а затем создается сам код, проходящий эти тесты. Это обеспечивает высокое качество и соответствие требованиям.

Shotgun Surgery Один из "запахов кода" (Code Smells), описывающий ситуацию, когда одно логическое изменение в системе требует внесения множества небольших изменений в разных, разрозненных местах кода, что увеличивает риск ошибок.

Feature Envy Один из "запахов кода" (Code Smells), описывающий ситуацию, когда метод или функция в одном модуле проявляет избыточную "зависть" к данным или функциональности другого модуля, часто обращаясь к ним больше, чем к своим собственным данным.

Data Clumps Один из "запахов кода" (Code Smells), описывающий ситуацию, когда группа из нескольких значений (например, имя, телефон, город) постоянно передается вместе как отдельные параметры через множество функций, вместо того чтобы быть объединенными в одну сущность (объект).

Ошибки

Частые ошибки и подводные камни

▲Недооценка случайности результатов ИИ: Использование ИИ для генерации кода без механизмов контроля и уточнения приводит к непредсказуемым результатам, требующим значительных переделок.
▲Жёсткая последовательность разработки: Следование крупным фреймворкам с жёсткой цепочкой шагов приводит к потере времени и ресурсов при любом изменении требований, так как вся цепочка должна быть перезапущена.
▲Использование ИИ-агентов без достаточных технических знаний: Отсутствие опыта в коммерческих запусках или понимания архитектуры может привести к тому, что ИИ будет генерировать технически верные, но неработоспособные или неподдерживаемые решения, превращая задачу на неделю в месяцы доработок.
▲Код в спецификации: Включение блоков кода в спецификации приводит к тому, что ИИ-модель слепо следует устаревшим или неоптимальным фрагментам кода, вместо того чтобы анализировать актуальное состояние проекта и предлагать наилучшие решения.
▲Разбросанная логика: Чрезмерная декомпозиция кода на множество мелких функций, разбросанных по файлам, затрудняет понимание общей логики программы как для человека, так и для ИИ, 'забивая' контекстное окно модели и увеличивая стоимость анализа.

Практика

Закрепите на своих задачах

Декомпозиция задачи с Grill-Me

Используя принципы скилла Grill-Me, выберите любую задачу по разработке (например, 'реализовать систему регистрации пользователей') и мысленно 'проведите' диалог с ИИ-агентом. Зафиксируйте 3-5 ключевых вопросов, которые бы задал ИИ, чтобы понять задачу, и какие рекомендованные ответы вы бы ему дали. Убедитесь, что понимание задачи достигнуто и вы не перепрыгиваете через уровни решений.

Разработка спецификации без кода

Возьмите результат декомпозиции из предыдущего задания. Создайте краткую спецификацию в формате, аналогичном скиллу To-Spec, описывающую план реализации 'системы регистрации пользователей'. Убедитесь, что в спецификации нет ни одного блока кода, а все описания достаточно детальны для того, чтобы ИИ мог понять, что именно требуется реализовать.

Оптимизация разбросанной логики

Представьте функцию processOrder(), которая вызывает следующие подфункции: calculateTotal(), applyDiscount(), checkStock(), sendConfirmationEmail(), updateInventory(). Опишите, как вы применили бы принципы инкапсуляции и 'теста на удаление' для оптимизации этой разбросанной логики, чтобы модель ИИ могла эффективнее понимать и изменять этот участок кода. Какие шаги вы предприняли бы для сбора этих функций в одну точку входа, и как бы вы проверили необходимость каждой из них?

Тест

Проверьте себя

01Какую проблему решает подход Мэтта Пакока к управлению ИИ-агентами по сравнению с крупными фреймворками?

02Какой из принципов скилла Grill-Me гарантирует, что модель не оставит пользователя один на один с пустым вопросом?

03Почему в спецификации, создаваемой скиллом To-Spec, запрещено размещать блоки кода?

04Что означает 'Shotgun Surgery' в контексте 'запахов кода', используемых в Code-Review?

05Какой подход использует скилл To-Tickets для разбивки задач, отличающийся от большинства фреймворков?

06Почему скиллы Мэтта Пакока спроектированы как очень короткие инструкции?

Выводы

Ключевые выводы

◆Модульный подход Мэтта Пакока с независимыми скиллами предлагает гибкую и адаптивную альтернативу жестким последовательным фреймворкам, позволяя более эффективно управлять процессом разработки с ИИ.
◆Скиллы Grill-Me, To-Spec и To-Tickets обеспечивают структурированный процесс от уточнения задачи до её декомпозиции на функциональные тикеты, минимизируя непредсказуемость ИИ-моделей.
◆Скиллы Implement и Code-Review внедряют лучшие практики разработки (TDD и двухсторонний ревью по стандартам Фаулера) для обеспечения высокого качества и соответствия кода спецификациям.
◆Принципы написания документации для агентов (сжатие контекста и использование готовых терминов) и скилл Improve-Codebase-Architecture помогают оптимизировать взаимодействие с ИИ и поддерживать чистоту архитектуры проекта.
◆Современные и более сильные ИИ-модели требуют меньше 'ведения за руку', что делает модульные скиллы особенно актуальными, поскольку они предоставляют модели правила и пространство для маневров, а не жесткие пошаговые инструкции.

Собрано Курсографом из одного источника. Источник: https://www.youtube.com/watch?v=AMtfFKTZUyM.