← 返回列表

Հարցազրույց AI-ի շարքից 16. Ինչպիսի՞ն պետք է լինի լավ spec coding-ը:

AI Knowledge AI Interview

Լավ Spec Coding-ը (սպեցիֆիկացիայով կառավարվող ծրագրավորում) հիմքում ունի «մշուշոտ գաղափարը» վերածելը «ճշգրիտ, ստուգելի և կատարվող պայմանագրի»: Այն ոչ միայն փաստաթուղթ գրելն է, այլ մարդու և AI-ի (կամ մարդու և մարդու) միջև աներկիմաստ հաղորդակցման լեզվի ստեղծումը: Ստորև կներկայացնեմ լավ spec-ի տեսքը՝ բովանդակության կառուցվածքի, գրման սկզբունքների, AI-ի հետ համագործակցության գործընթացի և որակի ստուգման չորս հարթություններով:

1. Սպեցիֆիկացիայի փաստաթղթի ստանդարտ կառուցվածք (ֆունկցիոնալ մոդուլի օրինակով)

Բաժին Պարտադիր բովանդակություն Օրինակ
1. Նպատակ և շրջանակ Մի նախադասությամբ նկարագրել, թե ինչ է արվում, հստակ նշել ինչ չի արվում «Իրականացնել օգտատիրոջ գրանցման API, առանց էլ. փոստի հաստատման»
2. Մուտք/Ելք պայմանագիր Տվյալների կառուցվածք, տիպ, պարտադիր/ըստ ցանկության դաշտեր, օրինակելի արժեքներ POST /register հարցման մարմին {email: string, password: string}, պատասխան 201 կամ 400 սխալի կոդով
3. Վարքագիծ և տրամաբանություն Բիզնես կանոններ, սահմանային պայմաններ, վիճակի անցումներ «Գաղտնաբառի երկարությունը 8-20 նիշ, պարունակի առնվազն մեկ թիվ; եթե էլ. փոստն արդեն գոյություն ունի, վերադարձնել 409»
4. Սխալների մշակում Բոլոր հնարավոր բացառիկ սցենարները և համապատասխան սխալի կոդերը/հաղորդագրությունները «Տվյալների բազայի կապի խափանում → վերադարձնել 503, չբացահայտել stack-ը»
5. Ոչ ֆունկցիոնալ պահանջներ Կատարողականություն (պատասխանի ժամանակը < 200ms), անվտանգություն (պարամետրացված հարցումներ), մատյանավորում, դիտարկելիություն «Բոլոր SQL-ները պետք է օգտագործեն նախապես կազմված հարցումներ; մատյանավորել email-ը, բայց ոչ password-ը»
6. Թեստային դեպքեր (կարևոր) Առնվազն 3 տիպական մուտք + 2 սահմանային/բացառիկ մուտք, տալ սպասվող ելք Տես ստորև աղյուսակը
7. Կախվածություններ և սահմանափակումներ Օգտագործվող գրադարանները, տարբերակները, միջավայրի փոփոխականները «Python 3.10+, FastAPI, միջավայրի փոփոխական DB_URL»

Թեստային դեպքերի օրինակ (ներկառուցված spec-ում)

Սցենար Մուտք Սպասվող ելք
Նորմալ գրանցում email: a@b.com, pwd: Pass1234 201, վերադարձնել user_id
Գաղտնաբառը չափազանց կարճ pwd: Ab1 400, սխալի կոդ WEAK_PASSWORD
Էլ. փոստն արդեն գոյություն ունի նույն email-ը 409, սխալի կոդ EMAIL_EXISTS

Լավ Spec-ը պետք է նախ գրի թեստային դեպքերը, քանի որ AI-ն կարող է դրանց հիման վրա ուղղակիորեն գեներացնել միավոր թեստեր, ավարտելուց հետո ավտոմատ ստուգել:

2. Spec գրելու հիմնական սկզբունքներ (SMART տարբերակ)

Սկզբունք Բացատրություն Հակաօրինակ
Ճշգրիտ (Precise) Օգտագործել կոնկրետ թվեր, տիպեր, բուլյան պայմաններ, խուսափել «հնարավորինս», «սովորաբար»-ից ❌ «Գաղտնաբառը պետք է բավականաչափ անվտանգ լինի» → ✅ «Գաղտնաբառը առնվազն 8 նիշ, պարունակի մեծատառ, փոքրատառ, թիվ»
Ստուգելի (Verifiable) Յուրաքանչյուր պահանջ կարող է գնահատվել ավտոմատ թեստով կամ մարդկային ստուգմամբ՝ անցում/ձախողում ❌ «Կոդը պետք է էլեգանտ լինի» → ✅ «Ֆունկցիայի ցիկլոմատիկ բարդությունը ≤ 10, առանց կրկնվող կոդի բլոկների»
Աներկիմաստ (Unambiguous) Նույն տերմինը ամբողջ տեքստում ունի միատեսակ իմաստ, անհրաժեշտության դեպքում տալ glossary ❌ «Եթե օգտատերը գոյություն չունի, վերադարձնել սխալ» → ✅ «Օգտատերը գոյություն չունի → վերադարձնել 404 և {code: 'USER_NOT_FOUND'}»
Ամբողջական (Complete) Ընդգրկել երջանիկ ուղին, բոլոր բացառիկ ուղիները, ոչ ֆունկցիոնալ պահանջները ❌ Գրված են միայն հաջող սցենարները → ✅ Ներառել տվյալների բազայի ժամանակի սպառումը, թույլտվության անբավարարությունը և այլն
Ատոմային (Atomic) Մեկ spec-ը նկարագրում է միայն մեկ ինքնուրույն մատակարարվող ֆունկցիոնալ կետ (հեշտացնում է AI-ի մեկանգամյա ավարտը) ❕ Մեկ spec-ով գրել «ամբողջ վճարային համակարգը» → ✅ Բաժանել «վճարման պատվերի ստեղծում», «վերադարձի ստորագրության ստուգում», «գումարի վերադարձ»

3. AI-ի հետ համագործակցության ժամանակ Spec Coding-ի գործընթաց

  1. Մարդը գրում է spec (վերոնշյալ կառուցվածքով, հատկապես թեստային դեպքերը և ֆունկցիայի ստորագրությունները):
  2. Spec-ը մեկ անգամ տրամադրել AI-ին (մի ավելացրեք պահանջներ երկխոսությամբ, խուսափեք vibe-ի աղտոտումից):
  3. AI-ն արտադրում է կոդ + միավոր թեստեր (AI-ն պետք է գեներացնի կատարվող թեստեր՝ ըստ spec-ի թեստային դեպքերի):
  4. Գործարկել թեստերը. Եթե բոլորն անցնում են, անցեք հաջորդ քայլին; եթե ոչ, փոփոխել spec-ը կամ ուղղակիորեն ուղղել կոդը (այս պահին կարելի է մտնել փոքր ցիկլ, բայց գրանցել փոփոխությունները):
  5. Մարդկային վերանայում. Ստուգել, արդյոք ներմուծվել են spec-ից դուրս ֆունկցիաներ (scope creep), ստուգել անվտանգությունը/կատարողականությունը:
  6. Ամրագրում. Spec-ի փաստաթուղթը և վերջնական կոդը միասին ներկայացնել պահոց՝ որպես մշտական փաստաթուղթ:

Հիմնական պրակտիկա. Spec-ի կոդավորում՝ օգտագործել spec.md + test_spec.py, որտեղ թեստային ֆայլն ուղղակիորեն վերցված է spec-ի օրինակներից, այնպես որ հետագայում կոդի փոփոխությունների դեպքում պարզապես գործարկել թեստերը՝ ստուգելու, թե արդյոք spec-ը խախտվել է:

4. Լավ Spec-ի բերած արդյունքները (կարող են ծառայել որպես ընդունման չափանիշներ)

  • Որոշակիություն. Նույն spec-ը տարբեր AI-ներին (կամ տարբեր մարդկանց) տալիս է մոտավորապես նույն իրականացումը:
  • Փորձարկելիություն. Կոդը գրելուց անմիջապես հետո կարելի է ավտոմատ ստուգել 90% ճշտությունը:
  • Պահպանելիություն. Կես տարի անց ցանկացած մարդ, նայելով spec-ին, կարող է հասկանալ սկզբնական դիզայնի մտադրությունը:
  • Ցածր հաղորդակցման ծախսեր. Թիմային քննարկումների ժամանակ քննարկվում է միայն spec-ը, ոչ թե կոդի կոնկրետ տողերը:
  • Անվտանգություն/որակի ներկառուցում. Անվտանգության պահանջները (օրինակ՝ պարամետրացված հարցումներ) և սահմանային պայմանները գրվում են spec-ում, AI-ն պարտավոր է հետևել:

5. Լավ Spec-ի օրինակ (ծայրահեղ պարզեցված)

# Spec: Օգտատիրոջ գրանցման API

## Շրջանակ
- Ստանալ email, password
- Չուղարկել հաստատման նամակ, չստուգել էլ. փոստի իրականությունը

## Պայմանագիր
POST /register
Content-Type: application/json
Request: { "email": string, "password": string }
Response 201: { "user_id": string }
Response 400: { "code": "INVALID_PASSWORD" | "INVALID_EMAIL" }
Response 409: { "code": "EMAIL_ALREADY_EXISTS" }

## Վարքագիծ
- email-ը պետք է համապատասխանի RFC 5322 հիմնական ձևաչափին (a@b.c)
- password: երկարությունը 8-20, պարունակի առնվազն մեկ թիվ և մեկ մեծատառ
- Օգտագործել bcrypt գաղտնագրման համար, աղի արժեքը 10
- Եթե տվյալների բազայում պահելուց առաջ հայտնաբերվի, որ email-ն արդեն գոյություն ունի → 409

## Թեստային դեպքեր (մուտք -> սպասվող կարգավիճակի կոդ+պատասխանի դաշտ)
| Մուտք email | password | Սպասվող |
|------------|----------|------|
| test@x.com | Pass1234  | 201, user_id գոյություն ունի |
| test@x.com | pass      | 400, INVALID_PASSWORD |
| bad        | Pass1234  | 400, INVALID_EMAIL |
| (արդեն գոյություն ունեցող email) | Pass1234 | 409, EMAIL_ALREADY_EXISTS |

## Ոչ ֆունկցիոնալ
- SQL-ները պետք է օգտագործեն պարամետրացված հարցումներ (կանխարգելել ներարկումները)
- Մատյանավորել գրանցման աղբյուրի IP-ն, չգրանցել գաղտնաբառը
- Պատասխանի ժամանակը 95% հարցումների համար < 100ms (առանց bcrypt-ի)

## Կախվածություններ
- Python 3.10+, FastAPI, bcrypt, asyncpg

Լավ Spec Coding = մարդու «դիզայնի որոշումները» վերածել մեքենայի «թեստային դեպքերի + տիպերի ստորագրությունների + վարքագծի սահմանափակումների», այնպես որ AI-ն միայն զբաղվի իրականացման լրացմամբ, իսկ մարդը մշտապես վերահսկի որակն ու ուղղությունը:

评论

暂无已展示的评论。

发表评论（匿名）