Набір промптів Claude для налагодження коду, рефакторингу й архітектурних оглядів

Чотири обмеження, на яких тримається кожен промпт нижче

Перш ніж перейти до промптів, розгляньмо правила, спільні для всіх них. Додавання цих правил до будь-якого промпту для коду покращує результат сильніше, ніж зміна моделі.

Вкажіть свою версію. Дані для навчання зазвичай зміщені в бік мажорної версії, про яку написано найбільше, а це часто не та версія, яку використовуєте ви. Фраза Ми на [фреймворк] [версія], [мова] [версія] запобігає більшості застарілих відповідей.

Обмежте дифф. Попросіть виправлення і часто отримаєте рефакторинг. Змінюй якомога менше, зберігай наявну структуру й назви, і перерахуй кожен змінений рядок з одним реченням причини це найкорисніше речення в цьому документі.

Просіть гіпотези перед рішеннями. Модель, яку запитали, що не так, дає здогадку, подану як висновок. Модель, яку попросили про ранжовані причини й дешеві перевірки, дає план діагностики.

Вимагайте опис режиму збою. Питання Що це може зламати, і це виправляє причину чи симптом? виявляє найдорожчий тип допомоги ШІ: зміну, яка прибирає симптом, а дефект залишається.

Налагодження

1. Ранжовані гіпотези

Ось помилка, відповідний код і те, що я вже виключив. Поки не давай виправлення. Перерахуй чотири найімовірніші причини, ранжовані за ймовірністю, і для кожної одну найдешевшу перевірку, яка підтвердить або спростує її. Помилка: [вставити]. Код: [вставити]. Уже виключено: [список]. Стек: [мова, фреймворк, версії].

2. Періодичний баг

Це збоює періодично, приблизно [частота], за умов [умови]. Перерахуй категорії періодичних збоїв, які могли б спричинити саме цей симптом: таймінг, порядок, вичерпання ресурсів, зовнішню залежність, витік стану між запусками, час чи часовий пояс, кешування. Для кожної скажи, що в коді підтверджує чи спростовує її, і що саме мені варто логувати, щоб їх розрізнити. Код: [вставити].

3. Локально працює

Це працює локально й не працює в [середовищі]. Перерахуй усі категорії відмінностей середовища, які могли б викликати саме цей симптом: конфігурація, змінні середовища, версії, файлова система й чутливість до регістру, часовий пояс і локаль, мережа й DNS, дозволи, обмеження ресурсів, відмінності збірки чи бандлінгу. Ранжуй за ймовірністю з огляду на симптом і дай мені діагностичну команду для кожної.

4. Поясни виправлення до того, як я його застосую

Поясни, чому це виправлення працює, що воно не виправляє і що може зламати. Якщо реальна причина в іншому місці, а це лише латка симптому, скажи про це прямо.

Code review

5. Огляд диффу

Розглянь цей дифф як вимогливий рецензент. Категорії за пріоритетом: помилки коректності, проблеми безпеки, необроблені режими збою, гонки станів, потім стиль. Для кожної знахідки дай серйозність, конкретний рядок і чому це важливо саме в цьому кодбейсі, а не загалом. Не коментуй форматування. Якщо дифф справний, скажи про це прямо замість того, щоб вигадувати знахідки. Конвенції: [опис]. Дифф: [вставити].

6. Перевірка безпеки

Розглянь цей код конкретно на предмет проблем безпеки: ін'єкції, прогалини в автентифікації й авторизації, небезпечна десеріалізація, секрети в коді чи логах, неперевірений ввід, що потрапляє до чутливої операції, і ризики залежностей. Для кожної дай конкретний шлях атаки, а не просто назви категорії. Чітко вкажи, що ти не можеш оцінити без [розгортання, шар автентифікації, чутливість даних].

7. Аудит режимів збою

Для кожного зовнішнього виклику в цьому коді вкажи, що відбувається, коли він повільний, коли він падає, коли повертає неочікувані дані і коли частково успішний. Які з них зараз необроблені, а які будуть тихими?

Останній пункт знаходить більше реальних продакшн-проблем, ніж звичайний огляд, бо запитує саме про шляхи, для яких ніхто не написав тест.

Рефакторинг і архітектура

8. План рефакторингу

Запропонуй послідовний план рефакторингу [опис]. Обмеження: публічний API [x] не можна змінювати, ми деплоїмо безперервно, тож кожен крок має бути придатним до окремого релізу, і тести мають проходити після кожного кроку. Для кожного кроку дай зміну, ризик, як її перевірити і як відкотити. Впорядкуй за ризиком, від найменшого. Поки не пиши код.

9. Обґрунтуй протилежну сторону

Я обираю [підхід A] замість [підходу B] для [контекст і обмеження]. Наведи найсильніші аргументи на користь B. Що мало б бути правдою про наші обмеження, щоб B було правильним вибором, і чи щось із цього правда тут? Не роби висновку, що обидва варіанти однаково валідні.

10. Розберись, що ти успадкував

Ось основні файли з вихідним кодом. Опиши: точки входу, потік даних від запиту до відповіді, стан, що є спільним, і де він змінюється, зовнішні залежності й що відбувається, коли кожна недоступна, і три ділянки, найімовірніше з багами, з огляду на складність і зв'язність. Явно вкажи, що ти не можеш визначити з наданого.

Ця остання інструкція важлива. Моделі описуватимуть поведінку файлу, який ви не вставили, виводячи її з назви. Явний список невідомого показує, що варто піти прочитати.

Тести

11. Тести, які ви б не написали

Напиши тест-кейси для цієї функції, зосередься на вводах, які я, ймовірно, не врахував: межі, порожні й null-значення, юнікод, дуже великі значення, конкурентні виклики і будь-яке неявне припущення в реалізації. Для кожного тесту вкажи, яке саме припущення він перевіряє. Функція: [вставити].

12. Перевір набір тестів

Ось функція і наявні для неї тести. Яка поведінка не покрита? Конкретно: шляхи помилок, граничні значення, взаємодії між параметрами і все, що робить реалізація, але жоден тест цього не перевіряє. Не переписуй наявні тести.

Другий промпт цінніший, і його рідко застосовують. Відсоток покриття показує, які рядки виконались, а не які поведінки насправді зафіксовані, і саме в розриві між цими двома живуть регресії.

Патерн другої думки

Найкорисніша звичка з усього цього набору, і єдина, для якої потрібно більше однієї моделі.

Отримайте відповідь від однієї моделі. Потім перемкніться і передайте її далі:

Інший інженер запропонував таке рішення цієї проблеми. Знайди, що в ньому не так: коректність у граничних випадках, конкурентність, обробка помилок, продуктивність за [масштаб], або простіший підхід, який був упущений. Якщо рішення справді надійне, скажи про це прямо, а не вигадуй заперечення. Проблема: [вставити]. Запропоноване рішення: [вставити].

Обидва результати корисні. Або друга модель знаходить реальну дірку, і тепер ви знаєте про це до того, як змержите зміни, або вона погоджується попри те, що її підштовхнули не погодитись, і це вагоме підтвердження. Ітерація з тією самою моделлю не дає жодного з двох, бо модель, яка оглядає власний результат, здебільшого погоджується сама з собою.

Використовуйте цей патерн для рішень, помилку в яких дорого виправляти: зміна схеми, виправлення конкурентності, все, що торкається автентифікації чи грошей. Не для рутинної роботи. Дивіться порівняння моделей одна поруч з одною, перемикання моделей посеред розмови і написання й налагодження коду кількома моделями, де весь цей процес описано в одному місці.

На що звертати увагу

Вигадані API. Впевнені назви методів, параметрів і ключів конфігурації, яких насправді не існує, особливо для бібліотек, які нещодавно змінились. Сигнатура виглядатиме правильно. Перевіряйте реальну документацію, перш ніж будувати щось на незнайомому.

Відсутність сигналу впевненості. Правильне виправлення й тонко хибне приходять з однаковою впевненістю в тоні. Тон нічого не каже.

Тихе розповзання обсягу. Саме для цього існує друге обмеження.

Театр безпеки. Назвати класи вразливостей у вашому коді, це корисний перший прохід. Це не аудит, і модель не знає вашу модель загроз, розгортання чи чутливість даних.

Тримайте промпти, якими користуєтесь щотижня, там, звідки можна вставити, і додайте постійні обмеження в інструкції проєкту, щоб вони застосовувались до кожного чату в цьому проєкті автоматично.