Перевод с разбором · для Вани

Цепочка промптов

О чём это

«Цепочка промптов» (по-английски — prompt chaining) — это приём, когда вы не пытаетесь решить задачу одним большим запросом, а дробите её на несколько последовательных шагов. Каждый шаг — отдельный промпт. Выходные данные одного шага становятся входом для следующего.

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

Что говорит Anthropic

В разделе «Chain complex prompts» документации Claude Anthropic пишет:

With adaptive thinking and subagent orchestration, Claude handles most multi-step reasoning internally. Explicit prompt chaining (breaking a task into sequential API calls) is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure.

The most common chaining pattern is self-correction: generate a draft → have Claude review it against criteria → have Claude refine based on the review.

По-русски: новые модели Claude умеют сами разбивать сложные задачи на шаги внутри (это называется «adaptive thinking» и «subagent orchestration»). Поэтому не каждый раз нужно вручную составлять цепочку. Но явная цепочка остаётся полезной в двух случаях:

• когда вам нужно посмотреть промежуточный результат — например, проверить план до того, как Claude начнёт писать код;
• когда вам нужна строгая структура процесса — сначала всегда план, потом всегда тесты, потом всегда коммит.

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

Когда дробить, когда не дробить

Дробите цепочкой, если:

• Задача задевает несколько слоёв сразу — например, новая фича в OrderService, миграция в БД и эндпоинт во фронте.
• Вы хотите проверить план до правок. Особенно когда меняется расчётная логика в OrderCalculationService или MaterialService.
• Вам нужно ревью своего же ответа — Claude хорошо ловит свои ошибки, если попросить отдельным шагом сверить результат с критериями.

Не дробите, если:

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

Пример самокоррекции

Самый универсальный паттерн — черновик → ревью → доработка. В Claude Code это удобно делать тремя сообщениями подряд в одном разговоре.

Шаг 1 — черновик:

Напиши первую версию метода recalculateOrder в OrderCalculationService.
Логика: пересчитать сумму заказа с учётом текущей наценки на материалы
из MaterialService. Не трогай OrderRepository, только сам расчёт.

Шаг 2 — ревью того же Claude по критериям:

Теперь сам проверь свой код по этим критериям:
1. Все ли граничные случаи покрыты (нулевая сумма, нет материалов, наценка 0)?
2. Нет ли скрытых обращений к БД внутри расчёта?
3. Совпадают ли имена с уже существующими в OrderService?
4. Нужны ли тесты в IntegrationTestBase, и если да — какие?

Выпиши проблемы списком. Не правь код пока.

Шаг 3 — доработка:

Хорошо, теперь поправь код по своему же списку. После каждой правки
коротко скажи, какой пункт ты закрыл.

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

Пример в вашем стеке: большая задача в Claude Code

Это ваш главный кейс. Допустим, нужно добавить новое поле в заказ («срок изготовления»), пробросить его через API, отобразить в React и учесть в расчётах. Соблазн — попросить Claude Code «сделай всё» одним сообщением. Так делать не надо.

Цепочка из четырёх шагов:

Шаг 1 — план.

Мне нужно добавить поле "срок изготовления" (deliveryDays, int) в заказ.
Прочти OrderService, OrderRepository, OrderCalculationService и
схему БД. Не пиши код. Дай план: какие файлы трогаем, в каком порядке,
какие миграции нужны, какие тесты в IntegrationTestBase придётся обновить.

Здесь вы останавливаетесь, читаете план, спорите. Если план плохой — не идите дальше, переформулируйте.

Шаг 2 — миграция и слой БД.

По плану из предыдущего сообщения сделай только пункт 1: миграция
схемы и изменения в OrderRepository. Не трогай OrderService и фронт.
После — покажи diff и поясни.

Шаг 3 — сервисный слой и расчёты.

Теперь пункт 2: проброс поля через OrderService и учёт в
OrderCalculationService. Тесты в IntegrationTestBase обнови параллельно.
Фронт пока не трогай.

Шаг 4 — фронт и финальная проверка.

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

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

Пара полезных приёмов от Anthropic

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

Минимальные изменения. Чтобы Claude не «улучшал» то, о чём вы не просили (новые модели любят это):

Claude Opus 4.5 and Claude Opus 4.6 have a tendency to overengineer by creating extra files, adding unnecessary abstractions, or building in flexibility that wasn't requested.

Промпт от Anthropic, который кладите в системную инструкцию или последний шаг цепочки:

Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused:

- Scope: Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.

- Documentation: Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.

- Defensive coding: Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs).

- Abstractions: Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task.

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

Не подгонять под тесты. Иногда Claude норовит написать решение, которое проходит конкретные тесты, а не решает задачу в общем виде:

Claude can sometimes focus too heavily on making tests pass at the expense of more general solutions, or may use workarounds like helper scripts for complex refactoring instead of using standard tools directly.

Готовый промпт от Anthropic:

Please write a high-quality, general-purpose solution using the standard tools available. Do not create helper scripts or workarounds to accomplish the task more efficiently. Implement a solution that works correctly for all valid inputs, not just the test cases. Do not hard-code values or create solutions that only work for specific test inputs. Instead, implement the actual logic that solves the problem generally.

Focus on understanding the problem requirements and implementing the correct algorithm. Tests are there to verify correctness, not to define the solution. Provide a principled implementation that follows best practices and software design principles.

If the task is unreasonable or infeasible, or if any of the tests are incorrect, please inform me rather than working around them. The solution should be robust, maintainable, and extendable.

Перевод сути: реши задачу в общем виде, а не «лишь бы тесты прошли». Тесты — способ проверить правильность, а не определение решения. Если задача невыполнима или тест кривой — скажи, не подгоняй обходом.

Не выдумывать про код, который не открывал. Этот промпт особенно полезен на шаге плана, когда Claude должен прочитать реальные файлы, прежде чем рассуждать:

<investigate_before_answering>
Never speculate about code you have not opened. If the user references a specific file, you MUST read the file before answering. Make sure to investigate and read relevant files BEFORE answering questions about the codebase. Never make any claims about code before investigating unless you are certain of the correct answer - give grounded and hallucination-free answers.
</investigate_before_answering>

Перевод сути: не фантазируй про код, который не открывал. Если упомянут конкретный файл — открой его до ответа. Это бьёт по самой частой ошибке Claude в больших проектах: уверенно описать метод, которого нет.

Убирать за собой. Claude иногда создаёт временные файлы-черновики при работе с кодом:

If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task.

Перевод: если создавал временные файлы или скрипты для проб и итераций — удали их в конце задачи.

Коротко

• Цепочка промптов — это разбиение задачи на отдельные шаги, между которыми вы видите промежуточный результат.
• Главный паттерн — самокоррекция: черновик → ревью по критериям → доработка.
• В Claude Code на больших задачах: план → слой БД → сервис → фронт и проверка. Между шагами останавливайтесь и смотрите.
• Anthropic даёт готовые промпты против «улучшайзинга», подгона под тесты и фантазий о коде — кладите их в системную инструкцию или на шаг ревью.
• На простых правках цепочка не нужна — она для случаев, где раньше вы рисковали сгенерить «всё за один заход».