Skip to content
← Все главы

Глава 01

Манифест

Deep Work Plan (DWP) — это методология на основе только Markdown для структурированного автономного выполнения работы ИИ-агентами разработки. Она превращает расплывчатую цель в пригодный для ревью план — спецификацию, — который агент может выполнять, приостанавливать, возобновлять и по которому может отчитываться, не теряя контекст и не импровизируя путь к несогласованным результатам.

Глубокая работа — для агентов

Название описывает практику, которую оно порождает: сфокусированное, продолжительное усилие над когнитивно сложной работой, удерживаемое структурой, а не силой воли. То самое свойство, что делает глубокую работу ценной для людей — концентрация без отвлечений, поддерживаемая на длинном горизонте, — это именно то, что нужно ИИ-агенту разработки, чтобы доводить до конца работу, растянутую на часы или дни. Deep Work Plan даёт эту структуру и тем самым превращает репозиторий в AI-first, пилотируемую агентами кодовую базу.

Агент без плана ведёт себя как работник умственного труда, который никогда не выделяет время, ничего не записывает и переключает контекст на каждом отвлечении. Deep Work Plan даёт агенту эквивалент забронированного календаря и письменного брифа: очерченные границы, ясную последовательность и долговечное место для фиксации прогресса.

Направление — это множитель

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

Это переосмысливает, что значит хорошо делегировать. Хорошее делегирование — это не просьба к агенту о работе, а определение работы достаточно ясно, чтобы её можно было выполнить правильно: цель, ограничения, контекст, которого агенту иначе не хватало бы, и критерии, решающие, удалось ли ему. Большая часть ценности создаётся до того, как начинается выполнение.

Deep Work Plan — это дисциплина выполнения этой работы «вверх по течению» в долговечной, повторяемой форме. Его два столпа — это две половины хорошего направления: спецификация определяет, как выглядит «правильно», а harness даёт агенту контекст и инструменты, чтобы этого достичь. Вместе они превращают сырую способность модели в надёжную инженерию — удерживаемую на протяжении задачи, идущей часами, и сохраняемую между агентами, которые меняются от сессии к сессии.

Spec-driven по своей сути

Это первый столп методологии, и, как и «harness», его стоит определить прямо.

Что такое spec-driven-разработка. В обычной работе, управляемой промптами, источником истины является разговор: вы просите у агента что-то, он редактирует файлы, и единственная запись о замысле — это чат-транскрипт, который прокручивается прочь и больше никогда не просматривается. Spec-driven-разработка (SDD) переворачивает это. Сначала вы записываете, что должно быть истинным — цель, границы, критерии приёмки, проверки, доказывающие, что работа сделана, — и именно эта письменная спецификация, а не разговор, является источником истины. Затем агент выполняет работу по спецификации, а не импровизирует из однострочного промпта.

Как DWP воплощает это. В Deep Work Plan план и есть спецификация. Цель становится пригодным для ревью планом; план раскладывается на атомарные задачи; каждая задача несёт явные критерии приёмки и validation gates; а протокол завершения подтверждает работу относительно них. План → задачи → gates → завершение — это SDD, сделанная конкретной и исполнимой.

Почему это важно. Написание спецификации сначала окупается тремя способами: оно сокращает отклонение от курса, потому что агента измеряют относительно заявленных критериев, а не тускнеющей памяти о запросе; оно делает работу проверяемой, потому что каждый gate либо пройден, либо нет; и оно делает работу возобновляемой, потому что спецификация переживает любую отдельную сессию или агента — другой агент может взяться за неё завтра и точно знать, что означает «готово».

Чем DWP отличается. Вокруг этой идеи сформировалось более широкое spec-driven-движение, включая GitHub Spec Kit, Amazon Kiro и Tessl. Эти подходы, как правило, привязаны к конкретному инструменту или платформе. DWP намеренно иной: он независим от инструмента и нативен репозиторию. Спецификация живёт в репозитории как обычный Markdown, поэтому путешествует вместе с кодом, а не с продуктом вендора, — и она напрямую сочетается со вторым столпом, поскольку спецификация сама является частью harness, который несёт репозиторий.

Репозиторий становится harness

Это второй столп методологии, и он заслуживает прямого определения — «harness» стало нагруженным термином, и значительная часть индустрии использует его, не поясняя, что он означает.

Что такое harness агента. Большая языковая модель сама по себе — лишь предсказатель текста. Превращает её в надёжного инженера всё то, что обёрнуто вокруг неё: контекст, который ей дают, инструменты, которые она может вызывать, цикл управления, решающий, что делать дальше, ограничители, ловящие ошибки, и устойчивое состояние, позволяющее ей остановиться и возобновиться. Эта окружающая обвязка и есть harness. Модель — это двигатель; harness — это шасси, рулевое управление и тормоза, которые делают двигатель безопасным в управлении.

Что такое harness-инженерия. Большинство команд строят эту обвязку неявно, внутри одного инструмента — конкретной IDE, продукта-агента или самописного фреймворка, — поэтому она работает только там и исчезает в тот момент, когда вы меняете инструмент. Harness-инженерия — это дисциплина намеренного проектирования этой обвязки как полноценного артефакта. Deep Work Plan занимает одну твёрдую позицию относительно того, где она должна жить: не в инструменте, а в самом репозитории.

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

Элемент harness Что он даёт Куда DWP помещает его в вашем репозитории
Контекст что агенту нужно знать AGENTS.md, docs/ и README по модулям
Инструменты что агент может делать навыки, агенты и команды dwp-* в .agents/
Цикл управления как идёт работа Deep Work Plan: план → атомарные задачи → gates → завершение
Ограничители что удерживает корректность явные критерии приёмки и validation gates
Состояние как пережить прерывание игнорируемые git-ом планы, черновики и журнал прогресса в .dwp/

Поскольку каждый элемент — это файл в репозитории, а не функция инструмента, harness переносим по самой своей конструкции. Это и есть однострочное утверждение, на котором держится остальная методология: сам репозиторий становится harness, так что любой агент может пилотировать любой репозиторий — без самописного фреймворка под каждый инструмент.

Почему важно структурированное автономное выполнение

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

DWP накладывает лёгкую структуру, которая напрямую устраняет каждый сбой:

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

Markdown до самого низа

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