Врз основа на вистински случај на автоматско програмирање со Claude Code, споделувам некои техники за промптови

Овој напис, преку вистински случај, ќе ви сподели вистински пример за употреба на Claude Code. Пред да споделам, да направиме мала анкета.

Оригиналното барање: Еден почитуван платен корисник сакаше да додадам време на промена на статиите во мојот напис.

На прв поглед, ова барање изгледа малку тешко за имплементација. Бидејќи статиите на мојата веб-страница не се зачувани во база на податоци, туку се изградени со SSG од next.js. Тие воопшто немаат време на ажурирање.

Една техника овде е: Кога решаваме проблем, не треба директно да го дадеме оригиналното барање на Claude Code, од следниве причини:

1. Оригиналното барање е релативно нејасно, може да го разбере погрешно, и ако тоа се случи, иако на крајот ќе додаде време, тоа време може да не е сигурно.

2. Потрошувачката на токени на Claude Code е навистина многу скапа, па нејасното барање може да доведе до голема потрошувачка на токени без смисла.

Затоа, треба да го разложиме оригиналното барање. Прво консултирав со deepseek, кој ми даде две решенија:

1. Време на изградба на датотеката: При секоја изградба, треба да го добиеме времето на изградба на датотеката, но стратегијата за пакување на turbopack е малку различна, бидејќи хаш-вредноста на датотеката се менува при секоја изградба, па ова време може да не е сигурно.

2. Време на git commit, што мислам дека е посигурно.

Откако имав приближна насока за решението, го имав овој едноставен промпт: Вметнете го времето на git commit во заглавието на секоја .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/your-path/page.mdx');
  return (
    
      {children}
    
  );
}

Но, вистинската ситуација е дека ми требаше резултат како овој, а извршниот резултат е сосема ист.

import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
  return (
    
      {children}
    
  );
}

И тогаш, се сопнав на грешка со промптот.

Внесов повторно промпт: Користете го истиот начин како погоре за да ги рефакторирате прескокнатите 171 датотеки.

Мојот израз, ако се размисли внимателно, има малку двосмисленост. Бидејќи Claude Code веќе ми даде предложено решение, но јас не го прифатив тоа решение. Мојата намера беше да ги изменам прескокнатите датотеки на истиот начин како стотиците веќе изменети датотеки, но за време на извршувањето, тој го протолкува како: решението што тој ми го предложи погоре.

Оваа двосмисленост директно предизвика тој да изврши 20 минути според она што не сакав, со уште 2 грешки за само-поправка во меѓувреме, и голема потрошувачка на моите токени. Двете двосмислености почнаа да се судираат и предизвикаа грешки.

Конечно, морав повторно да го откажам ова извршување и повторно да го појаснам моето значење.

Резиме

1. Во промптовите, најдобро е да се вклучат релативно стабилни и точни решенија, така што AI размислува колку е можно помалку, што може да ја намали стапката на халуцинации.

2. Промптовите за барањата не смеат да имаат двосмисленост, бидејќи тоа лесно води до грешки. Иако Claude Code на крајот може да ги поправи, тоа ќе предизвика голема потрошувачка на токени. И бидејќи LLM се базира на механизам за предвидување за производство на резултати, раните погрешни толкувања, двосмислености итн., ќе предизвикаат секој следен чекор да оди подалеку во погрешна насока, и тој ќе се обиде да биде логички конзистентен, создавајќи некои непостоечки работи, што ги зголемува проблемите и ја зголемува тежината на проверка за развивачите. Ако бидете измамени од неговите халуцинации, тоа може да има сериозни последици.

3. Ограничувањата на природниот јазик се помалку прецизни од оние на кодот. Вклучувањето на имиња на датотеки, кодни променливи, специфични кодни зборови, стручни термини итн. во промптовите значително ќе ги намали халуцинациите на Claude Code.