(ДУМАТЬ КАК ИНЖЕНЕР, А НЕ КАК ПОЛЬЗОВАТЕЛЬ ЧАТА)
Зачем вообще лог промтов
Без лога вы каждый раз:
заново изобретаете те же промты;
повторяете одни и те же ошибки;
не можете показать прогресс и результаты (ни себе, ни заказчику).
С логом вы:
видите, какие изменения в промте реально улучшили ответ;
можете “откатиться” к рабочей версии;
формируете базу кейсов и промт‑паттернов.
Думайте об этом как о мини‑лаборатории: гипотеза → эксперимент → результат → фиксация.
Базовая структура лога
Хранить можно:
в Markdown‑файле;
в Notion;
в Google Docs;
в SQLite/JSON, если любишь автоматизацию.
Рекомендуемая структура записи:
date – дата и время;
task – человеческое описание задачи (на языке бизнеса);
prompt_version – v1, v2, v3…;
prompt_text – сам промт;
input_example – пример входных данных;
result_quality – ok / fail / partial;
issues – где модель накосячила;
changes – что именно ты изменил в промте;
notes / next_steps – выводы, идеи для следующей итерации.
Шаблон в Markdown:
## [Дата] [Краткое название задачи]
**date:** 2026-01-02
**task:** Еженедельный отчёт по продажам из агрегированных данных
### v1
**prompt_version:** v1
**prompt_text:**
```text
[сюда сырой промт]
input_example:
[сюда пример входных данных]
result_quality: fail / partial / ok
issues:
Пункт 1
Пункт 2
changes_for_next_version:
Изменение 1
Изменение 2
v2
… и т.д.
Можно сделать тот же формат в JSON, если хотите потом анализировать программно.
Пример: 2–3 итерации на реальном кейсе
Возьмём задачу: “Еженедельный отчёт по продажам”
(как в предыдущих кейсах).
Итерация 1 – сырой промт
**date:** 2026-01-02
**task:** Автоматизировать черновик еженедельного отчёта по продажам для руководителя
**prompt_version:** v1
**prompt_text:**
```text
Посмотрите на эти данные по продажам и сделай отчёт.
Период: 2024-11-25 – 2024-12-01
Выручка: 12 500 000 ₽
Заказы: 3 200
Средний чек: 3 900 ₽
Прошлая неделя:
Выручка: 11 000 000 ₽
Заказы: 3 000
Средний чек: 3 666 ₽
План на текущую неделю по выручке: 12 000 000 ₽
Сделай краткий отчёт для руководителя.
input_example:
Те же данные, что в промте.
result_quality: partial
Что не так (issues):
Нет структуры: один длинный текст.
Нет явных % изменений (приходится считать самому).
Много воды: “компания демонстрирует хорошую динамику…”.
Есть домыслы (“эффективные маркетинговые активности”), которых нет в данных.
Нельзя автоматически распарсить и использовать в других системах.
changes_for_next_version:
Явно задать роль: “ты – аналитик”.
Попросить сначала посчитать изменения, а потом сформулировать текст.
Запросить конкретный формат (JSON).
Запретить выдумывать данные и делать лишние предположения.
Итерация 2 – усилили инструкции и формат
prompt_version: v2
prompt_text:
Ты – продуктовый аналитик, который готовит еженедельные отчёты для руководителя отдела продаж. Пиши без воды, конкретно, опираясь только на данные, которые я даю.
Контекст:
Мы делаем еженедельный отчёт по продажам. Важно:
– чётко показать факты (цифры и динамику),
– разделить выводы, основанные на данных, и гипотезы,
– предложить максимально конкретные действия.
Данные:
Период отчёта: 2024-11-25 – 2024-12-01
Текущая неделя:
– Выручка: 12_500_000 ₽
– Заказы: 3_200
– Средний чек: 3_900 ₽
Прошлая неделя:
– Выручка: 11_000_000 ₽
– Заказы: 3_000
– Средний чек: 3_666 ₽
План на текущую неделю:
– Плановая выручка: 12_000_000 ₽
Задача:
1. Посчитать:
– изменение выручки, заказов и среднего чека в % относительно прошлой недели;
– выполнение плана по выручке в %.
2. Сформировать краткий текстовый отчёт для руководителя:
– блок "Итоги недели" (3–5 предложений, только факты),
– блок "Интерпретация" (что это может значить, пометь как гипотезы),
– блок "Рекомендации на следующую неделю" (3–5 конкретных действий).
Важно:
– Явно помечай, что является "фактами" и что – "гипотезами".
– Не придумывай данные, которых нет.
– Не упоминай "маркетинговые активности", если я о них не говорил.
Формат ответа:
Верни JSON:
{
"metrics_comparison": {
"revenue_change_percent": 0,
"orders_change_percent": 0,
"avg_check_change_percent": 0,
"plan_achievement_percent": 0
},
"report_text": {
"summary": "Итоги недели (факты, 3–5 предложений)",
"interpretation": [
"Гипотеза 1",
"Гипотеза 2"
],
"recommendations": [
"Рекомендация 1",
"Рекомендация 2",
"Рекомендация 3"
]
}
}
Ответь строго валидным JSON, без текста вне объекта.
input_example:
Те же данные.
result_quality: partial → ближе к ok, но ещё есть проблемы
issues:
В ~20% запросов модель:
добавляет посторонний текст до/после JSON (ломает парсинг);
иногда округляет проценты странно (например, 13.63636 → 13.6 без нужды);
в interpretation иногда всё равно притягивает маркетинг, даже если его нет в данных.
changes_for_next_version:
Ещё жёстче зафиксировать требования по JSON (строго, без форматирования вокруг).
Ограничить интерпретации: “связывай только с метриками, не с каналами”.
Явно указать, как округлять (например, до 2 знаков).
Добавить фразу “если не можешь обосновать гипотезу из динамики метрик – не пиши её”.
Итерация 3 – доводим до “продовой” версии
prompt_version: v3
prompt_text (фрагмент изменений):
…
Задача:
1. Посчитать:
– изменение выручки, заказов и среднего чека в % относительно прошлой недели (округляй до 2 знаков после запятой),
– выполнение плана по выручке в % (до 2 знаков после запятой).
2. Сформировать краткий текстовый отчёт…
Ограничения:
– В блоке "Интерпретация" опирайся только на динамику метрик (рост/падение, соотношения).
– Не упоминай маркетинговые каналы, промоакции, сезонность и другие факторы, если я явно их не укажу.
Формат ответа:
Ответь строго валидным JSON **без текста до или после JSON-объекта**. Не добавляй никаких комментариев.
…
result_quality: ok
Что улучшилось:
JSON теперь почти всегда валидный и без префиксного/суффиксного текста – легче парсить.
Проценты стабильно округлены до 2 знаков.
Интерпретации стали скромнее, меньше галлюцинаций.
Рекомендации более связаны с изменениями метрик (а не абстрактный “усиливайте маркетинг”).
Оставшиеся моменты:
Иногда формулировки рекомендаций слишком общие → можно добавить чек‑лист/паттерн рекомендаций в отдельном промте.
В некоторых кейсах (маленькие изменения метрик) модель всё равно пытается “натянуть” смысл → можно добавить условие: “если изменения < 3%, пиши, что динамика несущественная”.
next_steps:
Вынести этот промт в отдельный файл 30_automation/weekly_sales_report.md.
Сделать Python‑обёртку и сохранять ответы вместе с логом промтов (дата/версия/результат).
Как логировать эксперименты в коде (кратко)
Если вы уже на Этапе 4 (интеграция с кодом), лог стоит вести не только руками, но и автоматически.
Простейшая схема на Python:
import json
import time
from pathlib import Path
LOG_DIR = Path("prompt_logs")
LOG_DIR.mkdir(exist_ok=True)
def log_experiment(task_name: str, prompt_version: str,
prompt_text: str, input_example: dict | str,
raw_response: str, result_quality: str,
issues: list[str], changes: list[str]) -> None:
ts = time.strftime("%Y-%m-%d_%H-%M-%S")
log_entry = {
"timestamp": ts,
"task": task_name,
"prompt_version": prompt_version,
"prompt_text": prompt_text,
"input_example": input_example,
"raw_response": raw_response,
"result_quality": result_quality,
"issues": issues,
"changes_for_next_version": changes
}
filename = LOG_DIR / f"{task_name}_{prompt_version}_{ts}.json"
filename.write_text(json.dumps(log_entry, ensure_ascii=False, indent=2))
Это уже даёт:
историю версий промтов по задачам;
возможность потом:
искать по задачам/датам;
анализировать, какие изменения обычно дают лучший прирост качества (например, добавление формата, явных ограничений, ролей).
Как использовать журнал экспериментов в своём развитии
Раз в неделю просматривай лог:
выберите 2–3 кейса, где был большой скачок качества между v1 и v2/v3;
зафиксируйте какие именно паттерны сработали (формат, роль, декомпозиция).
Начните оформлять из этого кейсы в портфолио:
до/после,
экономия времени,
снижение ошибок,
повышение предсказуемости.
Для повторяющихся задач:
как только видите, что промт “устаканился” (последние 2–3 итерации дают ок‑результат),
выносите его из лога в библиотеку (prompts/…), помечайте как “v1.0 stable”.
Так вы реально начинаете думать, как инженер: “сформулировал гипотезу → протестировал → задокументировал → стабилизировал → переиспользовал”.