AI ช่วยงาน Dev: สั่งให้เป็น ใช้ได้ทันที

บทนี้เป็นทางลัด ไม่ท่องทฤษฎี เอาไปใช้กับงานเขียนโค้ดของคุณได้เลยตั้งแต่วันนี้ เป้าหมายเดียว: สั่ง AI ให้ได้ผลลัพธ์ที่ใช้งานได้จริง โดยรู้ว่าตรงไหนเชื่อได้ ตรงไหนต้องตรวจ

AI ช่วยงาน dev ทำอะไรได้บ้าง

เครื่องมืออย่าง Claude Code ไม่ได้แค่เติมโค้ดให้ (auto-complete) แต่รับงานเป็นก้อน ๆ ได้ ลองมองมันเป็น pair (คู่เขียนโค้ด) ที่สั่งงานเป็นภาษาคนได้:

งาน	ตัวอย่างที่สั่งได้จริง
เขียนโค้ด (write)	"เขียน endpoint NestJS รับ upload ไฟล์ CSV แล้ว validate ด้วย Zod"
วางแผน (plan)	"วางแผนก่อน ยังไม่ต้องเขียน: จะเพิ่ม rate limit ให้ API ยังไง"
ออกแบบโครงสร้าง (design)	"ออกแบบ module structure สำหรับระบบ notification ใน Go"
ปรับปรุงโค้ด (refactor)	"แยกฟังก์ชันนี้ออกเป็นหลายส่วน ลด nesting ให้เหลือไม่เกิน 2 ชั้น"
หาบั๊ก (debug)	"เทสต์นี้ fail อ่าน stack trace นี้แล้วบอกว่าน่าจะพังตรงไหน"
เขียนเทสต์ (test)	"เขียน unit test ครอบ service นี้ให้ครบ edge case"

เทคนิคสั่งงานให้ได้ผลดี (สำคัญสุด)

ผลลัพธ์ห่วยหรือดี 80% มาจาก วิธีสั่ง ไม่ใช่ตัวโมเดล จำเวิร์กโฟลว์ (workflow) 5 ขั้นนี้ให้ขึ้นใจ:

• ให้ context (บริบท) ที่พอ: บอก stack (TS/NestJS/Go), ไฟล์ที่เกี่ยว, ข้อจำกัด และเป้าหมาย ยิ่งชัดยิ่งตรง
• ขอ plan ก่อนลงมือ code: ให้มันร่างแผนก่อน คุณตรวจแผนได้เร็วกว่าตรวจโค้ดทั้งก้อน
• ทำทีละขั้น (step by step): งานใหญ่แตกเป็นชิ้นเล็ก แต่ละชิ้นตรวจง่าย แก้ง่าย
• ให้ตัวอย่าง (example): แปะ pattern โค้ดที่คุณอยากได้ 1 ชิ้น มันจะเลียนสไตล์โปรเจกต์คุณ
• รีวิว/แก้เป็นรอบ (iterate): อย่าคาดหวังถูกครั้งเดียว บอกจุดที่ผิดแล้วให้มันแก้ต่อ

Prompt ดี vs ห่วย สำหรับงาน dev จริง

ความต่างอยู่ที่ context และการขอให้วางแผนก่อน ลองเทียบ:

❌ ห่วย	✅ ดี
"เขียน API auth ให้หน่อย"	"โปรเจกต์ NestJS + Prisma อยู่แล้ว วางแผนก่อน ยังไม่ต้องเขียน: เพิ่ม JWT login endpoint ที่ hash password ด้วย argon2 และ validate ด้วย class-validator"
"โค้ดนี้บั๊ก แก้ให้ที"	"ฟังก์ชันนี้ควรคืน user ที่ active เท่านั้น แต่มันคืนทุก user นี่คือโค้ดและ test ที่ fail: ... ชี้ต้นเหตุก่อน แล้วค่อยเสนอวิธีแก้"
"refactor ให้สวยหน่อย"	"แยกฟังก์ชัน 80 บรรทัดนี้เป็นฟังก์ชันย่อย ชื่อสื่อความหมาย ลด nesting เหลือไม่เกิน 2 ชั้น ห้ามเปลี่ยนพฤติกรรม แล้วบอกว่าแยกอะไรบ้าง"

ตัวอย่าง prompt ที่ดีในรูปแบบสั่ง Claude Code จริง:

# สั่งให้วางแผนก่อน ไม่ให้เขียนโค้ดทันที
วางแผนการเพิ่ม feature "soft delete" ให้ UserService (Go)
บริบท: ใช้ GORM, มี field deleted_at อยู่แล้ว
ข้อกำหนด: query ปกติต้องไม่เห็น record ที่ถูกลบ
อย่าเพิ่งเขียนโค้ด ขอ plan เป็นขั้น ๆ ให้ผมรีวิวก่อน

กับดักที่ต้องระวัง

สองอย่างนี้ทำให้ dev ส่วนใหญ่เจ็บตัว:

1. เชื่อโค้ดที่ได้โดยไม่ตรวจ: AI มั่นใจได้แม้ตอนผิด — เรียกว่า hallucination (การแต่งข้อมูลที่ดูจริงแต่ผิด) ชื่อ method, package, หรือ API ที่มันเรียกอาจไม่มีอยู่จริง
2. งานใหญ่เกินไม่ยอมแตกย่อย: โยนงานก้อนมหึมาให้ครั้งเดียว ผลที่ได้จะกว้างเกินตรวจ พังก็หาต้นเหตุยาก — แตกเป็นขั้นเล็กเสมอ