Ինչպես աշխատել մշակողի հետ AI-ով ստեղծված հավելվածի վրա

AI-ով ստեղծված հավելվածի վրա մշակողի հետ լավ աշխատելու համար տվեք նրան կոդը Git պահոցում, մեկ էջանոց ամփոփում, թե հավելվածը ինչ է անում և ինչու, և հստակ սահմանված առաջադրանք՝ «ավարտված» սահմանմամբ։ Համաձայնեցրեք, թե ով ինչ մասեր է փոխում, որ դուք և AI-ն չգրեք նրա աշխատանքը, պահեք պահոցը և հոստինգի հաշիվները ձեր անունով, և գաղտնի տվյալները փոխանցեք պատշաճ կարգավորումներով, ոչ թե հաղորդագրություններով։

Շատ մարդիկ AI-ով են կառուցում հավելվածի առաջին տարբերակը, իսկ հետո մշակող են ներգրավում՝ վճարումներ ավելացնելու, մի բանի շտկելու համար, որ AI-ն անընդհատ սխալ է անում, անվտանգության վերանայման համար կամ, երբ հավելվածը մեծանում է, դրա պատասխանատվությունը ստանձնելու համար։ Եթե դեռ որոշում եք՝ արդյոք վարձել, տե՛ս վարձել մշակող կամ կառուցել AI-ով։ Այս ուղեցույցը ենթադրում է, որ արդեն որոշել եք և ցանկանում եք, որ համագործակցությունը սահուն անցնի։

Երբ մշակողը արժե

Հաճախ հանդիպող պատճառներ՝

• Խնդիր, որ AI-ն չի կարողանում լուծել, կոկիկ հստակ փորձերից և վերադարձներից հետո։
• Ռիսկային տարածքներ․ վճարումներ, թույլտվություններ, զգայուն տվյալներ, տվյալների բազայի միգրացիաներ։
• Անվտանգության կամ կոդի վերանայում թողարկումից առաջ կամ ավելի մեծ հաճախորդներ վերցնելուց առաջ։
• Արդյունավետություն, երբ իրական թրաֆիկ է գալիս։
• Աճ․ հավելվածը բիզնես է դարձել և պետք է մեկը, ով տիրապետում է կոդին։

Որն է պատճառը, որ հստակ եք, ձևավորում է ամեն ինչ ստորև։

Քայլ 1. Կոդը բերեք փոխանակելի տեղ

Մշակողները աշխատում են Git պահոցներից։ Նախքան որևէ մեկին դիմելը․

1. Միացրեք նախագիծը մասնավոր GitHub (կամ նմանատիպ) պահոցին, կամ արտահանեք այն։
2. Համոզվեք, որ գաղտնի տվյալներ չկան ո՛չ կոդում, ո՛չ պատմության մեջ։ Տե՛ս ինչպես պահել API բանալիները անվտանգ։
3. Ստուգեք, որ նախագիծը աշխատում է նոր պատճենից՝ խնդրեք AI-ին գրել տեղադրման քայլերը։

Գրիր README մշակողի համար, որ միանում է այս նախագծին․ ինչ է անում հավելվածը, stack-ը, ինչպես տեղադրել և գործարկել լոկալ, պահանջվող միջավայրի փոփոխականները (միայն անունները), թղթապանակների կառուցվածքը և ամեն ինչ, որ խոցելի կամ անսովոր է։

Եթե Git-ը նոր է ձեզ համար, ինչպես օգտագործել Git-ը AI-ով ստեղծված հավելվածի հետ ներկայացնում է հիմունքները։

Քայլ 2. Գրեք մեկ էջանոց բրիֆ

Մշակողը չի անցել ձեր չաթի պատմության միջով։ Տվեք նրան համատեքստը մեկ էջում․

• Ինչ է անում հավելվածը, ում համար և քանի մարդ է օգտագործում այն։
• Ինչն է ամենակարևորը — հոսքեր, որ երբեք չպետք է կոտրվեն։
• Հայտնի խնդիրներ և ինչ արդեն փորձել եք։
• Առաջադրանքը և ինչպես կիմանաք, որ ավարտված է։
• Սահմանափակումներ․ բյուջե, ժամկետ, բաներ, որ չպետք է փոխեն։

Լավ «ավարտված» սահմանումը փորձարկելի է. «Մուտք գործած օգտատերը կարող է վճարել ամսական պլանի համար Stripe Checkout-ով, պլանը հայտնվում է իր հաշվի էջում, և customer portal-ում չեղարկումը իջեցնում է նրան ժամանակաշրջանի վերջում»։ Ոչ թե «կարգի բեր վճարումները»։

Քայլ 3. Տվեք մուտքը անվտանգ

• Կոդ. ավելացրեք նրանց պահոցի համագործակիցներ։ Աշխատանքը սկսվելուց հետո ZIP ֆայլեր մեկից մյուսին չուղարկեք։
• Կառուցիչ. եթե ձեր AI հավելվածի կառուցիչը աջակցում է թիմի անդամներին, հրավիրեք նրանց աշխատանքային տարածք, որ պարունակում է միայն այս նախագիծը։
• Գաղտնի տվյալներ. ավելացրեք հոստինգի կարգավորումներում կամ փոխանցեք գաղտնաբառերի կառավարիչով։ Բանալիները երբեք էլփոստով կամ չաթով մի տեղադրեք։
• Թեստային հաշիվներ. ստեղծեք թեստային տվյալներով, ոչ թե կիսվեք ձեր սեփական մուտքով։
• Արտադրական տվյալներ. միայն եթե իրապես պետք են, և միայն այն, ինչ պետք է։

Պահեք պահոցը, դոմենը և հոստինգի հաշիվները ձեր անունով։ Ավելացրեք մարդկանց, մի՛ հանձնեք հաշիվները։

Քայլ 4. Համաձայնեցրեք, թե ով ինչ է փոխում

Համակարգչային կոդի մեծ խնդիրն այն է, որ երկուսը՝ դուք AI-ով և մշակողը, միաժամանակ փոխում եք նույն կոդը։ Ընտրեք կանոն․

Ինչ էլ ընտրեք, յուրաքանչյուր աշխատանքային նստաշրջանից առաջ քաշեք վերջին կոդը, և մեծ փոփոխությունները արեք ճյուղերի վրա, որ մյուսը կարողանա վերանայել։

Քայլ 5. Հաղորդակցվեք գրավոր

• Խնդիրները հայտնեք քայլերով, սպասվող և իրական արդյունքներով։ Տե՛ս ինչպես գրել լավ սխալի հաղորդում։
• Որոշումները պահեք մեկ տեղում՝ խնդիրների հետևող, համօգտագործվող փաստաթուղթ կամ pull request-ի մեկնաբանություններ։
• Խնդրեք, որ յուրաքանչյուր pull request-ում պարզ լեզվով բացատրեն, թե ինչ են փոխել։
• Համաձայնեցրեք, թե որքան հաճախ եք ստուգում միմյանց։

Քայլ 6. Վերանայեք նրանց աշխատանքը

Աշխատանքը վերանայելու համար կոդ կարդալ պետք չէ։ Ստուգեք՝

• Անում է այն, ինչ ասում էր բրիֆը նախադիտման կամ բեմադրման պատճենում։
• Ոչինչ այլ չի կոտրվել — գործարկեք ձեր կարևորագույն հոսքերը։
• Բացատրել են, թե ինչ են փոխել և ինչու։
• Գաղտնի տվյալներ չեն հայտնվել կոդում։

Ավելի մանրակրկիտ նայելու համար՝ ինչպես վերանայել AI-ով գեներացված կոդը ներառում է ստուգացանկ, որ աշխատում է նաև մարդու գրած կոդի համար։ Կարող եք նաև խնդրել ձեր AI կառուցիչին պարզ լեզվով բացատրել մշակողի pull request-ը։

Քայլ 7. Պահեք սեփականությունը հստակ

• Պահոցը, հոստինգը, դոմենը և երրորդ կողմի հաշիվները մնում են ձերը։
• Գրավոր ամրագրեք իրենց գրած կոդի սեփականությունը, մինչ աշխատանքը սկսվի։ Պայմանագրային հարցերի համար ստուգեք տեղական կանոնները կամ խորհրդատուին։
• Աշխատանքն ավարտվելուց հետո հանեք նրանց մուտքը և փոխեք այն բանալիները, որ նրանք տեսել են։

Օրինակ հրահանգներ

Մշակողը փոխել է checkout կոդը վերջին pull-ում։ Պարզ լեզվով բացատրիր, թե ինչ են փոխել և կախված է արդյոք հավելվածի մնացած մասը դրանից։

Թվարկիր այս հավելվածի ամենաբարդ կամ ռիսկային մասերը, որ կարողանամ մշակողին ասել, թե որտեղ կենտրոնանա վերանայման ժամանակ։

Ես վճարումները հանձնում եմ մշակողին։ Սկսած հիմա, src/payments ենթաթղթապանակի ֆայլերին կամ /api/billing երթուղիներին մի դիպիր։ Եթե փոփոխությունը դրանք պահանջում է, ասա ինձ։

Սովորական սխալներ

• Բրիֆի բացակայություն։ Մշակողը վճարվող ժամերը ծախսում է՝ փորձելով հասկանալ, թե դուք ինչ էիք ուզում։
• Անորոշ շրջանակ, ինչպիսիք են «շտկիր սխալները» կամ «դարձրու արտադրության պատրաստ»։
• Երկուսի միաժամանակյա խմբագրում առանց pull-ի, ապա աշխատանքի կորուստ կոնֆլիկտներից։
• Սեփական մուտքի կիսվելը կամ բանալիների չաթ տեղադրելը։
• Հաշիվներ մշակողի անունով, որ դժվարացնում են բաժանվելը։
• Մուտքը հետ չվերցնելը և բանալիները չփոխելը աշխատանքից հետո։

Ստուգացանկ

• Կոդը գտնվում է մասնավոր պահոցում, իմ անունով, առանց գաղտնի տվյալների։
• README-ը բացատրում է տեղադրումը, մեկ էջանոց բրիֆը՝ հավելվածը և առաջադրանքը։
• Առաջադրանքը ունի փորձարկելի «ավարտված» սահմանում։
• Մուտքը տրվում է համագործակցի հրավերներով, գաղտնի տվյալները՝ կարգավորումներով կամ գաղտնաբառերի կառավարիչով։
• Համաձայնել ենք, թե ով ինչ է փոխում, և ես pull եմ անում նախքան հրահանգ տալը։
• Աշխատանքը վերանայվում է բրիֆի և կարևոր հոսքերի նկատմամբ։
• Սեփականությունը գրավոր է․ աշխատանքն ավարտվելուց հետո մուտքը հանվում է, բանալիները փոխվում են։

Մշակողի հետ աշխատանք Mythex-ում

• Հրավիրեք նրանց աշխատանքային տարածք։ Սեփականատերերը կարող են հրավիրել անսահմանափակ համագործակիցներ՝ առանց մեկ նստատեղի վճարի, իսկ անդամները աշխատում են տարածքի նախագծերի վրա։ Օգտագործեք առանձին աշխատանքային տարածք, որ տեսնեն միայն այս նախագիծը։ Հրատարակված հավելվածների կրեդիտները վճարվում են աշխատանքային տարածքի սեփականատիրոջը։ Տե՛ս Հրավերներ։
• GitHub sync և արտահանում (Pro). Միացրեք պահոց և push ու pull արեք, կամ արտահանեք նախագիծը՝ առանց գաղտնի տվյալների։ Տե՛ս GitHub, export, and import։
• Կիսվեք նախադիտման հղումով, որ ցույց տաք աշխատանքը ընթացքում մեկին, ով Mythex հաշիվ չունի․ ավարտելուց հետո ջնջեք այն։
• Ask ռեժիմը պատասխանում է կոդի մասին հարցերին՝ առանց այն փոխելու։ Օգտակար է մշակողի փոփոխությունները հասկանալու համար։

Եթե մշակողը հավելվածը կաշխատեցնի այլուր, տե՛ս ինչպես արտահանել և ինքնուրույն տեղակայել AI-ով ստեղծված հավելվածը։

Հարցեր