AI цуврал ярилцлага 16: Сайн spec coding ямар байх ёстой вэ?

Сайн Spec Coding (спецификацид суурилсан програмчлал) нь "тодорхойгүй санаа"-г "нарийн, баталгаажуулах боломжтой, гүйцэтгэх боломжтой гэрээ" болгон хувиргах үндсэн зарчим юм. Энэ нь зөвхөн баримт бичиг бичих биш, харин хүн ба AI (эсвэл хүн ба хүн) хоорондын хоёрдмол утгагүй харилцааны хэл бий болгох явдал юм. Доор би тодорхойлолтын агуулгын бүтэц, бичих зарчим, AI-тай хамтын ажиллагааны урсгал, чанарын баталгаажуулалт гэсэн дөрвөн хэмжээстээр сайн spec-ийн дүр төрхийг харуулах болно.

1. Тодорхойлолтын баримт бичгийн стандарт бүтэц (функциональ модулийн жишээгээр)

Бүлэг	Заавал бөглөх агуулга	Жишээ
1. Зорилго ба хамрах хүрээ	Нэг өгүүлбэрээр юу хийхийг тайлбарлаж, юу хийхгүйг тодорхойлох	"Хэрэглэгчийн бүртгэлийн API хэрэгжүүлэх, имэйл баталгаажуулалтыг оруулахгүй"
2. Оролт/гаралтын гэрээ	Өгөгдлийн бүтэц, төрөл, заавал/сонголт талбарууд, жишээ утга	`POST /register` хүсэлтийн бие `{email: string, password: string}`, хариу `201` эсвэл `400` алдааны кодтой
3. Загвар ба логик	Бизнесийн дүрэм, хил хязгаарын нөхцөл, төлөвийн шилжилт	"Нууц үгийн урт 8-20 тэмдэгт, дор хаяж нэг тоо агуулсан; имэйл аль хэдийн байгаа үед `409` буцаах"
4. Алдаа боловсруулалт	Боломжит бүх онцгой нөхцөл байдал, харгалзах алдааны код/мессеж	"Өгөгдлийн сангийн холболт амжилтгүй → `503` буцаах, стекийг ил гаргахгүй"
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)	Нэг нэр томьёо бүх бичвэрт ижил утгатай байх, шаардлагатай бол нэр томьёоны тайлбар өгөх	❌ "Хэрэглэгч байхгүй бол алдаа буцаах" → ✅ "Хэрэглэгч байхгүй → `404` буцаах, `{code: 'USER_NOT_FOUND'}`"
Бүрэн (Complete)	Амжилтын зам, бүх онцгой зам, функциональ бус шаардлагыг хамрах	❌ Зөвхөн амжилтын сценари бичсэн → ✅ Өгөгдлийн сангийн цаг хугацаа дуусах, зөвшөөрөл хүрэлцэхгүй гэх мэтийг оруулсан
Атомар (Atomic)	Нэг spec нь зөвхөн нэг бие даан хүргэх боломжтой функциональ цэгийг тодорхойлох (AI нэг удаа дуусгахад тохиромжтой)	❌ Нэг spec-ээр "бүх төлбөрийн систем" бичих → ✅ "Төлбөрийн баримт үүсгэх", "Дуудлагын гарын үсэг баталгаажуулах", "Буцаан олголт" гэж хуваах

3. AI-тай хамтран ажиллах Spec Coding урсгал

Хүн spec бичнэ (дээрх бүтэц, ялангуяа тестийн тохиолдлууд болон функцийн гарын үсгийг сайн бичнэ).
Spec-ийг AI-д нэг удаа өгнө (харилцан яриа хэлбэрээр шаардлага нэмэхгүй, vibe бохирдлоос зайлсхийх).
AI код + нэгжийн тест гаргана (AI нь spec-ийн тестийн тохиолдлуудад тулгуурлан гүйцэтгэх боломжтой тест үүсгэх ёстой).
Тестүүдийг ажиллуулна: Хэрэв бүгд амжилттай бол дараагийн алхам руу шилжинэ; хэрэв амжилтгүй бол spec-ийг өөрчлөх эсвэл кодыг шууд засах (энэ үед жижиг тойрогт орж болно, гэхдээ өөрчлөлтийг тэмдэглэх).
Хүний хяналт: Spec-ээс гадуур функц нэмсэн эсэхийг шалгах (scope creep), аюулгүй байдал/гүйцэтгэлийг шалгах.
Батлах: 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 |
| (аль хэдийн байгаа имэйл) | Pass1234 | 409, EMAIL_ALREADY_EXISTS |

## Функциональ бус
- SQL нь параметржүүлсэн асуулга ашиглах ёстой (инъекцээс хамгаалах)
- Логт бүртгэлийн эх үүсвэрийн IP-г бичих, нууц үгийг бичихгүй
- Хариу өгөх хугацаа 95% хүсэлт < 100ms (bcrypt-г оруулалгүй)

## Хамаарал
- Python 3.10+, FastAPI, bcrypt, asyncpg

Сайн Spec Coding = хүний "дизайны шийдвэр"-ийг машины "тестийн тохиолдол + төрлийн гарын үсэг + зан төлөвийн хязгаарлалт" болгон хувиргах бөгөөд AI зөвхөн хэрэгжилтийг дүүргэх үүрэгтэй, харин хүн чанар, чиглэлийг үргэлж хянадаг.