Tutorial 4 Prompting and Reviewing ru

Урок 4 · Промптинг и ревью

Цель: метанавык. Теперь вы умеете строить функцию с агентом — эта глава о том, как делать это гладко и повторяемо: писать промпты, которые срабатывают с первого раза, эффективно проверять diff-ы, итерировать, когда всё идёт наперекосяк, и сохранять темп между сессиями.

← Назад: Урок 3 Ваша первая задача для агента · Далее: Урок 5 Локализация

---

Промптите как ведущий, а не как поисковая строка

Агент — это быстрый, буквальный, рьяный junior-инженер. Ведите его так, как вели бы хорошего:

• Заявляйте цель и ограничения. «Добавь endorse» — слабо. «Добавь endorse по паттерну connect, только генератор с seed, с тестами, барьер остаётся зелёным» — сильно. Ограничения — это то, как вы получаете подходящий код.
• Указывайте на примеры. «Следуй паттерну, который использует renderConnect» бьёт абзац описания. Существующий код — лучшая спецификация.
• Просите план перед правками на всём нетривиальном. Дёшево перенаправить план; дорого распутывать десять отредактированных файлов.
• Одна задача на промпт. Связка «добавь endorse, ещё отрефактори генератор, ещё обнови README» производит запутанный diff, который трудно проверять.
• Дайте ему тестовый барьер. «Запусти npm test и не считай сделанным, пока не зелёно» превращает агента в нечто, проверяющее собственную работу.

Проверяйте diff каждый раз

Скорость — весь смысл агента, но непрочитанная скорость — это то, как выкатывают баги. Постройте быстрый, стабильный рефлекс ревью:

1. Область: изменил ли он только то, что должен? Несвязанные сдвинутые строки — тревожный сигнал.
2. Паттерны: совпадает ли с окружающим кодом, без новых зависимостей и без I/O внутри src/?
3. Правила проекта: для этого репозитория это только генератор с seed (grep diff на Math.random), видимый пользователю текст в языковых бандлах (не захардкоженный), и строки карточек никогда не превышают ширину, до которой раскладка добивает отступами.
4. Доступность: выживает ли новый вывод под --accessible? Запустите lockedin --accessible <your command> и проверьте, что это читается как чистый простой текст — никакие новые декоративные глифы не проскальзывают мимо a11yFilter.
5. Тесты: есть ли новый тест, и упал бы ли он реально, если функция сломается? Спросите: «Какую строку я бы изменил, чтобы этот новый тест упал?»
6. Запустите это: npm test, затем запустите команду и посмотрите на вывод.

Не обязательно понимать каждый символ — но вы обязаны понимать каждое решение. Если вы не можете объяснить изменение, попросите агента объяснить его, прежде чем принимать.

Итерируйте, когда не зелёно

Красный барьер — нормальный шаг, а не провал. Исправление — это точная обратная связь:

«npm test падает с: [paste the exact error]. Тест ширины renderEndorse ожидает, что каждая строка карточки ≤ 60 видимых столбцов. Исправь это, не ослабляя тест.»

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

Сохраняйте темп между сессиями

Настоящая работа охватывает больше одного захода. Две привычки держат агента эффективным со временем:

• Память / соглашения. Если ваш агент поддерживает долговременную память или файл инструкций проекта, запишите там правила, которым он должен всегда следовать (например, «вся случайность должна использовать pick/shuffle», «запускай npm test перед объявлением готовности»). Вы заявляете соглашение один раз вместо каждого промпта.
• Заметка о передаче. Этот репозиторий держит короткий, очищенный документ статуса в docs/HANDOFF.md: что за проект, как построен, как тестируется и что дальше. Когда вы возвращаетесь (или передаёте коллеге — или другому агенту), эта заметка восстанавливает контекст за секунды. Попросите своего агента поддерживать её в актуальности как часть изменения.

Ограждения, которые стоит держать

• Барьер не обсуждается. Зелёные тесты прежде чем что-либо выкатится. Именно это позволяет двигаться быстро и доверять выводу.
• Вы — ответственный ревьюер. Агент пишет; вы решаете. Принять diff — значит поручиться за него.
• Маленькие, проверяемые шаги бьют один гигантский прыжок. Каждое принятое изменение должно оставлять приложение рабочим.

---

✅ Попробуйте со своим агентом

1. Напишите одноабзацную спецификацию для команды mentor («раздаёт непрошеные советы»), включая ограничения, и заставьте агента построить её тесты-сначала — план, тесты, код, барьер — проверяя на каждом шаге.
2. Попросите агента обновить docs/HANDOFF.md, чтобы упомянуть новую команду.
3. Намеренно сломайте что-нибудь (например, удалите запись пула), запустите npm test и потренируйтесь передавать агенту точный сбой для исправления.

---

Куда идти дальше

• Пробегитесь по настоящему коду в src/lockedin.js — вы теперь знаете его форму.
• Прочитайте docs/HANDOFF.md для собственных заметок проекта о статусе и архитектуре.
• Насладитесь шутками в Справочнике команд.

Это весь учебник. Вы теперь умеете направлять ИИ-агента строить и менять настоящий софт за тестовым барьером — на самом самоуверенном примере, какой только можно вообразить. Согласны? 👇