Kitobni o'qish: «Крафт+. Как перестать быть оператором данных и начать управлять проектом»

Предисловие

Я двенадцать лет руковожу проектами в R&D и IT, а в отрасли более 18. Прошел путь от стажера до топ-менеджера и за это время я видел десятки руководителей, которые делают одно и то же: вручную собирают статусные отчёты, рисуют матрицы рисков, декомпозируют работы в Excel, переписывают одни и те же документы под каждого стейкхолдера. Рутина, которая сжирает часы каждый день и не двигает проект вперёд. Новое время дало мне, и таким как я шанс с помощью искусственного интеллекта освободиться от рутины.

КРАФТ+ вырос из этой боли. Я начал делегировать рутину цифровому стажёру (таким образом, как хотел бы чтобы ее в свое время делегировали мне) и увидел, что качество результата зависит не от модели, а от того, как поставлена задача. Методология родилась из десятков итераций: что работает, что ломается, где модель выдумывает, где экономит часы.

Книга написана для руководителей проектов, продуктов, тимлидов и аналитиков. Для тех кто принимает решения. Для тех, кто хочет делегировать рутину ИИ и сосредоточиться на главном: стратегии, команде, переговорах. Книга не учит создавать агентов, программировать или строить сложные системы. Книга учит ставить задачи цифровому стажёру так, чтобы он выдавал предсказуемые артефакты.

КРАФТ+ это методология промпт-менеджмента. Она выросла из популярного фреймворка CRAFT и добавила два блока, которых там не было: Табу и Рефлексию. Шесть элементов превращают хаос запросов в структурированные артефакты: таблицы, планы, оценки, отчёты.

Книгу можно читать подряд от Главы 1 до Главы 6, а можно использовать как справочник: открыл нужный раздел, скопировал шаблон, применил к своему проекту. Глава 2 и Матрица работают как каталог: нашли свой домен, посмотрели связку фреймворка и техники, применили. Приложение даёт пятнадцать готовых связок для копирования. Книга не просто об использовании чат-ботов, она про использование инструментов PMBOK, а цифровой стажер – лишь очередной инструмент руководителя.

Да, я не разделяю руководителя проектов от любого другого руководителя. Каждый человек, который руководит группой людей в той или иной степени использует инструменты проектного подхода.

Книга статична. Метод растёт. Обновления матрицы, разборы новых кейсов, ответы на вопросы читателей живут на pmcraft.ru и в телеграм-канале @craft_flow. Подписывайтесь, если хотите видеть изнанку метода после выхода книги.

Свобода начинается с устранения лишнего.

Введение. Две недели за двадцать минут

Понедельник, девять утра. Вы руководитель проекта или продукта. В календаре пять встреч, три дедлайна, два статусных отчёта. Вы садитесь за компьютер и открываете Excel. Сегодня нужно вручную скопировать данные из трекера в презентацию для PMO. Снова.

Вы нанимались управлять проектами. Вместо этого вы стали оператором данных.

Максим жил так же. Тридцать пять лет, руководитель проектов в R&D-компании, десять лет опыта, три параллельных проекта. Жена, сын пяти лет, который каждый вечер спрашивает: «Пап, ты придёшь на тренировку?» Максим обещает. И каждый раз задерживается, потому что нужно собрать ещё один отчёт, ещё одну матрицу рисков, ещё одну декомпозицию работ.

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

Однажды его вызывает топ-менеджер. Спонсор, от которого совет директоров ждёт результатов каждый квартал, и каждый проект, который он курирует, это его репутация. Он не терпит оправданий. Только факты и планы.

- У меня есть идея. Хочу запустить ИИ-ассистент для первичной оценки проектов. Чтобы по описанию идеи автоматически получать сроки, бюджет и риски. Оцени, сколько это будет стоить и сколько времени займёт. К пятнице.

Максим кивает. Он знает, что его ждёт. Внутри сжимается холодный комок: если оценка будет неверной, спонсор скажет «ты не можешь считать, давай закроем проект», и это будет не просто ошибка. Это будет подтверждение того, что он не справляется. Что три параллельных проекта это слишком. Что нужно было отказаться от одного из них полгода назад.

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

- Дорого. Давай пересмотрим.

Спонсор не повышает голос. Просто кладёт листок на стол и смотрит. Максим чувствует, как внутри всё сжимается. Ещё две итерации. День на верификацию с альтернативным экспертом. Жена звонит: «Ты придёшь на тренировку?», Максим смотрит на часы. Восемь вечера. «Завтра. Обещаю».

Итог: две недели. Отвлечены три человека. Получена оценка, которая всё равно может оказаться неверной.

Через полгода Максим делает то же самое за двадцать минут. Он возвращается в кабинет, открывает шаблон в заметках и заполняет контекст:

ЧЕРТЁЖ

БИЗНЕС-ЦЕЛЬ Создать ИИ-ассистент для первичной оценки проектов, который по описанию идеи генерирует сроки, бюджет и риски

ТЕКУЩЕЕ СОСТОЯНИЕ: Есть команда разработки (5 человек), технологии (Python, PostgreSQL), но нет опыта в этом сегменте

ОГРАНИЧЕНИЯ: бюджет 5 млн руб.; срок — Q3 2026; технологии — Python, PostgreSQL; compliance — требования 152-ФЗ

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

Чаще всего проблема во входных данных. Большинство руководителей скармливают стажёру огрызки: «помоги составить план». И получают десять страниц воды про «важность инноваций». Потом ругают модель, возвращаются к Excel и делают вывод, что ИИ в управлении не работает. Если входные данные поставлены достаточно конкретно и полно, то и вывод будет полезным.

Для верного старта беседы с ИИ есть методология КРАФТ+. Она представляет собой операционную систему для сессии ИИ. Вы один раз задаёте контекст, роль и ограничения, а дальше запускаете внутри этой системы нужные приложения: матрицы рисков, пользовательские истории, расчёты критического пути. Метод превращает хаос в структурированные артефакты: таблицы, планы, оценки, отчёты.

Операционная система бесполезна без приложений. Внутри неё работают техники промптинга и управленческие фреймворки Техники меняют то, как модель думает: рассуждает по шагам, ищет скрытые риски. Фреймворки меняют то, о чём мы говорим: распределяют ответственность, проверяют цели на прочность. А каталог приложений, матрица КРАФТ+ × PMBOK, показывает, какое из них запускать под какую задачу.

Что вы получите от этой книги

Книга учит методологии, которая вытаскивает вас из позиции оператора данных: вы перестаёте собирать артефакты вручную и начинаете их проверять и принимать по ним решения.

Вы научитесь сокращать рутину. Статусные отчёты, матрицы рисков, декомпозиция работ: всё это делегируется цифровому стажеру через метод КРАФТ+. Вы отрежете большую часть галлюцинаций: жёсткие требования и табу не дадут модели выдумывать факты, сроки и бюджеты. Вы получите предсказуемые артефакты: готовые документы и таблицы, которые можно сразу использовать в работе. И вернёте себе время для главного: стратегии, команды, развития.

Как устроена эта книга

Книга — инженерный мануал. Она построена так, чтобы вы использовали её как справочник. Три главы, матрица-каталог и приложение с готовыми шаблонами.

Глава 1. Анатомия промпта: Разбор метода КРАФТ+. Знакомимся с цифровым стажёром и разбираем каждый элемент чертежа: контекст, роль, действие, формат, требования и табу, рефлексию. В конце главы собираем метод в операционную систему и считаем его экономику: почему длинный промпт дешевле короткого.

Глава 2. Проект Максима: от идеи до подписи на акте. Проходим путь с Максимом от размытой идеи до закрытия проекта и смотрим, как инструмент меняет форму на каждой фазе. Пять процессных групп, десять доменов знаний, конкретные промпты и результаты. Инициация, планирование содержания и сроков, риски, коммуникации, исполнение и мониторинг, спринты, непредсказуемые задачи и связки, кризис и ребейзлайнинг, ретроспектива.

Матрица КРАФТ+ × PMBOK. Каталог приложений: какой фреймворк и какую технику брать под каждый домен. Справочник, к которому вы будете возвращаться в работе.

Глава 3. Ответственность: чья подпись на акте. Мусор на входе — красивая ложь на выходе. Правило лифта для конфиденциальных данных. Распределение ответственности между человеком и моделью. И эволюция руководителя из исполнителя в дирижёра.

Заключение. Что делать завтра утром. Пять конкретных шагов для первого применения метода.

Приложение. Библиотека гибридных промптов с аннотациями. Пятнадцать готовых связок «техника + фреймворк + КРАФТ+»: когда брать, что менять, на чём модель ломается.

Книгу можно читать подряд от Главы 1 до Заключения, а можно использовать как справочник: открыл нужный раздел, скопировал шаблон, применил к своему проекту. Глава 2 и Матрица работают как каталог: нашли свой домен, посмотрели связку фреймворка и техники, применили. Приложение даёт пятнадцать готовых связок для копирования. Книга не просто об использовании чат-ботов, она про использование инструментов PMBOK, а цифровой стажёр — лишь очередной инструмент руководителя.

Да, я не разделяю руководителя проектов от любого другого руководителя. Каждый человек, который руководит группой людей в той или иной степени использует инструменты проектного подхода.

Свобода начинается с устранения лишнего.

Глава 1. Анатомия промпта: Разбор метода КРАФТ+

КРАФТ+ — инженерный подход к составлению промптов для поддержки принятия решений. Он превращает хаотичные запросы в предсказуемые артефакты: таблицы, планы, оценки, отчёты. Каждый блок закрывает свою уязвимость. Пропустите один, и модель начнёт додумывать за вас.

Он вырос из популярного фреймворка CRAFT (Context, Role, Action, Format, Tone), который широко используется в практике промпт-инжиниринга. Базовый фреймворк хорошо работает для текстов. Но в управлении проектами нужны две вещи, которых там нет: жёсткие запреты и точка остановки перед генерацией. Без них модель неизбежно уходит в фантазии. Поэтому в методологии появились два дополнительных блока — Табу и Рефлексия. Табу говорит модели, чего ей категорически нельзя делать. Рефлексия даёт разрешение остановиться и задать уточняющие вопросы до того, как она начнёт генерировать ответ. Именно эти два элемента превращают базовый шаблон в рабочий инструмент для получения предсказуемых бизнес-результатов.

Другие подходы, Chain-of-Thought (цепочка рассуждений) и Few-Shot (обучение на примерах), решают свои задачи и дополняют методологию. CoT отлично работает для логических и математических задач. Few-Shot помогает тонко настроить стиль и формат ответа. КРАФТ+ задаёт жёсткие рамки, а внутри них, при необходимости, можно попросить модель рассуждать шаг за шагом или привести примеры.

Подход предлагает тратить время на проверку результата, а не на угадывание того, что модель имела в виду.

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

1.0. Стажёр, а не волшебник: память есть, опыта нет

Прежде чем разбирать чертёж по блокам, нужно понять, для кого он предназначен. Чертёж бесполезен без исполнителя. А исполнитель здесь — цифровой стажёр.

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

Стажёр не строит догадок и не читает мысли. Он исполняет написанное. Вы не сказали, какой стек, и он предложит свой. Вы не указали бюджет, и он заложит тот, который видел в обучающих данных. Каждое слово в промпте он понимает буквально, а не так, как вы имели в виду.

При всем колоссальном объеме знаний у стажера надо всегда помнить, что он не несёт ответственности. Он выдаст оценку, матрицу рисков, декомпозицию. Но если цифра окажется неверной, подпись на акте поставите вы, а не модель. Об этом подробно в главе 8.

Теперь, когда вы знаете, кто ваш стажёр и где его границы, переходим к чертежу. Шесть блоков задают реальность, в которой стажёр работает. Первый блок - фундамент. Без него всё остальное — фантазии модели.

1.1. К (Контекст): Фундамент реальности

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

Контекст - это факты реальности. Не ваши пожелания, не ваши догадки, а неизменные данные, в которых существует проект. Это «песочница», внутри которой ИИ должен работать. Всё, что вы не укажете в Контексте, модель выдумает сама - и эти догадки почти всегда будут стоить вам часов переделок.

Без контекста:

«Составь план разработки нового измерительного прибора. Бюджет примерно 10 миллионов, срок год. Сделай таблицу».

Что получает ИИ: Нет бизнес-цели (зачем этот прибор? для кого?). Нет текущего состояния (есть ли прототип? есть ли команда?). Нет технологий (какая элементная база? какое ПО?). Нет compliance (какие сертификации нужны? ГОСТы?). Аудитория не указана. ИИ выдумает всё это сам - и почти наверняка ошибется.

С контекстом:

КОНТЕКСТ:

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

Текущее состояние: Есть команда разработки (5 человек: 2 backend, 2 frontend, 1 ML-инженер), технологии (Python, PostgreSQL, базовая LLM-интеграция через API), но нет опыта в этом сегменте и нет готового продукта

ОГРАНИЧЕНИЯ:

- Бюджет: 5 млн руб.

- Срок: Q3 2026

- Технологии: Python, PostgreSQL, API-интеграция с LLM (без обучения собственных моделей)

- Compliance: требования к защите персональных данных (152-ФЗ), запрет на использование персональных данных клиентов для обучения

АУДИТОРИЯ: Совет директоров, требует четкого обоснования инвестиций

Что получает ИИ: ИИ понимает, зачем нужна оценка, в каких рамках работать, для кого готовить документ. Он не будет додумывать бюджет, срок или стек - всё это задано явно.

Видите разницу? В первом случае ИИ работает вслепую. Во втором - у него есть карта местности. Теперь давайте разберём, как построить такую карту.

ШАБЛОН КОНТЕКСТА

БИЗНЕС-ЦЕЛЬ: [Зачем мы это делаем — конкретный измеримый результат]

ТЕКУЩЕЕ СОСТОЯНИЕ: [Что уже есть: команда, технологии, наработки]

ОГРАНИЧЕНИЯ:

- Бюджет: [X млн руб.]

- Срок: [Дата или квартал]

- Технологии: [Стек, инструменты, интеграции]

- Compliance: [152-ФЗ, отраслевые стандарты, корпоративные политики]

АУДИТОРИЯ: [Для кого готовится артефакт]

Бизнес-цель. Задаёт направление мышления модели. Это не слоган и не миссия компании. Это конкретный, измеримый результат, ради которого затевается проект.

Плохо:

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

Хорошо:

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

Текущее состояние. Показывает, с чего начинаем. Это блок, который чаще всего забывают, и именно он порождает самые дорогие ошибки.

Если вы не укажете, что у вас уже есть команда из пяти разработчиков и готовый стек на Python, ИИ заложит в план три месяца на найм, обучение и закупку лицензий. Если не укажете, что прототип уже собран и прошёл внутреннее тестирование, ИИ начнёт с нуля - с CustDev и MVP.

Правило: пишите только то, что реально есть. Не то, что вы планируете нанять, не то, что хотите купить, а то, что уже в вашем распоряжении прямо сейчас.

Ограничения. Четыре подпункта, каждый из которых закрывает свою уязвимость:

● Бюджет - верхняя граница.

Без него ИИ предложит «оптимальное» решение, которое может быть в десять раз дороже вашего реального бюджета. Модель не знает, что такое «дорого» для вашей компании. Для стартапа 5 миллионов - это потолок. Для корпорации - это мелочь. Укажите цифру.

● Срок - временные рамки.

Без них модель заложит «реалистичные» 12–18 месяцев из своих обучающих данных, даже если вам нужно выйти на рынок через квартал. ИИ не знает про ваши корпоративные дедлайны, про привязку к выставке или к бюджетному циклу.

● Технологии - зафиксированный стек.

Без этого ИИ может предложить решение на Java, когда у вас вся команда на Python, или заложить интеграцию с SAP, когда у вас 1С. Это особенно критично в R&D-компаниях, где технологический стек часто уникален и не подлежит замене.

● Compliance - юридические и регуляторные рамки.

152-ФЗ, требования ЦБ РФ, отраслевые стандарты, внутренние политики безопасности. ИИ не знает, в какой юрисдикции вы работаете и какие штрафы грозят за нарушение. Если не укажете - получите план, который придётся переделывать после первой консультации с юристами.

Эти четыре ограничения покрывают 95% проектных задач. Если нужно больше - добавляйте, но только если это критично. Лишние ограничения сужают пространство решений без необходимости.

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

Правила использования

Начинайте каждый промпт с Контекста. Это фундамент. Если вы начнёте с действия, а контекст добавите в конце, модель может не учесть ограничения. Порядок элементов в КРАФТ+ не случаен.

Будьте конкретны в каждом блоке. Не «бюджет примерно 10 миллионов», а «Бюджет: 10 млн руб.». Не «срок год», а «Срок: Q3 2025». Измеримость - ваш главный инструмент против галлюцинаций.

Указывайте только то, что действительно ограничивает. Если у вас нет жёстких требований к технологиям - не пишите про них. Лишние ограничения сужают пространство решений. Но если ограничение есть - не стесняйтесь, пишите подробно. Лучше перестраховаться, чем получить план, который технически невозможен.

Практическое правило

Никогда не начинайте промпт с действия. Всегда сначала задавайте Контекст. Это как фундамент в строительстве: если вы начнёте класть стены без фундамента, дом рухнет. Контекст - это ваш фундамент реальности, без которого всё остальное - фантазии модели.

Шпаргалка

Создайте в заметках файл «Библиотека контекстов» с готовыми шаблонами под ваши типовые задачи. У вас, скорее всего, не больше пяти-семи повторяющихся сценариев: оценка нового продукта, запуск направления, внедрение системы, трансформация процесса, подготовка к аудиту.

Заполните один раз бизнес-цель, текущее состояние и ограничения для каждого сценария. Копируйте шаблон, меняйте только переменные в квадратных скобках. Это сокращает время на составление запроса и гарантирует, что вы никогда не забудете критически важный блок.

1.2. Р (Роль): Как заставить ИИ думать как эксперт, а не как чат-бот

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

Роль - это не украшение промпта. Это переключатель, который переводит модель из режима «чат-бота» в режим «эксперта».

Без роли:

«Ты - опытный менеджер. Оцени проект»

Что получает ИИ: Роль размыта («опытный» - это сколько лет? в какой области?). Нет seniority. Нет методологии. Модель будет рассуждать как универсальный помощник - поверхностно, без конкретики. Результат: общие фразы про «оптимизацию процессов», «повышение эффективности», «снижение рисков».

С ролью:

РОЛЬ:

Действуй как Senior Product Manager с десятилетним опытом запуска новых B2B-продуктов в R&D-компаниях и глубоким пониманием рисков при выходе на новые рынки. Используй метод трёх точек для оценки сроков (оптимистичная, пессимистичная, наиболее вероятная).

Что получает ИИ: Модель рассуждает как управленец. Использует PERT-формулу. Учитывает риски выхода на новый рынок. Даёт три сценария вместо одного. Говорит на языке Product Management: JTBD, CustDev, unit-экономика, go/no-go критерии.

Шаблон роли

РОЛЬ:

Действуй как [конкретная роль] с [уровень seniority] и [ключевая экспертиза]. Используй [конкретная методология].

Конкретная роль. Не «опытный менеджер», не «специалист», не «эксперт». А конкретная должность с понятными границами ответственности: Senior Product Manager, Руководитель проектов, Архитектор решений, Аналитик данных, UX-исследователь.

Почему это важно: модель обучалась на миллионах текстов, где разные роли говорят разным языком. Product Manager думает про ценность для клиента и unit-экономику. Project Manager - про сроки, ресурсы и риски. Архитектор - про технические зависимости и масштабируемость. Если вы не укажете роль, модель будет метаться между этими перспективами и выдаст «усреднённый» результат.

Уровень seniority. Junior, Middle, Senior, Lead, Head of, Director. Это не формальность - от уровня зависит глубина анализа и готовность брать ответственность.

● Junior даст поверхностный ответ, будет перестраховываться.

● Middle даст рабочий вариант, но без стратегического взгляда.

● Senior даст управленческий анализ с учётом рисков и ROI.

● Lead / Head of даст стратегическую рекомендацию с критериями принятия решений.

Для задач первичной оценки, планирования и подготовки артефактов для руководства - всегда берите Senior или выше. Для рутинных операционных задач (написание письма, составление списка) - достаточно Middle.

Ключевая экспертиза. Указывает область, в которой модель должна быть особенно сильна. Это сужает пространство решений и отсекает нерелевантные советы.

Примеры:

● «с глубоким пониманием рисков при выходе на новые рынки» - для оценки нового продукта

● «с опытом внедрения CRM в финтехе» - для проекта миграции

● «со знанием требований 152-ФЗ и отраслевых стандартов» - для compliance-задач

● «с опытом управления распределёнными командами» - для проектов с удалённой разработкой

Конкретная методология. Это самый мощный элемент роли. Когда вы указываете методологию, модель начинает применять её механически, даже если вы явно не попросили об этом в блоке «Действие».

Примеры:

● «Используй метод трёх точек для оценки сроков» - модель автоматически даст три сценария (оптимистичный, пессимистичный, наиболее вероятный)

● «Используй метод критического пути» - модель выявит зависимости между задачами

● «Применяй фреймворк RICE для приоритизации» - модель оценит каждую фичу по Reach, Impact, Confidence, Effort

● «Используй PERT-формулу: (O + 4M + P) / 6» - модель рассчитает ожидаемую длительность

Без указания методологии модель даст одно число «на глазок». С методологией - применит формулу и даст математически обоснованный результат.

Правила использования

Одна роль - один промпт. Не пытайтесь назначить ИИ несколько ролей одновременно: «Действуй как Product Manager и Архитектор и Аналитик». Модель будет метаться между перспективами и выдаст «усреднённый» результат. Если нужна мультидисциплинарная оценка - разбейте задачу на несколько промптов с разными ролями (цепочка промптов, о которой мы поговорим в разделе 3.1).

● Seniority должен соответствовать задаче. Для подготовки артефакта, который пойдёт руководству, берите Senior или выше. Для рутинной операционной задачи - Middle. Не берите Junior для стратегических решений - модель будет перестраховываться и не даст конкретных рекомендаций.

● Методология - это усилитель роли. Если вы указали роль Senior PM, но не указали методологию, модель будет рассуждать как PM «на ощупь». Если добавили методологию (PERT, RICE, критический путь) - модель начнёт применять её механически. Это самый дешёвый способ повысить качество результата.

● Явно указывайте российский контекст. Модель обучается на огромном массиве данных из разных стран - США, Европы, Азии. Если не указать, что проект работает в России, модель будет опираться на зарубежный опыт: GDPR вместо 152-ФЗ, HIPAA вместо российских медицинских стандартов, американские строительные нормы вместо ГОСТов. Добавьте в экспертизу: *«со знанием требований 152-ФЗ, ГОСТов и отраслевых стандартов РФ»* - и модель переключится на релевантный российский контекст.

● Не бойтесь специфичных ролей. Если ваш проект связан с радиоэлектроникой, hardware, embedded-разработкой - так и пишите: *«Действуй как Lead Embedded Engineer с опытом разработки устройств на STM32»*. Модель найдёт в своих обучающих данных релевантные тексты и даст специфичные рекомендации. Универсальные роли дают универсальные (читай: бесполезные) советы.

Практическое правило

Всегда указывайте три элемента роли: конкретная должность + seniority + методология. Это минимальный набор, который превращает ИИ из чат-бота в эксперта.

Если вы пропускаете хотя бы один элемент - результат будет хуже. Проверьте свои промпты: есть ли там все три компонента?

Шпаргалка

Проверенные роли под конкретные цели:

● Оценка нового продукта → Senior Product Manager + метод трёх точек

● Внедрение CRM → Senior Project Manager + метод критического пути

● Миграция данных → Lead Data Engineer + методология ETL

● Подготовка статусного отчёта → PMO Analyst + R/A/G-дашборд

● Анализ рисков → Senior Risk Manager + методология Monte Carlo

● CustDev → Lead UX Researcher + JTBD-фреймворк

● Техническое задание → Lead Business Analyst + BABOK

● Коммуникационный план → Senior PM + методология стейкхолдер-менеджмента

Копируйте шаблон, меняйте только переменные в квадратных скобках. Это сокращает время на составление промпта и гарантирует, что вы никогда не забудете указать методологию.

1.3. А (Активное действие): Глаголы силы против пассивных просьб

Самая частая ошибка в промптах - это вежливость. Люди пишут «помоги», «сделай», «пожалуйста» - и получают воду вместо результата. Модель не понимает, что именно вы хотите, и выдаёт «усреднённый» текст, который не подходит ни для чего.

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

Действие - это не вежливая просьба. Это инженерная спецификация: что именно модель должна сделать с Контекстом и Ролью, которые вы задали.

Без действия:

«Помоги с оценкой проекта»

Что получает ИИ: Непонятно, что делать. «Помоги» - это не команда, а просьба о помощи. Модель будет гадать: оценить сроки? Бюджет? Риски? Всё сразу? Написать текст? Сделать таблицу? Результат: размытый ответ, который не подходит ни для чего.

С действием:

ЗАДАЧА:

Проведи первичную оценку сроков и бюджета проекта создания ИИ-ассистента для оценки проектов.

Что получает ИИ: Чёткую команду: «проведи оценку» + конкретный объект (сроки и бюджет) + привязка к проекту из контекста. Модель знает, что делать.

Шаблон действия

ЗАДАЧА:

[Глагол силы] + [что именно сделать]

Глагол силы. Это не «помоги», не «сделай», не «пожалуйста». Это конкретное действие: «декомпозируй», «рассчитай», «сформируй», «проанализируй», «выяви», «оцени», «подготовь».

Почему это важно: глагол определяет, какую операцию модель должна выполнить над данными. «Декомпозируй» - разбей на части. «Рассчитай» - примени формулу. «Сформируй» - создай структуру. «Проанализируй» - выявь закономерности. Каждый глагол запускает свой алгоритм обработки информации.

Что именно сделать. Указывает объект действия. Не «сделай что-нибудь с проектом», а «декомпозируй проект на фазы». Не «оцени», а «рассчитай трудозатраты методом трёх точек». Конкретика отсекает догадки модели.

Правила использования

● Используйте глаголы силы, а не просьбы. Замените «помоги», «сделай», «пожалуйста» на «декомпозируй», «рассчитай», «сформируй», «проанализируй», «выяви», «оцени», «подготовь». Глагол силы - это команда, а не просьба.

● Указывайте объект действия. Не «оцени», а «оцени сроки и бюджет». Не «проанализируй», а «проанализируй риски проекта». Конкретика отсекает догадки модели.

● Разбивайте сложные задачи на несколько действий. Если задача включает несколько операций (декомпозиция + расчёт + анализ), разбейте её на отдельные пункты:

ЗАДАЧА:

1. Декомпозируй проект на фазы

2. Рассчитай трудозатраты методом трёх точек

3. Выяви критические риски для каждой фазы

● Избегайте размытых формулировок. Не «сделай хорошо», не «оптимизируй», не «улучши». Эти слова не имеют конкретного смысла для модели. Вместо «оптимизируй план» напишите «сократи длительность критического пути на 20% за счёт параллелизации задач».

● Не смешивайте действие с форматом. Действие отвечает на вопрос «что сделать?». Формат отвечает на вопрос «в каком виде выдать?». Это два разных блока. Сначала задайте действие, потом - формат. Если вы напишете «декомпозируй проект и сделай таблицу», модель может запутаться: главное - декомпозиция или таблица? Разделяйте эти инструкции.

Практическое правило

Всегда указывайте два элемента действия: глагол силы + объект. Это минимальный набор, который превращает просьбу в команду.

Если вы пропускаете хотя бы один элемент - модель будет догадываться. А догадки - это галлюцинации. Проверьте свои промпты: есть ли там конкретный глагол и конкретный объект?

Шпаргалка

Готовые формулировки действий под типовые задачи:

● Оценка сроков → «Рассчитай сроки методом трёх точек»

● Декомпозиция работ → «Декомпозируй проект на фазы и задачи»

● Анализ рисков → «Выяви риски и оцени вероятность и влияние»

● Приоритизация → «Приоритизируй бэклог по фреймворку RICE»

● Анализ конкурентов → «Проанализируй 5–7 конкурентов по критериям: ...»

● Подготовка структуры → «Сформируй структуру документа из 5 разделов»

● Написание ТЗ → «Сформируй техническое задание по шаблону BABOK»

Копируйте формулировку, меняйте только переменные. Это сокращает время на составление промпта и гарантирует, что вы используете глаголы силы, а не размытые просьбы.

1.4. Ф (Формат): Предсказуемый результат вместо лотереи

Почему один и тот же запрос в понедельник выдаёт аккуратный список, а во вторник - нечитаемую простыню текста? Модель не сошла с ума. Она просто не знает, в каком виде вам нужен ответ.

Формат - это упаковка результата. Это инструкция по сборке артефакта. Без неё ИИ выберет формат по умолчанию (обычно это сплошной текст или маркированный список), который вам, скорее всего, не подойдёт для дальнейшей работы.

Без формата:

«Проанализируй риски проекта создания ИИ-ассистента».

Что получает ИИ: Свободу творчества. Модель напишет красивый текст: «Во-первых, существуют технические риски... Во-вторых, рыночные риски...». Без формата вы получаете то же, что получил бы Максим, если бы не задал структуру таблицы: красивую простыню текста, которую невозможно использовать. Придётся вручную вычленять суть и переносить её в нужный документ.

С форматом:

ФОРМАТ:

Представь результат в виде таблицы со следующими колонками:

1. Категория риска

2. Описание риска

3. Вероятность (низкая/средняя/высокая)

4. Влияние на бюджет и сроки

5. План митигации

Что получает ИИ: Жёсткие рамки. С форматом модель выдаёт готовый артефакт для совета директоров. Она не будет писать вводные слова или философские рассуждения. Она заполнит каждую ячейку таблицы конкретными данными, строго по заданным колонкам.

Шаблон формата

ФОРМАТ:

Представь результат в виде [тип документа или структура]

со следующими обязательными элементами: [перечисление частей].

Тип документа или структура. Это физическая форма ответа. Не абстрактное «оформи красиво», а конкретный технический или деловой формат:

● Таблица

● Маркированный или нумерованный список

● CSV-файл с разделителем «;» (для импорта в Яндекс.Трекер или Kaiten)

● JSON (для интеграции с другими системами)

● Код диаграммы Mermaid (для визуализации процессов)

● Структура документа с заголовками H2 и H3

Обязательные элементы. Это содержимое формата. Недостаточно просто сказать «сделай таблицу». Нужно указать, какие именно колонки или поля в ней должны быть. Это лишает модель возможности импровизировать там, где нужна строгость.

Пример: не «сделай список задач», а «нумерованный список, где каждый пункт содержит: название задачи, ответственного и дедлайн».

Правила использования

● Задавайте формат явно. Никогда не надейтесь на «здравый смысл» модели. То, что кажется вам очевидным, для ИИ - лишь один из миллионов вариантов.

● Описывайте структуру, а не только название формата. Фраза «сделай таблицу» слишком размыта. Фраза «таблица с колонками: Фаза, Срок, Ответственный, Статус» - это спецификация.

● Используйте технические форматы для автоматизации. Если результат нужно куда-то перенести, просите сразу подходящий формат. Нужен импорт в таск-трекер? Просите CSV. Нужна схема для Confluence? Просите код Mermaid. Это экономит часы ручной переработки.

● Для сложных документов задавайте заголовки разделов заранее. Если вам нужен многостраничный отчёт, не пишите «напиши отчёт». Напишите: «Подготовь документ со следующей структурой: 1. Резюме для руководства. 2. Анализ текущего состояния. 3. Детальный план работ. 4. Бюджет».

● Запрещайте лишнее. Если формат должен быть строгим, добавьте в требования: «Не пиши вводных слов, приветствий или заключительных выводов. Выдай только запрошенный формат».

Практическое правило

Формат - это не дополнение, а часть спецификации. Если вы не задали формат, вы играете в лотерею. Всегда проверяйте промпт: есть ли в нём чёткая инструкция о том, как должен выглядеть финальный артефакт.

Шпаргалка

Базовый набор, который закрывает большенство потребностей:

● Для анализа рисков: «Представь результат в виде таблицы с колонками: Риск, Вероятность (1-5), Влияние (1-5), Митигация».

● Для импорта в трекер: «Выдай результат в формате CSV с разделителем ";". Колонки: ID, Задача, Оценка (чел/дни), Зависимости».

● Для визуализации процесса: «Сформируй блок-схему процесса в формате кода Mermaid (graph TD)».

● Для структурирования документа: «Подготовь оглавление документа с заголовками H2 и H3, кратко раскрыв суть каждого раздела в одном предложении».

● Для чистых данных: «Выдай только JSON-объект по следующей схеме: {...}. Не добавляй поясняющий текст до или после JSON».

Копируйте нужный сниппет и подставляйте свои переменные. Это гарантирует, что вы всегда получите результат, готовый к использованию, а не сырой текст для редактирования.

1.5. Т (Требования и Табу): Жесткие рамки вместо свободы творчества

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

Требования и Табу - это ограждения на краю обрыва. Требования говорят модели, что она *обязана* сделать. Табу говорят, чего ей *категорически нельзя* делать. Без этих блоков ИИ по умолчанию стремится быть «креативным» и «полезным», что в бизнес-задачах часто оборачивается галлюцинациями и раздутыми сметами.

Без требований и табу:

«Составь план внедрения ИИ-ассистента».

Что получает ИИ: Полную свободу. Модель добавит «вводные слова о важности инноваций», предложит нанять команду из 20 человек и заложит бюджет, который не пройдет ни один финансовый директор.

С требованиями и табу:

ТРЕБОВАНИЯ:

- Учти буфер на риски не менее 15% в каждой фазе.

- Включи этап валидации гипотезы спроса (CustDev).

ТАБУ:

- Запрещено предлагать покупку новых лицензий без обоснования ROI.

- Запрещено использовать термины «быстро» и «легко» без цифр.

- Запрещено предлагать обучение собственных LLM-моделей (только API).

Что получает ИИ: Четкие границы. Эти табу спасли оценку Максима от раздувания бюджета: запрет на обучение собственных моделей и требование использовать только API-интеграцию сразу отсекли нереалистичные и дорогие варианты, которые нейросеть могла бы предложить по умолчанию.

Шаблон требований и табу

ТРЕБОВАНИЯ:

- [Обязательное условие 1]

- [Обязательное условие 2]

ТАБУ:

- Запрещено [конкретное действие или результат 1]

- Запрещено [конкретное действие или результат 2]

Требования. Это обязательные условия, которые должны быть выполнены в результате. Они сужают поле для маневра, но направляют модель в нужное русло.

Примеры: «Используй метод трех точек», «Добавь колонку "Ответственный"», «Опирайся только на данные из приложенного текста».

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

Примеры: «Не добавляй факты, которых нет в контексте», «Не пиши вводных приветствий», «Не предлагай решения на Java, если в контексте указан Python».

Правила использования

● Формулируйте табу через запрет. Используйте слова «Запрещено», «Не делай», «Исключи». Это работает лучше, чем мягкие просьбы «Постарайся не делать».

● Делайте требования измеримыми. Не «сделай кратко», а «не более 300 слов». Не «учти риски», а «добавь буфер 15% к срокам». Измеримость не оставляет модели пространства для интерпретации.

● Конкретизируйте табу. Запрет «не выдумывай» не работает, модель не понимает, что это значит. Замените его на: «Используй только факты, указанные в блоке "Контекст". Если данных нет, напиши "Нет данных"».

● Не перегружайте списки. Оптимальный размер: 3–5 требований и 3–5 табу. Если правил больше десяти, модель начинает «забывать» часть из них или противоречить сама себе.

● Проверяйте табу на конфликт с требованиями. Нельзя написать в требованиях «Сделай подробный отчет на 10 страниц», а в табу «Не пиши больше 300 слов». Модель либо проигнорирует одно из правил, либо выдаст ошибку.

Практическое правило

Требования задают вектор, Табу ставят стены. Используйте оба блока вместе. Если вы дали только требования, модель найдет самый странный способ их выполнить. Если дали только табу, она найдет другую лазейку. Только вместе они создают предсказуемый результат.

Шпаргалка

Вот проверенные варианты, которые отсекают большинство типичных проблем:

● Против галлюцинаций: «Используй только факты из предоставленного контекста. Если информации недостаточно, явно укажи: "Нет данных"».

● Против воды: «Не пиши вводных фраз, приветствий, заключительных выводов или общих рассуждений о важности темы. Выдай только запрошенные данные».

● Против раздувания бюджета: «Запрещено предлагать закупку нового ПО или оборудования без прямого обоснования ROI и отсутствия аналогов в текущем стеке».

● Против размытых сроков: «Запрещено использовать слова "быстро", "оптимально", "в ближайшее время". Используй только конкретные сроки в днях или неделях».

● Для сохранения формата: «Запрещено добавлять поясняющий текст до или после запрошенного формата (таблицы, JSON, кода)».

Копируйте нужные пункты в свой промпт. Это превращает модель из «творческого помощника» в строгого исполнителя вашей воли.

1.6. + (Рефлексия): Когда модель умнее, чем вы думаете

Представьте, что вы нанимаете подрядчика на ремонт квартиры. Вы даёте ему подробное техническое задание: цвета, материалы, сроки. Он кивает, уходит работать - и через неделю возвращает результат, который технически безупречен, но бесполезен. Потому что вы забыли сказать, что у вас кот, который дерёт обои. А подрядчик не спросил.

Это именно то, что происходит с ИИ без рефлексии. Модель выполняет запрос буквально, но не думает о том, чего вы не сказали. Она не задаёт вопросов, даже если видит пробелы в контексте.

Рефлексия - это разрешение модели остановиться и подумать *перед* тем, как генерировать ответ. Это блок, который говорит: «Если тебе чего-то не хватает для качественного результата - спроси».

Без рефлексии:

ЗАДАЧА:

Проведи первичную оценку сроков и бюджета проекта

создания ИИ-ассистента.

Что получает ИИ: Команду выполнить задачу с тем, что есть. Даже если контекст неполный (не указан бюджет, не указаны технологии, не указан срок), модель всё равно выдаст оценку. Она заполнит пробелы догадками - и эти догадки почти всегда будут стоить вам часов переделок.

С рефлексией:

ПЕРЕД ГЕНЕРАЦИЕЙ:

Прежде чем отвечать, проанализируй запрос. Если не хватает

критически важных данных, задай мне до 3 уточняющих вопросов

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

мог упустить в контексте. Если всё понятно - приступай к

генерации оценки.

Что получает ИИ: Разрешение остановиться и подумать. Модель проанализирует контекст, выявит пробелы и задаст вопросы: «Какой бюджет?», «Какие технологии?», «Есть ли compliance-требования?». Вы отвечаете - и только потом модель генерирует результат. Но теперь он будет реалистичным, а не выдуманным.

Шаблон рефлексии

ПЕРЕД ГЕНЕРАЦИЕЙ:

Прежде чем отвечать, проанализируй запрос. Если не хватает

критически важных данных, задай мне до [N] уточняющих вопросов

о [что уточнять]. Если всё понятно - приступай к генерации.

Разрешение спросить. Это ключевой элемент. Модель по умолчанию не задаёт вопросов - она генерирует о твет сразу. Фраза «Если не хватает данных - задай вопросы» даёт модели разрешение остановиться и подумать.

Лимит вопросов. Указывайте конкретное число: «до 3 вопросов», «до 5 вопросов». Без лимита модель может задать десять вопросов, и диалог превратится в допрос.

Что уточнять. Задайте направление: «о скрытых рисках», «о зависимостях», «о compliance-требованиях». Это сужает поле для вопросов и делает их релевантными.

Правила использования

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

● Указывайте лимит вопросов. Не «задай вопросы», а «задай до 3 уточняющих вопросов». Это предотвращает бесконечный диалог.

● Задавайте направление для вопросов. Не «спроси, что нужно», а «спроси о скрытых рисках и зависимостях». Это делает вопросы релевантными.

● Разрешайте модели не спрашивать. Добавьте фразу: «Если всё понятно - приступай к генерации». Это предотвращает ситуации, когда модель задаёт вопросы ради вопросов.

● Отвечайте на вопросы модели сразу.** Если модель задала уточняющие вопросы, не игнорируйте их. Ответьте - и только потом просите генерировать результат.

Практическое правило

Рефлексия - это разрешение модели думать перед действием.** Используйте её для сложных задач, где контекст может быть неполным. Для простых задач рефлексия избыточна.

Шпаргалка

Готовые формулировки рефлексии под типовые задачи:

● Для оценки проекта: «Прежде чем отвечать, проанализируй запрос. Если не хватает критически важных данных, задай мне до 3 уточняющих вопросов о скрытых рисках, зависимостях или ограничениях. Если всё понятно - приступай к генерации».

● Для анализа рисков: «Перед генерацией проверь, есть ли в контексте информация о текущем состоянии проекта, команде и технологиях. Если нет - задай до 2 уточняющих вопросов».

● Для стратегического планирования: «Прежде чем предлагать решение, уточни: какие ограничения по бюджету и срокам? Какие compliance-требования? Какая аудитория результата? Задай до 3 вопросов».

● Для технических задач: «Перед генерацией проверь, указан ли стек технологий, версия языка, требования к производительности. Если нет - задай до 2 уточняющих вопросов».

● Универсальная: «Если в запросе есть неоднозначности или пробелы, которые критичны для качества результата, задай до 3 уточняющих вопросов. Если всё ясно - генерируй сразу».

Копируйте формулировку и подставляйте свои переменные. Это превращает модель из слепого исполнителя в думающего партнёра, который не боится задать вопрос.

1.7. Сборка промпта: От элементов к системе

Пришло время собрать элементы в единый механизм. Сам по себе блок «Контекст» или «Роль» не гарантирует результат. Магия начинается тогда, когда все шесть элементов работают вместе.

Порядок блоков в методе КРАФТ+ не случаен. Он выстроен так, чтобы постепенно сужать пространство для догадок модели, превращая её из творческого генератора текста в точного исполнителя вашей воли.

Логика проста и уже зашита в названии метода. Сначала мы задаем «песочницу» через Контекст. Без фактов реальности модель не знает, о чем вообще речь. Затем назначаем эксперта через Роль. Теперь модель знает, как думать и какую методологию применять. После этого даем команду через Активное действие. Модель понимает, что именно нужно сделать с данными из контекста, используя экспертизу роли.

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

Вот такой промпт собрал Максим для оценки новой идеи после получения задачи от спонсора.

КОНТЕКСТ:

Бизнес-цель: Создать ИИ-ассистент для первичной оценки проектов,

который по описанию идеи автоматически генерирует сроки, бюджет

и риски, чтобы сократить время принятия решений с двух недель

до одного дня

Текущее состояние: Есть команда разработки (5 человек), технологии

(Python, PostgreSQL, API-интеграция с LLM), но нет опыта в этом

сегменте и нет готового продукта

Ограничения:

- Бюджет: 5 млн руб.

- Срок: Q3 2026

- Технологии: Python, PostgreSQL, API-интеграция с LLM

(без обучения собственных моделей)

- Compliance: требования к защите персональных данных (152-ФЗ)

Аудитория: Совет директоров, требует четкого обоснования инвестиций

РОЛЬ:

Действуй как Senior Product Manager с десятилетним опытом запуска

новых B2B-продуктов в R&D-компаниях. Используй метод трёх точек

для оценки сроков (оптимистичная, пессимистичная, наиболее вероятная).

ЗАДАЧА:

Проведи первичную оценку сроков и бюджета проекта.

ФОРМАТ:

Представь результат в виде таблицы со столбцами: Фаза, Ключевые

задачи, Оценка трудозатрат (чел/дни), Оценка бюджета (руб.),

Критические риски. После таблицы добавь краткое резюме.

ТРЕБОВАНИЯ:

- Учесть буфер на риски в каждом этапе (не менее 15%)

- Включить фазу валидации гипотезы спроса (CustDev)

- Использовать метод трех точек для оценки сроков

ТАБУ:

- Запрещено предлагать покупку новых лицензий без обоснования ROI

- Запрещено игнорировать этап анализа конкурентов

- Запрещено предлагать обучение собственных LLM-моделей (только API)

- Запрещено использовать термины «быстро» и «легко» без цифр

ПЕРЕД ГЕНЕРАЦИЕЙ:

Прежде чем отвечать, проанализируй запрос. Если не хватает

критически важных данных, задай мне до 3 уточняющих вопросов.

Если всё понятно — приступай к генерации оценки.

Когда промпт собирается таким образом, он становится самодостаточным документом. Вы можете сохранить его в библиотеке шаблонов и использовать через месяц, передавать коллегам или адаптировать под другую задачу, просто меняя переменные в квадратных скобках.

КРАФТ+ работает как стартовый системный запрос. Вы загружаете его в начале диалога, и модель использует эти инструкции как базу для всех последующих ответов. Это похоже на установку скилла или загрузку контекста в рабочую память.

Но у рабочей памяти есть предел. В короткой беседе на десять-пятнадцать сообщений модель отлично держит все ваши табу и требования. В длинном диалоге на пятьдесят сообщений и больше внимание модели к начальным инструкциям размывается. Это известная проблема больших языковых моделей. Они лучше всего помнят начало и конец разговора, а середина, включая ваш исходный КРАФТ+, может потерять вес.

На практике это значит, что для сложных проектов нельзя использовать один промпт на весь жизненный цикл. Модель просто забудет часть ограничений к этапу исполнения. Поэтому в следующей главе мы будем использовать отдельный КРАФТ+ для каждой фазы проекта. А если вы ведете длинную сессию по одной задаче, периодически напоминайте модели ключевые табу или начинайте новый чат, скопировав туда исходный промпт.

Шпаргалка

Готовый шаблон для копирования:

КОНТЕКСТ:

Бизнес-цель: [...]

Текущее состояние: [...]

Ограничения:

- Бюджет: [...]

- Срок: [...]

- Технологии: [...]

- Compliance: [...]

Аудитория: [...]

РОЛЬ:

Действуй как [должность] с [seniority] и [экспертиза].

Используй [методология].

ЗАДАЧА:

[Глагол силы] + [что сделать].

ФОРМАТ:

Представь результат в виде [тип документа] со следующими

элементами: [...].

ТРЕБОВАНИЯ:

- [Обязательное условие 1]

- [Обязательное условие 2]

ТАБУ:

- Запрещено [конкретное действие 1]

- Запрещено [конкретное действие 2]

ПЕРЕД ГЕНЕРАЦИЕЙ:

Прежде чем отвечать, проанализируй запрос. Если не хватает

критически важных данных, задай мне до [N] уточняющих вопросов.

Если всё понятно — приступай к генерации.

Этот шаблон закрывает 95% задач по поддержке принятия решений. Остальные 5% — это сложные кейсы, где требуется цепочка промптов или тонкая настройка параметров модели, о чем мы поговорим в Главе 3 .

1.8. Ограничения и анти-паттерны: Когда метод не работает

КРАФТ+ — инструмент промпт-менеджмента. Его цель — поддержка принятия решений. Он превращает хаос идей в структурированные данные: оценки, планы, матрицы рисков.

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

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

Нужно придумать 50 слоганов или написать поздравление? Жесткие табу задушат модель. Творчество требует свободы. КРАФТ+ создан для дисциплины. Подход работает там, где есть четкое видение результата и нужен исполнитель, а не соавтор-визионер.

Хотите «поболтать» с ИИ или узнать общий факт? Блоки бюджета и compliance будут лишними. КРАФТ+ нужен там, где цена ошибки высока и результат влияет на ресурсы компании.

Даже при правильной сборке результат может быть плохим. Проблема почти всегда в одном из шести блоков.

Вы просили задать вопросы, а модель сразу выдала ответ. Инструкция в блоке «Перед генерацией» недостаточно жесткая. Усильте её: «ОБЯЗАТЕЛЬНО задай вопросы ПЕРЕД генерацией». Или смените модель. Некоторые архитектуры хуже следуют инструкциям на остановку. Но перед добавлением «Обязательно» проверьте результат генерации, может он верный и модели просто не потребовалась дополнительная информация (рефлексия не всегда востребована).

Модель предложила технически возможное, но финансово нереальное решение. В блоке «Контекст» не указаны жесткие ограничения. Добавьте бюджет и срок отдельными пунктами. Модель не знает, что такое «дорого» для вашей компании, пока вы не укажете цифру.

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

В одном чате таблица, в другом — список. Блок «Формат» слишком размыт. Не пишите «сделай таблицу». Пишите: «таблица со столбцами: Фаза, Срок, Ответственный». Конкретика убирает свободу интерпретации.

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

Вы просите «подробный отчет на 10 страниц» и запрещаете «писать больше 300 слов». Модель либо проигнорирует одно из правил, либо выдаст ошибку. Перед отправкой проверяйте блоки на противоречия.

Вы объединили несколько задач в один промпт и получили поверхностный результат по каждой. Модель распыляет внимание между задачами. WBS получается укрупнённой, истории размытыми, проверка формальной. Разбейте на отдельные промпты: один на задачу. Каждый промпт проверяйте отдельно. Это даёт точки контроля и возможность корректировки без переделки всего. Подробный пример в разделе 2.2.

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

Шпаргалка

Готовые формулировки для исправления типичных сбоев:

Против игнорирования Рефлексии: «ОБЯЗАТЕЛЬНО задай до 3 уточняющих вопросов ПЕРЕД генерацией. Не начинай ответ без моих подтверждений».

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

Против галлюцинаций: «Используй только факты из блока "Контекст". Если данных нет, явно укажи: "Нет данных"».

Против размытого формата: «Представь результат СТРОГО в виде таблицы со следующими колонками: [перечисление]. Никакого текста до или после таблицы».

Против выхода за бюджет: «Запрещено предлагать решения, превышающие бюджет [X руб.]. Если оценка превышает лимит, предложи варианты сокращения без нарушения требований».

Против объединения задач: «Каждую задачу выполняй отдельным запросом. Не объединяй WBS, формулирование историй и проверку INVEST в один промпт».

Эти формулировки — «аптечка первой помощи» для промптов. Держите их под рукой вместе с основным шаблоном.

1.9. КРАФТ+ как операционная система для ИИ

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

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

С моделью то же самое. Вы загружаете КРАФТ+ в начале сессии. Модель запоминает контекст, роль, формат, требования и табу. Дальше вы только переключаете задачи. Не нужно каждый раз заново объяснять, кто вы, что за проект и какие ограничения.

Внутри этой операционной системы работают приложения. Два типа.

Техники промптинга меняют то, как модель думает. Цепочка рассуждений заставляет рассуждать по шагам. Дерево мыслей просит рассмотреть несколько гипотез и выбрать лучшую. Примеры в запросе показывают формат через образцы. Подробно разберём их в Главе 3.