Spec-Driven Development (SDD) คืออะไร? สรุป Workflow ใช้ AI เขียนโค้ด

ลองนึกภาพนี้: คุณสั่ง AI agent ว่า "ช่วยทำระบบ export ข้อมูลลูกค้าเป็น CSV ให้หน่อย" AI เขียนโค้ดมาให้เสร็จภายในไม่กี่วินาที รันดูก็ทำงานได้ ไฟล์ CSV ออกมาจริง แต่พอลองเปิดดูละเอียด กลับพบว่ามันไม่ได้ escape comma ในชื่อลูกค้าที่มีเครื่องหมายจุลภาคอยู่ ไม่ได้จำกัดจำนวนแถวต่อครั้ง และ export ข้อมูลบัตรเครดิตที่ไม่ควรโผล่ในไฟล์นี้ด้วย

ปัญหาไม่ได้อยู่ที่ AI เขียนโค้ดไม่เก่ง มันเขียนโค้ดที่รันได้จริงเป๊ะ ปัญหาคือมันเดาสิ่งที่คุณ "ไม่ได้พูด" ผิดไปหมด นี่คือช่องว่างที่ทำให้แนวคิดที่ชื่อว่า Spec-Driven Development หรือ SDD กลายเป็นเรื่องที่ทีมพัฒนาทั่วโลกพูดถึงมากขึ้นเรื่อยๆ ในปี 2026

Spec-Driven Development คืออะไร?

พูดให้ตรงที่สุด Spec-Driven Development คือแนวทางที่ให้ "สเปก" (spec) ซึ่งอธิบายว่าระบบต้องทำอะไร มีเงื่อนไขอะไรบ้าง และอะไรคือเกณฑ์ว่างานเสร็จแล้ว เป็นตัวตั้งต้นก่อนที่จะให้ AI สร้างโค้ดออกมา แล้วให้สเปกนั้นเป็น "source of truth" ตัวจริง ไม่ใช่ตัวโค้ด

ความต่างจากการเขียนโปรแกรมแบบเดิมคือ สเปกใน SDD ไม่ใช่เอกสารที่เขียนทิ้งไว้แล้วไม่มีใครเปิดอ่านอีก มันเป็นเอกสารที่ "มีชีวิต" พอ requirement เปลี่ยน คุณแก้ที่สเปกก่อน แล้วค่อยให้ AI regenerate โค้ดส่วนที่เกี่ยวข้องใหม่ ไม่ใช่ไปไล่แก้โค้ดทีละจุดเอง พูดอีกแบบคือ สเปกกลายเป็นพรอมต์ที่มีโครงสร้าง แทนที่จะเป็นประโยคสั้นๆ ที่พิมพ์ขึ้นมาสดๆ

ทำไมแนวคิดนี้ถึงมาแรงตอนนี้

ต้องย้อนกลับไปที่ปัญหาของ vibe coding ก่อน (ถ้าใครยังไม่ได้อ่านบทความก่อนหน้าเรื่อง Vibe Coding vs Agentic Coding แนะนำให้อ่านคู่กัน) ตัว vibe coding เองใช้ได้ดีมากตอนทำโปรเจกต์เล่นๆ หรือ prototype แต่พอ AI agent เก่งขึ้น ทำงานได้ยาวขึ้น เริ่มถูกเอาไปใช้กับงานจริงมากขึ้น ปัญหาก็เริ่มโผล่ชัดขึ้นเรื่อยๆ

ปัญหาหลักคือ "ผลลัพธ์ตรวจสอบไม่ได้" (unverifiable output) พอไม่มีเกณฑ์ชัดเจนว่าอะไรคือถูกต้อง ก็ไม่มีทางรู้เลยว่าโค้ดที่ agent เขียนมาให้นั้น "ใช่" จริงๆ หรือแค่ "ดูใช่" การรีวิวโค้ดเลยกลายเป็นงานที่ไม่มีวันจบ เพราะต้องมานั่งเดาใจย้อนกลับว่า agent ตีความ requirement ยังไง

SDD แก้ปัญหานี้ตรงจุด เพราะบังคับให้คนที่สั่งงาน AI ต้องคิดและเขียนสิ่งที่ต้องการให้ชัดเจนตั้งแต่ต้น ก่อนที่ AI จะเริ่มลงมือเขียนโค้ดสักบรรทัดเดียว

Workflow จริงหน้าตาเป็นยังไง

เครื่องมืออย่าง GitHub Spec Kit ซึ่งเป็นตัวที่ทำให้แนวคิดนี้แพร่หลาย วาง workflow ไว้เป็น 4 ขั้นตอนหลักๆ

1. Specify

เขียนสเปกอธิบายสิ่งที่ต้องการแบบเจาะจง ไม่ใช่แค่ "ทำระบบ export CSV" แต่ลงรายละเอียดแบบมีเงื่อนไข เช่น "เมื่อผู้ใช้กดปุ่ม export ระบบต้องสร้างไฟล์ CSV ที่ escape เครื่องหมายจุลภาคในทุกฟิลด์ ต้องไม่รวมคอลัมน์ข้อมูลการชำระเงิน และต้อง limit ไม่เกิน 50,000 แถวต่อไฟล์" ยิ่งเขียนแบบมีเงื่อนไข "เมื่อเกิด X ระบบต้องทำ Y" ชัดเจนเท่าไหร่ AI ก็ยิ่งตีความผิดยากขึ้นเท่านั้น

2. Plan

ให้ AI ช่วยแปลงสเปกเป็นแผนทางเทคนิค เช่น จะแตะไฟล์ไหนบ้าง ใช้ library อะไร โครงสร้างข้อมูลเป็นยังไง ขั้นตอนนี้เป็นจุดที่คนยังตรวจทานได้ก่อนโค้ดจริงจะถูกเขียน

3. Tasks

แตกแผนออกเป็นงานย่อยที่ทำได้จริงทีละชิ้น แต่ละงานมีขอบเขตชัดว่าเสร็จแล้วต้องเป็นยังไง

4. Implement

ขั้นตอนนี้ AI agent ถึงจะลงมือเขียนโค้ดจริง โดยอิงจากสเปกและแผนที่ผ่านการตรวจแล้วในขั้นก่อนหน้า ไม่ใช่เดาเอาเอง

จุดสำคัญคือ ทุกขั้นตอนก่อน implement เป็นจุดที่มนุษย์เข้าไปตรวจทานและแก้ไขได้ทัน แทนที่จะไปเจอปัญหาตอนโค้ดเขียนเสร็จแล้วเหมือนที่มักเกิดกับ vibe coding

เครื่องมือที่รองรับตอนนี้

นี่ไม่ใช่เทรนด์ลอยๆ ที่มีแค่โปรเจกต์เล็กๆ พูดถึง ตอนนี้เครื่องมือ AI coding ตัวใหญ่แทบทุกเจ้าต่างมีเวอร์ชันของตัวเองในการรองรับ SDD ไม่ว่าจะเป็น GitHub Spec Kit ที่เป็นโอเพนซอร์สและใช้ได้กับ agent หลายตัว, AWS Kiro ที่ออกแบบมาให้สเปกเป็นส่วนหนึ่งของ interface ตั้งแต่แรก, หรือ Claude Code ที่แพ็กเวิร์กโฟลว์แบบนี้ไว้เป็น skill เรียกใช้ซ้ำได้ นักพัฒนาไม่จำเป็นต้องเลือกแค่เครื่องมือเดียว หลายทีมผสมกันตามงานที่ทำอยู่

SDD ต่างจาก Vibe Coding และ Agentic Coding ยังไง?

หลายคนสับสนว่า SDD เป็นคู่แข่งของ agentic coding หรือเปล่า คำตอบคือไม่ใช่ SDD ไม่ใช่รูปแบบใหม่ที่มาแทน แต่เป็นวินัยที่ใส่เข้าไปในกระบวนการ agentic coding ให้แม่นยำขึ้น

ถ้าจำได้จากบทความก่อนหน้า agentic coding คือการปล่อยให้ AI agent วางแผนและลงมือเองแบบ autonomous โดยมนุษย์คุมที่ขอบเขต คำถามคือ ขอบเขตนั้นมาจากไหน? คำตอบคือมาจากสเปกนั่นเอง พูดง่ายๆ SDD คือสิ่งที่ทำให้ agentic coding มีรั้วที่ชัดเจนขึ้น แทนที่จะบอก agent แค่เป้าหมายกว้างๆ

ส่วน vibe coding กับ SDD อยู่กันคนละขั้วเลย vibe coding คือพิมพ์สั้นๆ แล้วดูผลทันที ไม่มีขั้นตอนตรวจสเปกก่อน ส่วน SDD บังคับให้คิดและเขียนก่อนลงมือ ถ้า vibe coding คือการเดินเข้าครัวแล้วทำอาหารตามใจ SDD ก็คือการเขียนสูตรอาหารที่ระบุปริมาณและขั้นตอนชัดเจนก่อนจะเริ่มหั่นผัก

เหมาะกับงานแบบไหน?

SDD ไม่ใช่สิ่งที่ต้องใช้ทุกครั้งที่เขียนโค้ด ถ้าทำ prototype ส่วนตัวหรือทดลองไอเดียเร็วๆ vibe coding แบบเดิมยังเหมาะกว่าเยอะ เพราะขั้นตอนเขียนสเปกก่อนมันมีต้นทุนเวลา

SDD จะคุ้มค่าที่สุดเมื่อ

• งานนั้นต้องขึ้น production จริง มีผู้ใช้จริงมาเกี่ยวข้อง

• ทีมมีหลายคนทำงานพร้อมกัน ต้องมีจุดอ้างอิงกลางที่ทุกคนเข้าใจตรงกัน

• ต้องมี audit trail หรือเอกสารประกอบตามข้อกำหนดขององค์กร/กฎหมาย

• งานที่ซับซ้อนพอจะแตะหลายไฟล์ หลาย service พร้อมกัน ซึ่งถ้าใช้ prompt สั้นๆ ทีละรอบจะยิ่งเสียเวลากว่าการวางสเปกให้ชัดตั้งแต่แรก

ข้อควรระวัง

ข้อควรระวังที่สำคัญที่สุดคือ อย่าเขียนสเปกละเอียดจนเกินความจำเป็น มีข้อสังเกตจากวงการว่าถ้าพยายามเขียนสเปกให้ครอบคลุมทุกกรณีตั้งแต่ต้น จะกลายเป็นการเสียเวลาพอๆ กับเขียนโค้ดเองแบบดั้งเดิม จุดสมดุลที่ดีคือเขียนสเปกให้ครอบคลุม "เงื่อนไขที่สำคัญจริงๆ" ไม่ใช่พยายามคาดเดาทุก edge case ที่อาจไม่เคยเกิดขึ้นจริง

อีกจุดที่ต้องระวังคือ spec กับ code ต้องไม่หลุดจากกัน (spec-code drift) ถ้าทีมแก้โค้ดตรงๆ โดยไม่อัปเดตสเปก สเปกจะกลายเป็นเอกสารเก่าที่ไม่มีใครเชื่อถือ แล้วก็จะกลับไปสู่ปัญหาเดิมที่ SDD พยายามแก้อยู่ดี

สรุป

Spec-Driven Development คือการกลับมาให้ความสำคัญกับ "สิ่งที่ต้องการจริงๆ" ก่อนที่จะปล่อยให้ AI ลงมือเขียนโค้ด มันไม่ได้มาแทนที่ vibe coding หรือ agentic coding แต่เป็นวินัยที่ทำให้สองแบบนั้นน่าเชื่อถือขึ้นเมื่อต้องใช้กับงานจริง ตัวชี้วัดง่ายๆ ว่าควรใช้ SDD หรือไม่คือ ถ้าตอบไม่ได้ชัดว่า "เสร็จแล้ว" หมายถึงอะไร นั่นคือสัญญาณว่าถึงเวลาต้องเขียนสเปกก่อนแล้ว

ใครอยากตามเรื่องแนวนี้ต่อ แวะไปตามช่องทางของ Superdev Academy ได้ที่

• 🔵 Facebook: Superdev Academy Thailand

• 🎬 YouTube: Superdev Academy Channel

• 📸 Instagram: @superdevacademy

• 🎬 TikTok: @superdevacademy

• 🌐 Website: superdevacademy.com