Agent üçün dörd tapşırıq növü

"Portalın əsas səhifəsini tamamlayın" istəyinin arxasında bir neçə fərqli iş gizlənə bilər. Aksiya siyahısında filtr çatışmır. Banner düyməsi yanlış yerə aparır. Liderboard məlumatlarının hazırlanması iki dəfə yazılıb və hər dəyişiklik ikiqat baha başa gəlir. Üstəlik, aksiya ünvanının haradan gəldiyini heç kim dəqiq xatırlamır.

Belə bir xahişi alan adam yəqin ki, əlavə sual verər. Claude Code da soruşa bilər, amma tez-tez boşluqları özü doldurur - inandırıcı görünən, amma heç kimin sifariş etmədiyi işlə. Bu əlavə iş də hər tapşırıq növündə başqadır: filtrə axtarış da əlavə olunur, link düzəldiləndə dizayn dəyişir, refactoring zamanı çeşidləmə də "düzəldilir", araşdırma isə kod dəyişiklikləri ilə bitir.

Nə dəyişməlidir

Tapşırıq növlərini işin sonunda nəyin fərqli olacağına baxaraq ayırmaq asandır:

• əvvəl olmayan davranış əlavə olunub - feature, yeni imkan;
• davranış gözlənilən hala gətirilib - bugfix, xətanın düzəldilməsi. Əvvəldən mövcud olsa da, razılaşdırıldığı kimi işləməyən funksiya da buraya daxildir;
• xaricdən hər şey əvvəlki kimidir, kodun daxili quruluşu dəyişib - refactoring;
• layihə haqqında suala cavab almısınız, mənbə kodu dəyişməyib - research, araşdırma.

Tapşırıq növü sorğuda nəyi dəqiqləşdirmək və cavabda nəyi yoxlamaq lazım olduğunu göstərir. Agentə nə qədər sərbəstlik verəcəyiniz xətanın qiymətindən və tapşırığın ölçüsündən də asılıdır: insanların istifadə etdiyi koddakı dəyişiklik tədris layihəsində yeni səhifə əlavə etməkdən daha çox diqqət tələb edir. Bəzən tapşırıqlar qarışıq olur, məsələn, əvvəl araşdırma, sonra dəyişiklik. Bu halda hər mərhələnin öz nəticəsi və sərhədi olmalıdır.

Yeni imkan

Aksiya siyahısında yalnız aktiv olanları göstərən keçirici lazımdır. Şərtləri əvvəlcədən dəqiqləşdirək: active: true əlaməti olan aksiya aktiv sayılır; A və C aksiyalarında bu əlamət qoşuludur, B-də isə yox. Buradakı məlumatlar tədris üçündür, aşağıdakı sorğular isə öz layihənizə uyğunlaşdıra biləcəyiniz nümunələrdir.

"Aktiv aksiyalar üçün filtr əlavə et" sorğusunu agent, çox güman ki, artıqlaması ilə yerinə yetirəcək. Məsələn, keçirici əlavə olunacaq, yanına "madam ki, filtrləyirik" deyə axtarış sahəsi, üstəlik bitmə tarixinə görə çeşidləmə də qoyacaq. Bunların hər biri ayrıca məntiqli görünür. Bir yerdə isə heç kimin sifariş etmədiyi və indi yoxlanmalı olan kiçik bir alt-sistemə çevrilirlər.

Artıq əlavələri heç olmasa səhifədə görmək olur. Daha pisi, agent sizin vermədiyiniz qərarı səssizcə özü qəbul edəndə baş verir. Andrej Karpathy öz MenuGen layihəsi haqqında danışmışdı: giriş Google vasitəsilə, ödəniş Stripe-la edilir, agent isə alışı hesabla email ünvanına görə əlaqələndirib. İki xidmətdə fərqli ünvanı olan istifadəçilərin ödənişi hesaba bağlanmır. Məlumatla bağlı qərarları - qeydləri hansı əlamətə görə əlaqələndirmək və layihədə artıq olan qeydlərlə nə etmək - siz qəbul edirsiniz; bunu elə sorğuda yazmaq daha yaxşıdır. Bizim sual daha sadədir: active əlaməti heç olmayan aksiya ilə nə etməli?

Özbaşına iş görməyin başqa səbəbi nümunə koddur. Agent layihədə oxşar kod axtarıb onu təkrarlayır, amma bənzər görünən yer elə hamının çoxdan yenidən yazmaq istədiyi kod ola bilər. Layihədə yaxşı nümunə varsa, özünüz göstərin.

Yeni imkan üçün bir istifadəçi ssenarisi və tapşırığa daxil olmayan işlərin açıq siyahısı lazımdır:

Əsas səhifədəki aksiya siyahısına "Yalnız aktivlər" keçiricisi əlavə et.
Aktiv aksiya active: true olan qeyddir; bu sahə yoxdursa, aksiya qeyri-aktivdir.
Mövcud məlumatlarla yoxlama: qoşulanda A və C görünsün, söndürüləndə A, B və C.
Axtarış, çeşidləmə və başqa filtrlər əlavə etmə, bunlar ayrı tapşırıqlardır.
Layihədə oxşar keçirici varsa, eyni qaydada et
və hansı nümunəyə əsaslandığını bildir.
Əvvəl görəcəyin ssenarini bir cümlə ilə de,
sonra cavabımı gözlə. Hələ faylları dəyişmə.

Son iki sətir az zəhmət tələb edir, amma faydalıdır: agentin danışdığı ssenari niyyətinizlə üst-üstə düşmürsə, bunu dəyişiklikdən əvvəl görəcəksiniz. Agent planı göstərəndə ona qısa sual verin: həll həddindən artıq mürəkkəb və ya yarımçıq deyil ki, və o niyə belə hesab edir? Bu sual istənilən plan üçün yararlıdır, amma xüsusilə feature tapşırığında, çünki əlavə iş məhz burada gizlənir. Nəticədə keçiricinin hər iki vəziyyətini yoxlayın və səhifədə artıqlıq yaranmadığına da baxın.

Xətanın düzəldilməsi

Əsas səhifədəki banner düyməsi aksiya şərtləri olan /campaign/ səhifəsini açmalıdır, amma /old/ ünvanına aparır.

Agent üçün ən qısa yol /campaign/ ünvanını düymənin linkinə yazmaqdır. Ünvan elə linkdə saxlanırsa, bu, həqiqətən kifayət edər. Amma ünvan başqa düymələrin də istifadə etdiyi ümumi məlumatlardan gəlirsə, belə dəyişiklik yalnız simptomu gizlədər: bu düymə işləyər, amma məlumatdakı xəta qalar. Fayl onsuz da açıqdır deyə bannerin aralıqlarını və rəngini yeniləmək də tez-tez görülən addımdır.

Düymənin özünə baxıb hansı halla üzləşdiyinizi anlamaq olmur, bunu yalnız koddan görmək mümkündür.

Nəsə istəməzdən əvvəl xətanı özünüz təkrarlayın: düyməni basın və hara apardığına baxın. Xəta sizdə təkrarlanmırsa, tapşırığı bağlamağa tələsməyin; əvvəl onu gördüyünüz addımları və məlumatları dəqiqləşdirin. Xətanı təkrarladıqdan sonra səbəbini tapmaq lazımdır. Düymənin ünvanı haradan götürdüyünü bilmirsiniz? Problem deyil, agentə veriləcək ilk sual da elə budur:

Əsas səhifədə banner düyməsi /old/ ünvanına aparır, /campaign/ olmalıdır.
Əvvəl düymənin ünvanı haradan götürdüyünü tap və həmin yeri göstər.
Hələ faylları dəyişmə.
Təsdiqimdən sonra ünvanı təyin olunduğu yerdə düzəlt.
Bannerin dizaynına toxunma.

Dəyişiklikdən sonra ilkin əməliyyatı təkrarlayın: düyməni basın, ünvanı yoxlayın, səhifədə aksiya şərtlərinin göründüyünə əmin olun. Ümumi ünvan məlumatlarını dəyişmisinizsə, onlardan istifadə edən daha bir yeri də yoxlayın.

Kodun daxili quruluşunun dəyişdirilməsi

Liderboard məlumatlarının hazırlanması iki yerdə demək olar ki, eyni cür yazılıb, hər dəyişiklik isə hər iki yerdə edilməlidir. Məqsəd bir nüsxə saxlamaq və cədvəli dəyişməməkdir.

Dəyişiklikdən sonra əvvəlki kimi qalmalı olan şeyə invariant deyilir. Burada eyni məlumatlarla iştirakçıların sırası və cədvəldəki rəqəmlərdir.

Refactoring zamanı baş verən xəta səs-küy salmır. Xallar bərabər olanda çeşidləmə dəyişir, yuvarlaqlaşdırma başqa cür olur, amma xəta mesajı çıxmır - cədvəl sadəcə yanlış nəticə göstərir. Agent iki variantı birləşdirib heç nə işə salmadan "davranış dəyişməyib" deyə bilər. Yaxud köhnə çeşidləmə ona qəribə göründüyü üçün yolda onu "yaxşılaşdıra" bilər.

Belə ardıcıllıqda bir dəst götürək: 10 xallı A, 20 xallı C, 20 xallı B, 15.5 xallı D. Bu gün cədvəl C: 20, B: 20, D: 15.5, A: 10 göstərir. Refactoring üçün etalon məhz mövcud kodun bu nəticəsidir, hətta başqa cür istəsəniz də. Dəst təsadüfi seçilməyib. C, B-dən əvvəl gəlir, buna görə yeni versiya eyni xalları ad üzrə sıralamağa başlasa, B önə keçəcək. Kəsrli qiymət isə yuvarlaqlaşdırmanın dəyişdiyini göstərər.

Hər iki problemin qarşısını alan sorğu belədir:

Liderboard məlumatlarının hazırlanması iki yerdə təkrarlanır, birini saxla.
Cədvəlin davranışını dəyişmə, hətta qəribə görünsə belə,
belə yerləri ayrıca qeyd et.
Dəyişiklikdən əvvəl mövcud yoxlamaları işə sal və
A: 10, C: 20, B: 20, D: 15.5 dəsti üçün cədvəli göstər. Hər iki nəticəni saxla.
Dəyişiklikdən sonra eyni addımları təkrarla və müqayisə et.
Hesabatda məlumatların indi harada hazırlandığını göstər.

Saxlanmış nəticələri hesabatdakı "üst-üstə düşür" sətrinə baxmaqla kifayətlənməyin, özünüz müqayisə edin. Uyğunluq yalnız bu məlumatlarda davranışın qorunduğunu göstərir, bundan artığını yox. Sorğunun son sətri tapşırığın özünü yoxlayır: cədvəlin eyni qalması təkrar kodun həqiqətən aradan qaldırıldığı anlamına gəlmir.

Burada isə yarımçıq həll heç nə etməməkdən də pisdir. Tutaq ki, bir nüsxə qaldı, çağırışların bir hissəsi isə yeni versiyaya keçdi. Cədvəl dəyişməyib, amma məlumatı hazırlamağın indi iki yolu var. Agent növbəti sorğunu yerinə yetirərkən köhnə üsula söykənə bilər, çünki hansının doğru olduğunu bilmir. Birləşdirməyə başladınızsa, bir versiyaya çatdırın; vaxt çatmırsa, daha əvvəl dayanın və nəyin yarımçıq qaldığını yazın.

Dəyişiklik etmədən araşdırma

Research digər növlərdən ən çox fərqlənir: nəticədə dəyişdirilmiş layihə yox, cavab alırsınız. Portalımızla bağlı sual budur: aksiya düyməsinin apardığı ünvan harada seçilir? Bu, xətanın düzəldilməsinin əvvəlindəki eyni sualdır, sadəcə burada dəyişiklik sifariş olunmayıb. Qarışıq tapşırıq da belə görünür: əvvəl araşdırma, sonra ayrıca mərhələdə düzəliş.

Agentin burada iki tipik səhvi olur. Birincisi, yolda düzəlişə başlamaqdır: qüsurlu hissəni tapır və onu düzəltmək təsvir etməkdən daha asan görünür. Beləcə, araşdırma tapşırıq dəqiqləşdirilmədən və yoxlanmadan dəyişikliklə əvəz olunur. İkinci səhv daha incədir. Agent kodu oxuyur və səhifənin necə işlədiyini əminliklə danışır, halbuki səhifəni işə salmayıb. Kənardan baxanda oxuduqlarının təkrarı müşahidədən fərqlənmir.

Üçüncü səhv elə sorğunun özündən başlayır. Orada sonra nə edəcəyinizi yazsanız, agent cavabını bu məqsədə uyğunlaşdıracaq: hazırkı quruluş əvəzinə, necə yaxşı olacağı barədə fikir verəcək. Buna görə research zamanı mövcud quruluşu soruşun, niyyətinizi isə növbəti mərhələyə saxlayın. Aşağıdakı sorğuda ünvanı sonradan düzəltmək barədə bir kəlmə də yoxdur.

Əsas səhifədəki banner düyməsinin ünvanı haradan götürdüyünü tap. Heç nəyi düzəltmə.
Cavabında faylları və koddakı yerləri, onların əlaqəsini göstər,
oxumaqla nəyi müəyyən etdiyini, işə salmaqla nəyi öyrəndiyini yaz,
həmçinin hələ nələri bilmədiyini qeyd et.

Belə sorğuya yaxşı cavab, təxminən, belə görünür: "pages/home.html faylında düymənin ünvanı promo.url sahəsindən götürülür, bu sahənin qiyməti data/promo.json faylında /old/ olaraq təyin olunub. Bunu iki faylı oxuyaraq müəyyən etdim. Səhifəni işə salmamışam və skriptlərin ünvanı dəyişib-dəyişmədiyini yoxlamamışam". Əlaqəni yoxlamaq olur, bilik sərhədi də dürüst göstərilib.

Yolda şübhəli bir yer tapılsa, qoy cavaba ayrıca sətir kimi düşsün: nə görünür və nəticə çıxarmaq üçün nə çatışmır. Düzəliş isə öz tapşırığı olan növbəti mərhələdir.

İlk addım və sərhədlər

Hər şeyi bir cədvəldə ümumiləşdirək.

Üçüncü sütunda sorğuda açıq şəkildə qadağan edilməli olanlar var. Dördüncü sütunda isə özünüz yoxlamalı və ya cavabda göstərilməsini istəməli olduğunuz məqamlar yazılıb.

Əks tərəfi də var: tapşırıq növünün adı öz-özlüyündə heç nəyə icazə vermir. "Bu, refactoring-dir" deyib modulun yarısını yenidən yazmaq olmaz; "bu, bugfix-dir" deyə dizaynı da dəyişmək olmaz. Növ sualı və yoxlamanı seçməyə kömək edir, sərhədləri yenə siz müəyyən edirsiniz.

Altı sorğunu yenidən yazın

Aşağıda tez-tez yazılan altı sorğu var. Hər biri üçün növü müəyyən edin və agentin daha az şeyi özü uyduracağı şəkildə yenidən yazın: nəticə, sərhəd, yoxlama. Təhlil dərhal ardınca gəlir, ona görə əvvəl özünüz cəhd edin.

1. "Liderboard-u CSV-yə ixrac edin".
2. "Liderboard bəzən eyni iştirakçını iki dəfə göstərir, düzəldin".
3. "pages/home.html faylını hissələrə bölün, çox böyükdür".
4. "Əsas səhifə niyə bu qədər yavaş yüklənir?"
5. "Linki düzəldin, bir də dizaynı yenidən yazın".
6. "Portalı yaxşılaşdırın".

Mümkün təhlil variantlarından biri budur. Sizin ifadələriniz fərqli ola bilər, vacib odur ki, onlarda həmin dayaqlar olsun.

1. Liderboard-un ixracı.
Feature. Ssenari dəqiqləşdirilməyib: fayla hansı sütunlar düşəcək, sətirlər hansı ardıcıllıqla olacaq, ixrac düyməsi harada yerləşəcək? Asanlıqla gözdən qaçan məlumat sualı da var: xalı hələ olmayan iştirakçılar fayla düşməlidirmi? Bunu özünüz həll edin, yoxsa agent qərar verəcək. Ayrıca nə edilməməli olduğunu yazın: idxal, sütun seçimi, başqa formatlar. Yoxlama sadədir: A, B, C, D dəsti ilə faylı ixrac edin və sətirləri ekrandakı cədvəllə müqayisə edin.

2. İştirakçı iki dəfə görünür.
Bugfix, amma burada əsas söz "bəzən"dir, "düzəldin" yox. Təkrarın nə vaxt yarandığı bilinmir, agentin də düzəldəcəyi konkret şey yoxdur. Onun ən ehtimal olunan addımı isə cədvəli göstərməzdən əvvəl təkrarları silmək olacaq. Gizlədilmiş simptom elə budur. Əvvəl hansı əməliyyatdan sonra və hansı məlumatlarla sətirin ikiqatlandığını müəyyən edin, sonra agentdən dəyişiklik etmədən bunun baş verdiyi yeri tapmasını istəyin. Yoxlama - təkrarı yaradan eyni ssenaridir.

3. Böyük faylı bölmək.
Refactoring-dir, amma invariant göstərilməyib və "heç nəyi pozmadıq" fikrini yoxlamaq mümkün deyil. Belə əlavə edin: səhifə əvvəlki kimi görünsün və işləsin - banner, aksiya siyahısı, liderboard; dəyişiklikdən əvvəl yoxlamaların nəticəsini qeydə alın. Həmçinin agentin həvəsini məhdudlaşdırın: markup-u fayllara ayırarkən aralıqları dəyişmək və ya class adlarını yeniləmək asandır.

4. Səhifə yavaş açılır.
Research: bu sualdır, sürətləndirmə sifarişi deyil. Amma agent bunu asanlıqla "daha sürətli et" kimi başa düşə bilər və "heç nəyi dəyişmə" deməsəniz, cavab yerinə təxmini optimallaşdırma alacaqsınız. Cavabda ölçülənləri oxunanlardan ayırmasını istəyin: "şəkillər bir neçə meqabayt tutur" - agent bunu yoxlayıbsa, faktdır; "yəqin skript yavaşıdır" isə ehtimaldır. Səbəb məlum olandan sonra düzəlişi növbəti mərhələdə edin.

5. Linki düzəltmək və dizaynı yenidən yazmaq.
Bir sorğuda iki nəticə istənir. Link düzəlişi - bugfix. Yeni dizayn bu dörd növdən heç birinə tam uyğun gəlmir: davranış yox, görünüş dəyişir. Ən yaxını feature-dir, sadəcə nəticə ssenari ilə deyil, maket və ya ekran görüntüsü kimi nümunə ilə təsvir olunur. Əvvəl bugfix bölməsindəki sorğu ilə linki düzəldin, sonra yoxlayıb dizayna keçin:

İndi bannerin dizaynını @banner-mockup.png maketinə uyğunlaşdır.
Düymənin ünvanını və mətnləri dəyişmə.

6. Portalı yaxşılaşdırmaq.
Növü müəyyən etmək olmur və təxmin etmək də lazım deyil. Sorğunu onu verən adama ünvanlanmış suala çevirin: hazırda konkret nə mane olur? Xahişi özünüz etmisinizsə, sualı özünüzə verin. Bunu agentə də tapşırmaq olar:

Nəyisə dəyişməzdən əvvəl məndən ən çox beş sual soruş,
konkret olaraq nəyi yaxşılaşdırmağı anlamaq üçün lazım olanları.
Faylları dəyişmə.

Cavablardan tapşırığın növü adətən öz-özünə aydın olur.