Одне речення проти невлучних фіксів Claude Code
Playwright-скрипт для вивантаження CSV замовлень зламався. Автор одразу вставив помилку в Claude Code з проханням «fix it» — той тричі підряд правив час очікування, а причина була в іншому: змінився UI логін-екрана, і сесія встигала закінчитися. Втрачено півдня (умовно 4 год × 2000 єн/год = 8000 єн за зупинку).
Рішення: перед фіксом просити назвати 3 гіпотези причини і спосіб перевірки кожної. Людина звіряє гіпотезу зі скріншотом чи URL і лише тоді дозволяє правити код. За досвідом автора причина звужується до ~10 хвилин замість півдня.
Три гіпотези замість миттєвого fix it
Принцип: перед тим, як просити виправити код, просиш спочатку назвати причину. Формулювання, яке додають на початок повідомлення з помилкою:
直す前に、まず再現手順と原因の仮説を3つ出して。コードはその後。(переклад: «Перш ніж виправляти, спочатку виведи кроки відтворення і 3 гіпотези причини. Код — після цього».) Якщо потрібна ще й перевірка кожної гіпотези, додається друге речення:
各仮説について、確認方法（見るログ・画面・値）も1行で書いて。(переклад: «Для кожної гіпотези напиши в один рядок спосіб перевірки — який лог, екран чи значення дивитися».) Для CSV-скрипта гіпотези вийшли такі: повільний рендеринг елемента (перевірка — лог наявності елемента на момент кліку), змінився UI логін-екрана (перевірка — скріншот у момент збою), сесія закінчилась (перевірка — URL у момент збою, чи це логін-сторінка). Людина дивиться на скріншот і URL і за кілька хвилин бачить, яка гіпотеза вірна, замість подальших здогадів разом з моделлю.
Підтвердження гіпотези перед фіксом
Обрану гіпотезу передають окремим повідомленням і лише тоді дозволяють правити код:
仮説Cで進める。確認のためのログ出力だけ先に入れて。まだ修正はしないで。(переклад: «Продовжуй з гіпотезою C. Спочатку додай лише лог для перевірки. Поки нічого не виправляй».) Коли причина підтверджена логом, просять фікс прямо під конкретну причину, а не під симптом:
原因は仮説C（セッション切れ）だった。ログインページに戻された時は、再ログインして処理を続ける修正をして。(переклад: «Причина — гіпотеза C (закінчення сесії). Зроби так, щоб при поверненні на логін-сторінку відбувався повторний логін і процес продовжувався».)
Той самий принцип на іншому збої: мовчазний fail
У автора був інший випадок — тижневі платні публікації статей зупинились на 5 тижнів, і він цього не помітив, бо автоматизація «вважала публікацію успішною, хоча вона фактично провалилась». Причина — текст обрізався через ліміт символів під час генерації. Висновок той самий: не довіряти статусу «успіх» від скрипта чи моделі без власної перевірки.
Відтоді після кожного запуску додається перевірка фактичного результату і лист при збої. Для CSV-вивантаження це один рядок: перевірка, що файл існує і в ньому є хоча б один рядок. Той самий підхід застосовано і до сесій логіну — щоранку автоматично перевіряється, чи вдається залогінитись, і якщо автентифікація мовчки закінчилась, надсилається лист.
Де прийом не рятує
- Якщо всі три гіпотези не влучні — просять «ще 3 інші гіпотези», а не одразу фікс
- Гіпотезу обирають за доказами, які бачили самі (скріншот, URL, лог), а не за тим, яку гіпотезу Claude подав першою
- Метод доцільний для помилок з невідомою причиною; для дрібних фіксів, де причина очевидна, він лише додає крок
«Близько 10 хвилин» на звуження причини — особистий досвід автора, не вимірювана метрика.