ຊຸດສຳພາດ AI 16: Spec Coding ທີ່ດີຄວນເປັນແນວໃດ?

Spec Coding (ການຂຽນລະຫັດຕາມສະເປັກ) ທີ່ດີ, ຫຼັກການຄືການປ່ຽນ "ຄວາມຄິດທີ່ບໍ່ຊັດເຈນ" ໃຫ້ກາຍເປັນ "ສັນຍາທີ່ຊັດເຈນ, ກວດສອບໄດ້, ແລະ ປະຕິບັດໄດ້". ມັນບໍ່ພຽງແຕ່ຂຽນເອກະສານ, ແຕ່ລະບົບການສື່ສານທີ່ບໍ່ມີຄວາມກຳກວມລະຫວ່າງຄົນ ແລະ AI (ຫຼືລະຫວ່າງຄົນກັບຄົນ). ຂ້າງລຸ່ມນີ້ຂ້ອຍຈະສະເໜີຮູບແບບຂອງ spec ທີ່ດີຈາກ 4 ມຸມມອງຄື: ໂຄງສ້າງເນື້ອໃນຂອງ spec, ຫຼັກການຂຽນ, ຂະບວນການຮ່ວມງານກັບ AI, ການກວດສອບຄຸນນະພາບ.

1. ໂຄງສ້າງມາດຕະຖານຂອງເອກະສານ spec (ຍົກຕົວຢ່າງໂມດູນຟັງຊັນ)

ບົດ	ເນື້ອໃນທີ່ຕ້ອງມີ	ຕົວຢ່າງ
1. ເປົ້າໝາຍ ແລະ ຂອບເຂດ	ອະທິບາຍໃນປະໂຫຍກດຽວວ່າເຮັດຫຍັງ, ກຳນົດວ່າ ບໍ່ເຮັດຫຍັງ	“ປະຕິບັດ API ລົງທະບຽນຜູ້ໃຊ້, ບໍ່ລວມການຢືນຢັນອີເມວ”
2. ສັນຍາຮັບ/ສົ່ງ	ໂຄງສ້າງຂໍ້ມູນ, ຊະນິດ, ຊ່ອງທີ່ຕ້ອງມີ/ບໍ່ຕ້ອງມີ, ຕົວຢ່າງຄ່າ	`POST /register` ຮ່າງກາຍຮ້ອງຂໍ `{email: string, password: string}`, ຕອບສະໜອງ `201` ຫຼື `400` ພ້ອມລະຫັດຂໍ້ຜິດພາດ
3. ພຶດຕິກຳ ແລະ ເຫດຜົນ	ກົດລະບຽບທຸລະກິດ, ເງື່ອນໄຂຂອບ, ການປ່ຽນສະຖານະ	“ຄວາມຍາວລະຫັດຜ່ານ 8-20 ຕົວ, ຢ່າງໜ້ອຍມີຕົວເລກ 1 ຕົວ; ຖ້າອີເມວມີຢູ່ແລ້ວໃຫ້ສົ່ງຄືນ `409`”
4. ການຈັດການຂໍ້ຜິດພາດ	ສະຖານະການຍົກເວັ້ນທີ່ເປັນໄປໄດ້ທັງໝົດ ແລະ ລະຫັດຂໍ້ຜິດພາດ/ຂໍ້ຄວາມທີ່ສອດຄ້ອງ	“ການເຊື່ອມຕໍ່ຖານຂໍ້ມູນລົ້ມເຫຼວ → ສົ່ງຄືນ `503`, ບໍ່ສະແດງ stack trace”
5. ຄວາມຕ້ອງການທີ່ບໍ່ແມ່ນຟັງຊັນ	ປະສິດທິພາບ (ເວລາຕອບສະໜອງ < 200ms), ຄວາມປອດໄພ (parameterized query), ບັນທຶກ, ຄວາມສາມາດໃນການສັງເກດ	“SQL ທັງໝົດຕ້ອງໃຊ້ precompiled; ບັນທຶກ `email` ແຕ່ບໍ່ບັນທຶກ `password`”
6. ກໍລະນີທົດສອບ (ສຳຄັນ)	ຢ່າງໜ້ອຍ 3 ການປ້ອນຂໍ້ມູນປົກກະຕິ + 2 ການປ້ອນຂໍ້ມູນຂອບ/ຍົກເວັ້ນ, ໃຫ້ຜົນໄດ້ຮັບທີ່ຄາດຫວັງ	ເບິ່ງຕາຕະລາງລຸ່ມນີ້
7. ການອາໄສ ແລະ ຂໍ້ຈຳກັດ	ໃຊ້ library ອັນໃດ, ເວີຊັນ, ຕົວແປສະພາບແວດລ້ອມ	“Python 3.10+, FastAPI, ຕົວແປສະພາບແວດລ້ອມ `DB_URL`”

ຕົວຢ່າງກໍລະນີທົດສອບ (ຝັງໃນ spec)

ສະຖານະການ	ການປ້ອນຂໍ້ມູນ	ຜົນໄດ້ຮັບທີ່ຄາດຫວັງ
ລົງທະບຽນປົກກະຕິ	email: `a@b.com`, pwd: `Pass1234`	`201`, ຄືນ `user_id`
ລະຫັດຜ່ານສັ້ນເກີນໄປ	pwd: `Ab1`	`400`, ລະຫັດຂໍ້ຜິດພາດ `WEAK_PASSWORD`
ອີເມວມີຢູ່ແລ້ວ	ອີເມວດຽວກັນກັບຂ້າງເທິງ	`409`, ລະຫັດຂໍ້ຜິດພາດ `EMAIL_EXISTS`

Spec ທີ່ດີຕ້ອງຂຽນກໍລະນີທົດສອບກ່ອນ ເພາະ AI ສາມາດສ້າງ unit test ໂດຍກົງຈາກພວກມັນ, ແລະ ກວດສອບອັດຕະໂນມັດຫຼັງຈາກເຮັດສຳເລັດ.

2. ຫຼັກການຫຼັກໃນການຂຽນ Spec (ຕົວແປຂອງ SMART)

ຫຼັກການ	ຄຳອະທິບາຍ	ຕົວຢ່າງທີ່ບໍ່ດີ
ຊັດເຈນ (Precise)	ໃຊ້ຕົວເລກສະເພາະ, ຊະນິດ, ເງື່ອນໄຂ Boolean; ຫຼີກລ່ຽງ “ເທົ່າທີ່ເປັນໄປໄດ້”, “ໂດຍທົ່ວໄປ”	❌ “ລະຫັດຜ່ານຕ້ອງປອດໄພພໍ” → ✅ “ລະຫັດຜ່ານຢ່າງໜ້ອຍ 8 ຕົວ, ມີຕົວໃຫຍ່, ຕົວນ້ອຍ, ຕົວເລກ”
ກວດສອບໄດ້ (Verifiable)	ທຸກຂໍ້ກຳນົດສາມາດຕັດສິນວ່າຜ່ານ ຫຼື ລົ້ມເຫຼວດ້ວຍການທົດສອບອັດຕະໂນມັດ ຫຼື ການກວດສອບດ້ວຍມື	❌ “ລະຫັດຕ້ອງສວຍງາມ” → ✅ “ຟັງຊັນມີ cyclomatic complexity ≤ 10, ບໍ່ມີຕັນລະຫັດຊ້ຳ”
ບໍ່ກຳກວມ (Unambiguous)	ຄຳດຽວກັນໃຊ້ຄວາມໝາຍດຽວກັນທົ່ວຂໍ້ຄວາມ; ຖ້າຈຳເປັນໃຫ້ມີ glossary	❌ “ຖ້າຜູ້ໃຊ້ບໍ່ມີ, ສົ່ງຄືນຂໍ້ຜິດພາດ” → ✅ “ຜູ້ໃຊ້ບໍ່ມີ → ສົ່ງຄືນ `404` ພ້ອມ `{code: 'USER_NOT_FOUND'}`”
ສົມບູນ (Complete)	ຄຸມທັງສາຍທີ່ມີຄວາມສຸກ, ທຸກສາຍຂໍ້ຜິດພາດ, ຄວາມຕ້ອງການທີ່ບໍ່ແມ່ນຟັງຊັນ	❌ ຂຽນແຕ່ສະຖານະການສຳເລັດ → ✅ ລວມທັງຖານຂໍ້ມູນ timeout, ສິດບໍ່ພຽງພໍ ແລະ ອື່ນໆ
ເປັນອະຕອມ (Atomic)	ໜຶ່ງ spec ພຽງອະທິບາຍຈຸດຟັງຊັນທີ່ສາມາດສົ່ງມອບແຍກຕ່າງຫາກໄດ້ (ເພື່ອໃຫ້ AI ເຮັດແລ້ວສຳເລັດ)	❌ ໃຊ້ໜຶ່ງ spec ຂຽນ “ລະບົບຊຳລະເງິນທັງໝົດ” → ✅ ແຍກເປັນ “ສ້າງໃບຊຳລະ”, “ກວດສອບລາຍເຊັນ callback”, “ຄືນເງິນ”

3. ຂະບວນການ Spec Coding ເມື່ອຮ່ວມງານກັບ AI

ຄົນຂຽນ spec (ໂຄງສ້າງຂ້າງເທິງ, ໂດຍສະເພາະຂຽນກໍລະນີທົດສອບ ແລະ ລາຍເຊັນຟັງຊັນ).
ປ້ອນ spec ທັງໝົດໃຫ້ AI (ບໍ່ແມ່ນການສົນທະນາເພີ່ມຄວາມຕ້ອງການ, ຫຼີກລ່ຽງ vibe ປົນ).
AI ສົ່ງອອກລະຫັດ + unit test (AI ຕ້ອງສ້າງ test ທີ່ປະຕິບັດໄດ້ຕາມກໍລະນີທົດສອບໃນ spec).
ດຳເນີນການ test: ຖ້າຜ່ານທັງໝົດ, ກ້າວໄປຂັ້ນຕອນຕໍ່ໄປ; ຖ້າບໍ່ຜ່ານ, ແກ້ໄຂ spec ຫຼື ແກ້ໄຂລະຫັດໂດຍກົງ (ຕອນນີ້ສາມາດເຂົ້າສູ່ວົງຈອນນ້ອຍໄດ້, ແຕ່ຕ້ອງບັນທຶກການປ່ຽນແປງ).
ກວດສອບໂດຍມະນຸດ: ກວດສອບວ່າມີຟັງຊັນນອກ spec ເຂົ້າມາບໍ່ (scope creep), ກວດສອບຄວາມປອດໄພ/ປະສິດທິພາບ.
ເຮັດໃຫ້ຖາວອນ: ສົ່ງເອກະສານ spec ແລະ ລະຫັດສຸດທ້າຍຮ່ວມກັນເຂົ້າ repository, ເປັນເອກະສານຖາວອນ.

ການປະຕິບັດທີ່ສຳຄັນ: Spec ກາຍເປັນລະຫັດ — ໃຊ້ spec.md + test_spec.py, ໂດຍໄຟລ໌ test ມາຈາກຕົວຢ່າງໃນ spec, ດັ່ງນັ້ນເມື່ອແກ້ໄຂລະຫັດພາຍຫຼັງ ພຽງແຕ່ດຳເນີນການ test ກໍ່ສາມາດກວດສອບວ່າ spec ຖືກທຳລາຍຫຼືບໍ່.

4. ຜົນກະທົບຂອງ Spec ທີ່ດີ (ສາມາດໃຊ້ເປັນເກນຮັບຮອງ)

ຄວາມແນ່ນອນ: spec ດຽວກັນໃຫ້ກັບ AI ຕ່າງກັນ (ຫຼືຄົນຕ່າງກັນ) ສ້າງຜົນໄດ້ຮັບທີ່ໃກ້ຄຽງກັນ.
ການທົດສອບໄດ້: ທັນທີທີ່ຂຽນລະຫັດສຳເລັດ ກໍ່ສາມາດກວດສອບຄວາມຖືກຕ້ອງ 90% ໂດຍອັດຕະໂນມັດ.
ການບຳລຸງຮັກສາໄດ້: ຫຼັງ 6 ເດືອນ ຜູ້ໃດກໍ່ສາມາດອ່ານ spec ແລະ ເຂົ້າໃຈເຈດຕະນາການອອກແບບເດີມ.
ຕົ້ນທຶນການສື່ສານຕ່ຳ: ໃນທີມງານເວົ້າລົມກັນສະເພາະ spec, ບໍ່ແມ່ນແຖວລະຫັດສະເພາະ.
ຄວາມປອດໄພ/ຄຸນນະພາບຖືກສ້າງໃນ: ຂໍ້ກຳນົດດ້ານຄວາມປອດໄພ (ເຊັ່ນ parameterized query) ແລະ ເງື່ອນໄຂຂອບຖືກຂຽນໄວ້ໃນ 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, ຢ່າງໜ້ອຍມີຕົວເລກ 1 ຕົວ ແລະ ຕົວໃຫຍ່ 1 ຕົວ
- ໃຊ້ 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 ຕ້ອງໃຊ້ parameterized query (ປ້ອງກັນ injection)
- ບັນທຶກ IP ຕົ້ນກຳເນີດການລົງທະບຽນ, ບໍ່ບັນທຶກ password
- ເວລາຕອບສະໜອງ 95% ຄຳຮ້ອງຂໍ < 100ms (ບໍ່ລວມ bcrypt)

## ການອາໄສ
- Python 3.10+, FastAPI, bcrypt, asyncpg

Spec Coding ທີ່ດີ = ການຂຽນ "ການຕັດສິນໃຈອອກແບບຂອງຄົນ" ໃຫ້ກາຍເປັນ "ກໍລະນີທົດສອບ + ລາຍເຊັນຊະນິດ + ຂໍ້ຈຳກັດພຶດຕິກຳ" ຂອງເຄື່ອງ, ເຮັດໃຫ້ AI ພຽງແຕ່ຮັບຜິດຊອບການຕື່ມການປະຕິບັດ, ແລະ ຄົນຍັງຄວບຄຸມຄຸນນະພາບ ແລະ ທິດທາງຢູ່ສະເໝີ.