AI စီးရီး အင်တာဗျူး ၁၆- ကောင်းမွန်သော Spec Coding ဆိုတာ ဘယ်လိုမျိုးလဲ။

Spec Coding (Specification-Driven Programming) ၏ အဓိကအချက်မှာ 'မရှင်းလင်းသော အတွေးအခေါ်များ' ကို 'တိကျသော၊ အတည်ပြုနိုင်သော၊ လုပ်ဆောင်နိုင်သော စာချုပ်' အဖြစ် ပြောင်းလဲရန်ဖြစ်သည်။ ၎င်းသည် စာရွက်စာတမ်းတစ်ခုရေးရုံမျှမက၊ လူနှင့် AI (သို့မဟုတ် လူချင်းကြား) အဓိပ္ပါယ်ကွဲလွဲမှုမရှိသော ဆက်သွယ်ရေးဘာသာစကား တစ်ခုကို တည်ဆောက်ခြင်းဖြစ်သည်။ အောက်တွင် သတ်မှတ်ချက်များ၏ အကြောင်းအရာဖွဲ့စည်းပုံ၊ ရေးသားခြင်းဆိုင်ရာ မူများ၊ AI နှင့် ပူးပေါင်းဆောင်ရွက်ခြင်း လုပ်ငန်းစဉ်၊ အရည်အသွေးစစ်ဆေးခြင်း ဟူသော ရှုထောင့်လေးခုမှ ကောင်းမွန်သော spec ၏ပုံစံကို ဖော်ပြပါမည်။

၁။ သတ်မှတ်ချက်စာရွက်စာတမ်း၏ စံဖွဲ့စည်းပုံ (လုပ်ဆောင်ချက်မော်ဂျူးကို ဥပမာထား)

အခန်း	မဖြစ်မနေပါဝင်ရမည့်အကြောင်းအရာ	ဥပမာ
၁။ ရည်မှန်းချက်နှင့် နယ်ပယ်	ဘာလုပ်ရမည်ကို ဝါကျတစ်ကြောင်းတည်းဖြင့်ဖော်ပြပါ၊ မလုပ်ရမည့်အရာ ကိုရှင်းလင်းစွာဖော်ပြပါ	"အသုံးပြုသူမှတ်ပုံတင်ခြင်း API ကိုအကောင်အထည်ဖော်ရန်၊ အီးမေးလ်အတည်ပြုခြင်းမပါဝင်"
၂။ အဝင်/အထွက် စာချုပ်	ဒေတာဖွဲ့စည်းပုံ၊ အမျိုးအစား၊ မဖြစ်မနေ/ထည့်နိုင်/မထည့်နိုင် အကွက်များ၊ နမူနာတန်ဖိုးများ	`POST /register` တောင်းဆိုချက်ကိုယ်ထည် `{email: string, password: string}`၊ တုံ့ပြန်မှု `201` သို့မဟုတ် `400` အမှားကုဒ်ပါဝင်သည်
၃။ အပြုအမူနှင့် ယုတ္တိဗေဒ	လုပ်ငန်းစည်းမျဉ်းများ၊ နယ်နိမိတ်အခြေအနေများ၊ အခြေအနေပြောင်းလဲမှုများ	"စကားဝှက်အရှည် ၈-၂၀ လုံး၊ အနည်းဆုံးဂဏန်းတစ်လုံးပါရမည်။ အီးမေးလ်ရှိပြီးသားဖြစ်ပါက `409` ပြန်ပေးရမည်"
၄။ အမှားကိုင်တွယ်ခြင်း	ဖြစ်နိုင်သော ခြွင်းချက်အခြေအနေအားလုံးနှင့် သက်ဆိုင်ရာအမှားကုဒ်/မက်ဆေ့ချ်များ	"ဒေတာဘေ့စ်ချိတ်ဆက်မှုပျက်ကွက်ပါက → `503` ပြန်ပေးရမည်၊ stack ကိုမဖော်ပြရ"
၅။ လုပ်ဆောင်ချက်မဟုတ်သော လိုအပ်ချက်များ	စွမ်းဆောင်ရည် (တုံ့ပြန်ချိန် < 200ms)၊ လုံခြုံရေး (parameterized query)၊ မှတ်တမ်း၊ စောင့်ကြည့်နိုင်မှု	"SQL အားလုံးကို ကြိုတင်စုစည်းမှုသုံးရမည်။ `email` ကိုမှတ်တမ်းတင်သော်လည်း `password` ကိုမမှတ်တမ်းတင်ရ"
၆။ စမ်းသပ်မှုကိစ္စများ (အရေးကြီး)	အနည်းဆုံး ပုံမှန်အဝင် ၃ ခု + နယ်နိမိတ်/ခြွင်းချက်အဝင် ၂ ခု၊ မျှော်လင့်ရမည့်အထွက်ကိုပေးပါ	အောက်ပါဇယားကိုကြည့်ပါ
၇။ မှီခိုမှုများနှင့် ကန့်သတ်ချက်များ	မည်သည့်လိုင်ဘရီ၊ ဗားရှင်း၊ ပတ်ဝန်းကျင်ပြောင်းလဲနိုင်သော အရာများကိုသုံးမည်နည်း	"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 သည် ၎င်းတို့အပေါ်အခြေခံ၍ ယူနစ်စမ်းသပ်မှုများကို တိုက်ရိုက်ထုတ်လုပ်နိုင်ပြီး၊ ပြီးစီးပါက အလိုအလျောက်စစ်ဆေးနိုင်သောကြောင့်ဖြစ်သည်။

၂။ Spec ရေးသားခြင်း၏ အဓိကမူများ (SMART ပုံစံကွဲ)

မူ	ရှင်းလင်းချက်	ဆန့်ကျင်ဥပမာ
တိကျမှု (Precise)	တိကျသော ကိန်းဂဏန်းများ၊ အမျိုးအစားများ၊ မှန်/မဟုတ် အခြေအနေများကိုသုံးပါ၊ 'ဖြစ်နိုင်သမျှ'၊ 'များသောအားဖြင့်' ကိုရှောင်ပါ	❌ "စကားဝှက်သည် လုံလောက်စွာလုံခြုံရမည်" → ✅ "စကားဝှက်သည် အနည်းဆုံး ၈ လုံး၊ စာလုံးကြီး၊ စာလုံးသေး၊ ဂဏန်းပါရမည်"
အတည်ပြုနိုင်မှု (Verifiable)	လိုအပ်ချက်တိုင်းကို အလိုအလျောက်စမ်းသပ်ခြင်း သို့မဟုတ် လူကိုယ်တိုင်စစ်ဆေးခြင်းဖြင့် အောင်မြင်/မအောင်မြင် ဆုံးဖြတ်နိုင်ရမည်	❌ "ကုဒ်သည် လှပရမည်" → ✅ "လုပ်ဆောင်ချက်၏ ဆိုင်ကလိုမက်တစ်ရှုပ်ထွေးမှု ≤ ၁၀၊ ထပ်တူကုဒ်တုံးများမရှိရ"
အဓိပ္ပါယ်ကွဲလွဲမှုမရှိခြင်း (Unambiguous)	တူညီသောဝေါဟာရကို စာတစ်လျှောက်လုံးတွင် တသမတ်တည်းသုံးပါ၊ လိုအပ်ပါက glossary ပေးပါ	❌ "အသုံးပြုသူမရှိပါက အမှားပြန်ပေးရမည်" → ✅ "အသုံးပြုသူမရှိပါက `404` နှင့် `{code: 'USER_NOT_FOUND'}` ပြန်ပေးရမည်"
ပြည့်စုံမှု (Complete)	ပျော်ရွှင်သောလမ်းကြောင်း၊ ခြွင်းချက်လမ်းကြောင်းအားလုံး၊ လုပ်ဆောင်ချက်မဟုတ်သော လိုအပ်ချက်များကို ဖုံးအုပ်ပါ	❌ အောင်မြင်သောအခြေအနေကိုသာရေးသည် → ✅ ဒေတာဘေ့စ်အချိန်ကုန်ခြင်း၊ ခွင့်ပြုချက်မလုံလောက်ခြင်း စသည်တို့ပါဝင်သည်
အက်တမ်ပိုင်းခြားခြင်း (Atomic)	spec တစ်ခုသည် လွတ်လပ်စွာပေးပို့နိုင်သော လုပ်ဆောင်ချက်တစ်ခုကိုသာဖော်ပြရမည် (AI က တစ်ကြိမ်တည်းပြီးမြောက်စေရန်)	❌ "ငွေပေးချေမှုစနစ်တစ်ခုလုံး" ကို spec တစ်ခုတည်းဖြင့်ရေးသည် → ✅ "ငွေပေးချေမှုအမိန့်ထုတ်ပေးခြင်း"၊ "ပြန်လည်ခေါ်ဆိုမှုအတည်ပြုခြင်း"၊ "ငွေပြန်အမ်းခြင်း" ဟူ၍ ခွဲပါ

၃။ AI နှင့် ပူးပေါင်းဆောင်ရွက်ရာတွင် Spec Coding လုပ်ငန်းစဉ်

လူက spec ရေးသည် (အထက်ပါဖွဲ့စည်းပုံ၊ အထူးသဖြင့် စမ်းသပ်မှုကိစ္စများနှင့် လုပ်ဆောင်ချက်လက်မှတ်များ)။
spec ကို AI သို့ တစ်ခါတည်းထည့်သွင်းပေးပါ (စကားပြောပုံစံဖြင့် လိုအပ်ချက်များထပ်မံမထည့်ပါနှင့်၊ vibe ညစ်ညမ်းမှုကိုရှောင်ပါ)။
AI မှ ကုဒ်နှင့် ယူနစ်စမ်းသပ်မှုများ ထုတ်ပေးသည် (AI သည် spec ရှိ စမ်းသပ်မှုကိစ္စများအတိုင်း လုပ်ဆောင်နိုင်သော စမ်းသပ်မှုများကို ထုတ်လုပ်ရမည်)။
စမ်းသပ်မှုများကို လုပ်ဆောင်ပါ- အားလုံးအောင်မြင်ပါက နောက်တစ်ဆင့်သို့သွားပါ။ မအောင်မြင်ပါက spec ကိုပြင်ဆင်ပါ သို့မဟုတ် ကုဒ်ကိုတိုက်ရိုက်ပြင်ဆင်ပါ (ဤအချိန်တွင် သံသရာအသေးစားသို့ဝင်နိုင်သော်လည်း ပြောင်းလဲမှုများကို မှတ်တမ်းတင်ရမည်)။
လူကိုယ်တိုင်စစ်ဆေးခြင်း- spec ပြင်ပရှိ လုပ်ဆောင်ချက်များ (scope creep) ပါဝင်လာခြင်းရှိမရှိ၊ လုံခြုံရေး/စွမ်းဆောင်ရည်ကိုစစ်ဆေးပါ။
တည်မြဲစေခြင်း- spec စာရွက်စာတမ်းနှင့် နောက်ဆုံးကုဒ်ကို repository သို့အတူတကွတင်သွင်းပါ၊ အမြဲတမ်းစာရွက်စာတမ်းအဖြစ်သိမ်းဆည်းပါ။

အဓိကကျင့်သုံးမှု: Spec ကိုကုဒ်အဖြစ်ပြောင်းလဲခြင်း – spec.md + test_spec.py ကိုသုံးပါ၊ စမ်းသပ်မှုဖိုင်သည် spec ရှိ နမူနာများမှတိုက်ရိုက်လာသည်။ နောက်ပိုင်းတွင် ကုဒ်ကိုပြုပြင်သည့်အခါ စမ်းသပ်မှုများကိုလုပ်ဆောင်ရုံဖြင့် spec ပျက်စီးခြင်းရှိမရှိကို အတည်ပြုနိုင်သည်။

၄။ ကောင်းမွန်သော Spec ၏အကျိုးသက်ရောက်မှုများ (လက်ခံနိုင်မှုစံနှုန်းများအဖြစ်သုံးနိုင်)

သေချာမှု- တူညီသော spec ကို မတူညီသော AI (သို့မဟုတ် မတူညီသောလူများ) အားပေးပါက ဆင်တူသော အကောင်အထည်ဖော်မှုကိုရရှိသည်။
စမ်းသပ်နိုင်မှု- ကုဒ်ရေးပြီးသည်နှင့် ၉၀% သော မှန်ကန်မှုကို အလိုအလျောက်အတည်ပြုနိုင်သည်။
ထိန်းသိမ်းနိုင်မှု- ခြောက်လအကြာတွင် မည်သူမဆို spec ကိုကြည့်ရှုပြီး မူလဒီဇိုင်းရည်ရွယ်ချက်ကို နားလည်နိုင်သည်။
ဆက်သွယ်ရေးကုန်ကျစရိတ်နည်းပါးခြင်း- အဖွဲ့ဆွေးနွေးသည့်အခါ spec ကိုသာဆွေးနွေးသည်၊ ကုဒ်လိုင်းများကိုမဆွေးနွေးပါ။
လုံခြုံရေး/အရည်အသွေးပါဝင်ခြင်း- လုံခြုံရေးလိုအပ်ချက်များ (parameterized query ကဲ့သို့) နှင့် နယ်နိမိတ်အခြေအနေများကို spec တွင်ရှင်းလင်းစွာဖော်ပြထားသောကြောင့် AI က လိုက်နာရမည်။

၅။ ကောင်းမွန်သော 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: အရှည် ၈-၂၀ လုံး၊ အနည်းဆုံးဂဏန်းတစ်လုံးနှင့် စာလုံးအကြီးတစ်လုံးပါရမည်
- bcrypt ကိုသုံး၍ ကုဒ်ဝှက်သိမ်းဆည်းပါ၊ ဆားကုန်ကျစရိတ် ၁၀
- ဒေတာဘေ့စ်သို့မသိမ်းမီ email ရှိပြီးသားဖြစ်ပါက → 409

## စမ်းသပ်မှုကိစ္စများ (အဝင် -> မျှော်လင့်ရမည့် status code + တုံ့ပြန်မှုအကွက်)
| အဝင် email | password | မျှော်လင့်ချက် |
|------------|----------|------|
| test@x.com | Pass1234  | 201, user_id ရှိရမည် |
| test@x.com | pass      | 400, INVALID_PASSWORD |
| bad        | Pass1234  | 400, INVALID_EMAIL |
| (ရှိပြီးသားအီးမေးလ်) | Pass1234 | 409, EMAIL_ALREADY_EXISTS |

## လုပ်ဆောင်ချက်မဟုတ်သော လိုအပ်ချက်များ
- SQL ကို parameterized query ဖြင့်သုံးရမည် (injection ကာကွယ်ရန်)
- မှတ်တမ်းတွင် မှတ်ပုံတင်သည့် IP ကိုမှတ်တမ်းတင်ပါ၊ password ကိုမမှတ်တမ်းတင်ရ
- တုံ့ပြန်ချိန် 95% တောင်းဆိုချက်များ < 100ms (bcrypt မပါဝင်)

## မှီခိုမှုများ
- Python 3.10+, FastAPI, bcrypt, asyncpg

**ကောင်းမွန်သော Spec Coding = လူ၏ "ဒီဇိုင်းဆုံးဖြတ်ချက်များ" ကို စက်အတွက် "စမ်းသပ်မှုကိစ္စများ + အမျိုးအစားလက်မှတ်များ + အပြုအမူကန့်သတ်ချက်များ" အဖြစ်ရေးသားခြင်းဖြစ်ပြီး AI ကို အကောင်အထည်ဖော်မှုကိုသာ ဖြည့်သွင်းစေကာ လူက အရည်အသွေးနှင့် ဦးတည်ချက်ကို အမြဲထိန်းချုပ်ထားသည်။