Это обзорная страница Anthropic про промпт-инжиниринг — искусство формулировать запрос так, чтобы модель понимала, что вы хотите. Сама оригинальная статья короткая: она объясняет, когда вообще имеет смысл этим заниматься, и даёт ссылки на более подробные материалы. Здесь — та же структура, но с поправкой на ваш случай: вы не пишете код, который вызывает модель из бэкенда; вы работаете с Claude Code Desktop как с напарником, который читает и правит ваш Kotlin/Ktor проект. Поэтому из всего набора техник вам нужен довольно скромный базовый минимум — но он реально влияет на то, насколько Claude попадает в ваши задачи с первого раза.
Anthropic в оригинале формулирует так: «This guide assumes that you have: 1. A clear definition of the success criteria for your use case; 2. Some ways to empirically test against those criteria; 3. A first draft prompt you want to improve». То есть руководство предполагает, что у вас уже есть:
Для вашего рабочего процесса это переводится так. «Критерий успеха» —
это не абстрактная метрика, а конкретный ответ на вопрос «как я
пойму, что Claude сделал то, что я просил». Например: тест
JwtFilterTest зелёный; в OrderRepository
появился новый метод с правильной сигнатурой; markupMaterialsPct
теперь учитывается в расчёте. «Способ проверить» — это
./gradlew test, запуск приложения, ручная проверка
в браузере. «Первый черновик промпта» — то, что вы напишете
Claude'у в чате, прежде чем начать его уточнять.
Если этого нет — Anthropic советует сначала
разобраться с критериями успеха и оценками (eval'ами). У вас
«оценка» гораздо проще, чем у тех, кто строит продакшн-сервис на
модели: ваши тесты в IntegrationTestBase и есть ваш
основной способ проверить, что Claude не сломал систему.
Anthropic делает важную оговорку: «Not every success criteria or failing eval is best solved by prompt engineering. For example, latency and cost can be sometimes more easily improved by selecting a different model». То есть не каждую проблему стоит решать через формулировку промпта. Иногда проще сменить модель.
В вашем контексте это звучит так. Если Claude не справляется с
большим рефакторингом OrderService — иногда дело не в
промпте, а в том, что вы запустили Sonnet на low-усилии вместо Opus
на high. Если ответы стали медленными — возможно, в контексте уже
300 тысяч токенов, и проще начать новую сессию, чем переписывать
запрос. Промпт-инжиниринг — это инструмент, а не молоток для всех
гвоздей.
Anthropic держит все техники в одной живой странице — Prompting best practices: ясность формулировок, примеры (few-shot), структурирование через XML-теги, role prompting (когда модели говорят «ты — опытный архитектор Kotlin»), thinking (chain-of-thought, цепочка рассуждений) и prompt chaining (разбиение задачи на цепочку промптов). Это не отдельные приёмы из разных школ — это один набор, и осваивать его лучше постепенно, по мере того как сталкиваетесь с проблемами.
В нашем треке мы пройдём этот же набор, но не весь сразу: начнём с самых дешёвых и надёжных приёмов (чёткость, прямота, примеры) и дойдём до более тонких (chain-of-thought, разбиение на этапы). Каждая следующая статья — один приём с примерами на вашем коде.
Anthropic ссылается на два интерактивных туториала: один на GitHub'е (prompt-eng-interactive-tutorial), другой в виде Google-таблицы. Оба построены вокруг работы через API — то есть предполагают, что вы пишете код, который вызывает модель. Для вашего случая (работа в Claude Code Desktop) они скорее избыточны; полезнее сразу читать дальнейшие статьи этого трека и пробовать приёмы прямо в своих сессиях с Claude Code.
Если всё-таки хочется посмотреть оригинальные туториалы — ссылки выше открываются без входа в аккаунт.
Следующая статья — про базовый и самый важный приём: писать модели чётко и прямо. Это не «искусство красивых формулировок», а привычка не оставлять Claude'у пространства для домысливания.