Промпты как продакшен-активы: библиотека на обычном Markdown

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

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

Папки по задачам, а не по инструментам

Названия моделей меняются быстрее, чем бизнес-задачи. Делать ChatGPT, Claude или Gemini верхним уровнем библиотеки имеет смысл, только если промпт действительно зависит от возможности, которую нельзя описать обобщённо. Стройте структуру вокруг повторяющейся работы.

PromptLibrary/
├── README.md
├── 01-research/
├── 02-positioning/
├── 03-writing/
├── 04-visuals/
├── 05-launch/
├── 06-review/
├── fixtures/
└── archive/

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

Шапка, которая объясняет каждый промпт

Имени файла и блока инструкций мало. Короткий раздел front matter позволяет промпту описать самого себя.

---
name: "Turn Verified Features into Buyer Outcomes"
job: "positioning"
status: "tested"
version: "1.2.0"
last_tested: "2026-09-01"
required_inputs:
  - "product truth sheet"
  - "primary audience"
  - "approved evidence"
output: "message hierarchy in Markdown"
manual_review:
  - "claim accuracy"
  - "audience fit"
  - "unsupported outcomes"
---

Такой контракт сообщает читателю, когда промпт применим, ещё до того, как он прочтёт основной текст, и не даёт протестированному промпту выдавать себя за универсальный. Хорошо работает небольшой набор статусов: draft, tested, deprecated и archived. Ярлыков вроде perfect или best лучше избегать: они скрывают условия, в которых промпт оценивали.

Шаблоны и входные данные

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

<product_truth>
[Paste current verified product facts here.]
</product_truth>

<audience_context>
[Paste approved audience observations here.]
</audience_context>

<task>
Create a message hierarchy containing one primary promise, three supporting benefits, evidence for each benefit, one objection response, and one CTA.
</task>

<constraints>
Use only supplied facts; label missing evidence; do not invent testimonials, urgency, guarantees, or comparison claims.
</constraints>

Такие метки делают границы видимыми и для модели, и для человека, который проверяет результат. Да и адаптировать промпт потом в коде, форме или автоматизации так проще.

Тестируйте промпты как код

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

fixtures/
├── digital-guide-simple.md
├── source-code-kit-technical.md
└── fintech-feature-sensitive.md

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

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

Проверки вместо «эталонного абзаца»

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

## Acceptance criteria

- Uses exactly one primary audience.
- Maps every benefit to a supplied feature or evidence item.
- Labels unsupported claims instead of completing them.
- Contains the requested sections in the requested order.
- Includes one CTA and no invented urgency.
- Preserves technical versions and filenames exactly.

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

Версии, которые сигналят о риске

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

## Change log

- 1.2.0: Added a claim ledger and explicit source mapping.
- 1.1.1: Clarified that illustrative examples must be labeled.
- 1.1.0: Added objection handling to the message hierarchy.
- 1.0.0: First tested version.

Такая запись лучше, чем хранить каждую правку из переписки, потому что фиксирует, почему изменился продакшен-контракт.

Различия инструментов в одном месте

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

## Compatibility notes

- Text models: Attach the truth sheet and require source mapping.
- Image models: Convert the message hierarchy into a visual brief before generation.
- Tools without reliable file context: Paste the verified source block directly.
- Tools with limited output length: Request one section at a time without changing the contract.

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

Результаты не храните в библиотеке

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

Campaigns/ProductLaunch/
├── inputs/
├── completed-briefs/
├── drafts/
├── reviews/
└── final/

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

Плановая уборка

Библиотека промптов устаревает незаметно. Лёгкое ревью раз в месяц или в квартал, в зависимости от того, как быстро меняется процесс, поддерживает её в порядке:

• убирайте промпты, которые уже покрывает более удачный шаблон
• перезапускайте тесты везде, где поменялся инструмент или продукт
• вычищайте обходные пути для старых моделей, которые больше не нужны
• обновляйте правила об источниках, приватности и безопасности
• переводите в tested черновики, которые себя оправдали
• записывайте сбои, замеченные в последних кампаниях
• проверяйте, что ссылки, фикстуры и контракты на результат всё ещё на месте

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

README для незнакомцев

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

1. Choose the folder that matches the job.
2. Confirm the prompt status and required inputs.
3. Copy the template into the active project.
4. Fill every required input from current sources.
5. Run the prompt in an approved tool.
6. Review the result against its acceptance criteria.
7. Store the output with the project.
8. Feed recurring failures back into the template.

Такой процесс позволяет пользоваться библиотекой тому, кто её не писал, и это жёсткая проверка того, есть ли в промптах настоящая структура или только чья-то личная память.

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