На основі реального випадку автоматичного програмування з Claude Code: поділюся деякими прийомами формулювання запитів

У цій статті, на основі реального випадку, поділюся з вами практичним досвідом використання Claude Code. Перед тим, як почати, проведемо невелике опитування.

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

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

Ось один із прийомів: при вирішенні проблем ми не повинні просто "згодовувати" початкове завдання Claude Code, і на це є кілька причин:

1. Початкове завдання відносно розмите, і воно може бути неправильно зрозуміле. Якщо це станеться, то в результаті час може бути доданий, але цей час може виявитися ненадійним.

2. Витрати токенів у Claude Code дійсно дуже високі. Тому розмите завдання може призвести до марної витрати великої кількості токенів.

Отже, нам потрібно розбити початкове завдання на частини. Спочатку я проконсультувався у deepseek, і він запропонував мені два рішення:

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

2. Час коміту в git. Я подумав, що це має бути більш надійним варіантом.

Після того, як з'явився загальний напрямок вирішення, у мене з'явився простий запит: скомпілювати час коміту git у заголовку кожної статті .mdx.

Claude Code досить надійний. Якщо запит точний, то загалом проблем не виникає, і він просто починає виконувати завдання.

Після того, як я витратив 7 доларів зі свого ліміту, і приблизно через 20 хвилин, виконання нарешті завершилося успішно.

Як і очікувалося, трапилася несподіванка: він пропустив зміни у 171 файлі.

Ось де криється проблема. Насправді, у цих пропущених файлах був лише додатковий параметр pass, все інше було абсолютно однаковим.

<PostLayout pass>...

Але він не проявив гнучкості і визначив цей додатковий параметр як абсолютно інший користувацький компонент. І потім просто пропустив його, не обробивши ~ ~

import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
  const gitInfo = getGitFileInfo('src/app/ваш_шлях/page.mdx');
  return (
    <Layout gitInfo={gitInfo || undefined}>
      {children}
    </Layout>
  );
}

Але насправді мені потрібен був такий результат, і робочий результат повинен бути абсолютно однаковим.

import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
  return (
    <MdxLayout pass filePath="src/app/r19base/(4.compiler)/23.compilerlower/page.mdx">
      {children}
    </MdxLayout>
  );
}

І тут я потрапив у пастку з формулюванням запиту.

Я знову ввів запит: використовуючи той самий спосіб, що й вище, реструктуруйте пропущені 171 файл.

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

Ця невелика двозначність призвела до того, що він 20 хвилин виконував завдання за небажаним для мене сценарієм. Посеред процесу двічі виникали помилки, які він сам виправляв, і він жадібно поглинав мої токени. Два різних тлумачення почали конфліктувати, що призвело до помилок.

Зрештою, мені довелося скасувати це виконання і чіткіше сформулювати мою думку.

Підсумок

1. У запиті краще містити відносно стабільне та точне рішення. Чим менше AI має міркувати, тим менша ймовірність галюцинацій.

2. У запиті не повинно бути двозначностей, оскільки вони легко призводять до помилок. Хоча Claude Code в кінцевому підсумку може виправити їх, це призведе до великої витрати токенів. Оскільки LLM генерує результати на основі механізму прогнозування, раннє неправильне тлумачення чи двозначність призводять до того, що кожен наступний крок віддаляє від правильного шляху все далі. Крім того, він намагатиметься логічно обґрунтувати свої дії, генеруючи неіснуючі речі. Чим більше він пише, тим більше проблем виникає, що також ускладнює перевірку для розробника. Якщо ви піддастеся його галюцинаціям, це може мати серйозні наслідки.

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